Les fondements du développement agile par Laurent Desmons (ldesmonsmcsd@hotmail.com)

Introduction

Dans mon article précédent, "Mettre en place son environnement de développement .NET", je présentais une démarche pour mettre en oeuvre un atelier logiciel à la disposition du développeur .NET, afin qu'il puisse utiliser au quotidien des outils destinés à faciliter ses développements, le tout dans un esprit volontairement très "XP", ou "eXtreme Programming". 

Cet article propose maintenant de démystifier ce terme en présentant une petite synthèse des fondements du "développement agile".

Qu'est-ce que "le développement agile" ?

Le développement agile, aussi appelé "développement adaptatif", peut être considéré comme "un style de développement logiciel itératif centré sur les personnes et qui met l'accent sur la satisfaction du client à travers l'intégration continue d'un logiciel entièrement fonctionnel". 

Afin de clarifier cette notion somme toute encore un peu vague (mais pleine de bon sens), on peut énoncer les principes et les fondements suivants (voir http://agilemanifesto.org/):

• mettre en oeuvre des individualités et des interactions, plutôt que des procédés et des outils. Cela se manifeste par l'accent mis sur les êtres humains en tant qu'individus et sur l'expertise des équipes de développement, qui communiquent entre elles de façon très serrée et dans un esprit de confiance constant
• produire un logiciel entièrement testé et qui fonctionne, plutôt qu'une documentation claire. On rejoint ici les notions de développement itératif (notion de phases) et d'intégration continue (notion de builds journaliers), en insistant sur la simplicité et la robustesse du code produit (tests systématiques)
• collaborer avec le client, plutôt que négocier un contrat. Le client devient un partenaire à part entière, qui participe au développement dans le sens où il détermine l'objectif à atteindre pour obtenir une réelle plus-value (qui seule justifie les efforts effectués pendant le développement)
• répondre aux modifications, plutôt que suivre un plan. Il est bien évident que personne, pas même le client, ne peut appréhender avec précision l'ensemble des besoins dès le début du projet. Le développement agile vise à atteindre un compromis entre les spécifications initiales présentées aux développeurs (et sur lequel se fonde le planning) et le résultat final qui bien souvent s'en éloigne un peu voire beaucoup, en absorbant les modifications tout au long du cycle de développement. Cela réclame des outils de suivi et une attitude constante de coopération avec le client.

Différentes méthodes

Il s'agit donc avant tout d'efficacité et d'adaptation, l'objectif étant comme toujours de répondre aux demandes tout en respectant les délais et les coûts. On privilégie d'abord les individus et les interactions. Plus facile à dire qu'à faire, et voilà pourquoi des méthodes ont été mises au point afin de mettre en action ces principes. Au cours de cet article je vais tenter de faire la synthèse de quelques unes des méthodes de développement agile les plus connues, puis de fournir une comparaison sur leurs spécificités. 

Je vais donc m'attarder sur les méthodes suivantes :

• Extreme Programming (XP)
• Rational Unified Process (RUP)
• Scrum
• Feature-Driven Development (FDD)

Extreme Programming (XP)

Proposée par Kent Beck, c'est la méthode la plus connue, et la plus en vogue. A vrai dire il s'agit plus d'un ensemble de pratiques à dimension humaine, plutôt qu'une véritable méthode. Il faut bien reconnaître qu'elle a de gros côtés positifs et qu'elle est assez facile à mettre en oeuvre, au prix parfois d'un changement de mentalité et d'une acceptation par l'ensemble des équipes impliquées. Il s'agit ici d'appliquer "à l'extrême" les principes du développement agile, en se focalisant sur les besoins du client, les individualités, le développement itératif et l'intégration continue. Le développeur et ses relations avec le client sont au coeur de XP. Cette méthode convient à des équipes petites voire moyennes, soit jusqu'à une vingtaine de personnes environ. 

Le plus surprenant dans cette méthode est qu'elle peut sembler naturelle, mais qu'elle n'est concrètement pas évidente à appliquer et à maîtriser car elle réclame beaucoup de discipline et de communication (contrairement à la première impression qui peut faire penser à une ébullition de cerveaux individuels). Il s'agit d'aller vite, sans perdre de vue la rigueur du codage et les fonctions finales de l'application. La grande force de XP (et le plus grand risque de le faire échouer) est précisément sa simplicité et le fait qu'on va droit à l'essentiel, selon un rythme qui doit rester constant.

On peut énoncer ainsi les 13 principes fondamentaux de XP :

• Le planning est fait conjointement avec le client de façon à se focaliser uniquement sur les buts principaux à atteindre et différer les objectifs secondaires. Il est nécessaire de procéder par priorités, aussi bien fonctionnelles que techniques (ce qui se rapproche du Risk-Driven Development). Il s'agit donc également d'avoir le courage de discuter avec le client sur certains points de l'application qui peuvent poser problème.
• Le développement est itératif, le logiciel est livré fréquemment : XP découpe le projet en phases, comme dans un projet classique (définition des besoins, construction, déploiement), mais la phase de construction est découpée en multiples itérations qui sont elles-mêmes découpées en phases (spécifications courtes, développement, tests, retour du client). Le fonctionnel de l'application est décrit en brefs scenariis qu'on peut implémenter tout de suite et que le client peut juger très tôt. Les mésententes de compréhension sont alors réduites au maximum.
• Les équipes XP mettent en production un système simple très tôt, et intègrent les modifications très fréquemment, sur un temps de cycle très court. L'objectif est de disposer d'un pilote opérationnel très rapidement et de réduire au maximum les risques dès le début du projet, ainsi que de fournir très régulièrement des versions effectives
• Les équipes XP emploient des métaphores afin de clarifier les fonctionnalités à atteindre
• Un logiciel XP doit être basé sur un design simple qui se focalise sur les besoins actuels du client, ni plus ni moins (on ne monte pas une usine à gaz "au cas où plus tard..."). On va droit à l'essentiel.
• Un logiciel XP est testé et validé à tout moment. Les développeurs écrivent les tests d'abord et codent ensuite (Test-Driven Development)
• Le système est remanié progressivement, tout au long du développement, par petits morceaux. Le logiciel est propre : pas de duplication, une grande communication, simple, mais complet. Le nettoyage doit se faire régulièrement (prévoir des séances pour toute l'équipe).
• Les programmeurs XP travaillent en binôme sur la même machine. Chaque programmeur code à tour de rôle, pendant que l'autre réfléchit à la prochaine fonctionnalité à implémenter. Cela nécessite tout de même une bonne entente en tant qu'individualités. Cela est censé produire un code robuste et de qualité. En pratique ce n'est pas aussi simple ni répandu, car il ne s'agit pas de perdre de temps en discussions interminables entre deux façons de coder une fonction. Souvent, les développeurs ne s'associent donc en binômes que lors des séances de refactoring, ou quand ils ont à résoudre un problème difficile à plusieurs.
• Tout le code appartient à tous les programmeurs, la responsabilité est collective. Quand il faut changer quelque chose, on peut le faire tout de suite, ce qui permet de travailler à plein régime et de bien appréhender les problèmes de turn-over
• L'intégration du logiciel est continue, avec plusieurs builds par jour. On n'attaque pas tout en bloc de front, mais on sépare la tâche en petits modules intégrés et testés progressivement. Le système est donc plus stable et opérationnel rapidement. Cela impose de disposer d'outils que chaque développeur maîtrise pleinement.
• Les semaines n'ont que 40 heures. Les programmeurs fatigués font plus d'erreurs. 
• Le client est représenté sur place. Les développeurs sont assistés par une personne dédiée, qui est chargée de déterminer les besoins, fixer les priorités, rédiger les cahiers de recette et répondre aux questions des programmeurs
• Standards de codage. Pour que les équipes travaillent effectivement par paires, et pour permettre le partage de l'ensemble du code, il est nécessaire que tous les programmeurs écrivent le code de la même façon, avec le même style, et des règles pour communiquer clairement (en ce sens, les "design patterns" sont vite indispensables)

Rational Unified Process (RUP)

Élaboré par les membres de Rational Software (maintenant IBM) dont Philippe Kruchten, RUP est une véritable méthode qui couvre l'ensemble du cycle de développement. Son étendue, son coût et sa lourdeur apparente la réserve pour les projets de moyenne voire de grande importance. Bien que ses auteurs affirment qu'il est possible d'adapter RUP pour de petits projets, la tâche semble ardue, car RUP propose un processus complet dont la rigueur et le formalisme (documentation exhaustive) peuvent rebuter. Une formation préalable est indispensable si on ne veut pas se perdre dans les centaines de pages HTML qui forment le processus et les nombreux "artefacts" (documents et logiciels) que RUP propose de produire. 

RUP a un coût d'investissement très important et, en un sens, il peut être considéré comme pas tellement "agile" car trop rigide. Il s'agit ici cependant d'un véritable outil complet de gestion de projets. RUP fournit un cadre générique qu'il faut adapter à chaque application. Il est centré sur une architecture incrémentale et itérative, le développement s'articule autour du modèle objet et des cas d'utilisation, et favorise UML en tant que langage de modélisation. RUP affecte à chacun un rôle très clair. RUP est formé d'un découpage en 4 phases : inception (objectifs et cas d'utilisation), élaboration (architecture logicielle), construction (développement), transition (déploiement). Chaque phase se découpe en itérations. Chaque itération dure entre deux semaines et six mois et fournit une version de l'application. 

Moins "extrémiste" que XP, RUP donne en même temps une apparence de plus grande rigueur, ce qui peut rassurer certains clients habitués aux documentations exhaustives.

Les principales pratiques liées à RUP sont :

• un développement itératif et piloté par les risques (les cas d'utilisation sont pris en compte en fonction de priorités)
• les besoins du client sont suivis et formalisés précisément
• l'architecture est fondée sur des composants objets
• les modèles sont visuels, et formalisés avec UML
• la qualité du logiciel est vérifiée régulièrement, par des tests systématiques et l'intégration continue
• les changements sont contrôlés avec rigueur

Scrum 

Le terme "Scrum" (qui provient d'une stratégie de rugby) se rapproche plus d'une gestion de ressources humaines plutôt que d'une réelle méthode de développement. Il s'agit ici de ne pas oublier le côté humain du développement. Cette approche a été mise au point par Ken Schwaber.

Théoriquement, Scrum peut se marier d'ailleurs très bien avec XP, en fournissant aux développeurs "agiles" un cadre de prise en compte du facteur humain. On peut alors envisager des projets plus importants qu'avec le simple XP. Comme RUP, il s'agit d'un processus incrémental, mais bien moins formalisé : Scrum ne propose aucune pratique de développement, juste des pratiques de management. Il s'agit en fait d'un cadre de gestion de projets bien adapté aux méthodes de développement agile, comme XP.

Les principales caractéristiques de Scrum sont :

• identifier les changements très tôt
• donner toute confiance aux développeurs et les laisser faire leur travail
• faire des itérations de 30 jours ("sprints") pour laisser le temps de coder. Chaque itération a un objectif bien précis ("backlog") et fournit une nouvelle fonctionnalité testée.
• faire des réunions tous les jours pour encadrer les équipes et recaler les objectifs

Feature-Driven Development (FDD)

Cette méthode, élaborée par Jeff de Luca et Peter Code, est plus formalisée que XP. On peut presque considérer que FDD est une application très "light" de RUP, car sa particularité est de ne se concentrer que sur les phases de design et de réalisation, ce qui consiste à :

• élaborer le modèle objet du domaine avec des diagrammes UML

• découvrir la liste des fonctions de l'application

• implémenter chacune de ces fonctions, l'une après l'autre. Pour cela on forme de petites équipes responsables d'une ou deux fonctions.

• l'implémentation est découpée en itérations (de 1 à 3 semaines environ). Chaque itération consiste à implémenter une fonction que le client peut tester, depuis l'analyse jusqu'à la mise en service, et les builds sont réguliers

• le projet est suivi de près et l'accent est mis sur le résultat obtenu, la qualité étant primordiale dans cette approche

• des outils permettent de suivre précisément le déroulement du projet

• les rôles de chaque intervenant sont bien clarifiés

Comparaison entre les méthodes 

Le tableau suivant (inspiré de "Agile Software Development Methods" par Pekka Abrahamsonn et Outi Salo, VTT Publications 478) peut servir à comparer sommairement les méthodes présentées dans cet article 

Méthode

Points clés

Désavantages

  XP

  Développement guidé par les besoins du client. Equipes réduites, centrées sur
  les développeurs. Binômes. Builds journaliers. Amélioration constante,
adaptativité aux modifications.

  On se focalise sur l'aspect individuel du développement, au détriment d'une vue globale
  et des pratiques de management ou de formalisation.
  On risque ainsi de manquer de contrôle et de structuration en laissant les développeurs
  trop libres de dériver par rapport aux fonctions de l'application.

Conclusion 

Le développement agile repose sur des principes simples et naturels. Il est soutenu par des méthodes qui partagent beaucoup de points communs :

• la satisfaction et l'implication du client
• l'accent mis sur les capacités individuelles et l'expertise
• la collaboration, la confiance et la communication
• le développement itératif, simple et robuste
• l'intégration continue
• l'adaptation aux changements

Les méthodes présentées ici se distinguent toutefois par leur portée et leur domaine d'application, ainsi que par l'environnement de travail dans lequel elles peuvent être mises en oeuvre : cela devrait vous aider à faire un choix "agile" le jour où vous déciderez peut-être d'adopter l'une d'entre elles...

Auteur : Laurent Desmons 

Copyright © 2004