Definition Of Done

Nicolas V

Vous commencez à travailler sur un produit en adoptant l’état d’esprit Agile ? Ou êtes-vous peut être déjà en train de travailler sur son évolution… Avez-vous déjà entendu parler de la Definition of Done (définition de fini) ?

DOD

 

Watch10 min de lecture

Rien de mieux qu’un exemple concret pour vous présenter et comprendre à quoi va servir la Definition of done (definition de fini) :

– la story 34 sur la gestion d’erreur elle en est où ?
– elle est finie, je l’ai passée en done (finie).
– ah bon, mais le client vient de me dire qu’elle manque dans la revue
– ça je ne sais pas, moi tout ce que je dis c’est que pour moi elle est finie
– mais elle est déployée ?
– aucune idée

Ça vous évoque des souvenirs ? C’est pour éviter ce genre de dialogue que la Definition of Done (définition de fini) doit être définie.

Avant le premier Sprint, le Product Owner et l’équipe ont besoin de s’accorder sur la Definition of Done, qui est un sous-ensemble des activités nécessaires pour créer un incrément de produit potentiellement livrable (Potentially Shippable Product Increment).

Ken Shwaber insiste sur l’incertitude introduite sur la possibilité de livraison. Il reste x effort à fournir pour livrer réellement. En cumulant, les effort ainsi empilés sur une release, on arrive à un décalage de la date prévue et à un manque de prédictibilité.

En fait Jeff Sutherland insiste aussi, les Dupont-Dupond sont d’accord là-dessus :

[youtube https://www.youtube.com/watch?v=Jlb195JT7hM]

 

 Rédigeons notre Definition of Done

La Definition of Done doit être partagée par les membres de l’équipe. Il est donc important que tout le monde participe : scrum master, Product Owner, developpeurs, testeurs…

Cette definition peut se découper en plusieurs thématiques, voici un exemple :

  • Les tests unitaires sont effectuées
  • Le code est examiné par les pairs (s)
  • Le code est inspecté
  • La user story est bien intégrée
  • La user story est documentée

C’est encore flou ? Voici un exemple réel d’une definition of done :

  • Les tests d’acceptance associés à la story sont tous implémentés et passent
  • Le code est mergé dans le tronc et a été nettoyé
  • Le nouveau code s’intègre correctement et les tests de non-régression passent sur l’ensemble du code
  • La version incluant cette évolution a été déployée en environnement de qualification
  • Le  gestionnaire de suivi a été mis à jour (demande close)

Vous avez votre liste ? Affichez-là dans le bureau. Elle doit être accessible et visible par tous.

 

[box type=”info”] Attention, cette définition n’est pas gravée dans le silicium. Elle est amenée à évoluer, par exemple suite à des feedbacks pendant la revue de Sprint.[/box]

Guide Scrum 2013 :

“au fur et à mesure que l’équipe Scrum prendra de la maturité, on s’attend à ce que leur définition de « terminé » s’étende progressivement pour inclure des critères plus rigoureux, permettant un niveau de qualité plus élevé.”

 

7P de l’atelier  :

C’est bien joli et facile sur le papier mais concrètement comment je fais pour animer ce workshop ? Je vous propose d’utiliser un  7P (créateur : James Macanufo) :

  • Purpose – objectif : En tant que membre de l’équipe, je veux identifier et partager avec mes collègues la definition of done afin que tout le monde soit d’accord sur ce qu’est une user story finie.
  • People – participants : Product Owner, Scrum Master, Testeurs, Développeurs. L’expertise de chacun dans son domaine va permettre d’avoir une definition of done qui couvre tout le processus de cycle de vie de la user story.
  • Product – produit : A la fin du workshop nous voulons une feuille de paper board avec la liste des critères que nous devrons respecter pour dire qu’une user story est finie. L’équipe doit être d’accord avec ces critères.
  • Process :
      •  5 min : Introduction des règles du workshop et présentation de l’objectif ainsi que du livrable attendu.
      • 10 min : Par binôme rédiger les idées sur des post-it
      • 20 min : Partage, mettre les post-it au mur
      • 45 min : Prioriser les points les plus important, ceux qu’il faudrait commencer demain
  • Préparation : Demander à votre équipe d’aller chercher des informations sur la definition of done sur internet avant de venir au workshop.
  • Practical concerns : Nous aurons besoin de post-it des marqueurs, un paper board
  • Pitfalls – Risques :
    • Ne pas être d’accord et tourner en rond sans s’écouter : proposez à l’équipe d’identifier les bénéfices et les limites du point qui pose problème, donner du sens aux mots pour que tout le monde comprenne de quoi l’on parle.

 

Pour aller plus loin, avez- vous déjà entendu parler de la Definition of Ready (definition de prêt) ? Le couple Definition of Ready et Done (definition de prêt et fini) formant le contrat entre le P.O. et l’équipe de réalisation permettant l’auto-organisation technique de l’équipe. A découvrir dans un prochain article.

En attendant, partagez avec nous vos Definitions Of Done dans les commentaires.

Auteur / autrice

S’abonner
Notification pour
9 Commentaires
Le plus récent
Le plus ancien
Commentaires en ligne
Afficher tous les commentaires

Bonjour,

Les explications et la méthodologie sont très clairs mais dans la pratique il y a beaucoup de questions auxquelles de je trouve pas de réponses :
1. Que faire si le produit est déjà en prod et que le Backlog est constitué principalement de bogues qu’il faut traiter et tester sur 3 environnements recette, préprod et Prod ?
2. Comment une équipe constituée de testeurs et de développeurs peut se mettre d’accord sur la définition de Done ( Pour les testeurs c’est validé et pour les développeurs c’est résolu) ?
3. Que faire dans le cas où un élément ne peut être validé réellement que par le client qui n’est pas toujours disponible ?

Merci pour votre retour.

J’ai appliqué à la lettre pour un résultat à 80%. Pas si mal pour une première itération. La difficulté fut surtout de se concentrer sur la terminologie comprise (et connue) par chacun.

Merci Nicolas pour ce canevas. A suivre …

François (Business & Agile Coach – Belgium)

You’re Welcome 🙂

[…] Article de Nicolas Verdot pour Coactiv. […]

[…] Article de Nicolas Verdot pour Coactiv. […]

[…] Article de Nicolas Verdot pour Coactiv. […]

[…] Article de Nicolas Verdot pour Coactiv. […]

[…] Article de Nicolas Verdot pour Coactiv. […]

[…] Article de Nicolas Verdot pour Coactiv. […]