Résistance, équilibre et renforcement
Just Do It ?
- Qu'est-ce que tu crois que je devrais faire ? - Moi à ta place j'arrêterais tout simplement de faire X et je commencerais à faire Y. - Oui, facile à dire... - C'est une question de discipline. Il suffit de s'y mettre.
Nous avons tous vécu cette scène du conseil d'ami, comme émetteur et comme receveur. C'est un antipattern; comme tous les antipattern, il part d'une bonne idée: dans certaines circonstances, la résistance à faire le premier pas représente le seul obstacle réel au changement. Il suffit de faire!
La suite, on la connaît : c'est une série d'arguments logiques qui s'arrête quand l'un des deux protagonistes jette l'éponge. La logique ne peut aider à défaire les situations dans lesquelles elle n'est pour rien.
Une situation de blocage est rarement le seul fait d'un manque de volonté, ou le fait d'une seule cause en général. En prenant assez de recul, et en cherchant les liens de cause à effet possibles entre les éléments de la situation, on peut alors appréhender celle-ci comme un système, formé de boucles de rétroactions négatives (tendant vers un équilibre) ou positives (tendant vers le renforcement d'un phénomène).
Un exemple
Paul, manager récemment entré en poste, vient de convoquer une réunion avec Clara, Daniel et Alexandre, l'équipe de développement du projet ALPHA. Ce projet itératif incrémental affiche un nombre croissant d'anomalies à chaque livraison en recette. Paul fait part de son inquiétude :
- Sauf erreur, le nombre de retours augmente à chaque livraison. Je me demande si nous pourrons mettre en production à la date prévue. Qu'est-ce que vous en pensez ?
Clara avance une explication: - Il faut savoir que tous les retours ne représentent pas forcément des erreurs de notre fait..
Paul interrompt en levant les mains: - Clara, mon intention en posant cette question n'est pas de trouver à qui la faute, mais de chercher une solution avec vous.
Alexandre prend la parole, hésitant : - Honnêtement, je suis content qu'on en parle, je ne sais plus quoi faire. Il semble que plus on corrige de bugs, plus il en tombe de nouveaux !
Paul, autant que les développeurs, sait bien que les bugs ne "tombent" pas dans un programme. Il demande: - Qu'est-ce que vous pourriez faire qui permettrait de réduire le nombre de retours ? Daniel lui répond sur un ton légèrement agacé: - Ce qu'on fait déjà, figure-toi, on les corrige. - Je me suis mal exprimé: qu'est-ce qui ferait qu'il y aurait moins de bugs introduits dans le programme ? Daniel, de plus en plus agacé : - Ce n'est pas comme si on les introduisait exprès...
Consternation. Alexandre intervient : - Non, mais, on pourrait sans doute écrire plus de tests unitaires. Puis Clara : - On pourrait simplifier le code. Franchement, le module de pricing est devenu compliqué, tordu, même. C'est un nid à bugs. Daniel élève la voix : - Et vous le trouvez où le temps pour faire tout ça ? - Je ne sais pas, répond Alexandre; on est déjà mercredi et je n'ai fait que des bugfixes depuis lundi.
Paul perçoit les conflits qui sous-tendent cette discussion. Il lui vient soudain une idée noire: si nous reculons la date de livraison, c'est la fin de ma période d'essai. Il réfléchit. Si nous livrons un système défectueux, aussi. Il a en tête les mots d'ordre du management : "Faire plus et mieux avec moins!". On est loin de cette vision théorique, pour tout dire, à l'opposé. Alexandre le sort de sa réflexion : - On est tout simplement dans une spirale infernale. - Tu veux dire un cercle vicieux, c'est ça ? demande Paul.
Un cercle vicieux (ou boucle de renforcement positif) est une structure fréquemment rencontrée dans un système qui semble "résister" au changement. En analysant cette structure, il est possible de trouver des points d'interventions, voire de transformer le cercle vicieux en cercle vertueux.
Tracer le système
Paul prend un marqueur et se dirige vers le tableau blanc. - Dans mon précédent poste, quelqu'un m'a appris à créer des diagrammes de relations de causes à effet. Je vous propose d'essayer, pour y voir plus clair. Paul explique en dessinant : - On a ici un phénomène de "retours en anomalie", mesurable par le nombre de retours ouverts. Afin de réduire ce nombre, l'équipe corrige les bugs. Un phénomène, mesurable en heures passées, que j'appellerai "effort de correction". Plus il y a de retours ouverts en anomalie, plus l'effort de correction augmente; plus l'effort de correction augmente, plus le nombre de retours en état ouvert diminue. - Jusque là tout va bien, dit Daniel, un peu sceptique. - Oui, c'est une boucle équilibrée, dit Paul, en dessinant une petite balance au centre de la boucle. Or, Alexandre a dit tout à l'heure "Plus on en corrige, plus il en tombe". Alexandre intervient : - C'était une façon de parler. - N'empêche. Il nous manque quelque chose dans ce système. Qu'est-ce qui fait augmenter le nombre de retours en anomalies ? Clara relit ce qu'elle a noté : - Pas assez de tests unitaires, pas assez de refactoring, code illisible... Paul continue à dessiner: - Produire ces tests unitaires, ce refactoring, cette simplication, notons cela "effort sur la qualité du code" - Si tu veux. - Est-ce qu'une augmentation de cet effort aurait pour effet une réduction du nombre de retours ? - Je ne crois pas, dit Daniel, cela réduirait le risque de bugs futurs, mais cela ne changerait rien à ceux que nous avons déjà ! - Exact, répond Paul, il y a un délai dans la relation de cause à effet entre ces deux phénomènes.
Daniel s'impatiente : - Et donc ? Qu'est-ce qu'on peut faire ? Paul trace un dernier lien, ainsi qu'une balance : - Théoriquement, devant chaque nouveau retour en anomalie, il faudrait travailler à la qualité du code, de manière à rééquilibrer le système. Daniel s'exclame : - Et les bugs on en fait quoi ? Clara dit sur un ton calme : - Daniel a raison, Paul, ce serait la chose à faire, mais là, on n'a pas le temps. Paul souligne plusieurs fois sur le diagramme, la boucle qui relie l'effort de correction à l'effort sur la qualité du code : - Mais on si on n'y fait rien, dans peu de temps ce sera pire encore, et on aura encore moins de temps pour y faire quelque chose !
Long silence. Alexandre demande : - Qu'est-ce que tu proposes, Paul ?
Conclusion (provisoire)
Paul se rassoit, respire un grand coup, et dit : - D'abord, partager la situation avec le client, et tenter d'ajuster le périmètre de la première version. - Ok. Ensuite ? - Ensuite, nous cherchons toutes les actions qui permettent de sortir du dilemme.
Dans cet exemple, Paul et son équipe n'ont pas encore de solution claire à leur problème, en tout état de cause, rien d'actionnable à court terme. Mais ils ont fait deux pas importants :
- élargir le cadre du problème considéré afin de le voir comme un système, c'est à dire un ensemble de phénomènes régi par des relations mutuelles d'influence;
- identifier les boucles de rétro-actions qui régissent l'évolution de ce système, et à partir de là les points d'interventions possibles sur le système.
(à suivre)