« 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%20Beaumont 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 />  

<br /> <span style="display: block; text-align: justify">Évidemment, il s'agit d'une vision idéalisée des choses. Dans la pratique, les choses sont plus nuancées parce que les priorités associées aux différentes étapes du workflow ne sont pas aussi nettes que vous le souhaitez. Les nouveaux items peuvent avoir une très haute priorité et venir s'insérer dans les items PRÊTS. D'un autre côté, cette façon de voir le backlog peut vous aider à respecter l'ordre des priorités : quelque chose de PRÊT peut par définition avoir une priorité plus haute que quelque chose qui n'est pas dans cet état.</span><span style="display: block; text-align: justify"><br /> </span><br /> <span style="display: block; text-align: justify">Du partitionnement au flux</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Si nous reconsidérons les différentes étapes du flux précédemment décrit et que nous les mettons côte à côte, nous obtenons :</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">[[Image:From_Partitioning_to_Flow.png|From_Partitioning_to_Flow.png]]<br /> </span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Le fait d'utiliser la même couleur pour "Nouveau" et "Prêt", et une autre couleur pour "En préparation" et "Dans le Sprint actuel" n'est pas une coïncidence. '''"Nouveau" et "Prêt" sont des buffers priorisés''', "En préparation" et "Dans le Sprint actuel" sont des tâches en cours (Work-In-Progress). Parcourons le flux étape par étape.</span><span style="display: block; text-align: justify"><br /> </span><br /> <span style="display: block; text-align: justify">Buffer priorisé : Nouveau</span><span style="display: block; text-align: justify"><br /> </span><span style="display: block; text-align: justify">Les items du backlog dans l'état '''Nouveau''' sont ceux que vous n'avez pas encore traités, en tout cas pas suffisamment pour qu'ils soient PRÊTS. Malgré tout, en pratique, j'ai constaté qu''''il est sage d'effectuer un tri minimum sur ces items''' : si vous avez des idées dans tous les sens, vous serez très vite submergé par une avalanche d'items. Les parties prenantes ont tendance à dire "J'ai un millier d'idées !", mais la plupart d'entre elles sont juste des idées. Seule une petite portion de ces idées sont vraiment réalistes et utiles à implémenter. Ce tri initial devrait être simple, mais il requiert déjà une certaine discipline de la part des parties prenantes pour analyser leurs besoins. Ne vous inquiétez pas trop des plaintes des parties prenantes, en général une partie prenante appréciera toujours de savoir ce qu'elle peut faire pour que ces besoins soient pris en compte. Pour qu'un item soit pris en compte dans le backlog Nouveau, '''une partie prenante devrait fournir les informations suivantes''' :</span><span style="display: block; text-align: justify"><br />