Jouez avec la « definition of done »
Lors 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 :
- La User Story est développée lors du Sprint X : elle est présentée au P.O lors de la démo.
- Le P.O prend le temps de la valider pendant le Sprint X+1.
- 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 ...Fin du jeu Dimanche 29 à 23h59 :)
25/05/2011 à 20:31
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 !!
25/05/2011 à 21:36
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
25/05/2011 à 21:43
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 ?
26/05/2011 à 09:33
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)
27/05/2011 à 17:30
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 ?
9/11/2011 à 21:56
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.