Les méthodes agiles, et plus particulièrement Scrum, mettent l'accent sur la valeur apportée aux clients et sur la qualité. Et pour cela, il existe deux notions très intéressantes : la definition of ready et la definition of done.
Comment les utiliser ? Et quelles sont les différences ?
Voyons cela ensemble.
Qu'est-ce que la definition of done ?
La definition of done, ou DoD, est une checklist de critères à vérifier permettant de s'assurer qu'une user story est réalisée à 100% dans un contexte agile. Cette pratique permet d'assurer un niveau d'exigence de qualité minimum tout au long du projet.
Dans un contexte agile, l'équipe ne s'engage pas sur une quantité de travail à effectuer (le nombre d'items intégrés au sprint backlog). Elle s'engage sur ce que signifie un incrément de qualité via cette definition of done.
Elle évolue au fur et à mesure des itérations et des besoins qui émergent. Elle est mise à jour lors des rétrospectives de l'équipe Scrum.
Qu'est-ce que la definition of ready ?
La definition of ready, ou DoR, est une liste d'éléments qui définissent la qualité attendue par l'équipe afin de commencer le développement d'une user story dans les projets agiles. Cette liste prend généralement la forme d'une checklist à valider.
Tout comme la definition of done, la definition of ready contribue à maintenir un haut standard de qualité durant le projet. Elle permet également la facilitation de la communication entre l'équipe de développement et le product owner.
Elle assure également une compréhension commune de ce que signifie une user story prête à être développée, et une user story de qualité.
C'est un levier pour améliorer la qualité de vos user stories. Elle est ainsi complémentaire à la definition of done, qui permet d'assurer un haut niveau de qualité des incréments (le travail livré à la fin du sprint).
Je réponds à vos questions sur la definition of ready dans cet article.
Definition of done vs Definition of ready
Maintenant que l'on a vu ce qu'est la définition de fini (definition of done) et définition de prêt (définition de ready), voyons ensemble les principales différences qui existent entre ces deux notions :
Critères | DoR - Définition of Ready | DoD - Definition of Done |
|---|---|---|
Description | Liste d'éléments qui définissent la qualité attendue par l'équipe afin de commencer le développement d'une user story. | Liste contextuelle de critères à vérifier, permettant de s'assurer qu'un travail est réalisé à 100% et est prêt à être livré au client. |
Usage | Améliore la qualité de rédaction et de spécification des récits utilisateurs (user stories) | Définit le niveau d'exigence de qualité minimum que l'équipe doit respecter pour ses incréments de sprint |
Concerne | Les items du product backlog (user stories) | Le travail à réaliser en cours de sprint (user stories dans le sprint backlog) |
Contenu | Bonnes pratiques à suivre dans la rédaction et la spécification des user stories (commun pour tous) | Critères d'achèvement (commun pour tous) + Critères d'acceptation (propre à chaque user story) |
Artefact et Engagement | Artefact de transparence officieux. Poussé par Jeff Sutherland, co-créateur de Scrum. | Artefact de transparence. Engagement lié à l'incrément. |
Décrit dans le guide Scrum | Non | Oui |
Garant et Responsabilités | Équipe de développement + Product Owner | Équipe de développement + Product Owner |
Quand la créer | Idéalement le 1er sprint, mais reste optionnel | Avant le 1er sprint |
Évolutivité | Oui, peut et doit évoluer au fur et à mesure des itérations | Oui, peut et doit évoluer au fur et à mesure des itérations |
Fréquence de mise à jour | A chaque fois que nécessaire. La question doit être posée à la fin de chaque sprint. | A chaque fois que nécessaire. La question doit être posée à la fin de chaque sprint. |
Quand mettre à jour | Idéalement pendant la rétrospective. Peut être fait en cours de sprint si nécessaire. | Pendant la rétrospective uniquement. Ne doit jamais être mis à jour en cours de sprint. |
Exemples de critères de la definition of done
Vous trouverez ci-dessous les critères les plus courants qui apparaissent dans la definition of done. J'attire votre attention sur le fait que cette liste n'est pas exhaustive, vous pouvez y ajouter vos propres critères.
Il y a cependant un critère qui devrait apparaître dans toutes les definition of done, toutes équipes confondues : "les critères d'acceptation de la user story sont respectés".
- Le développement est terminé.
- Les tests unitaires sont réalisés et sont OK.
- Le code a été revu par un autre programmeur.
- La qualité s'améliore.
- La dette technique diminue.
- Les maquettes graphiques sont respectées.
- Les pages du site web se chargent en moins d'une seconde.
- L'intégration continue fonctionne.
- L'incrément est utilisable sur un environnement de test.
- La documentation est écrite.
- L'application de démo est disponible.
- La recette de la fonctionnalité a été effectuée par l'équipe.
- Les critères d'acceptation de la user story sont respectés.
Exemples de critères de la definition of ready
Voici quelques critères qui peuvent apparaître dans la definition of ready. Bien sûr il ne s'agit pas d'une liste exhaustive, et vous pouvez très bien ajouter vos propres critères :
- Un titre explicite.
- Une description ou une proposition de valeur, la plupart du temps formulée comme ceci : "En tant que [..], je peux [...] afin de [...]."
- La user story est compréhensible et réalisable.
- La user story est testable.
- La user story a des critères d'acceptation de définis.
- Les dépendances sont identifiées, s'il y en a.
- L'estimation a été réalisée par l'équipe de développement.
- Les critères de scalabilité, performance et sécurité sont détaillés si nécessaire.
- Un jeu de données de tests fourni à l'équipe.
- Une maquette est fournie.
Critères d'achèvement vs Critères d'acceptation : Quelles différences ?
Il existe deux types de critères qui permettent de définir la qualité d'un travail :
- Les critères d'achèvement.
Ils représentent les critères à respecter pour qu'un travail soit terminé à 100%. C'est ce qu'on appelle communément la definition of done, ou définition de fini.
Ils s'appliquent à l'ensemble des éléments du backlog. - Les critères d'acceptation.
Ils sont uniques et associés à une seule user story. Ils indiquent les conditions de satisfaction métier qui permettent de satisfaire l'utilisateur.
Un critère d'achèvement sur la definition of done peut être de respecter tous les critères d'acceptation de la user story.
Allons un peu plus loin, et analysons ensemble les différences qui existent entre les critères d'achèvement (la definition of done) et les critères d'acceptation (uniques pour chaque user story)
Caractéristiques | Critères d'achèvement | Critères d'acceptation |
|---|---|---|
Description | Indique ce qui doit être fait pour qu'une user story soit terminée (tests, documentation, etc...) | Indique les conditions de satisfaction métier d'une user story qui permettent de satisfaire l'utilisateur |
Usage | Commune à tous les éléments du backlog. | Unique pour chaque user story. |
Garant et responsabilité | L'équipe de développement est garante et responsable de la definition of done. | Le Product Owner est garant des critères d'acceptation. |
Évolutivité | Peut évoluer en rétrospective. | Sont négociés au moment de la rédaction d'une user story. |
Qualité | La definition of done garantit le respect des critères d'acceptation, en plus d'autres éléments. | Le respect des critères d'acceptation ne garantit pas le respect de la definition of done. |
