Methodes Agiles

Pragmatisme & Réactivité au royaume du développement informatique

Les méthodes agiles apportent une nouvelle conduite de projet dans le domaine du développement de logiciels. L'objectif est d'obtenir une meilleure réactivité et une beaucoup plus grande souplesse dans un cadre hautement qualitatif. De manière générale, elle sont beaucoup plus pragmatiques que les méthodes traditionnelles et sont customer centric : leur seul objectif est d'assurer la satisfaction continue du client.

Enseignements

La baseline des méthodes agile est "We value individuals and interactions over processes and tools". Globalement, les principaux enseignements que je tire de ces méthodes sont les suivantes : 

• Le client doit être au coeur du projet. Il doit manipuler les livrables régulièrement et doit vraiment être au coeur de la conception continue de l'objectif. Ceci est très engageant et certains experts de l'agilité imposent qu'une ressource client soit complément intégrée à l'équipe projet (à défaut, il faut un contact très privilégié entre un membre de l'équipe de développement et un membre du fonctionnel). Ainsi, le développeur doit être au contact direct des utilisateurs et observer leurs comportements. Ces contacts peuvent éviter des eccueils évidents en confrontant directement ces deux mondes. Les communications verticales et hiérarchiques doivent être ainsi modifiées pour bénéficier d'échanges très précis et réactifs.
• Etre MonoTâche : la plupart de nos entreprises et systèmes sont multi-tâches, mais le développeur doit demeurer mono-tâche en ordonnancant de manière concertée ces actions. Ceci permet un meilleur versionning du code source de l'application et de manière générale une meilleure efficacité et gestion du développement.
• Le pragmatisme est de rigueur : aucun outil ou méthodologie ne peut être uniquement théorique, ils doivent coller de manière très étroite à un opérationnel étudié. Les outils peuvent apporter une réelle aide mais un simple jeu de Post-it peut parfois jouer exactement le même rôle. Le réflexe de l'ingénieur est bien souvent de trouver la solution avant de cerner le besoin : la démarche inverse est bien souvent plus efficace.
• La simplicité doit demeurer le maître mot. Les concepts de KISS (Keep It Short and Simple) et de DRY (Don't Repeat Yourself) doivent être en permanence appliqués : toujours aller à l'essentiel sans complexifier pour la beauté de l'art et réutiliser les maximum d'éléments existants. 
• La collaboration est omniprésente dans les méthodes agiles, que ce soit entre le client et l'équipe de développement mais également au sein de l'équipe. Il est important que l'ensemble des acteurs aient intégrés ces valeurs pour permettre un échange efficace et non bridé. 
  
• Le changement perpétuel est un élément omniprésent dans les équipes travaillant en agilité. Il faut donc que les collaborateurs soient capables de suivre ce changement. Il s'agit d'insufler une dynamique d'équipe qui permettent de suivre ce rythme.
  
• Le test est la pierre angulaire des méthodes agiles dans le développement informatique. Les développements doivent inclure en permanence et en priorité cette dimension. On parle donc de Test Driven Development. Une bonne couverture de test permet
• de pouvoir opérer des changements radicaux dans le développement (les tests permettant une analyse d'impact fiable)
• d'avoir confiance dans la fiabilité du code en mettant en place des indicateurs et des procédures précis sur la qualité de la réalisation
• de ne plus craindre les mises en production (qui, au demeurant, sont d'ailleurs très régulières dans ce contexte)

Les différentes méthodologies préconisent l'utilisation de cycles d'itération très courts (15 jours maximum). 

Pour ou Contre ?

Pourquoi utiliser les méthodologies agiles et les développement en cycles incrémentaux (itérations courtes) ? En voici quelques avantages : 

• Livrer à temps et atteindre rapidement des quick wins:  le schéma ci-dessus montre bien qu'après quelques itérations permettant de réaliser un socle de base, les retours sur investissement sont rapides et observables.
• Relever les défis du renouvellement fréquent, très courants dans les projets web par exemple. Ainsi, on sera mieux à même 
• Fiabiliser les ressources en permettant une duplication de la connaissance (Collective Ownership)
• Permet de gérer à la fois les demandes régulières et urgentes
• Obtenir une meilleure visibilité continue sur l'objectif final
• Atteindre une meilleure adaptabilité et une meilleure gestion du changement
• La dette technique augmente au fil des projets. Le but de l'agilité est de garantir la qualité constante d'un projet.
  

Cependant, l'adoption de cette organisation rencontre en générale certaines réticences : 

• L'engagement du prestataire semble faible car il ne s'engage pas sur un objectif final. Cependant, les projets ont, en général, tous besoin d'une adaptabilité des objectifs. Même sur un projet simple et très périmétré, on ne maîtrise jamais tous les facteurs (intégration, dépendance extérieure). L'intérêt donc des méthodes agiles est qu'on pourra ajuster l'objectif au fur et à mesure. Ainsi, la règle des 80/20 peut être contrecarrée : peut être qu'avec 85% ou 90% des objectifs initiaux, la réalisation semblera suffisante et nous économiserons une bonne partie des investissements.
• L'engagement du client semble très fort. Trop lié à son opérationnel, il lui semble parfois difficile de pouvoir s'impliquer autant. Cependant, si le projet est important, je pense que le jeu en vaut la chandelle. Cela fait d'ailleurs partie du pragmatisme de certaines déclinaisons des méthodes agiles : "si ta tâche n'est pas importante, elle n'est donc pas indispensable donc ne la fait pas"
• La contractualisation est difficile car l'objectif est flou. En effet, aucun objectif précis n'est visé. Cependant, quand on voit que bon nombre de projets dépassent leur budget initial, ces méthodes permettent de mieux piloter l'évolution et d'anticiper les débordements et ainsi d'assurer une meilleure maitrise continue de l'équilibre budget/résultat
• Les méthodes agiles font parfois peur car elles bousculent les protocoles et les voies hiérarchiques. Ainsi, elle imposent que la communication transversale soit facilitée. Cependant, ces nouvelles organisations permettent une meilleur compréhension du besoin de l'utilisateur et donc un produit final répondant mieux aux objectifs.
• De la même manière, ces méthodologies révolutionnent certaines de nos habitudes et manières de travailler et elles provoquent souvent une réticence naturelle au changement. Une technique telle que la programmation en binôme (pair programming) est dérangeante à bien des égards (perte de contrôle, impression de perte de productivité, diffusion de la connaissance...) mais leurs pratiquants prouvent que sa pertinence est complète.

& Après ?

 

Souvent cantonnées au monde du développement informatique, les méthodologies Agile sont davantage une organisation de travail et peuvent donc être facilement appliquées à un domaine plus large. Il s'agit de méthodes impactantes au niveau des organisations et des hommes. Leurs mises en place doivent être sponsorisées par des poids lourds hiérarchiques pour obtenir leur adoption généralisée. 

Enfin, ces méthodes sont selon moi plus des règles de conduites (comme le code des pirates :-) ) et il appartient à chaque organisation de fixer leur propre application, avec pragmatisme et objectivité. Il y a dans le monde de l'agilité (comme ailleurs) des puristes de méthodologies. Je suis d'un avis différent et j'irais même jusqu'à dire que la notion même d'agilité va contre cette rigidité où les équipes doivent s'adapter en permanence à des contextes particuliers.

Il y a plusieurs déclinaisons des méthodes agiles. Voici 4 d'entre elles que je trouve intéressantes (les branches sont cliquables) : 

 

  

 

Il y a des sources d'inspiration dans chacune de ces méthodes, à vous de vous en faire une idée...