Six conseils pour améliorer votre définition de “Fini”

Rappels

La définition de “Fini”,  “Definition of Done”  ou DoD[1] en anglais représente les critères qui déterminent si un travail est accompli. Cette définition peut concerner les éléments du Backlog du produit (Les fonctionnalités à réalise), les tâches qui réalisent ces éléments, l’incrément (le résultat d’un Sprint) et la release finale du produit.
Il s’agit d’un artefact important dans Scrum car  Il  permet à tous les participants  au projet de partager une signification commune des résultats attendus.

La définition de “Fini” ou DoD, doit donc être explicite est visible à l’intérieur et à l’extérieur de l’équipe Scrum. Parmi les objectifs attendus du DoD :

  • Eviter le syndrome de “Fini à 90%”. Ce syndrome cause souvent des dégâts dans les projets. En effet, ce sont en général les 10% restants qui consomment 90% du budget et provoquent les dépassements.
  • Permettre au Product Owner de définir les critères d’acceptation des résultats. Ces critères, définis explicitement, lui permettront d’accepter ou de refuser le travail fourni par l’équipe de développement.
  • Permettre à l’équipe de développement lors de la décomposition des éléments du Backlog du Produit en tâches de réalisation,  de tenir comptes de toutes les tâches nécessaires à la satisfaction du DoD. En effet, en ayant en tête les critères d’acceptation, l’équipe pourra identifier, en plus des tâches de codage,  des tâches auxquelles elle n’aurait pas pensé. Par exemple, les tests, la documentation, le déploiement, etc. Ces tâches sont consommatrice du temps. En tenir compte dans le processus de planification permet d’avoir des plannings plus fiables.

Conseils pour élaborer le DoD

Conseil N°1

Élaborez une   un DoD propre à votre équipe et à votre projet.  Chaque étant  différent, il n’existe pas de définition générique pouvant s’appliquer sur tous les projets.

 Conseil N°2

Jouez collectif. Toute l’équipe Scrum (Product Owner, Equipe de développement, Scrum Master) doit participer à l’élaboration du DoD. Cela permet d’aboutir à une définition consensuelle et partagée.

 Conseil N°3

Assurez-vous de la visibilité du DoD. L’équipe peut disposer de plusieurs moyens pour assurer cette visibilité : Affichage sur le mur Agile de l’équipe, diffusion sur un  Wiki dédié au projet, etc.

Conseil N°4

Considérez un DoD pour chacun des quatre artefacts suivants : Les tâches, les éléments du Backlog, l’incrément produit par le Sprint et le release finale :

  • Un DoD pour les tâches : Avoir un DoD pour chaque tâche permet aux membres de l’équipe de bien l’estimer et considérer toutes les facettes du travail nécessaire.

  • Un DoD pour  les éléments du backlog du produit : Avoir un DoD pour chacun  des éléments du Backlog du produit permet de spécifier ses critères d’acceptation. Le Product Owner ce sert de ce DoD pour valider les résultats de l’équipe.
  Un DoD pour l’incrément du Sprint : L’incrément du Sprint est l’ensemble des fonctionnalités réalisées dans le Sprint. Avoir un DoD au niveau de l’incrément permet de garantir que les fonctionnalités mises ensemble  forment un résultat exploitable et  potentiellement livrable en production.

  • Un DoD pour  la release : La release peut être considérée comme l’incrément résultant du dernier Sprint. On peut alors considérer que le DoD de la release est celui du dernier incrément. Cependant,  avoir un DoD pour la release permet d’étendre et rendre les critères d’achèvement plus stricts. Cela et notamment utile dans le cas où les incréments intermédiaires ne sont pas destinés à un déploiement en production.  Le DoD de la release peut alors contenir des critères de tests en environnement de pré-production, l’établissement d’un planning de mise en production, etc.

 Conseil N°5

Fixez des objectifs réalistes. Il est inutile d’avoir des DoD qui ne seront jamais atteints car trop stricts ou pas faisable. Lors d’une mission de diagnostic que j’ai effectué sur un projet Agile, le DoD de l’incrément (réalisé en sous-traitance) stipulait que l’incrément doit être testé sur des données provenant de la production. Or pour des raisons de confidentialité, les données de la production n’étaient pas accessibles au sous-traitant.  Il faut donc avoir des objectifs réalisables même moins ambitieux quitte à les améliorer par la suite (conseil N°6 ci-dessous).

Conseil N°6

Entretenez régulièrement vos DoD. Cet entretien peut s’avérer nécessaire pour diverses raisons :

  • Entretien pour adaptation. Le DoD peut devenir inadapté et obsolète. Par exemple pour cause de changement du contexte du projet. Il faut modifier le DoD de façon à tenir compte du nouveau contexte.
  • Entretien dans une démarche d’amélioration continue. Une équipe qui débute dans Scrum peut commencer par définir des DoD “minimalistes”.  A mesure que sa maturité augmente d’un Sprint à l’autre, elle peut étendre  ses DoD pour  inclure des critères plus stricts et avoir une qualité meilleure.

La rétrospective du Sprint est une bonne opportunité pour évaluer le DoD et définir un plan pour l’adapter et l’améliorer.


[1] « DoD» n’est pas un acronyme officiel mais il est largement utilisé par la communauté Agile.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s