Definition of Done (DoD)

Qu'est-ce que Definition of Done (DoD) ?

" Le "Definition of Done" (DoD) est une description formelle de l'état de l'incrément lorsqu'il répond aux mesures de qualité requises pour le produit " - [Schwaber 2020].

Alors que Scrum a été créé en 1995, ce concept a été introduit dans Scrum à partir de 2009 [Verheyen 2020], apparemment à partir d'un patron proposé en 2002 par Dan Rawsthorne [Rawsthorne 2015]. La DoDcrée une transparence pour tous sur les artefacts livrés. Elle est basée sur une compréhension partagée de ce qui doit être fait pour que ces choses soient faites lorsqu'elles sont considérées au niveau du produit [Madan 2019] ; par conséquent, si plusieurs équipes travaillent sur le même produit, elles peuvent avoir des DoD différentes mais leur travail combiné doit impliquer une DoD basée sur le produit pour le rendre libérable. 

Même si cette approche a tendance à entraîner un échelonnement du SDLC, elle sera toujours préférable à la publication d'un code médiocre car, comme SAFe aime à le dire,"On ne peut pas mettre à l'échelle un code merdique" [SAFe 2021-42] et La DoDaide à connaître l'odeur à l'avance. Sans cela, le code est envoyé en production sans connaître les impacts qu'il aura sur les opérations. Cependant, l'échelonnement n'est pas une malédiction, tendre vers une organisation basée sur les Feature Team réduit ce goulot d'étranglement et il existe des tonnes de pratiques agiles qui aident à tout faire en même temps.

Impact sur la maturité des tests

La DoD Le concept est souvent confondu avec les "critères d'acceptation" (CA) ; en fait, alors que les CA varient de la User Story (US) à US, La DoD est de rang supérieur [Purushotham 2020]. Il est également applicable à tout élément du Backlog de produit (PBI) ainsi qu'à tout événement tel que le raffinement et la planification de sprint, les démonstrations ou les rétrospectives pour s'assurer que chaque cérémonie est complète [Dalton 2018].

La DoDse compose de trois éléments principaux [Madan 2019] :

• Exigences commerciales ou fonctionnelles : les CA
• Les questions de qualité subjectives ou mesurées, telles que la couverture des tests, l'ouverture du site bugs, etc.
• Exigences non fonctionnelles

Ces composants peuvent être perçus à l'aide d'une "grille de réflexion" [Gupta 2008] afin d'entrer dans les détails et d'identifier plus précisément les éléments d'une liste de contrôle.

‍

En fait, une étude des publications sur le site La DoDa permis d'identifier 62 critères qui couvrent 9 catégories, principalement axées sur la conformité réglementaire [Silva 2017].

‍

En effet, selon le point de vue adopté, La DoDaura des valeurs différentes selon la personne qui exprime ses attentes, ainsi différents niveaux de "Fait" peuvent être définis [Rawsthorne 2015] :

• US doit être "fait" - US est "fait" et est vérifié en termes de DoD.
• Les fonctionnalités doivent être "faites/faites/faites" lorsque toutes les composantes US sont "faites/faites" et que le PO valide que la fonctionnalité est suffisamment bonne.
• Les produits doivent être "Faits/Défaits"lorsqu'il y a suffisamment de fonctionnalités "Faits/Défaits"pour être utiles aux utilisateurs et que la version est prête du point de vue des opérateurs.

Ces boucles de rétroaction sur les statuts "Fait" sont simplement comme le processus d'apprentissage en double boucle d' Argyris [Argyris 1977] [Moustier 2020] ; bien faire les choses au niveau N permet de viser un niveau supérieur. Ils reflètent la maturité de l'équipe qui actualise La DoDdes contraintes internes et externes. Plus ils pratiquent les Gemba Walks ou agissent comme des X-Teams, plus le site La DoD est précis et pertinent [Moustier 2020]. Cependant, fixer une DoD avec des normes très élevées dès le début avec des équipes qui ne sont pas prêtes pour cela n'est pas une bonne idée. Tout comme pour les jeux, il faut avoir quelques victoires et de bons rendements de première passe pour s'y mettre. Il faut donc mesurer le bonheur au sein de l'équipe, notamment grâce à un simple calendrier Niko-Niko.

Quel que soit le contenu de votre DoD, la chose à garder à l'esprit est la dimension de "compréhension partagée". Elle ne doit donc jamais être poussée par une seule personne mais doit plutôt émerger des personnes qui seront chargées d'appliquer ces critères. Pour faciliter cette approche, un jeu de cartes appelé "DoD Kards" a été créé pour permettre à l'ensemble de l'équipe de décider du site La DoDà appliquer avec le site Product Owner [Velasquez 2017].

Le point de vue d'Agilitest sur cette pratique

D'un point de vue économique et DevOps, l'automatisation est un must have et l'automatisation des scripts de test est inévitable et cela devrait alors faire partie de tout DoD au niveau US . De plus, lorsqu'il s'agit de l'automatisation des scripts de test, les scripts doivent être traités comme du code de production, ce qui implique également des critères supplémentaires sur La DoDpour permettre des scripts maintenables et durables tels que "FIRST" [Tekguard 2018] [Moustier 2019-1] ou l'utilisation de harnais de test pour permettre la testabilité et l'exécution rapide des tests.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍