La « definition of done », un impératif de la qualité du produit

Dans un contexte Agile, le rythme régulier de mise en production des incréments est parfois teinté de précipitation et un certain manque d’excellence. Or, l’agilité est au contraire une méthode qui demande une rigueur extrême pour assurer des livraisons rapides et régulières. 

Afin de limiter ces irrégularités, de nombreuses équipes agiles mettent en place la definition of done qui est « un fondement du product management » et un impératif absolu pour assurer la qualité de nos livraisons.

Dans cet article nous revenons sur l’importance de la definition of done avec Jean-Pierre Lambert, qui nous a partagé sa vision durant un WeFiiT Talk.

Qu'est ce que la definition of done?

Découlant de la méthode SCRUM, la « definition of done » (ou définition du fini), est une liste de critères à vérifier, afin de déterminer si les user stories ou tickets sont vraiment terminés. Communément appelée la DoD, c’est un pré-requis important à utiliser afin d’atteindre le niveau d’exigence requis durant le développement d’un produit digital.

En effet, SCRUM stipule qu’à la fin de chaque sprint, les user stories terminées et passées en DONE (fini), soient testées, documentées et potentiellement livrables en environnement de production.
Au-delà de la validité des critères d’acceptation, la DoD peut contenir tous les éléments pertinents pour garantir la qualité du produit en question.

Aussi, la definition of done permet d’aligner les équipes techniques et métiers sur les résultats attendus et acceptables à la fin du sprint, évitant ainsi de nombreux allers-retours et déceptions.
Enfin, une fonctionnalité qui ne respecte pas tous les critères de la DoD, ne doit pas être présentée durant la revue du sprint, et est considérée comme incomplète.
 

Comment construire la DoD ?

La definition of done peut être élaborée en atelier par l’équipe technique, le product owner, scrum master et l’équipe QA agile. En effet l’exercice consiste à se mettre d’accord sur les critères qui semblent essentiels pour atteindre le niveau d’exigence souhaité pour le produit et assurer des livraisons de qualité.

D’ailleurs, Jean-Pierre Lambert propose également d’utiliser le jeu de cartes DoD Kards, créées par Thomas Wallet et  Camilo Velázquez de Kleer pour composer votre definition of done de manière ludique.

Enfin, gardez à l’esprit que votre DoD dépend de la nature du produit, du secteur et de ses contraintes, de l’environnement technique et de la maturité de l’équipe.

Exemple de critères présents dans la DoD :

  • Revue du code effectuée
  • Les critères d’acceptation de la User Story sont tous validés
  • Les différents tests ont été finalisés et acceptés par les acteurs de la qualité du produit (QA, PO, développeurs)
  • La documentation a été mise à jour
  • Les maquettes graphiques sont respectées
  • Livré sur un environnement stable
Une fois la première version de la DoD définie, n’hésitez pas à la partager avec vos parties prenantes pour leur expliquer la démarche et les rassurer sur la qualité des livrables qu’ils vont recevoir. 
 

Piège à éviter 

Le piège à éviter est de se retrouver avec une liste infinie de critères détaillés et impossible à terminer durant un sprint. Il faut garder à l’esprit que la definition of done est un engagement fondamental de l’équipe à livrer une user story finie, elle ne doit pas devenir une contrainte. 

Il est fortement conseillé de commencer par une liste contenant les éléments qui vous semblent impératifs, puis la faire évoluer au fur et à mesure des sprints

La definition of done en pratique

WeFiiT Talk : " [...] 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. "
portrait JP lambert
Jean-Pierre Lambert
Coach Agile & Qualité

En effet,  après sa création la DoD est souvent oubliée ou mise de côté dans un effort de maintenir la cadence et d’assurer les livraisons des incréments. 

Aussi, veillez à l’utiliser régulièrement avec votre équipe, durant les sprints, en review et profitez-en pour la questionner, l’affiner ou l’étoffer selon vos besoins et standards de qualité.

Nous tenons à remercier encore Jean-Pierre Lambert, fondateur de ScrumLife, pour sa participation au WeFiiT Talk. Nous avons été ravis d’échanger avec lui autour de cette problématique importante et de recevoir ses conseils ! 
A bientôt pour un prochain WeFiiT Talk ! 

PSSST 👀

Cet article vous a plu ❤️ ? N’hésitez pas à le partager pour que d’autres puissent en profiter ! Rejoignez-nous aussi sur Linkedin pour ne rien manquer et suivre notre veille sur les contenus Product & Quality !
Vous voulez en savoir plus? Jetez un oeil à ces articles sur le blog WeFiit :
Partager sur linkedin
Partager sur twitter
Partager sur email