« Préparer le PRÊT - Itérer jusqu'à TERMINÉ » : différence entre les versions

<div id="content_view" class="wiki" style="display: block"> Auteur : Serge Beaumont<br /> Source : [http://blog.xebia.com/2009/07/flow-to-ready-iterate-to-done/ Flow to READY, Iterate to DONE]<br /> Date : 04/07/2009<br />

Traducteur : Fabrice Aimetti<br /> Date : 13/07/2009<br />

''Traduction :''<br /> <br /> ''Lors d'un précédent billet, [http://blog.xebia.com/2009/06/the-definition-of-ready/ j'ai introduit la définition de PRÊT]. Préalablement au présent billet, je souhaitais en écrire un sur la différence entre les notions de flux ("kanban") et d'itération. Cependant, j'avais beaucoup plus à dire que prévu sur le sujet qui a finalement pris une toute autre dimension. Je rassemblerai mes idées plus tard et cela fera l'objet d'un autre billet. Soyez donc un peu patient avec moi : je trouve que '''le travail de Product Owner est beaucoup mieux réalisé en adoptant la notion de flux'''. Et puisque mon collègue Lars Vonk m'a dit qu'il attendait de lire ce billet, j'expliquerai ici juste comment s'y prendre. Lars, on peut démarrer... :)''<br /> <span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Les items d'un backlog ne sont pas tous égaux. Un item de backlog commence sous la forme d'une ébauche (la classique strophe "En tant que... Je veux... Pour...") et nécessite d'être détaillé jusqu'à ce qu'il soit positionné dans un sprint par l'équipe. Un Product Owner gère un workflow de la même manière qu'une équipe pour Terminer ses tâches. '''Scrum ne dispose d'aucun support spécifique pour le Product Owner''' : d'une manière ou d'une autre, le Backlog Produit "apparaît" d'un seul coup. Dans ce billet, je vais essayer de combler cette lacune concernant le processus que peut suivre un Product Owner.</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Je présenterai un mode de '''partitionnement''' du backlog appliqué à la notion de flux, la '''nature''' de ces partitions et la manière de procéder pour obtenir suffisamment de choses Prêtes pour que l'équipe les sélectionne dans le Sprint suivant.</span><span style="display: block; text-align: justify"><br /> </span><br /> <span style="display: block; text-align: justify">Préparer le PRÊT</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:Flow_to_Ready.png|Flow_to_Ready.png]]</span><span style="display: block; text-align: justify">Le flux de travail consiste dans la définition de nouveaux items par le rôle Product Owner, leur préparation pour qu'ils soient PRÊTS, leur sélection par le rôle Équipe pour qu'ils les TERMINENT. Notez que je parle explicitement de "rôle" ici : les membres de l'équipe ont un rôle à jouer pour soutenir le rôle Product Owner à définir et préparer des items PRÊTS.</span><span style="display: block; text-align: justify"><br /> </span><br /> <span style="display: block; text-align: justify">Partitionner le backlog</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:Partitioning_the_Backlog.png|Partitioning_the_Backlog.png]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><br />  Un backlog peut être grossièrement partitionné en 4 régions basées sur le flux de travail :<br />