Se mettre d’accord sur la définition de TERMINE (ou DONE) prend parfois beaucoup de temps à l’équipe et est souvent sujet à moult discussions si l’équipe n’a pas encore la maturité nécessaire dans sa pratique de l’agilité.
Cette démarche est pourtant ESSENTIELLE dans la vie du projet et contribue fortement au succès, ou échec, de l’utilisation d’une méthode Agile. Pour ceux qui auraient des difficultés à s’accorder sur la définition de TERMINE, je vous recommande d’écouter les conseils de Scott Downey (Coach Agile chez MySpace)
Lorsque Scott accompagne une équipe vers l’hyper-productivité (de 100 à 240) en 6 à 12 semaines (pour Scott la bonne durée d’une itération est 1 semaine), il préfère imposer sa définition initiale du TERMINE tant que l’équipe n’est pas en mesure de proposer quelque chose de plus pertinent.
Le TERMINE de Scott comporte les 5 points suivants :
- Fonctionnalité complètement implémentée
- Code finalisé
- Pas de défauts connus
- Fonctionnalité approuvée par le Product Owner
- Fonctionnalité prête à être déployée
Une approche très simple et très efficace à mettre en place sur tous les projets qui se veulent être agile et qui n’ont pas encore une définition correcte de TERMINE.
Pour plus d’information, je vous invite à parcourir la présentation faite dernièrement par Jeff Sutherland et Scott Downey : Shock Therapy : British Telecom Presentation
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.
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.
Hmmm, tu sembles dire que le PO n’est pas le client. Ça me paraît pour le moins paradoxal.
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 🙂
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.