Ca Scrum !

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 :

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 :

 Loading ...

Fin du jeu Dimanche 29 à 23h59 :)