Rédiger une définition de « terminé » qui empêche vraiment le travail de fuir
En Scrum, la définition de « terminé » est la compréhension partagée de ce que signifie l'achèvement du travail sur l'incrément. Le Guide Scrum est sans détour sur son importance : si un élément ne respecte pas la définition de « terminé », il ne peut être livré et ne fait pas partie de l'incrément. Une définition faible n'est donc pas un problème de documentation. C'est une fuite de qualité qui expédie du travail inachevé sous l'étiquette « terminé ».
Beaucoup d'équipes en rédigent tout de même une qui ne dit guère plus que « code écrit et testé ». Quand l'équipe partageait une même salle, les écarts se repéraient au bureau voisin. Avec les équipes dispersées dans leurs bureaux à domicile au début de 2021, ces repérages informels ont disparu, et une définition de « terminé » avec du mordant est devenue le rempart de la qualité. Voici comment en rédiger une.
Rendez chaque ligne vérifiable
Une définition de « terminé » n'est utile que si n'importe quel développeur peut regarder un élément et répondre oui ou non sans débat. Remplacez les adjectifs par des contrôles.
Au lieu de « bien testé », précisez la barre : tests unitaires écrits et réussis, cible de couverture convenue atteinte, et compilation au vert.
Au lieu de « revu », précisez qui et comment : revue de code par les pairs effectuée et commentaires résolus.
Au lieu de « documenté », nommez l'artefact : la note de changement destinée à l'utilisateur et tout changement d'API consigné.
Incluez le travail non fonctionnel toujours escamoté : accessibilité, contrôles de sécurité et performance dans le seuil convenu.
Confirmez que le travail est intégré et déployable dans l'environnement cible, et pas seulement fonctionnel sur un portable.
Construisez-la, appropriez-vous-la et resserrez-la avec le temps
La définition de « terminé » appartient aux développeurs, non à un gestionnaire qui dicte une liste. Construisez-la ensemble pour que l'équipe l'applique vraiment, puis traitez-la comme une norme vivante.
Rédigez-la avec toute l'équipe. Tenez une séance où les développeurs énumèrent chaque étape qui les a déjà piégés. La paternité partagée transforme une liste en un engagement que les gens défendent.
Respectez les normes de l'organisation. Si votre organisation a une définition de « terminé » plus large, la vôtre doit l'égaler ou la dépasser. L'équipe peut ajouter des critères plus stricts, jamais plus laxistes.
Appliquez-la pendant le sprint, pas à la fin. Les éléments progressent vers « terminé » en continu. La traiter comme une barrière finale produit un tas de travail presque fini qui échoue à la revue de sprint.
Inspectez-la et adaptez-la en rétrospective. Quand un défaut passe au travers, demandez quelle ligne de la définition l'aurait attrapé, puis ajoutez cette ligne. La définition devrait se renforcer à mesure que l'équipe apprend.
Une vraie définition de « terminé » change le ton de chaque conversation. « Est-ce terminé ? » cesse d'être un jugement et devient une liste que chacun peut dérouler. La vélocité peut fléchir au début, le temps que le travail caché devienne visible, mais ce que vous livrez est réellement livrable, et c'est le seul progrès qui mérite d'être compté. Pour une équipe à distance, cette norme partagée et explicite fait souvent la différence entre la transparence et la dérive silencieuse.
Si vos équipes ont besoin de normes de livraison qui font que « terminé » signifie la même chose partout, le service-conseil en gestion de programmes et de projets de XNM peut vous aider à les définir et à les ancrer.