Extreme Programming : L’industrialisation

Après avoir mis en place les bonnes pratiques d’XP dans notre précédent article, nous allons pouvoir rythmer le fonctionnement pour passer à une phase d’industrialisation.

Mettre en place le rythme itératif de développement

Désormais, votre équipe a toutes les cartes en mains pour adopter un cycle itératif de développement. Elle est en mesure de s’engager sur un petit périmètre. Une fois toutes les précédentes étapes passées et le contenu de l’itération défini, vous pouvez encore « monter le niveau » et vous appuyez sur d’autres pratiques XP.

La culture du test automatique est respectée, cela signifie que les tests unitaires sont désormais systématisés. Même si ce n’est pas à proprement parler une pratique XP, une piste à envisager est d’adopter le Test Driven Development. Le TDD est populaire car c’est une mécanique qui permet de faire émerger un design simple.

Le binomage ou pair programming est peut-être la pratique la plus polémique. Il faut être lucide : c’est difficile et tout le monde n’en est pas capable. Mais c’est une excellente pratique pour assurer le partage de la connaissance ou la montée en compétences d’un nouvel équipier. Dans certains cas, ce n’est pas plus coûteux que de s’astreindre à de la revue de code ! Proposez le pair programming à l’équipe. Ne le rendez pas forcément systématique, mais dans certains cas de figure comme un petit défi technique ou une difficulté à surmonter, c’est souvent une excellente solution. Par ailleurs, c’est aussi un excellent moyen de parvenir à avoir une équipe cross-fonctionnelle parce qu’XP prône la non-spécialisation des équipiers. Ainsi, nul n’est irremplaçable et tout le monde peut intervenir sur toutes les couches de l’application, s’en est fini des équipes organisées par composants.

Enfin, l’amélioration continue est un objectif de toute équipe agile. Maintenant que vous avez une équipe rompue à un certain nombre de pratiques techniques, pourquoi ne pas l’y ouvrir ? Mettre en place une rétrospective régulière va lui permettre d’inspecter sa manière de travailler et de s’adapter (inspect and adapt). La rétrospective est une cérémonie pour réfléchir explicitement sur les événements marquants depuis la fois précédente, et décider collectivement des actions d’amélioration sur lesquelles les équipiers s’engagent. Cela permet à l’équipe de trouver ses propres pratiques et de faire ses choix pour petit à petit devenir auto-organisée et apprenante.

Le complément idéal des méthodes Scrum et Kanban

À l’heure actuelle, Scrum et Kanban ont le vent en poupe. Ces méthodes adressent très bien le cycle de vie du développement informatique au niveau organisationnel. Or, ils ne mettent en avant aucune pratique technique. C’est pour cela qu’ils se mixent naturellement à au moins un sous-ensemble de pratiques XP, c’est le complément idéal.

Sans le support de ces pratiques, Scrum et Kanban se heurtent à des difficultés ou ne permettent pas de donner l’intégralité de leurs bénéfices. Comment mettre la qualité des développements au centre des préoccupations sans intégration continue et tests automatisés ? Comment assurer une responsabilité collective du code sans conception collaborative, sans standard de programmation ?

Considérez XP comme il le mérite : un ensemble d’excellentes pratiques adoptées par les équipes de développement parmi les plus performantes au monde. Vous voulez un logiciel de qualité dont les utilisateurs recommandent l’utilisation ? Penchez-vous dessus !

XP, parce qu’il facilite la mise en place de pratiques périphériques

XP a été pensé par des développeurs et pour des développeurs. Ce référentiel de bonnes pratiques permet à une équipe produit d’adopter des concepts qui n’étaient pas courants quand XP a été imaginé.

Faire de l’A/B testing ou s’inspirer du Lean Startup est maintenant possible. Votre architecture et votre organisation rendent maintenant facile le test d’hypothèses. Les implémenter, les déployer et les valider est maintenant possible. Organiser des pivots est bien plus facile quand le coût du développement et du déploiement ont été drastiquement réduits. Cela présuppose, bien entendu, d’être également en mesure d’instrumentaliser le code pour mettre en place des indicateurs d’utilisation de vos fonctionnalités, bref d’avoir des métriques qui rendent possible la modification d’un produit sur la base d’informations quantitatives et qualitatives.

L’intégration continue n’est maintenant qu’un premier pas vers un plus grand objectif : le déploiement continu. Pour en arriver là, il faut optimiser la livraison en production, et cela passe par l’automatisation de la chaîne de delivery…

Vous avez maintenant tous les arguments en faveur de l’adoption d’un large spectre des pratiques XP. Si vous vous engagez dans cette voie, vous aurez un code propre, testé automatiquement, la capacité de mettre en production des incréments produit en des temps courts et de l’amélioration continue.