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.
