Lorsque l’on travaille dans un environnement agile, on entend régulièrement parler de la « DOD » et de la « DOR ». A plusieurs reprises, je me suis aperçu que ces notions étaient parfois abstraites ou méconnues. Dans certains cas, elles sont mises en place mais finalement peu ou pas utilisées, à l’image des bonnes résolutions que l’on prend en début d’année mais que l’on ne fait jamais…. Autant de signes qui m’ont donné envie de poser quelques lignes sur le papier afin que chacun puisse alimenter sa propre réflexion.

Dans cet article nous allons tout d’abord partir à la rencontre de la DOD : quel est ce concept ? comment est-ce qu’on la construit ? doit-elle être mise à jour ? puis nous partirons à la découverte de sa petite sœur, la fameuse DOR. Nous verrons qu’il existe des points communs entre les deux.

DOD : DEFINITION OF DONE

Le concept du « travail terminé » : de la vie quotidienne…à l’IT.

La Definition of Done est aussi connue sous l’acronyme « DOD » comme vous l’aurez compris. Littéralement c’est la définition de ce qui est fini / terminé… « Definition of Done ».

Une fois que l’on a dit ça, il est légitime de se poser la question suivante : c’est quoi un travail terminé ? Souvent j’ai constaté que chacun peut avoir sa propre définition.

Pour commencer, prenons un exemple de la vie quotidienne : une personne que l’on nommera Paul demande à ses enfants de plier leur linge et de le ranger dans leur armoire. Quelques heures plus tard, Paul s’aperçoit que seuls les chaussettes sont regroupées par paires et rangées correctement. Le reste des habits étant trié par couleur et mis en tas sur le lit. Ce n’est pas ce que Paul avait imaginé... Pour les enfants le niveau de qualité du pliage et du rangement était suffisant mais pas pour Paul. Au travers de cet exemple on commence à comprendre qu’il peut être préférable que tout le monde ait la même définition du « travail terminé » afin d’éviter les mauvaises surprises…

Pour revenir au monde de l’IT, quand on est amené à travailler en différentes étapes successives, il peut être important que l’on soit d’accord sur ce qu’est le travail terminé. L’objectif est de savoir quand on peut « pousser » notre travail à une autre étape afin qu’une tierce personne puisse le récupérer. Pour illustrer ce paragraphe, prenons l’exemple suivant : comment le Product Owner, peut-il considérer que le développement d’une US est terminé ? Comment peut-il déterminer que cette US peut rentrer dans le périmètre de la prochaine démo ? Dans ce cas, la DOD peut être un outil intéressant. Continuez la lecture vous allez comprendre pourquoi...

La DOD : de quoi est-elle composée ?

De manière simple la DOD peut être caractérisée comme une liste de critères faisant référence à ce qu’il faut avoir fait pour considérer le travail comme terminé.

Pour revenir à notre exemple, voici quelques critères qui pourront aider le PO à déterminer si une US peut être « démontrée » :

• Tests unitaires réalisés : ils couvrent 70% du code.
• Code validé : le code produit pour l’US a été revu par 2 pairs.
• Documentation à jour : la documentation associée à l’US a été écrite ou mise à jour.
• Suivi à jour : JIRA ou un autre board ont été actualisés
• Démo prête : la « démo » a été préparée avec les données à utiliser et les différents cas à démontrer.

Attention rien n’est gravé dans le marbre ! Il peut exister plusieurs autres critères en fonction du projet et du contexte de l’entreprise !

Notons que toutes les US sur un sprint donné ont la même DOD. Il faut considérer les critères de la DOD comme une invitation à la réflexion. Ecrire de la documentation pour toutes les US du backlog a-t-elle un sens ? Est-ce pertinent pour chaque US ? Est-ce que cela apporte de la valeur ? Il faut se poser la question et si la documentation pour une US n’est pas pertinente et bien il convient de ne pas la faire ce qui n’empêchera pas l’US d’être démontrée...

Autrement dit la DOD ne doit pas être un frein on doit savoir parfois « lâcher un peu la corde » pour ne pas bloquer les développements.

Quand et comment la construire ?

Sur la temporalité il n’y a pas de règles précises. En générale la DOD est déterminée avant le premier sprint planning. Certaines équipes la définissent en cours de projet car elles n’ont pas pensé ou jugé nécessaire de la réaliser avant. Il existe différentes manières de créer une DOD, citons en deux….

Tout d’abord, l’équipe peut s’inspirer de la DOD d’autres équipes. Imaginons une équipe qui découvre le contexte de l’entreprise ou qui fait ses premiers pas dans un environnement agile. Elle peut dans ce cas se baser sur une DOD déjà réalisée et utilisée, lui permettant d’avoir une première base de travail et d’échange afin d’éviter le syndrome de la feuille blanche. Bien évidemment il ne faut pas reprendre aveuglement la DOD de son « voisin » mais se demander quels sont les critères exploitables pour mon projet ? Il peut s’agir aussi d’un REX intéressant.

L’autre piste à exploiter est celle de l’expérience du Scrum Master. Dans ce cas le Scrum peut proposer une liste de critères pour éclairer et guider l’équipe. Les différents acteurs choisissant alors les critères leur paraissant significatifs et adaptés au projet à un moment donné.

Quelle que soit la méthode cela passe par une réunion d’équipe pour que les membres puissent définir ensemble une première DOD.

La DOD peut-elle évoluer ?

Une seule réponse : oui ! La DOD peut évoluer, rien ne l’oblige à être statique dans le temps ! L’équipe peut ajouter des critères ou en supprimer. Bien souvent, la DOD évolue pendant le projet. Par exemple, si les acteurs rencontrent un problème et qu’ils aimeraient qu’il ne se reproduise pas et bien ils peuvent rajouter un critère dans la DOD. Au fur et à mesure la DOD est le reflet des apprentissages de l’équipe.

Il est fortement déconseillé de la faire évoluer en plein milieu de sprint. Si l’équipe rajoute un critère impactant cela peut faire « exploser les compteurs » et perturber la réalisation des développements. Cependant, si pour le bien du produit un nouveau critère doit être absolument intégré sans perturber l’objectif et la date de fin du sprint alors la situation doit s’étudier…

DOR : DEFINITION OF READY

Le concept du « travail prêt »

La Definition of Ready, connu sous l’acronyme DOR est la liste d’éléments qu’une user story doit rassembler pour être candidate au développement. Ce sont les critères qui vont permettre à la user story de passer du backlog produit au backlog sprint. Elle est considérée comme un contrat entre le PO et les développeurs.

La DOR peut être un« garde-fou » pour éviter les sprints plannings qui s’éternisent et qui peuvent impacter la motivation de l’équipe. Si une US respecte la DOR, les développeurs devraient avoir tous les éléments à disposition pour l’évaluer rapidement et précisément. On peut alors éviter de multiples questions en sprint planning et on minimise le risque de sous-estimer une US.

Création, mise à jour et composition : des points communs avec la DOD !

Comme pour beaucoup de décisions que prennent les équipes agiles, la DOR doit être élaborée par le biais d’une discussion ouverte à l’image de la DOD. Là encore pas de recette miracle…l’équipe peut s’appuyer sur les expériences d’autres équipes ou d’experts agiles afin d’avoir une première rampe de lancement adaptée à son projet bien sûre !

Tout comme la DOD, la DOR n’est pas figée dans le temps. Elle évolue en parallèle de la progression de l’équipe en termes de confiance et de maturité. La DOR n’a pas d’obligation à changer à chaque fin de sprint. Toutefois, l’équipe doit de temps en temps prendre le temps nécessaire pour s’assurer que cette dernière est toujours en adéquation avec la maturité de l’équipe et le contexte du projet.

Comme « sa petite sœur » la DOR est composée également de critères sur lesquels l’équipe va s’appuyer pour définir si l’US est prête à être développée. Ci-dessous quelques exemples de critères :

• L’US a été présentée à l’équipe par le PO. Elle a été challengée acceptée et comprise par l’ensemble des membres de l’équipe
• Le besoin a été spécifié : les règles de gestion sont exprimées et des exemples les illustrent
• Des maquettes sont disponibles pour préciser le besoin
• L’équipe a décliné l’US en tâches techniques

Liste non exhaustive bien évidemment !

DOR : Bonne ou mauvaise pratique ?

Même si la DOR est considérée comme une bonne pratique, là encore il ne faut pas que la DOR soit un frein à l’agilité. Parfois, tout ce qui est dans le sprint planning n’est pas forcément prêt. Une US embarquée dans le sprint peut voir sa maquette IHM réalisée en cours de sprint pour différentes raisons (manque de temps du designer, adaptation de dernière minute…). Bien sûr, ce fonctionnement est à pratiquer à la marge mais il peut être utilisé.

En conclusion

Nous venons de poser quelques mots sur ces deux notions fréquemment rencontrées en agilité. Comme nous le montre le schéma ci-dessous la DOD et DOR interviennent en amont et en aval du sprint. Vous l’aurez compris la DOD et la DOR sont jumelles dans le fonctionnement même si elles ont des objectifs différents. Il n’y a pas d’obligation à les utiliser mais elles peuvent être d’une aide précieuse en particulier pour les équipes qui débutent en agilité. Si vous n’avez pas encore mis en œuvre ces notions je vous invite à les essayer car en générale quand on y goûte on les adapte !