Voltaire l’a écrit : « le mieux est l’ennemi du bien ». Les équipes modernes de développement savent que les « vrais artistes livrent » et que l’innovation intervient souvent au fil des itérations. 

Pour les équipes agiles, savoir à quel moment un produit ou un projet est « terminé » permet d’éviter les boucles d’itérations sans fin qui embrouillent et compliquent plus un projet qu’elles ne l’améliorent. L’absence d’une définition claire de ce qui est « terminé » (done en anglais) peut engendrer un perfectionnisme paralysant, ou pire, de la passivité.

La Definition of Done (DoD) est un ensemble de livrables fixés dans le cadre d’un projet ou d’un contrat qui, une fois terminés, serviront de points de repère concrets pour un projet. En bref, il s’agit d’une liste de produits à livrer et d’une compréhension commune des exigences auxquelles l’équipe doit répondre avant de mettre un produit à la disposition des utilisateurs.

Étant donné qu’une DoD agile devra être déterminée dès le début du projet, il est également essentiel qu’elle soit abordée lors de la planification et du brainstorming initiaux d’un projet. Voyons comment une DoD aide les chefs de projet et les équipes agiles à rester flexibles, productifs et concentrés sur l’expérience utilisateur et comment créer ce document. 

Definition of Done : pourquoi l'utiliser ?

Pour apprendre, rien ne vaut l’expérience. Or, l’expérience des utilisateurs est le meilleur moyen de comprendre si votre produit répond aux besoins de ces derniers. Bien sûr, pour obtenir ces informations, vous devez avoir lancé un produit. 

En établissant et en intégrant une DoD dans votre processus de travail, vous parviendrez plus rapidement à un lancement produit, ou du moins à un produit minimum viable. À partir de là, vous pourrez obtenir les commentaires dont vous avez besoin pour fabriquer de meilleurs produits, améliorer la planification, et visualiser et planifier vos projets futurs. Examinons de plus près chacun de ces avantages.

Recueillir des avis utiles pour vous améliorer

Une DoD reflète les étapes nécessaires au succès d’un sprint. Pour les équipes Scrum et agiles, ce référentiel permet de tester, d’itérer, d’apprendre et d’améliorer le résultat du prochain sprint. Chaque étape de la DoD offre la possibilité de recevoir des commentaires tout en gardant le plan de lancement sur les rails.

Améliorer la planification

Lorsqu’un projet n’est jamais « terminé », il est probable que de nombreuses tâches en cours embrouillent et encombrent les futurs sprints et flux de travail. Les sprints sans fin aboutissent souvent à des problèmes trop complexes et, même si l’objectif est toujours la qualité et la fonctionnalité, il est indispensable de lancer un produit minimal viable et de tirer des enseignements des interactions avec les utilisateurs. 

La Definition of Done aide les équipes Scrum et agiles à répartir les produits en incréments définissables, ce qui permet de mieux planifier les sprints à venir. Grâce à la DoD, les équipes de développement peuvent livrer, tester, apprendre, itérer, répéter, le tout avec une vision prospective et en accomplissant des progrès.

Visualisation de l'avancée des projets

Outre l’amélioration de la planification Agile, la DoD agile vous aide à visualiser l’avancée du projet rapidement, afin que vous ayez toujours une vision claire de ce qui a été terminé, de ce qui va suivre et de la direction que prend le développement du produit. Ce niveau de transparence peut également contribuer à garantir une certaine cohésion au sein de l’organisation. En effet, lorsque les conversations sur les directives et les travaux de développement de produits se déroulent en silos, les orientations stratégiques divergent rapidement. 

Comment rédiger une Definition of Done ? Plusieurs représentations sont possibles, mais ses critères individuels sont généralement documentés sur une roadmap produit ou un tableau Scrum qui décrit et illustre clairement l’état d’avancement d’un sprint de produit. 

Au fil du temps, la DoD contribuera à la réactivité de l’équipe en veillant à ce que le travail ne soit pas dupliqué et que le produit ou l’environnement applicatif dans son état livrable réponde aux demandes des utilisateurs et aux attentes du marché. 

Le reflet de la qualité d’un projet agile

Les méthodologies de travail agiles sont intrinsèquement flexibles, mais aussi axées sur les résultats. Les équipes Scrum et agiles expérimentées font leur cette flexibilité, mais se concentrent également sur des objectifs communs et cherchent à fournir le meilleur produit possible dans les meilleurs délais. La Definition of Done accompagne et reflète cette agilité. 

Comment rédiger votre Definition of Done ?

Nous avons parlé brièvement des risques du perfectionnisme et de l’apathie. Ces deux défauts peuvent résulter de l’absence d’une DoD et aboutissent à l’échec du lancement. Les différentes équipes et parties prenantes peuvent avoir des idées différentes de ce que signifie « terminé », mais il est important de collaborer et de faire des compromis pour parvenir à un consensus sur les critères d’acceptation de chaque récit utilisateur, fonctionnalité ou problème et de tenir chaque membre de l’équipe responsable du respect de ce niveau d’exigence. Ces exigences doivent être claires, applicables et toujours accessibles.

Qui définit la Definition of Done ?

La mise en place d’une Definition of Done doit être une collaboration transversale entre les équipes produit, les chefs de projet, le contrôle qualité et les parties prenantes concernées. La définition de la DoD dépend des utilisateurs actuels et des priorités de l’entreprise, mais signifie généralement que le code développé répond aux objectifs des récits utilisateurs, de la fonctionnalité, de la version ou du problème, et ne provoque pas de rupture par rapport à un sprint précédent du développement du produit. 

À un niveau plus tactique et détaillé, les critères de la DoD peuvent ressembler à ceci : 

• Le code est écrit
• Le code est documenté
• Le code est révisé
• Le code ou la version est déployé dans un environnement de test 
• Le code réussit les tests

Outre les outils plus traditionnels de visualisation et de gestion de projet agile tels que les roadmaps produit et les tableaux Scrum, les outils de collaboration visuelle tels que Lucidspark peuvent également garantir la clarté des exigences de la DoD pour les équipes non techniques, l’accès de toutes les personnes concernées à ces exigences, ainsi qu’une vision partagée de ce qui est nécessaire pour faire évoluer la fonctionnalité, et de ce qui suivra. 

Créer une liste de critères et des exigences spécifiques pour répondre à la DoD (les critères d’acceptation) :

En termes simples, les critères d’acceptation sont les points de référence requis pour répondre aux exigences de votre DoD. Une fois la Definition of Done en place, il est essentiel de créer une liste de règles qui tiennent compte de l’ensemble du projet ainsi que du contexte du sprint en cours, et qui s’appliquent à chaque tâche de ce sprint, qu’il s’agisse d’une expérience applicative entièrement nouvelle ou d’une simple correction de bug. Le plus important, c’est la cohérence. 

Voici une liste simple de critères d’acceptation de l’état « terminé » ou « Done ». Remarque : ces critères peuvent changer à mesure que vos exigences et priorités en matière de DoD et de produits évoluent. 

• Test unitaire réussi
• Code révisé
• Critères d’acceptation pour chaque question respectés
• Tests fonctionnels réussis
• Exigences non fonctionnelles satisfaites
• Récit utilisateur accepté par le chef de produit

Une fois que ces points sont remplis, vous pouvez considérer qu’un sprint est « terminé », puis observer, tester et appliquer vos connaissances pour imaginer de nouvelles fonctionnalités produit, corriger les problèmes, itérer et optimiser les fonctionnalités actuelles, et planifier votre prochain sprint. Le point fort de la DoD agile ? Elle permet à votre équipe d’évoluer et d’apprendre en permanence. 

S’assurer que l’équipe soit responsable des éléments d’action

Il est essentiel que les critères d’acceptation soient partagés pour que chaque membre de l’équipe soit responsable de chaque étape. Au cours de votre processus de sprint planning, les membres individuels de l’équipe seront responsables de différentes étapes. Veillez à ce que vos critères d’acceptation et vos listes soient consultables parallèlement au travail en cours afin de maintenir la visibilité et la responsabilité à chaque étape du cycle de développement. 

S’assurer que la DoD répond aux besoins de l’organisation ou aux objectifs du contrat :

Pour éviter de perdre du temps et de se lancer dans des sprints inutiles, il est important de vérifier de temps en temps les priorités et votre DoD par rapport aux objectifs organisationnels plus larges afin de s’assurer de leur conformité et d’éviter tout point mort stratégique. Après tout, le succès d’un produit n’a de valeur que par les objectifs qu’il atteint. Une collaboration et une conformité minutieuses avec les principales parties prenantes et les chefs de produits garantiront que chaque sprint profitera à l’entreprise dans son ensemble. 

Pour de nombreuses équipes de développement de produits axées sur la qualité, il peut être tentant de viser la perfection pour chaque sprint et chaque version d’une application. Les équipes qui adoptent la DoD peuvent agir avec agilité, en apprendre plus sur leurs utilisateurs plus rapidement et, en fin de compte, fabriquer de meilleurs produits.