La Définition de PRET

((/dotclear/public/serge_beaumont.jpeg|Serge Beaumont|L|Serge Beaumont, juil 2009))J’ai traduit l’excellent article de ++[Serge Beaumont|http://www.scrumalliance.org/profiles/3256-serge-beaumont|en]++ publié le 19 juin 2009 sur le Blog de Xebia : ++[The Definition of READY|http://blog.xebia.com/2009/06/19/the-definition-of-ready/|en]++.%%% %%% %%% >  »Hier, j’ai participé à la conférence « Integrating Agile » durant laquelle j’ai fourni certains éléments de réponse concernant une problématique que je considère comme étant le « Grand Trou Noir » de Scrum : le rôle du Product Owner. Suite à l’échange qui a eu lieu, je souhaitais écrire un billet sur le sujet et « éclaircir » un peu le trou noir… 🙂 »%%% > %%% > __La Définition de Prêt__%%% > %%% > J’ai donné des cours de CSM (Certified Scrum Trainer) avec Jeff Sutherland, et il y a à peu près 6 mois, il a ajouté dans ses supports de cours des références à ce qu’il nomme « le modèle dynamique de Scrum ». La caractéristique principale était l’ajout d’un état PRÊT à l’opposé de l’état TERMINÉ. Ici, l’idée est que __l’équipe a besoin de se trouver dans une situation stable et connue, pour être capable d’accomplir son travail correctement__. Cela a immédiatement trouver un écho en moi : j’ai vu __tellement d’équipes mises en difficulté parce que le Product Owner ne pouvait pas leur donner un objectif clair__, que mettre en œuvre l’état PRÊT me semblait effectivement le but à atteindre. Mais l’était-il réellement et comment l’atteindre ? Je pense pouvoir aujourd’hui bien répondre à ces questions.%%% > %%% > ((/dotclear/public/serge-beaumont-business-ownership-in-an-agile-environment-focus-value-flow010-300×225.png|Here’s a picture from Serge Beaumont’ course material to illustrate the concept|C|Here’s a picture from Serge Beaumont’ course material to illustrate the concept, juil 2009)) >  »Extrait de mes supports de cours Scrum illustrant le concept… »%%% > %%% > Dans une équipe auto-organisée, montrer clairement la cible à atteindre est très important : __l’auto-organisation n’existe pas si vous n’avez rien à organiser__. L’état PRÊT empêche l’équipe d’être mise en difficulté en lui garantissant que les pré-requis nécessaires à la bonne exécution d’un Sprint ont bien été remplis.%%% > %%% > __Définir PRÊT__%%% > %%% > Le mode de __définition de PRÊT__ est identique à celui de TERMINÉ à quelques différences près. Alors que dans la Définition de TERMINÉ le « fournisseur » est l’Équipe et le « client » est le Product Owner, il en va tout autrement avec la __Définition de PRÊT : l’Équipe est le « client » et le Product Owner est le « fournisseur »__. Même si je détaillerai la définition de PRÊT plus tard, on peut déjà dire qu’__être dans l’état PRÊT revient à ce que l’équipe déclare : « Ah, nous y sommes ! »__.%%% > %%% > Même si l’on peut ajouter n’importe quel pré-requis à la Définition de PRÊT, le besoin de disposer d’un bon backlog passe devant toutes les autres considérations ; vous devez donc travailler sur deux éléments : préparation des User Stories et préparation du Backlog.%%% > %%% > __Quand une User Story est-elle PRÊTE ?__%%% > %%% > J’ai constaté qu’une User Story est prête lorsque vous avez répondu à 3 questions : __Pourquoi ? Quoi ? et Comment ?__, qu’elle a été __estimée__ et qu’elle est suffisamment __petite__.%%% > %%% > – __Pourquoi ?__ Qu’essaye d’atteindre les parties prenantes ? Quels sont leurs objectifs ? Quel est le contexte métier ? Quelle est la __Valeur Quantitative__ ?%%% > – __Quoi ?__ Quelle est la __Vision de la Cible__ ? Quel est le résultat final de la user story ?%%% > – __Comment ?__ Quelle est la __Stratégie d’Implémentation__ ? Quel est le coût associé (story points) ? La story est-elle suffisamment petite (story points vs vélocité de l’équipe) ?%%% > %%% > Notez bien qu’en répondant à ces questions, __je n’en déduis pas que vous devez tout documenter__. Encore une fois, c’est l’équipe qui sait ce dont elle a besoin. Si le dos d’une nappe suffit, alors allez y. Si l’équipe demande plus, alors donnez lui. Notez que __le niveau de détail nécessaire doit être déterminé par user story__. Certaines user stories métiers sont classiques comme d’habitude, et il peut suffire de dire : « Je veux l’une de ces choses, mais cette fois en vert ». Par contre, d’autres user stories pourraient être moins évidentes, par exemple, si elles sont liées à un nouveau processus dans le service de soins intensifs d’un hôpital. Vous avez peut-être besoin d’un peu plus dans ce cas là… :-)%%% > %%% > J’utilise le terme « __stratégie__ d’implémentation » pour clarifier un peu plus le besoin de détail désiré. Spécifié totalement le Comment ? vous ramènerez au modèle de la cascade, mais vous ne pourrez pas effectuer une estimation par points si l’équipe n’a pas une première idée de la manière dont elle va aborder la user story. Par conséquent, __vous allez aussi loin que nécessaire pour spécifier l’implémentation et permettre une estimation par points__. Notez qu’il s’agit d’un effet secondaire inhérent aux sessions de planning poker, donc le plus facile est de capturer le besoin tout au long de l’estimation. Et je vous conseille vraiment de le faire. J’ai trop souvent constaté que l’équipe se reposait la question de savoir pourquoi elle avait estimé 5 points pour telle user story, 2 jours à peine après la session de planning poker… :-)%%% > %%% > Finalement, une User Story est PRÊTE si __l’équipe peut l’implémenter et si le Product Owner peut la prioriser__.%%% > %%% > __Quand le Backlog est-il PRÊT ?__ > %%% > Le backlog est PRÊT lorsqu’un ensemble de __User Stories couvrant de 1,5 à 2 Sprints__ dans le haut du backlog sont PRÊTES, que ces user stories sont suffisamment petites pour permettre de les répartir dans l’équipe.%%% > %%% > __Pour finir, suivez ce précepte :__%%% > %%% > __Ne conservez rien dans l’état non PRÊT dans votre Sprint et ne laissez rien en sortir qui ne soit dans l’état TERMINÉ.__%%% > %%% > Bien, maintenant que nous savons définir l’état PRÊT, je vous raconterai dans un prochain billet comment atteindre cet état…%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *