Extreme Programming

Cette méthodologie, considérée par certains comme un phénomène de mode de par la profusion de littérature qu’elle a déjà engendrée, férocement défendue par ses adeptes aux quatre coins du globe, est devenue particulièrement populaire dans le milieu des développeurs qu’elle séduit en tout premier lieu. Elle se caractérise par quatre valeurs et douze pratiques que nous allons détailler ci-après sous l’angle architectural.

L’une des raisons de son succès est qu’elle produit de la valeur quasi immédiatement pour le client en implémentant rapidement ses scénarios utilisateur (user story). Ce chapitre décrit les grandes lignes de la méthode et s’attache surtout aux aspects architecturaux qu’elle impose.

1. Quatre valeurs

La méthode XP repose sur les quatre valeurs fondamentales suivantes : la communication (une place de choix est faite à l’oralité, considérée comme moins sujette aux incompréhensions que l’écrit), la simplicité (toujours faire la chose la plus simple qui puisse marcher), le feedback (impliquer le client très tôt, prendre en compte ses impressions ainsi que le recul que peuvent nous donner nos collègues) et le courage (passer par les initiatives).

2. Douze pratiques

a. Développement piloté par les tests (TDD)

On parlera aussi de « test-first » design. Dès lors qu’on commence par développer les tests, on s’assure qu’ils échouent et seulement enfin on commence à coder pour faire passer l’ensemble des tests. Il y a deux types de tests : les tests unitaires implémentés par les développeurs qui testent le code et le design et les tests d’acceptance qui couvrent les scénarios et qui sont, dans la mesure du possible, écrits par le client. Le regain d’intérêt porté au test unitaire est en partie dû à cette pratique, particulière à XP. C’est un bienfait dont toutes les autres méthodologies peuvent profiter.

C’est la pratique la plus utile que cette méthodologie ait mise en place, elle libère la créativité du développeur...

Scrum

Scrum dérive de la théorie des systèmes adaptatifs et fut influencé par les pratiques de l’industrie japonaise, en particulier par les principes de développement LEAN ainsi que par les stratégies de gestion des connaissances de Takeuchi et Nonaka.

Scrum n’est pas à proprement parler une méthodologie ou un processus, il s’agit plutôt d’une compression des meilleures pratiques issues de 50 ans de développement logiciel. On parlera d’un cadre de travail (Framework) simple qui implémente les bonnes pratiques du Manifeste Agile. De plus, l’une des singularités de Scrum est qu’il n’est pas applicable qu’au seul domaine informatique, mais à bien d’autres comme l’organisation d’un mariage, la gestion d’un projet de paysage…

C’est une méthode agile visant à produire de meilleurs logiciels plus rapidement et plus agréablement, aujourd’hui adoptée sur des projets notables comme par exemple Google AdWords qui est entièrement issu de cette méthodologie.

1. Concept

Scrum est pensé pour ajouter de l’énergie, de la clarté et de la transparence au projet en termes d’implémentation et de planification. L’usage de cette méthodologie aura pour effets :

De démultiplier la vitesse de développement.
D’aligner les objectifs individuels et ceux de l’organisation.
De créer une culture pilotée par la performance.
De fournir un haut niveau de communication de la performance à tous les niveaux.
D’améliorer la qualité de vie et le développement personnel.

Dans le même esprit que XP, avec Scrum on pense qu’il est inutile voire nuisible de spécifier le produit en amont, d’en faire un bon design préalable, car il est humainement impossible de tout prévoir et qu’une bonne idée survenant dans les dernières étapes du projet serait plus de l’ordre de la menace que du bienfait.

En outre, les processus classiques de type Waterfall ou Spirale se sont avérés source de souffrance morale pour les équipes qui subissent des plannings établis plusieurs mois à l’avance en dépit des aléas du projet.

De plus, Scrum est censé...

Processus Unifié Ouvert (Open UP)

Cette partie survole les grands principes du Processus Unifié Ouvert (Open UP), une instance ouverte du Rational Unified Process (RUP), mais dont il ne garde que les caractéristiques essentielles.

1. Rational Unified Process (RUP)

Avant de parler de la version agile du processus unifié, résumons un peu le processus originel, à savoir le RUP, processus mis au point par la société IBM Rational.

Le Rational Unified Process est une approche du développement logiciel itérative, centrée sur l’architecture et pilotée par les cas d’utilisation.

Itérative car elle procède par petits incréments.
Centrée sur l’architecture dès les premières étapes du projet. Un système fonctionnel est bâti dès les premières itérations de manière à lever les risques techniques au plus tôt.
Pilotée par les cas d’utilisation car toutes les fonctionnalités du système découlent des cas d’utilisation (cf. chapitre Cas d’utilisation). Ceci garantit que seules les fonctionnalités qui offrent de la valeur ajoutée aux utilisateurs seront développées.

2. Open UP

Open UP est un processus de développement minimaliste et autosuffisant (dans le sens où il ne contient que l’essentiel des éléments organisationnels du processus unifié). Aussi, il ne faut pas s’attendre à y trouver des guides détaillés pour la gestion de projet concernant des situations particulières telles que le management des grandes équipes, des aspects contractuels ou des situations critiques. Toutefois, ce processus permet de définir complètement la manière de créer un système.

Open UP est un processus agile - contrairement à RUP - qui met en pratique les points clés du Manifeste Agile. Il cherche donc, lui aussi, à favoriser une bonne communication des équipes pour garantir une compréhension claire et partagée du projet. L’idée directrice est d’encourager l’implication des parties prenantes (clients, utilisateurs…) plutôt que de dissiper trop d’énergie en livrables et formalismes improductifs.

Open UP propose une approche...

Méthodes agiles