samedi 23 juillet 2011

Les bonnes pratiques n'ont pas de cadre

Dans mon article précédent, j'ai essayé de convaincre qu'il fallait arrêter d'essayer d'adopter une conduite agile de projet dans un contexte de forfait. Cela vous attriste : vous déprimez à l'idée de travailler à l'ancienne. Vous voulez quand même de l'agilité dans votre vie de développeur. Bien.

Scrum met peu l'accent sur les pratiques de développement pourtant décrites par extreme programming. Il y en a peu mais toutes sont intéressantes.

Tout d'abord, le développement dirigé par les tests (TDD). C'est un point difficile. Si on suit les principe d'XP, aucune ligne de code ne doit passer en production si elle n'a pas d'abord fait l'objet d'un test unitaire en échec. On est dans la discipline pure. Pourtant, cette pratique permet d'avoir un contrôle quasi total du code en frôlant 100% de couverture par les tests. L'intérêt est d'autant plus grand lorsque cette pratique est couplée à de l'intégration continue (voir plus bas). Le paradigme qu'elle met en place est que la première nécessité d'un module développé est de pouvoir être testé rapidement de façon automatisée. Ce point surclasse le principe d'encapsulation cher à la programmation orientée objet. De prime abord, on peut penser qu'une telle pratique engage un surcout, surtout si on n'est pas habitué à automatiser les tests. D'habitude, on commence par rédiger le code de production et on s'assure manuellement de son bon fonctionnement. De plus, les tests représentent du code supplémentaire à maintenir ce qui n'est pas compris dans le budget... D'autorité, je dis que les avantages dépassent le surcout. Les tests sont maintenus car lancés et mis à jour avant chaque retouche de code. Le surcout en temps doit être pris en compte dans les chiffrages.
La vraie difficulté est de dépasser le barrage culturel et de former l'équipe à cette pratique.

Une deuxième pratique intéressante est l'intégration continue. L'IC consiste à faire tourner la construction du projet régulièrement, en la déclenchant par exemple sur la validation de fichiers dans le système de gestion de code source. Le point fort de cette pratique est qu'elle est peu couteuse à mettre en place, même longtemps après le début de développement, comme dans le cadre d'une tierce maintenance applicative. Les intérêts sont multiples.
Tout d'abord, vous pouvez contrôler que les sources compilent toujours après une validation. C'est un peu le niveau zéro de l'intégration[1].
Ensuite, le système permet d'installer une plateforme de test automatiquement, même vierge. Vous contrôlez ainsi qu'il n'y a pas de problème d'installation et vous disposez d'une plateforme "propre" pour faire des tests manuels.
Enfin, lorsque vous avez une bonne couverture de tests unitaires, vous pouvez les lancer à chaque mise à jour du dépôt de code source. Avec la pratique du TDD, vous mettez ainsi en place une non régression permanente pour un coût nul.
Les systèmes populaires d'intégration continue aujourd'hui sont Jenkins et Hudson (c'est le même système) mais si vous ne voulez pas (ou ne pouvez pas) utiliser Java sur votre plateforme, vous pouvez très bien développer un système simple avec des scripts et cron.

Dernière pratique d'ingénierie, le développement en binôme (pair programming). Pour moi, elle est la plus difficile à mettre en place mais ses bénéfices sont intéressants.
Le plus évident est le transfert de connaissance, l'apprentissage. C'est efficace pour montrer une technique comme le TDD, l'intérêt d'une règle de développement, des raccourcis clavier ou autre fonctionnalité de l'IDE pour aider le binôme à augmenter sa productivité. Cet aspect n'est malheureusement intéressant que pour le moins expérimenté[2].
Un autre aspect est la relecture de code, l'un pouvant voir des problèmes dans le code que l'autre ne saisit pas au premier abord ; même si la personne au clavier est la plus expérimenté, elle bénéficiera d'un autre point de vue sur son code. La discussion sera également bénéfique pour les deux parties.
Enfin, en mélangeant les binômes sur différents aspect du produit, on améliore la connaissance globale du code par l'équipe.
Il y a effectivement de bonnes choses mais il est compliqué de mettre cette pratique en place de façon systématique : elle a un côté "socialisation forcée" qui peut ne pas convenir à tout le monde. Elle est en outre difficile à argumenter avec la hiérarchie qu'on veut mettre deux personnes au lieu d'une sur une tâche. Ne prétendez pas que la tâche sera terminée deux fois plus vite : c'est faux même s'il y a un gain de productivité. C'est en terme de qualité de code et de capacité d'apprentissage de l'équipe que cela se joue.

Pour conclure ce deuxième article, disons que ces bonnes pratiques d'ingénierie ont été promue aux travers des valeurs de l'agilité. Elles sont adaptables à n'importe quel type de projet car elles mènent à une meilleure qualité du produit livré[3], avec moins de bogues mais aussi une architecture plus flexible, que l'on peut remodeler sans crainte grâce au tests. Elles visent à donner une meilleur maîtrise du processus de livraison. Soyez honnêtes, intégrez le surcout de ces pratiques dans vos chiffrages. Ne badinez pas avec la qualité du produit, votre réputation et celle de votre entreprise est en jeu.

Cet article aborde des techniques connues avec un point de vue candide mais quand je vois les gens travailler autour de moi, je pense que ça valait le cout de l'écrire.

Pour la suite, j'aborderais les pratiques de conduite de projet issues de l'agilité bénéfique même dans un cadre forfaitaire.


[1] si le code en gestion de source ne compile même pas, il va falloir en discuter avec l'équipe
[2] je me demande toutefois si la personne qui a posture de mentor dans cette situation ne va pas vouloir "briller" devant le n00b et faire une performance :).
[3] un contrat de TMA est plus rentable quand le produit n'a pas de bogue.