Je me retrouve toujours dans des discussions à propos des pratiques de l'eXtreme Programming et de la façon dont elles peuvent être adoptées dans Scrum et dans les autres méthodologies Agile. Toutefois, je remarque que la plupart des gens ne savent pas que c'est une méthodologie en elle-même. Des gens comme Ron Jefferies, Kent Beck et Ward Cunningham ont été les pionniers de cette méthodologie. Le premier projet eXtreme Programming remonte au 6 mars 1996. Il a déjà été démontré qu'elle fonctionne très bien dans de nombreuses entreprises et industries de différentes tailles autour du monde. EXtreme Programming fonctionne car elle souligne la satisfaction client. Au lieu de livrer tout ce que vous pourriez potentiellement vouloir à une certaine date dans le futur, ce processus livre le logiciel dont vous avez besoin comme vous en avez besoin. XP permet à vos développeurs de répondre avec assurance aux changements d'exigences du client, même tard dans le cycle de vie du projet.
Je vais d'abord préparer le terrain pour les valeurs, les rôles, les principes de planification et de gestion, et de conception et développement. Ensuite, je vous parlerai de mon expérience personnelle du point de vue d'un Coach Agile implémentant eXtreme Programming en tant que méthodologie, suivie de mes recommandations et la conclusion.
Valeurs
- Tout le monde fait partie de l'équipe et nous communiquons en face à face quotidiennement. Nous travaillerons ensemble sur tout, des spécifications au code. Nous créerons ensemble la meilleure solution que nous trouverons à notre problème.
- Simplicité : Nous ferons ce qui est nécessaire et ce qui est demandé, mais rien de plus. Cela maximisera la valeur créée pour les investissements réalisés jusque-là. Nous avancerons par petites étapes simples jusqu'à notre but et atténuerons les échecs à mesure qu'ils arriveront. Nous créerons quelque chose dont nous serons fiers et le maintiendrons sur le long terme à des coûts raisonnables.
- Feedback : Nous prendrons chaque engagement d'itération sérieusement en délivrant un logiciel qui fonctionne. Nous ferons une démonstration de notre logiciel tôt et souvent, et écouterons ensuite attentivement et ferons les changements requis. Nous discuterons du projet et adapterons nos processus autour de lui, pas l'inverse.
- Courage : Nous dirons la vérité à propos de la progression et des estimations. Nous ne documenterons pas d'excuses pour les échecs car nous avons prévu de réussir. Nous n'avons peur de rien car personne ne travaille jamais seul. Nous nous adapterons aux changements quand ils arriveront.
- Respect : Tout le monde montre et ressent le respect qui lui est dû en tant que membre important de l'équipe. Chacun contribue à la valeur, même si c'est seulement avec de l'enthousiasme. Les développeurs respectent l'expertise des clients et réciproquement. Le management respecte notre droit d'accepter la responsabilité et de recevoir l'autorité sur notre propre travail.
Rôles
Vérificateur : circule et demande à chaque Développeur comment il se sent, écoute la réponse, et prend des actions si les choses semblent mal se passer. Les actions comprennent la suggestion d'une session CRC, organiser un rendez-vous avec le Client, demander au Coach ou à un autre Développeur de l'aider.
Client : écrit les User Stories et spécifie les Tests Fonctionnels. Définit les priorités, explique les stories, assiste aux sessions CRC. Il a l'autorité de trancher sur les questions concernant les stories.
Développeur (Extreme Programmer) : estime les stories, définit les Tâches d'Ingénierie, estime le temps que vont prendre les stories et les tâches, implémente les stories et les Tests Unitaires.
Testeur : implémente et exécute les Tests Fonctionnels. Affiche les résultats sur des graphiques, fait en sorte que les gens sachent quand les résultats des tests déclinent. (Note : les Développeurs font leurs propres Tests Unitaires).
Coach : peut planifier des réunions (e.g. Plan d'Itération, Planning d'Engagement), fait en sorte que le processus de la réunion soit suivi, note les résultats de la réunion pour un rapport futur, passe au Vérificateur. Il ne dit pas aux gens ce qu'ils doivent faire (le Client et le Plan d'Itération le font), quand ils doivent finir (Planning d'Engagement), ou ne vérifie pas comment ils s'en sortent (Vérificateur). Il mentore l'équipe !
Certains rôles peuvent être combinés par une même personne. Par exemple, une même personne peut avoir les rôles de Coach et de Vérificateur. Certains rôles ne devraient probablement pas être combinés. Développeur-Vérificateur, Développeur-Testeur, Client-Développeur, Coach-Testeur en sont des exemples. Le Coach ne devra probablement pas être combiné avec autre chose que le Vérificateur.
Planification et Gestion
Planning de livraison : une réunion de prévision de livraison est utilisée pour créer un planning de livraison, qui énonce l'ensemble du projet. Le planning de livraison est ensuite utilisé pour créer les plannings d'itération pour chacune d'entre elles. Planning d'itération : une réunion de prévision d'itération se déroule au début de chaque itération pour produire le planning des tâches de développement de cette itération. La meilleure pratique consiste en des itérations d'une semaine. Les User Stories sont choisies pour cette itération par le client depuis le planning de livraison par ordre de rentabilité. Les tests d'acceptance en échec qui doivent être réparés sont aussi sélectionnés. Le client choisit des user stories dont le total des estimations atteint la vélocité de l'itération précédente.
Chaque itération ressemble essentiellement à l'illustration ci-dessous :
Gestion : le Management doit fournir à l'équipe un open space de travail dédié et définir un rythme durable. L'équipe doit effectuer un stand up pour commencer chaque journée. La Vélocité du Projet est mesurée à la fin de chaque itération et répare les pratiques XP quand elles sont transgressées.
Conception et Développement
L'équipe devra faire de son mieux pour conserver la simplicité, utiliser les métaphores système pour décrire l'implémentation et les CRC cards pour les sessions de conception. Elle crée des solutions pointues pour réduire le risque et n'ajoute pas de fonctionnalité trop tôt. L'équipe réfactore quand et où c'est possible et implémente des stratégies de Développement Guidé par des Tests (TDD), des frameworks de tests automatisés, du pair programming, et de l'intégration et du déploiement continu.
Mon Expérience
Pour un client de la Silicon Valley, nous avons travaillé avec lui pour créer la vision produit et le backlog du programme, priorisé par valeur métier. Ensuite, nous avons joint les différents représentants des équipes de développement agiles pour fournir l'apport initial des user stories. Cela nous a conduit à re-prioriser les epics et les user stories en se basant sur les dépendances, à ajouter des technical stories (e.g. architecture), suivi par la création de la roadmap. Le client et les représentants de l'équipe ont d'abord pu se mettre d'accord sur la diffusion des user stories dans les backlogs respectifs des équipes et sur les étapes initiales de livraison. Nous avons ensuite organisé une réunion de planification de livraison de deux jours durant laquelle chaque équipe a discuté et noté ses stories dans son backlog pour la prochaine livraison. Les équipes XP utilisèrent des cartes Classe Responsabilité Collaboration (CRC) pour faire un brainstorming initial des concepts de conception, des métaphores pour clarifier le critère d'acceptance avec le client, et ont créé des petits programmes de proof of concepts/research. A la fin de la planification de livraison, chaque équipe fit un récapitulatif des fonctionnalités sur lesquelles elles travailleraient pour la livraison et s'il y avait des inconnues, des risques ou des dépendances manquantes. Ensuite, elles utilisèrent le fist of five pour confirmer leur engagement dans la livraison, en se basant sur leur backlog. Après le récapitulatif et la prise de confiance sur les engagements de chaque équipe, le projet passa à l'exécution.
Chaque Planification de Livraison était suivie de l'itération 0 (d'une semaine). L'équipe utilisait ce temps pour mettre en place l'intégration continue et les serveurs de déploiement, faire plus de cartes CRC, mettre en place des postes de pair programming et des frameworks de tests unitaires automatisés (AUT), définir sa Definition of Done (DoD), choisir sa méthodologie Agile (e.g. eXtreme Programming), concevoir ses itérations de développement, paramétrer des outils pour gérer son travail, et plus simplement tout ce qui était nécessaire à lancer l'équipe dans le développement et l'implémentation.
eXtreme Programming a très bien fonctionné pour nous. Par exemple, l'intégration continue avec des tests automatisés réduisit les problèmes habituels rencontrés avec les fusions de code. Cela procura plus de chances de déployer à la fin de chaque semaine (itération) sur le serveur de test, permettant ensuite au client de jouer avec la version, de mettre à jour et de re-prioriser le backlog en se basant sur ce qu'il avait découvert.
L'avantage principal d'eXtreme Programming qui plut au client dans ce cas fut la flexibilité de changer la priorisation et les stories à l'intérieur d'une itération. Scrum est particulièrement rigide sur ce point. On laisse au client la possibilité de réduire considérablement son stress de planifier l'itération parfaite.
Du point de vue de l'équipe, l'avantage principal fut la réduction du temps de planification. Encore une fois, dans Scrum, les réunions de planification peuvent durer une journée entière si vous planifiez une itération de quatre semaines. Mais, comme les itérations d'eXtreme Programming sont beaucoup plus courtes et flexibles, la planification est assez courte - moins de 45 minutes dans le cas présent.
Recommandations et Directives pour les Equipes XP
- La taille des équipes doit être de 5 personnes ou moins. C'est important car plus l'équipe est petite, moins il y a de vecteurs de communication, et donc, plus la focalisation se porte sur la réalisation du travail.
- Les itérations durent une semaine - car vous voulez constamment obtenir des retours et intéragir avec votre client. Avec une équipe étroitement liée, c'est possible.
- Le Planning Game est une réunion au début de chaque itération pour prioriser le travail et faire des estimations techniques - c'est censé être une réunion rapide et efficace puisque le planning peut changer si nécessaire. Comme les itérations durent une semaine et que les priorités peuvent changer en cours d'itération, vous ne voulez pas passer trop de temps à planifier votre engagement.
- Essayez de livrer après chaque itération si possible et si votre équipe n'est pas une partie d'un groupe d'équipes travaillant sur une même livraison. Comme dans Scrum, vous voulez obtenir du code potentiellement livrable à chaque Sprint.
- Le contenu de chaque itération est flexible tant que le travail n'a pas démarré. Vous voulez donner à votre client la plus grande flexibilité raisonnable. Donc, le travail planifié qui n'a pas été démarré dans une itération devrait être flexible pour changer de priorité ou de contenu. Cela peut nécessiter une conversation avec le client au milieu de l'itération.
- L'équipe travaille par ordre strict de priorité. Les fonctionnalités à développer sont priorisées par le client. Tout comme dans Scrum, nous voulons nous focaliser sur la valeur métier (meilleur retour sur investissement), pas sur le contenu ou le budget.
- XP incorpore des pratiques d'ingénierie, tout particulièrement des choses comme le développement guidé par les tests, les tests automatisés, le pair programming, la conception simple, le refactoring, et ainsi de suite. eXtreme Programming consiste à être efficient et efficace. L'automatisation est la clé pour y arriver. Plus vous pouvez automatiser, sans créer de charge supplémentaire, plus vous améliorerez la qualité générale et rendrez l'équipe efficace et efficiente dans la réalisation des engagements de l'itération.
- Faites des stand-up quotidiens de 15 minutes. Comme dans Scrum, c'est le seul moment où l'équipe peut se synchroniser formellement pour discuter de ses progrès. Un bon stand-up n'est pas un rapport d'avancement mais plutôt une conversation à propos du progrès réalisé compte tenu des engagements de l'itération.
- Evitez de travailler plus de 40 heures par semaine. Les statistiques ont montré que faire d'incroyables heures de travail est contre-productif pour les développeurs et qu'ils vont à l'inverse commencer à faire des erreurs et à créer plus de travail.
- Quand les stories sont terminées, montrez votre travail au client pour le faire valider et ajoutez-le à la base de code officielle. Tout comme dans Scrum, seule la satisfaction client importe. Plus tôt il voit votre travail, plus tôt il donne des retours.
- Faites une Rétrospective au moins une fois toutes les trois itérations. Il y aura toujours des opportunités d'amélioration. D'un autre côté, vous ne voulez pas ensevelir vos équipes sous les réunions car les itérations sont très courtes. Donc, faire une Rétrospective une fois toutes les trois semaines ne fera pas suffoquer l'équipe et elle en verra la valeur.
Conclusion
Souvenez-vous qu'eXtreme Programming est une méthodologie agile de développement logiciel. XP vous aide à rester léger sur vos appuis en évitant les fardeaux inutiles et en incorporant constamment les retours. Le changement des attentes est un risque attendu et acceptable, car le client voit le développement du système en temps réel. Les erreurs sont tout de suite visibles et sont corrigées alors que l'implémentation de la fonctionnalité est fraîche et malléable, de la même façon qu'un potier retravaille l'argile.
Les développeurs travaillent et retravaillent le code dans les projets eXtreme Programming. Le client voit le système grandir depuis un niveau au dessus du niveau de détail. Le système est aussi efficace que les détails qu'il incarne. Les détails sont importants, et eXtreme Programming le renvoie au client de la seule façon qui soit importante : du code qui fonctionne.
Ci-dessous, un résumé holistique d'eXtreme Programming par Ron Jefferies :
A propos de l'Auteur
Dr. Raman a plus d'une décade d'expérience en gestion de projet, transformation et implémentation, coaching et formation agile. Il a compté parmi ses clients des entreprises comme Nike, Intel, PayPal, Millennial Media, AOL, Bristol Myers Squibb, Biogen Idec, Center for Medicare and Medicaid Services, L'Oreal, Galderma, Chimes, Johns Hopkins, RWD, pour n'en citer que quelques-unes. Dr. Raman a quatre diplômes académiques, incluant deux licences en Recherche Biomédicale et Sciences de Laboratoire et deux Masters en Technologie de l'Information respectivement de l'Université du Maryland, l'Université Towson, et l'Université George Mason. Dr. Raman excelle dans plusieurs méthodologies/frameworks de gestion de projets comme Scrum, Waterfall, le modèle en V, Kanban, SAFe, etc.