Jouez avec la « definition of done »

Validation fonctionnelleLors d’un moment d’échange entre équipes agiles, nous avons eu de vives discussions sur « les tests fonctionnels ».

D’un côté, certaines équipes prônaient la validation fonctionnelle dans la définition du terminé. Cela pouvait se faire de plusieurs manières :

1 – Par délégation : La User Story est claire pour l’équipe, le P.O partage ce sentiment et les critères d’acceptation sont écris et non ambigus. La « simple » écriture d’un scénario avec Sélénium servira de validation fonctionnelle.

2 – Par participation : Le P.O est sollicité pendant le Sprint afin de validé la Story.

3 - Par la démo : Le P.O valide pendant la démo.  :)

Dans tous les cas, il s’agit de validation et non de remise en question de la fonctionnalité. Si le besoin change, on laisse tomber la fonctionnalité : elle ne sera pas produite (terminée) lors du Sprint et le P.O pourra de nouveau la présenter lors du prochain SPM.

De l’autre côté, d’autres équipes prônaient la validation fonctionnelle en dehors du Sprint. Le principe est le suivant :

  1. La User Story est développée lors du Sprint X : elle est présentée au P.O lors de la démo.
  2. Le P.O prend le temps de la valider pendant le Sprint X+1.
  3. Si la Story ne « marche pas » ; alors il y aura une « Bug Story » lors du Sprint X+2. S’il faut la compléter ou modifier son fonctionnement, alors il y aura une nouvelle « User Story »

Ces 2 approches ont leurs avantages :

  • Dans la première, la définition du « done » est claire : on peut mettre en production. Comme lu sur Twitter cette semaine :

@danielbrolund If « done » doesn’t mean 100%, « donedone » is less and « donedonedone » even less. Compare 0.99>0.99*0.99>0.99*0.99*0.99. :-)

  • La deuxième solution a aussi son avantage : elle réduit la « pression » mise sur la validation fonctionnelle et permet à l’équipe d’avancer !

Je vous propose donc le jeu suivant :

Pour vous, est-ce que la validation fonctionnelle (par le P.O) doit être dans la "definition of done" ?

  • Oui (73%, 16 Votes)
  • Non (23%, 5 Votes)
  • Ca dépend : Cette réponse est réservée à Alex :) (4%, 1 Votes)

Total Voters: 22

Loading ... Loading ...

Fin du jeu Dimanche 29 à 23h59 :)

7 Réponses à “Jouez avec la « definition of done »”

  1. Nathalie :

    Bonjour, C’est effectivement un bon questionnement.
    Pour nous, nous le considérons toujours dans la définition du « Done Done ». Par User Story nous avons systématiquement les tâches suivantes :
    - Code review
    - Correctifs suite au code review
    - Revue fonctionnelle (consiste à faire passer tous les tests case)
    - Revue de QA (nous essayons de le faire faire à une personne non technique, ou externe au projet)

    Les stories ne sont pas fermées avant cela. Mais c’est l’idéal dans le meilleur des mondes, souvent nous sommes justes dans le temps !

    Dans tous les cas, après déploiement chez le client, il y a toujours des ajustements à faire au sprint x+2.

    Alors je dis oui dans le done done, et un peu dans le cela dépend !!

  2. Alex :

    Tu sais ce qu’elle te dise les minorités à moustache … enfin j’ai quand même voté « Ca dépend » même si j’avais envie de voter non.
    Il est important que l’équipe monte en puissance et en connaissance sur les aspects fonctionnels, il faut le le produit devienne le produit de l’équipe et non celui du Product Owner.
    Donc un DONE au niveau de l’équipe devrait être suffisant sans avoir besoin d’intégrer le DONE du PO dans le DOD … mais je reconnais que cette situation n’est pas e,core la majorité des cas.
    Sur les nombreux projets que je coacg, j’ai vu des équipes fonctionner avec succès dans les 2 modes que tu décris (1 et 2 … mais pas le 3 qui n’est qu’une conséquence) mais également être en échec dans les 2 modes … d’ou ma réponse « Ca dépend » que je te remercie de m’avoir réservé :)
    Amitié
    Alex

  3. dibus :

    Salut Alex ! Cela me fait toujours très plaisir de te lire ici ! Est-ce que tu penses Est-ce que tu penses qu’une des 2 solutions est plus « Scrum » que l’autre ?

  4. fxMaq :

    Je connais plutôt le premier mode. Je n’ai pas eu l’impression que cela ait empêché l’équipe de s’approprier le produit :) Malgré ce que dit Alex, mon sentiment est que moins les choses sont ambiguës entre le PO et l’équipe mieux cela vaut pour tout le monde.
    Dans le deuxième mode : comment le PO définira t-il que la story « ne marche pas » ? pour moi, pour que la story soir claire et bien développée, les critères doivent être clairement exprimés (ils ne doivent pas être définis lors du test).
    Dans le premier mode le fait de valider lors de la démo, n’empêche pas une validation plus poussée lors du sprint x+1 pouvant être à l’origine de l’ajout d’une nouvelle story pour le sprint x+2 …

    En tout cas, le plus important pour moi est de savoir que la question se pose et donc qu’il faut se la poser si nécessaire :) (j’avoue que je ne me l’étais pas posée jusqu’à maintenant)

  5. Eric :

    Salut,
    J’ai affiché ta question pendant la formation PSM ce matin après le chapitre sur le Done et laisser 5 minutes de réflexion aux participants.

    Tout d’abord ils ont tous voté oui pour les raisons suivantes, dont je vous laisse juge d’apprécier la pertinence:
    - si le Done n’est pas complet, le PO ne sait pas ce qu’il inspecte pendant la Revue
    - si le Done n’est pas complet, le sentiment qu’à l’équipe d’avancer est illusoire
    - si le Done n’est pas complet, le PO est incapable de libérer une version à la fin d’une itération si cela fait du sens pour lui

    De plus nous avons relevé quelques points que nous porterions à l’attention de l’équipe:
    - Chers PO et Equipe, Pourquoi créer des « Bug story » alors qu’il suffit de ré-ouvrir la story d’origine qui s’avère en fait non acceptable en l’état ?
    - Chers PO et Equipe, J’ai peur que le fait que vous utilisiez le terme « Démo » soit un indicateur que vous pourriez tirer beaucoup plus de vos « Revues ». Consacrer vous bien du temps à mettre à jour votre backlog, votre done, à décider si cela est censé de libérer une version, à décider s’il faut continuer ou bien arrêter ce projet ?
    - Cher PO, quel est l’intérêt premier de faire du Scrum pour toi ? Qu’est-ce qui a changé pour toi ?

  6. Laurent :

    Hello les intellectuels du DON,

    je pourrai en parler en live à Mr Dibus qui bosse à 5m. de mois, mais autant utiliser le WWW pour élargir le cercle de nos amis et de cette discussion :

    DON
    = fait
    = en on parle plus
    = tout ceux qui ont eu l’occasion de s’exprimer ont approuvé
    =tous ceux qui ont eu l’obligation de s’exprimer n’ont pas émis de réserves
    = on met le sprint en production, point barre
    = le sujet et clôt, point barre

    pourquoi tergiverser sur un done à X étages ?

    a+

    L.

    PS : point barre est une excellente émission sur couleur3.ch à écouter sur le oueb

    tergiversation = équipe pas maturez comme le commente Alex, le pb n’est donc pas le DOD

    L.

  7. Cécile :

    Je me permets de réagir parce que « tergiverser » ne me semble pas être le bon terme.
    Je suis SM sur une plateforme de TMA et notre PO est bien présent mais à distance.
    Nous devons donc, pour nos démos mais à fortiori à chaque fois que l’on veut présenter notre travail, livrer sur notre plateforme de recette.
    Cette plateforme est tenue par notre exploitant, nous n’avons donc pas les mains libres pour déployer quand et comme nous voulons.
    Ainsi une livraison en recette nous prend 1 journée en délais. Sur un sprint de 3 semaines nous ne pouvons pas nous permettre de faire des MER aussi souvent que souhaité pour faire valider notre travail par le PO.
    Notre équipe est suffisamment montée en compétence et en qualité pour avoir un 1er filtre de validation.
    Chez nous la DOD est exprimée fonctionnellement par le PO lors de la sélection de la US dans le sprint et c’est moi, non technique, qui valide la US pour la démo sur la base définie par le PO.
    Cette US ne sera effectivement fermée qu’à l’issue de la démo si le PO la valide mais cette « double » étape de validation ne ma parait pas être une entorse au bon déroulement de notre Scrum.
    C’est juste une manière d’adapter la méthode à nos contraintes techniques et pour moi c’est ça être agile. En outre ça permet à l’équipe de se concentrer sur ce qu’elle a estimé.
    Si le PO ne valide pas la US c’est souvent parce que le besoin n’était pas bien exprimé et/ou compris et ça nous arrive de moins en moins.

    Ceci dit nous sommes en TMA et nos sprint sont donc composés à 80% de « bugstory » et non pas de constructions neuves, ceci explique peut-être cela.

Mettre un commentaire