top of page
Rechercher

La D.o.R et la D.o.D, qui les prépare ? Et à quoi servent ?

Photo du rédacteur: Abdellah MANNIOUIAbdellah MANNIOUI

Dernière mise à jour : 6 janv. 2020


Parmi les problèmes et les douleurs observées chez pas mal des équipes agiles c'est la perte du temps dans la phase d'affinage et préparation des User Stories. L'équipe de développement essaye de comprendre le besoin en posant plusieurs questions, et en demandant tous les Input nécessaire pour qu'une User Story soit prête pour la réalisation, ainsi que le Product Owner essaye de récupérer le maximum de détail et des éléments nécessaire suite à la demande de l'équipe de réalisation.


Aussi bien le problème de validation des US terminées que ça soit de la part du PO, ou des parties prenantes lors de la cérémonie de sprint Review, Car on se trouve souvent dans des situations de manque de synchronisation et alignement des acteurs.


Afin de remédier à ces problèmes, et démarrer le projet avec une vision claire et partagée de ce qu'il faut donner comme éléments nécessaires de la part du Product Owner et Parties Prenantes pour bien comprendre et accepter le besoin, ainsi de ce qu'il faut préparer et livrer à chaque fois de la part de l'équipe de développement pour accepter les incréments produits et le travail réalisé lors d'un Sprint, il est vivement recommandé d'organiser un atelier lors de la phase de cadrage initiale intitulé "DoD / DoR".


La Definition Of Ready :


La D.o.R (Definition Of Ready) est une liste des critères et éléments élaborée initialement par toute l'équipe agile Scrum, et de préférence dans la présence des parties prenantes, afin de se mettre d'accord sur les éléments à fournir avec chaque besoin afin qu'il soit accepté par l'équipe de développement pour l'estimer et le réaliser. Il s'agit d'un réflexe de groupe.


Cette liste doit contenir le nécessaire pour que le besoin soit clair, précis, réalisable, estimable, et bien sûr acceptable par l'équipe de développement, comme ça on évite la perte du temps, et les aller-retour lors de la phase d'affinage. Cette liste sera un outil et un référent visible et bien compris par tous les acteurs, et en cas de besoin on peut modifier son contenu lors de Sprint Retrospective.


Le contenu de la D.o.R peut contenir différents critères touchant les 3 phases (Conception, Développement, et Test), en occurrence :


  • Une maquette type s'il s'agit d'un nouveau écran.

  • La valeur métier associée.

  • Liste des règles de gestion associées.

  • Liste des tests d'acceptation.

  • La liste des dépendances est bien décrite.

  • La stratégie de la démonstration est bien comprise par les développeurs et testeurs.

  • Etc....

La Definition Of Done :


La D.o.D (Definition Of Done) à son tour est une liste des critères qui doit être vérifiée et réalisées afin qu'on puisse considérer que la demande ou l'User Story en question est terminée (Statut "DONE"). C'est à dire qu'elle est candidate pour mise en production.


Cette liste va garantir que tout les acteurs ont la même vision de ce qui est attendu par chaque demande en terme de besoin fonctionnel, valeur métier, et qualité, et tout cela en toute transparence.


Cela va aider beaucoup l'équipe de développement lors de l'estimation des demandes, car ils auront une visibilité claire sur ce qui attendu comme travail et réalisation à part le codage.


Cette liste doit contenir l'ensemble des critères liés aux trois volets (Fonctionnement, qualité Interne, et qualité Externe), en occurrence :


  • Revue de code si nécessaire.

  • Standard du code à respecter.

  • Tests d'acceptation bien passés.

  • Version du code si nécessaire.

  • Tests croisés si nécessaires.

  • Tests de Performance.

  • Validation de l'User Story par le Product Owner.

  • Documentation à fournir si demandée.

  • ...Etc.

Conclusion :


Le contenu de la "D.O.R" et "D.O.D" n'est pas gravé dans le marbre, mais plutôt il est personnalisé et modifiable par l'équipe en cas de besoin selon l'environnement et contexte du projet, et il est toujours préférable et recommandé d'inviter tous les acteurs lors de l'atelier de création ou mise à jour de ces deux listes.


Il est fortement recommandé d'initier ces deux liste lors de la phase de cadrage du projet, à condition de ne pas les utiliser comme des freins ou des cartes dans le cas de tensions ou conflits entre les acteurs d'une équipe ou projet.








21 vues0 commentaire

Posts récents

Voir tout

Commentaires


Post: Blog2_Post
bottom of page