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 ?
- Comment construire la DoD ?
- La definition of done en pratique.
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.
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
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
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 👀
