Commentaires sur : Jouez avec la « definition of done »

Par : Laurent

Laurent — Wed, 09 Nov 2011 20:56:18 +0000

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 ?

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

Par : Eric

Eric — Fri, 27 May 2011 16:30:03 +0000

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 ?

Par : fxMaq

fxMaq — Thu, 26 May 2011 08:33:31 +0000

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)

Par : dibus

dibus — Wed, 25 May 2011 20:43:05 +0000

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 ?

Par : Alex

Alex — Wed, 25 May 2011 20:36:26 +0000

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