Martin Fowler a publié un article sur son blogue qui présente les symptômes d’un mal qu’il nomme le Scrum Flasque (Flaccid Scrum). J’ai vu les symptômes qu’il cite se manifester à plusieurs reprises lors de divers mandat en clientèle chez des entreprises faisant une transition vers Scrum:
They want to use an agile process, and pick Scrum
They adopt the Scrum practices, and maybe even the principles
After a while progress is slow because the code base is a mess
Comme le mentionne Fowler, Scrum est un processus mettant l’emphase sur des techniques de gestion de projet et qui, contrairement à Xtreme Programming, ne met délibérément pas de l’avant des pratiques d’ingénierie spécifiques. Selon lui, les gens adoptant Scrum ont tendance à croire que si le processus ne parle pas des aspects techniques, c’est qu’ils sont moins importants que le reste. Ainsi, rapidement, « No Big Design Up-Front » devient «No Design At All ». Et s’ensuit une dette technique qui ne s’arrête plus de grandir…
Que faire pour inverser la vapeur? Les pratiques XP (le Test-Driven Development, le refactoring, le pair programming, le collective code ownership) sont une réponse possible et souhaitable. Toutefois, selon mon expérience, elle prennent du temps à assimiler, tout particulièrement dans les grandes organisations ayant souvent connu un fonctionnement plus directif par lequel les développeurs ont l’habitude de recevoir d’un architecte une grande partie des détails de la solution à réaliser. On demande la plupart du temps à ces développeurs d’apprendre TDD alors qu’ils vivent la pression d’un projet et qu’ils ont parfois des difficultés à reconnaître les symptômes d’un mauvais design et qu’ils maîtrisent mal les bases mêmes de l’orienté-objet. Comment faire pour aider les développeurs ainsi conditionnés à prendre en main une plus grande part du travail de conception? Et comment faire pour aider les équipes adoptant une approche agile à minimiser et contrôler leur dette technique?
Pourquoi ne pas introduire des code reviews? Non, non, ne fuyez pas! Je ne parle pas d’un processus de revue de code à la Fagan, extrêmement rigide et coûteux. Je parle plutôt d’un processus léger de revue par les pairs, et en partie au moins automatisé. On ne parle presque pas des revues de code dans le monde agile parce qu’elles semblent souffrir de cette image désuète, dépassée et poussiéreuse. Une image de lourdeur tout ce qu’il y a de moins agile…
Pourtant, les outils d’inspection du code automatisés deviennent de plus en plus sophistiqués et aptes non pas seulement à détecter les erreurs de style, mais aussi à mettre en lumière les duplications, les code smells de toutes sortes, les failles dans la couverture de test, etc. Par exemple, dans le monde Java, il faut désormais considérer un outil comme Sonar, libre et gratuit, comme un indispensable, une aide monumentale à la visualisation et l’identification de la dette technique s’adressant à tous les intervenants d’un projet. Sonar consolide les données recueillies par plusieurs autres outils, comme Findbugs, Checkstyle, PMD, Cobertura et bien d’autres, les digère et les présente sous une forme compréhensible et grandement utile.
En dehors des outils, pourquoi ne pas inclure dans notre définition de done une revue de code « humaine » pour traiter en équipes des problématiques plus pointues comme le respect des requis, la qualité des tests, le respect du cadre architectural, etc. La compagnie SmartBear a produit un très bon papier présentant des recommandations dans l’adoption un tel processus. Et d’autres outils émergent également pour supporter ce type léger de revue de code par les pairs à même l’IDE (Jupiter, ReviewClipse, Rietveld, CodeCollaborator, etc.) permettant par exemple d’associer des commentaires avec des lignes ou blocs de code. Certains de ceux-ci s’intègrent également avec les systèmes de gestion des sources pour automatiser la revue de code avant ou après un commit.
Je crois fermement aujourd’hui que les revues de code, autant humaines qu’automatisées, sont un outil complémentaire et nécessaire durant l’apprentissage des techniques XP par une équipe de développement. Elle sont une occasion en or pour un coach technique d’enseigner le repérage des code smells et une aussi belle occasion pour les membres de l’équipe d’apprendre en observant le travail des autres, de mieux communiquer, de se sentir comme faisant partie d’un groupe uni et organisé et de se sentir engagés dans le développement d’un logiciel de qualité supérieure. Allez-y! Redonnez du tonus à votre Scrum!
Précisons aussi que cette année, nous avions décidé de démarrer l’atelier avec la base de code générée l’année dernière… oups… on peut alors comprendre que c’est dur de reprendre le code déjà écrit par un tiers… mais n’est-ce pas là notre lot quotidien de développeur? J’aime beaucoup la formule qui définit la qualité de code de cette façon : “un code de qualité c’est un code qui peut évoluer facilement dans les mains d’une autre personne”… eh oui, nous sommes nous-même toujours enclin à trouver que notre code est beau, mais ce n’est pas le plus important : est-il “vraiment beau” pour un autre? J’ai pris pas mal de plaisir en codant avec 
