Commentaires sur : Une définition de TERMINE

Par : Rémy Sanlaville

Rémy Sanlaville — Mon, 20 Apr 2009 14:23:37 +0000

Je suis tout a fait d’accord sur l’importance de se mettre d’accord sur le TERMINE (DONE).

Par contre, cela n’est pas souvent si facile que cela (ce qui est le problème de nombreux projets).

Par exemple, que signifie exactement le premier item de la liste de Scott : Fonctionnalité complètement implémentée ?

En tant que développeur, qu’est-ce qui me permet de dire que la fonctionnalité est complètement implantée ? Comment le PO décrit les conditions pour indiqué que la fonctionnalité est complètement implantée ?

On commence à avoir des éléments de réponses avec le BDD/TRD… mais c’est qu’un début.

Par : Alexandre Boutin

Alexandre Boutin — Wed, 15 Apr 2009 12:29:23 +0000

Il est vrai que chez Yahoo nos clients sont les internautes … donc à la fois personne en particulier et tout le monde en général … et que nous avons besoin d’un PO en interne qui représente l’ensemble de ces clients.

Je reconnais que dans le cas évoqué j’ai considéré que le PO était le représentant du client et pas le client lui-même, ce qui est malheureusement TRES SOUVENT le cas et pas seulement chez Yahoo. Pour ce qui est du cas idéal décrit par Beck, ta remarque est donc parfaitement valable

Par : Fabien Bézagu

Fabien Bézagu — Wed, 15 Apr 2009 12:16:51 +0000

Hmmm, tu sembles dire que le PO n’est pas le client. Ça me paraît pour le moins paradoxal.

Par : Alexandre Boutin

Alexandre Boutin — Wed, 15 Apr 2009 11:51:03 +0000

Dans ce cas, je reprendrais les mots de Mary Poppendieck qui dit : « si un défaut est connu et non corrigé, alors il devient un comportement normal de l’application (une fonctionnalité) et ne doit plus être considéré comme une défaut »

Et on retombe alors sur le « pas de défauts connus », car l’approche de Beck me semble laisser une trop grande porte ouverte au Product Owner qui préfèrera livrer au client plutôt que corriger et qui entraînera l’équipe dans la spirale infernale du « legacy code » qui augmente.

Par : Fabien Bézagu

Fabien Bézagu — Wed, 15 Apr 2009 10:34:21 +0000

Je ne suis pas tout à fait d’accord sur le troisième point («Pas de défauts connus»).
Je retiens plutôt l’approche de Beck : les défauts connus par l’équipe de développement doivent être exposés au product owner qui décide en connaissance de cause.
C’est le product owner qui possède les éléments permettant d’évaluer et, le cas échéant de prendre, les risques.