Extreme Programming : La mise en place des fondations.

Dans notre dernier article, nous nous sommes attachés à rappeler les valeurs et le but d’XP. Passons maintenant à la mise en place.

Nous pouvons ranger les projets informatiques en deux grandes catégories : la maintenance d’applications existantes (souvent désignées par le terme « legacy ») et le développement de nouvelles applications (from scratch). Pour toute équipe en charge d’une application de la seconde catégorie, vous pouvez naturellement passer le premier paragraphe.

Assainir la base de code existante

Il est malheureusement courant qu’une application se base sur un code qui ne soit pas complètement satisfaisant, propre et facilement maintenable. Il est répandu de parler de dette technique. Celle-ci se conçoit comme la dette financière d’un pays; plus le temps passe et plus la solder coûte cher. Ainsi, lorsque nous n’investissons pas dès le départ dans des mécanismes de qualité, cette dette se creuse dès les premiers jours.

Dans le cas d’applications legacy, les premières actions à mener adressent cette douleur. Il s’agit alors de mobiliser l’équipe pour une première phase d’ajout de test et de refactoring minimale. Elle doit permettre de supprimer le code mort (les portions de code qui ne sont plus utilisées) et de simplifier le plus possible le code existant. Comment savoir quand s’arrêter ? Cette étape doit être permettre de rendre le code testable, pour être en mesure de mettre en place un framework de tests automatisés. En effet, XP porte en lui la culture du test automatique, vecteur de qualité des développements et de confiance pour les futurs développements.

Votre équipe a pu mettre en place un framework de tests ? Félicitations, vous pouvez passer à l’étape suivante !

Mettre en place l’intégration continue

L’intégration continue est une des pratiques XP et adresse notamment le feedback. En mettant en place l’intégration continue, l’équipe sait au plus tôt si un nouveau développement implique de la régression : le harnais de tests le détectera automatiquement ! L’intégration continue doit se faire à chaque modification de code, et cette pratique, mise en avant par XP, est en place dans bon nombre d’équipes de développement.

Grâce à cela, un principe peut se mettre en place : tout nouveau développement doit obligatoirement être testé. Si vous êtes partis de notre première étape, il reste probablement encore beaucoup de code qui n’est pas testé. Appliquez alors la règle du boy-scout. Lorsqu’un développeur prend la responsabilité de faire une évolution qui touche une portion de code qui n’est pas encore testée, il faut laisser la place plus propre qu’il ne l’a trouvée : simplifier le code, le refactorer et ajouter les tests unitaires nécessaires. Petit à petit, vous soldez votre dette… C’est maintenant qu’une valeur de XP entre alors en jeu ‘le courage’ : ces phases de refactoring, progressives, permettent d’élargir la couverture de tests.

Je vous invite à regarder le screencast de Sandro Mancuso sur refactoring et la mise en place de tests sur du Legacy Code.

la base de code continue de s’assainir. La confiance de l’équipe grandit. Cela peut se ressentir jusque dans l’utilisation de l’application, qui a des chances de se stabiliser. Vos utilisateurs vous en seront reconnaissants.

À ce stade, vous avez donc une architecture qui permet l’exécution automatique de votre batterie de tests.

Découper le produit en petits incréments

XP a posé les premières pierres d’une autre manière de collecter le besoin et d’organiser le travail en conséquence. Une des 13 pratiques préconisées consiste à définir le rôle du client sur site qui n’est autre que l’ancêtre du Product Owner. Ce rôle est de plus en plus populaire : c’est lui qui a la charge d’être le guichet unique pour les développeurs et qui collectent l’intégralité des besoins que l’application doit satisfaire. Le client sur site est le garant de la maximisation de la valeur métier, c’est lui qui définit des éléments de travail qui sont suffisamment petits pour être développés durant des périodes de temps courtes. En Scrum ou en Kanban, vous entendrez bien souvent parler de User Stories.

Il s’agit d’abandonner un modèle de spécifications fonctionnelles qui porte sur de gros lots de développements, qui seront longs et fastidieux à spécifier, donc long à développer et qui par conséquence allongent dangereusement la boucle de feedback. En 2015, à l’heure où les applications mobiles que vous utilisez quotidiennement sont mises à jour régulièrement avec de nouvelles fonctionnalités ou de profondes évolutions de l’existant, vos utilisateurs ne sont plus prêts à attendre de longs mois de nouvelles versions de leurs applications professionnelles.

Ces petits éléments de travail sont présentés lors d’un cérémonial XP, le planning game. Le but est de mettre autour de la table la voix de l’utilisateur (le client sur site) et l’équipe de développement. Le client sur site présente les prochains chantiers, les développeurs peuvent alors les challenger (et même sur le volet fonctionnel), ils en discutent pour les estimer et s’engager sur leur développement durant la prochaine itération. Les bénéfices en sont clairs : la conception devient collaborative et émergente. La collaboration permet le partage de la connaissance et la mise en place d’un véritable esprit d’équipe. L’émergence de la conception permet d’adresser les évolutions en respectant une autre valeur XP : la simplicité. En appliquant une logique de petits pas, l’équipe de développement ne s’expose pas à la mise en place de solutions trop complexes, on ne met en place systématiquement que la solution la plus simple qui répond à notre besoin tel que nous le connaissons à ce moment là.

Arriver à cette étape est une grande victoire, vous avez l’ensemble des éléments pour passer au niveau supérieure : l’industrialisation, qui fera l’objet d’un futur article.