Cavalcade
♔♕♟♗ Jusqu'à la fin de la partie, les observateurs se sont tus. Puis ils commentent :
— Cet échange de fous, c'était une erreur. Il valait mieux tenir le centre.
— J'avais un pion d'avance. J'aurais pu gagner !
— Avec quel plan ?
— Justement ! Je n'avais pas de plan. Et pas de temps non plus. C'est pour cela qu'il fallait simplifier.
Les échecs et le développement de logiciel ont au moins ceci en commun : ils nous mettent face à une montagne de complexité, à appréhender en un temps limité. Souvent cette limite de temps fait de la montagne un véritable mur. D'où l'expression : "aller dans le mur".
⛰
Un état de l'art inadapté ou désaligné, c'est un projet de développement qui va bientôt se trouver en retard, et qui pourrait bien aller dans le mur.
Par définition l'état de l'art rassemble les procédés, recettes, patterns, pratiques qui permettent de résoudre un problème dans un contexte donné en un minimum de temps. Par exemple si une équipe a dans son état de l'art la pratique des tests d'intégration automatisés, c'est parce qu'elle sait que cette pratique est le moyen le plus rapide d'atteindre certains objectifs de qualité, toutes choses égales par ailleurs. Supprimez les TIs autos, tout en maintenant l'objectif, et l'équipe vous opposera un délai supplémentaire. 🗓
protip ☞ lorsqu'une équipe retire de son état de l'art une pratique de prévention des défauts tout en se promettant de tenir ses délais, c'est qu'elle vient subrepticement et implicitement de changer les objectifs du projet.
De même qu'il est impossible à un joueur de se mettre à étudier les problèmes de milieu de partie alors qu'une partie est en cours et que la pendule tourne, il est très difficile pour une équipe en retard d'acquérir de nouvelles pratiques en vue de les ajouter à son état de l'art. L'état de l'art est certes rempli de recettes pour aller plus vite, mais l'acquisition de ces recettes demande du temps.
Au début du projet, l'équipe n'a pas le temps d'améliorer ses pratiques :
- celles ci ne sont pas (encore) remises en question
- sa roadmap chiffrée au plus juste lui permet tout juste de caser les fonctions demandées
Au milieu du projet, l'équipe n'a pas plus le temps d'améliorer ses pratiques :
- sa stratégie l'a mise en retard
- elle "sauve les meubles" : apprendre est devenu un luxe
Au lieu d'évoluer de plateau en plateau, l'équipe dévale une pente fatale. Pour peu qu'elle remplace une date manquée par une date tout aussi intenable, elle court sans répit. Ses chances d'améliorer son état de l'art sont donc battues en brêche.
protip ☞ le cadrage d'un projet est le meilleur moment pour inventorier l'état de l'art de l'équipe.
PS: Chez CodeWorks nous avons même un atelier qui permet de faire cet inventaire.