RYTHME (IN)SOUTENABLE

Sur son blog, sur les mailing list XP France et FrenchSUG, David Brocard a relancé la discussion sur la mise en pratique du principe agile du rythme soutenable.

LE RYTHME SOUTENABLE

"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." (Agile Manifesto)

Ce principe est très louable:

• Il privilégie les objectifs à long terme sur les objectifs à court terme.
• Il assure un flux continu et constant de création de valeur qui maintient la qualité du produit, assure l'avancement et améliore la prédictibilité du développement.
• Il instaure un rythme permettant de mettre en place la résolution systématique des problèmes et l'amélioration continue.
• Il rappelle que le développement est réalisé par des hommes et qu'il faut respecter leur rythme de travail - dans leur intérêt, dans celui du projet et des clients.
• Il permet d'enchainer les projets, les uns après les autres, car les développeurs restent disponibles (en bon état ...).

LE PROBLÈME

• En revenant sur plusieurs années de projet, est-ce que le rythme soutenable a été appliqué?
• Est-il compatible de la mise en pratique des autres principes du Manifeste Agile?
• A t-on au moins gagné un rythme plus soutenable qu'auparavant, lorsque nous utilisions des méthodes plus théoriques et (faussement) prédictives?
• Après 150 jours ouverts de développement sur un même projet, j'avais écrit que nous étions passé de l'itération au sprint sur notre projet en perdant le rythme soutenable (voir billet). Qu'en est-il après 350 jours ouvrables de développement sur ce même projet?

LE PLUS DUR EST A VENIR

Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable le long du V descendant. Pour tenir un jalon intermédiaire (spécification, conception, codage) il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.

Puis, le rythme devenait bien plus désagréable lors de la remontée du V. L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point (et réécrire) ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...

Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.

C'EST DUR TOUT LE TEMPS

Avec la pratique du cycle de vie itératif et incrémental court, le stress et les heures de travail n'ont pas disparu. Ils ont été lissé assez uniformément le long du développement (il reste des pics lors des itérations qui précèdent une livraison formelle). Aussi, le stress et le surcroit de travail apparaissent très tôt dans le développement.

Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.

Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité (et d'autres indicateurs) peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.

Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles lissent tôt et tout au long du projet le stress qui culminait auparavant vers la fin (théorique) du développement.

Notez que la technique du Heijunka dans la Lean recherche spécifiquement ce lissage de la charge de travail et du stress.

SANS PIC NI RELÂCHE

Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de relâche. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un daily-stand-up-meeting, avec le burndown chart actualisé quotidiennement, avec un build publié et avec des tests de recette automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!

Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.

LA COURSE A LA VÉLOCITÉ

Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.

STRESSANTE TRANSPARENCE

Au rythme s'ajoute le stress de la transparence. Il faut du courage pour afficher sa courbe de productivité et sa courbe de non-qualité. Il faut du courage pour mettre une lumière qui devient rouge lorsque le build est cassé. Il faut du courage pour montrer ses problèmes. Donner des indicateurs, cela peut aussi être donner le bâton pour se faire battre. Être transparent, c'est aussi accueillir la critique: "Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire" (François Brun).

NOUVEAUX SYMPTÔMES

Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un riche folklore d'équipe. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que "le Gizmo", "le Perfect", "le saut de la troisième corde", "le J'off" et bien d'autres encore.

Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des mécanismes collectifs de protection contre la souffrance au travail. Malheureusement, c'est un fonctionnement très classique étudié par la psychodynamique du travail. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.

Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.

QUEL QUE SOIT LA MÉTHODE

Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux (pour des raisons économiques) et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les périodes de charrette (période intense de travail pour terminer à temps une commande, une tâche sous contrat).

NÉANMOINS

Les démarches de type agile ont la particularité de lisser cette charge de travail dans la durée et de monter très tôt le rythme. Ce rythme est sans pic ni relâche. A cela s'ajoute le stress de la transparence. Clairement, il faut du courage pour pratiquer une démarche du type agile.

La variable d'ajustement reste le curseur de la vélocité. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent (très facilement) en faire.
Ces démarches sont diablement efficaces et motivantes mais elles ne peuvent bien sur pas tout résoudre.

LE SYNDROME DE LA DECHARGE PUBLIQUE

En quelques 350 jours ouvrés de développement sur une même application, j'ai développé une attitude extrémiste et dogmatique quant au maintien de la qualité du logiciel. Je dois en irriter plus d'un dans l'équipe (désolé).

Dans ce billet, je tente de justifier cette attitude. (Le développeur extrémiste a été dévoilé dans le billet UN BON CODE).

LA PETITE HISTOIRE

Avez-vous déjà remarqué que lorsque la décharge publique est fermée, il y a parfois un particulier qui déverse ses détritus devant le portail d'entrée? (voir photo) Avez-vous aussi remarqué qu'une fois qu'un premier "vandale" a ouvert le bal, d'autres suivent son exemple.

"Après tout, l'entrée est déjà souillée, alors c'est pas quelques détritus de plus qui vont changer quelque chose ..."

Parfois même, autres continuent cette dégradation alors même que la décharge a réouvert ses portes!

Ce qui est notable dans ce comportement, c'est que le premier à dégrader l'entrée de la décharge commet l'acte le plus "difficile". Il dégrade un lieu propre. Par contre, il est bien plus aisé pour les suivants de suivre cet exemple en continuant à dégrader le lieu.

Il est aussi notable que si le personnel de la décharge avait immédiatement nettoyé les détritus du premier vandale, les suivants n'auraient probablement pas osé vider leurs détritus devant la porte.

REVENONS A NOS MOUTONS

Ce syndrome se transpose au code d'une application logicielle. Si un premier développeur amorce la dégradation de la qualité du code, par exemple en ne testant pas sa modification, en laissant des warnings de compilation ou en ne respectant pas les standards de l'application, alors d'autres continueront à dégrader l'application.

"Après tout, pourquoi tester ma modification alors que 20% des lignes d'instructions ne sont pas couvertes? Mon code non-testé se noiera dans la masse et passera inaperçu ..."
"Après tout, pourquoi passer du temps à corriger mes 2 warnings de compilation alors que le build en détecte déjà 23?"

Sur plus de 350 jours ouvrés de développement d'un même logiciel, à 25 contributeurs, nous avons remarqué que si la qualité commence à se dégrader, alors le phénomène s'emballe. Il devient alors très difficile et coûteux de l'endiguer et de le résorber. Nous pouvons même autopsier ce phénomène en observant notre courbe d'historique de la non-qualité (voir précédant billet dédié à cette pratique). D'ailleurs, nous utilisons cette même courbe pour détecter l'amorce du phénomène et déclencher les actions correctives.

Il y a une autre raison pour laquelle il faut maintenir l'application propre. Notre build complet publie la liste de la non-qualité détectée. Plus la liste est importante et plus il est difficile pour un développeur d'y retrouver les problèmes liés à son travail. Petit à petit, ce développeur va se lasser de rechercher les défauts qui le concernent directement au milieu de pages de défauts.
Par contre, si la liste des défauts détectés reste très faible, alors chaque développeur y retrouvera immédiatement et très visiblement sa non-qualité. Elle sera si visible que les autres équipiers pourront aussi la repérer. Alors, naturellement, chaque développeur évitera de se faire repérer comme contributeur à la non-qualité en corrigeant au plus tôt ses défauts.

MIEUX VAUT PRÉVENIR QUE GUÉRIR

Ce phénomène me semble très naturel. S'il est n'est pas rigoureusement contenu, l'application va progressivement "pourrir". Il sera alors de plus en plus difficile de faire évoluer le logiciel. Pire, le tas des petits défauts sans conséquence va cacher les bugs dangereux.

Pour palier à ce problème, je pense qu'il est primordial de développer une attitude extrémiste quant à la dégradation de l'application. Ceci est d'autant plus vrai si l'application est volumineuse, si le projet est long, si le nombre de contributeurs est important ou si l'application est critique (notre projet réuni tous ces critères à la fois). Il est judicieux de s'acharner à retirer tous les défauts au plus tôt pour laisser un code propre que personne ne souhaitera dégrader.

POUR ALLER PLUS LOIN

Dans d'autres contextes, ce phénomène et l'attitude appropriée pour l'endiguer sont connus sous le nom Fixing Broken Windows. Ce même phénomène a été transposé au développement de logiciels par les Pragmatic Programmers dans leur article Software Entropy, dans l'entretien Don't Live With Broken Windows et dans leur très bon livre The Pragmatic Programmer.
Bonnes lectures!

UN BON CODE ...

Dans l'ordre, un bon code

1. passe ses tests avec succès;
2. ne peut être mal utilisé;
3. ne contient pas de redondance;
4. exprime clairement l'intention;
5. est aussi court que possible.

Paraphrase ...
A peu de choses près, les points 1, 3, 4 et 5 sont une citation de Kent Beck, créateur de l'eXtreme-Programming. Praticien de la programmation par contrat, j'y ai rajouté le point 2. (Qu'est-ce que je ne ferai pas pour citer les travaux de Kent Beck et Bertrand Meyer dans le même billet :o)

... néanmoins utile
J'ai la chance de relire beaucoup de code, de binommer avec de nombreux développeurs et d'enseigner. Dans le cadre de ces activités, cette citation en cinq points m'est très utile. Je m'en sers beaucoup et je la cite souvent. Je dois sûrement passer pour un extrémiste dogmatique et têtu ... (Après tout dans un équipe, il est bon d'atteindre un certain ratio développeur extrémiste / développeur laxiste)
N'empêche qu'il y a beaucoup de sagesse empirique dans cette citation. Entre autre, l'ordre des critères est très important.

1. Tu testeras
Les tests occupent le haut du podium. Un code qui n'est pas testé n'a pas de valeur. C'est du code sans garantie. Toute ligne d'instruction doit être couverte par un test. Cela se vérifie très bien avec les outils d'analyse de la couverture structurelle.

2. Tu détromperas
Un code qui ne peut être mal utilisé est un code détrompé. Il contribue à la gestion préventive des défauts dans l'application. La programmation par contrat est une excellente pratique pour détromper le code. Quitte à parler de programmation par contrat, il serait plus exacte de dire: "Un bon code garantie sa postcondition si sa précondition est garantie par son appelant". Pour en savoir plus sur cette pratique rare mais vraiment efficace, vous pouvez lire un précédant billet sur ce sujet.

3. Tu ne te répèteras pas
La duplication est source de défauts multiples et de reprises multiples. Elle nuit à la clarté des intentions. Admettons que j'"hérite" d'un code non testé. Sans hésitation, je préfère consacrer du temps à le tester qu'à en éliminer les redondances. (En fait, j'éliminerai les redondances dès que les tests passeront :o)

4. Tu seras clair et explicite
Le code est bien plus souvent lu qu'écrit - y compris par son auteur! D'ailleurs, l'écrivain est avant tout son propre lecteur. Autant faciliter la vie de tous ces relecteurs. Comme pour le point précédant, je préfère tester que renommer et découper. (Pareil, je renommerai et découperai dès que les tests passeront :o)

5. Tu seras bref
La brièveté du code arrive en dernier car elle peut entrer en conflit avec les points 1, 3 et 4. Dans un tel cas de figure, la brièveté n'est pas prioritaire.
Pour rendre un code testable, il faut souvent créer des interfaces pour injecter des dépendances à la construction des objets. Cela augmente la taille du code. Le test amène également à découper en petites classes et il y a un talon déclaratif à payer pour cette modularité.
Un code sans duplication peut amener à créer une opération pour 2 lignes dupliquées. Au total, en comptant le surcroit de déclaration, cette pratique peut augmenter le nombre de lignes. D'ailleurs, avez vous remarqué que les exemples de code remanié sont TOUJOURS plus longs que leur code d'origine? (voir Clean Code)
Pour rendre un code plus explicite, nous sommes amené à homogénéiser le niveau d'abstraction dans le code des opérations. Pour cela, nous encapsulons le code de niveau d'abstraction inférieur dans une opération. Là encore, nous payons une taxe pour la déclaration des opérations.

Et le code des tests?
Ce codex en 5 règles s'applique au code, mais aussi aux tests, car les tests sont du code. On peut penser qu'il ne faut pas tester les tests sinon on n'en finit jamais. Pourtant, la pratique du Test Driven Developpment issue de l'eXtreme-Programming intègre par construction le test du test!
En effet, lorsque nous commençons par écrire un test qui échoue, puis nous modifions le code jusqu'à ce que le test passe avec succès, nous vérifions la justesse du test. Ce tte démarche en 2 étapes est le test du test.

Un de plus (violation du critère 3!)
Désolé, ceci était le 1379ème billet visant à définir un bon code. Plusieurs livres y consacrent leurs pages. C'est un peu comme les chaînes de chance/malchance. Lorsqu'on lit un de ces billets, on se doit d'en écrire un à son tour ...