S’assurer que la Definition of Done est bien respectée
Utilisation de fiches pense-bête
Au projet Player de la Direction du Numérique de France Télévisions nous avons mis en place des petites fiches remplies de cases à cocher pour matérialiser le Definition of Done :
Il ne s’agit ni plus ni moins que d’une checklist du Definition of Done de l’équipe. Lorsque l’équipe pense avoir terminé une US, on prend la liste, on en fait le tour, et on coche méthodiquement chaque case.
Alors pourquoi c’est cool ?
(si jamais vous ne trouviez pas déjà que c’était super cool)
S’assurer que la DoD est bien respectée
D’une, parce que j’ai rarement, voire jamais vu une équipe faire systématiquement et exhaustivement le tour de la DoD en Revue de Sprint pour s’assurer que chaque US est bien “done-DONE”.
Donc déjà, ça nous assure qu’on atteint bien le niveau d’exigence qu’on s’est fixé. Et pas un bricolage où on considère done des US pour ne se rendre compte que plus tard qu’en fait il manque des petits trucs. Comme une doc qu’on n’a pas mis à jour. Ou une revue de code qu’on n’a pas mené à fond. Ou parfois des trucs beaucoup plus gros, comme un script de déploiement qu’on a oublié de mettre à jour… Bref, on est heureux quand on s’en rend compte bien plus tard, et qu’on perd alors beaucoup de temps.
Parce qu’on peut éviter de refuser des US quasiment done
Et l’autre raison pour laquelle ces fiches à cocher c’est super cool, c’est parce qu’on les remplit avant la Revue de Sprint. Ainsi, quand on se rend compte qu’on a oublié des trucs, il est encore temps de corriger le tir. Il aurait été dommage de recaler en Revue de Sprint une US alors qu’il ne resterait que deux-trois détails à gérer, c’est si rapide à corriger…
On remplit les fiches avant la Revue de Sprint, ce qui laisse le temps de corriger le tir
Pourquoi on ne s’y met que maintenant ?
L’idée en soi n’est pas spécialement originale : nous y avions déjà pensé et l’avions déjà envisagé. Cependant nous n’avions jamais osé passer le pas. Sûrement le côté enfantin de la checklist, on aime bien se regarder soi-même de haut et se dire qu’on n’en a pas besoin. Et bien si, en fait, on en a besoin.
On aime bien se regarder soi-même de haut et se dire qu’on n’en a pas besoin.
Quoi qu’il en soit, c’est la lecture de 96 Visualization Examples par Jimmy Janlén qui nous a convaincu d’essayer. Encore merci à ce grand Jimmy !
Une DoD vivante
Cette approche rend également la DoD beaucoup plus vivante. Ce n’est plus un doc dans le Wiki qu’on met à jour de temps en temps mais un véritable outil qui fait partie de notre quotidien. Très concrètement, nous avons déjà mis à jour cette nouvelle DoD, dès la première itération d’utilisation de la checklist.
Nous avons déjà mis à jour cette nouvelle DoD, dès la première itération d’utilisation de la checklist
L’action de Rétrospective ajouter ce critère à la DoD ne donne plus l’impression d’une action fantoche qui ne fera pas avancer les choses mais bel et bien de quelque chose qui impactera directement le quotidien de l’équipe.
Et ça marche aussi pour d’autres choses ?
Par ailleurs, l’approche de la checklist s’applique aussi à d’autres éléments, avec succès. Par exemple, dans le cadre de notre process de mise en production, nous définissons une liste des scenarios de non-régressions à exécuter ainsi que la liste des devices sur lesquels exécuter ces scenarios. Nous avons donc fait des petites fiches pour expliciter quels sont ces devices :
Votre avis ?
Qu’en pensez-vous ? Est-ce que cela vous donne envie d’essayer ?
A propos de Jean-Pierre Lambert
Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.
Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !
J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…