L’importance du Definition Of Done

Posté le par Jean Francois Helie

Nous voici en bilan d’itération d’une équipe agile, l’objectif du client est de valider les stories et de déterminer la vélocité de l’équipe

  • « La story 30 est-elle bien terminée ? » demande le client
  • « Oui mais il manque des tests Fitnesse », répond le chef de projet
  • « Bon, s’il manque que les tests Fitnesse, on peut la mettre à terminé plus tard. On va voir ce que ça donne « , dit le client
  • Le client teste l’application à partir de son navigateur web
  • « Mais il manque la validation du champ de saisie ! », s’exclame le client

  • « Oui, c’est pas grave, on le fera ensuite, tu peux mettre la story en jaune, on la mettra à vert cette après-midi », dit le chef de projet
  • « Bon … », dit le client (qui commence à perdre confiance)
  • « La story suivante, …, 41, où en est-elle ? », demande le client
  • « On l’a développé mais pas commité sur le serveur d’intégration, mais Marco qui est là peut te la montrer sur son poste de développement », répond le chef de projet
  • « Non, mais ça va pas ! », dit le client
  • « C’est pareil, tu sais », dit le chef de projet

Ce genre de réunion peut vous arriver à partir du moment où l’équipe n’a pas défini ce qu’est le Definition Of Done pour elle. Sans DOD, vous pouvez rester dans le doute, le client peut perdre confiance et l’équipe peut oublier que le code doit être de qualité. Plus grave, sans DOD ou règles de qualité fixées par l’équipe, l’équipe sera limitée dans son développement et son efficacité

Exemple de DOD d’une équipe:

  • > 80% de couverture de code par les tests unitaires
  • Build OK sur plateforme d’intégration
  • Test manuel de chaque story
  • Revue de code croisée
  • Fitnesse valide

8 commentaires sur “L’importance du Definition Of Done”

  • Emilie Chabbouh
    Dans notre équipe, on avait commencé avec un DOD de ce genre, mais nous rencontrions fréquemment le cas d'une story passée à "A valider" qui était bugguée techniquement du coup elle repassait à "En cours" dès que la MOA commençait à la tester. L'équipe a identifié le problème en rétrospective, et nous avons décidé de re-travailler sur le DOD (en cours d'itération 3) pour limiter les allers-retours entre "A valider" et "En cours". Résultat, on a découpé le Definition of Done en plusieurs parties : - Pour mettre une story dans le backlog de l'itération n+1 (tout ce qui a trait à la rédaction des tests de recette) - Pour passer une story à "A valider" (couverture TU, build OK sur intégration, test manuel de la story par l'équipe de dev) - Pour passer une story à "Done" (test manuel de la story par le PO) - Pour préparer la démo de fin d'itération (build OK sur UAT, non régression, doc à jour) - Pour la livraison d'une release (doc d'exploit, doc utilisateur) avec la responsabilité associée à chaque item du DOD : dev, PO, CP... Pour l'instant, nous n'avons pas encore entamé les tâches pour la livraison d'une release, mais elles sont affichées, et on sait qu'on devra prendre du temps pour rattraper cette "dette" à un moment ou un autre.
  • Ismaël Héry
    Pas mal votre process Emilie. Si en plus vous limitez le Work in Progress à chaque étape vous êtes à deux doigts de faire du "Kanban" !
  • Emilie Chabbouh
    Justement... Sur les premières itérations, nous avons observé que nous avions beaucoup de stories "En cours" juste avant la fin de l'itération. Cela augmentait le risque : plusieurs stories risquaient de ne pas passer à "Done" pour la revue. Nous avons modifié le scrumboard, de façon à n'avoir que 4 "places" pour les stories "En cours", sachant que l'équipe compte 5 développeurs. Je pourrai vous en dire plus sur l'efficacité de cette action à la fin de l'itération !
  • Gilles
    Limiter l'en-cours est une très bonne idée ! A rapprocher de l'approche Scrum-(kan)ban http://leansoftwareengineering.com/ksse/scrum-ban/
  • Gilles S
    Merci pour ce partage Emilie. Je voudrais juste savoir si vous avez des tests fonctionnels de type Fitnesse svp ? Dans mon experience de l'"agile", meme les TU que nous faisions dans les premieres itérations sont rapidement devenus obsoletes et "l'agilité" (evolutions des besoins...) a eu raison des tests programmatiques :) Nous avons travaillé avec une autre personne pour constituer des tests fonctionnels au niveau navigateur avec un outil de test du marché. De meme, l'agilité du projet a également eu un gros impact sur la qualité du code produit par les équipes... Merci encore
  • Nico
    Bonjour, vous pouvez également vous inspirer de la méthode de gestion du DOD issue de la présentation suivante : http://www.sigmat.fr/dotclear/index.php?post/2009/03/27/Le-retour-d-exp%C3%A9rience-d-Atchik-Realtime
  • Emilie Chabbouh
    Bonjour Gilles, Concernant les TU : Nous travaillons en TDD. Du coup, pour faire évoluer une fonctionnalité, les développeurs commencent par modifier le TU, le lancent (et le font planter, forcément) puis font évoluer le code. Ainsi, les TU ne sont jamais obsolètes. Concernant les tests fonctionnels : Le contexte projet fait que nous n'avons pas automatisé les tests fonctionnels pour l'instant (pas de Fitnesse). Mais nous prévoyons de le faire pour la prochaine release. En revanche, nous avons un wiki dans lequel les MOA écrivent un hybride de test fonctionnel et spécification (et le font évoluer quand la fonctionnalité évolue). Les MOA testent chaque story réalisée sur la base de ce pseudo test de recette. Par ailleurs, avant de passer une story à "A valider", les développeurs testent l'application sous IE6 (navigateur qui sera utilisé par les utilisateurs) pour éliminer une bonne partie des bugs avant la validation fonctionnelle. Cette règle est d'ailleurs écrite dans le DoD.
  • Pierre Neis
    La DoD est le coeur même de Scrum (désolé, mais je pense que les projets évoqués sont principalement XP). Dans SCRUM, la DoD est à plusieurs niveaux: le produit, le process, l'architecture, le Sprint, la tâche. La règle de base est: testé, documenté, et potentiellement livrable. La tâche, la story lorsqu'elle est DONE, celle-ci définitivement terminée. Qui décide du DONE? - au niveau du Produit: c'est le Product Owner étant donné qu'il est le responsable du produit et qu'il gère le Release Plan. Il accepte que les Sprints Done: càd. si 99% du Sprint Backlog est DONE, le Sprint est rejeté et les Items seront intégrés dans le nouveau Sprint Planning : HALF DONE IS NOT DONE, QUALITY FIRST. En clair, si le Sprint est DONE et qui vous n'avez validé les tests d'usabilité et que votre liste de bugs est vide et que tous les critères d'acceptance ont été validé. - au niveau du Process: c'est le Scrum Master inspecte et adapte le Process Scrum lors de la Rétrospective. Dans les équipes Scrum performantes, le Scrummaster défini un level of Done (continuous deployment, deployment, continuous integration, automatisation des tests, tests unitaires, etc...). Dans les équipes distribuées, le Scrummaster inspecte et adapte le Process/Flow au niveau de l'équipe et rapporte au Process Master pour faciliter l'alignement. - au niveau de l'architecture: l'architecte valide l'architecture du produit et rapporte au niveau supérieur. (là, j'avoue, je chipote un peu...) Pour conclure, pas DoD si pas de Definition of Ready. Pas de Scrum si pas de DoD. ex. Les Scrum considérant le client comme le Product Owner accepte les demandes des clients sans tenir compte de la qualité du Produit: cela donne fréquemment des Projets qui démarrent et qui ne finissent jamais. DoD c'est le contrat entre le Product Owner et l'Equipe afin que celle-ci puisse évaluer correctement les charges imputables à chaque tâche en respectant la stratégie de qualité définie au préalable.

      • Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha