Une approche progressiste
Le développement agile, aussi appelé “développement adaptatif”, est 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.
Principes fondamentaux
Les principes et les fondements du développement agile sont:
- 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.
Plusieurs méthodes
Le développement agile vise avant tout l’efficacité et l’adaptation, l’objectif étant comme toujours de répondre aux demandes tout en respectant les délais et les coûts. Afin de mettre en action ces principes, plusieurs méthodes de développement agile ont été synthétisées. Les plus connues sont:
- 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 plusieurs 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.
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.
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
Expertise OperMIX
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. Laissez OperMIX vous aider à faire un choix “agile” le jour où vous déciderez peut-être d’adopter l’une d’entre elles.

