Pourquoi il faut définir le terminé?

C’est étonnant le nombre de personnes dans le monde du travail qui m’amènent à la même constatation : il manque des critères commun de ce qu’est un travail terminé. Dans une agence Web, par exemple, un manager reçoit le cahier des charges, le fournit à un chef de projet qui le détaille, demande aux graphistes, développeurs, rédacteurs et testeurs d’agir sur leur domaine. Entre leur travail à chacun, le chef de projet doit contrôler que tout est terminé pour le poste suivant. Entre deux postes de même nature aussi. On pourrait croire que chaque poste de travail apporte sa pierre à l’édifice sans pour autant contrôler la jonction des différents points. Pourtant, ‘terminer’ doit converger vers un retour sur investissement, quelque soit la rémunération cherchée, monétaire ou autre. Alors pourquoi, sur toute la chaîne, j’entends régulièrement deux développeurs donner des estimations très divergente de ce qu’il reste à faire après avoir produit leur code? Pourquoi lorsqu’untel dit que c’est terminé, d’autres, au même stade parlent de 5 minutes et enfin, certains vont faire un ratio du temps passé à ‘coder’? Pourquoi avons nous l’impression qu’il faut repasser après celui-là alors que lorsque celui-ci finit, tout est OK?

Un problème de cadre de référence

Si vous avez l’habitude de Scrum ou des méthodes agiles, vous voyez venir une “Définition de Terminé” en réponse à ces problèmes (en anglais “Definition of Done” ou DoD). Et vous avez raison, les équipes n’ayant pas de DoD tombent souvent dans le piège de se poser la question “C’est fini ou fini fini ?”. C’est la même question lorsqu’on dit “Ton estimation, elle comprend quel tâches?”.

Si, par exemple, lorsque mon graphiste me dit qu’il a fini le design d’une page, j’ai l’habitude qu’il ait contrôlé les alignements et fait un pré-découpage simple à intégrer en HTML/CSS. Alors que se passera-t-il lorsque je planifierai la prochaine page avec celui qui me fournit le PSD brut? C’est aussi l’histoire du stagiaire qui vient vous dire qu’il a fini le développement que vous lui avez confié : vous testez sur le serveur d’intégration, et il n’y a rien; vous regardez sur le versionning, et rien non plus. Les développeurs expérimentés avec qui vous travaillez vous ont toujours livré lorsqu’ils vous disent “J’ai finit”.

La définition de terminé

C’est une des base de l’organisation d’une équipe agile : créer un langage commun sur les actions à effectuer avant d’annoncer une tâche terminée. Cette checklist, souvent très simple et semblant présenter le B-A-BA du métier est néanmoins nécessaire pour éviter d’être dans une zone d’incertitude, d’inconfort et donc de stress immense à terme. Par exemple, on peut écrire dans une définition de terminé, pour une équipe de développement Web classique :

  • Code développé et fonctionnel
  • Build Projet OK
  • Tests Unitaires automatiques OK
  • Code déployé sur le Git
  • Code déployé sur le serveur de développement
  • Tests des nouvelles fonctionnalités sur le serveur de développement

Un levier extraordinaire pour l’amélioration des livrables

Ça semble être des étapes très basiques pour certains, mais d’après les discussions que j’ai avec chacun, le niveau n’y est pas. J’entends trop dire que l’estimation de deux membres d’équipe diverge, que le livrable n’est pas de qualité, que les clients s’arrachent les cheveux après la mise en production d’un “développement urgent”. La DoD aide à éviter tout ceci grâce à :

  1. La simplicité de mise en œuvre de l’outil
  2. La compréhension commune de la frontière entre “En cours” et “Terminé”
  3. Le partage clair des exigences de livrable
  4. L’opportunité d’ajouter ou supprimer des éléments lorsque nécessaire

Toutes personne du projet estime selon cette nouvelle norme estime donc exactement la même chose. A partir de là, lorsque quelqu’un dit “j’ai terminé”, tout le monde comprend ce qu’il a fait et quelle est la prochaine étape.

Comment s’assurer qu’elle soit utile ?

Il existe quelques conditions nécessaires pour que la DoD fonctionne:

  • Émergente : Elle doit venir des personnes qui doivent la respecter, afin de créer un engagement. Imposer la DoD, c’est mettre un triangle dans un carré : un triangle trop petit, on laisse des trous, trop grand ça bloque. Dans les 2 cas, c’est inutile.
  • Toujours respectée : Déroger à une règle de la DoD, c’est la porte ouverte aux dérives. Il faut donc y penser dès le départ : ne rien y mettre qui soit trop compliqué, penser à mettre des conditions (“si ce n’est pas un script, vérifier la build”), éviter les “90% fait” ou les imprécisions, qui peuvent vite mener à ne jamais terminer ou à oublier le point en question.
  • Simple : Idéalement, elle tient sur une demi feuille A4, afin d’être affichée sur tous les murs des espaces de travail concernés. Ca permet donc de la retenir et de la respecter plus facilement.
  • Adaptée à la tâche donnée : On ne demande pas au graphiste de compiler son design, ou au commercial de faire du TDD. Ce n’est pas grave si cela mène à créer une DoD pour chaque métier, voire plusieurs DoD selon l’étape du travail à faire.
  • Révisée régulièrement : La vie est en constante évolution, vos produits, projets et équipes aussi. Leurs conditions de succès aussi, et par conséquent, leur DoD aussi.

Si vous n’étiez pas familier avec cette notion, j’espère que vous avez assimilé ce concept, qui est sans doute le plus simple à comprendre et le plus “tous-terrains” du monde de l’agilité. D’ailleurs, j’espère même que vous testerez ceci dès demain. Pour les agilistes aguerris, j’espère que ces quelques explications vous aideront à revoir votre définition actuelle avec du recul, ou à expliquer plus simplement ce concept à ceux qui en auraient besoin. Dans tous les cas, pour cet article, c’est terminé.