Préparer le PRÊT – Itérer jusqu’à TERMINÉ

((/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 4 juillet 2009 sur le Blog de Xebia : ++[Flow to READY, Iterate to DONE|http://blog.xebia.com/2009/07/04/flow-to-ready-iterate-to-done/|en]++.%%% %%% %%% >  »Lors d’un précédent billet, ++[j’ai introduit la définition de PRÊT|/dotclear/index.php?post/2009/07/08/La-definition-de-PRET]++. 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… » :-)%%% > %%% > 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.%%% > %%% > 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.%%% > %%% > __Préparer le PRÊT__%%% > %%% > ((/dotclear/public/Flow_to_Ready.png|Flow to READY|C|Flow to READY, juil 2009)) > %%% > 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.%%% > %%% > __Partitionner le backlog__%%% > %%% > ((/dotclear/public/Partitioning_the_Backlog.png|Partitioning the backlog|C|Partitioning the backlog, juil 2009)) > %%% > Un backlog peut être grossièrement partitionné en 4 régions basées sur le flux de travail :%%% > 1. les items __dans le Sprint__ en cours,%%% > 2. les items dans l’état __Prêt__,%%% > 3. les items __en cours de préparation__ pour être Prêts, et%%% > 4. le reste : __nouveaux__ besoins.%%% > %%% > É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.%%% > %%% > __Du partitionnement au flux__%%% > %%% > 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 :%%% > %%% > ((/dotclear/public/From_Partitioning_to_Flow.png|From partitioning to flow|C|From partitioning to flow, juil 2009)) > %%% > 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.%%% > %%% > __Buffer priorisé : Nouveau__%%% > %%% > 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 :__%%% > – une story,  »uniquement en termes d’__expérience métier__ », qui décrit leur expérience et leur besoin __sans mentionner la manière dont le produit l’implémentera__%%% > – __la classique strophe de la user story__ (En tant que… Je veux… Pour…)%%% > – une (grossière) __évaluation du bénéfice__%%% > – une grossière __indication de la taille__ (c-à-d le coût) : petit, moyen, grand. (Notez que l’estimation est meilleure lorsque le membre de l’équipe ou le product owner ont discuté avec les parties prenantes qui ont plus de connaissance sur le produit attendu).%%% > %%% > L’__urgence métier vous donne un niveau grossier de la priorité__, ce qui vous permet de décider quel item prendre en premier.%%% > %%% > __Tâches en cours (WIP) : Préparation__%%% > %%% > Cette étape est la plus importante pour le Product Owner : c’est __le moment où l’essentiel du travail du Product Owner est réalisé.__%%% > %%% > Le Product Owner est le point d’entrée unique pour toutes les parties prenantes, et c’est bien sûr intentionnel. Il doit y avoir un seul point focal pour les exigences et les priorités, sinon cela risque d’incomber au rôle de l’équipe; le rôle Product Owner est donc tout sauf inutile. Un malheureux effet secondaire pour notre pauvre Product Owner est qu’__il subit constamment les exigences et les pressions de toutes les parties prenantes__. Le Product Owner tente de faire face à ce dilemme. Je pense que c’est exactement à ce moment que le style flux/kanban excelle : __limiter explicitement le nombre de tâches en cours (WIP) est l’un des meilleurs outils à utiliser pour apporter un peu de bon sens dans la vie du Product Owner__.%%% > %%% > __Le Product Owner traite les items dans l’étape de Préparation selon la capacité__. Exactement comme une équipe qui prend du travail jusqu’à atteindre sa capacité maximale et qui ne change rien tant que le Sprint n’est pas terminé, un Product Owner prend un certain nombre d’items (j’ai constaté 2 items par personne dans le rôle de Product Owner, mais je ne sais pas s’il s’agit d’une règle générale), les traite jusqu’à ce qu’ils soient PRÊTS, et prend uniquement de nouveaux items lorsque qu’un espace se libère dans l’étape de préparation.%%% > %%% > __Le Product Owner n’a pas besoin de (et dans le plupart des cas ne peut pas) fournir toutes les informations, mais il est responsable de s’assurer que quelqu’un peut le faire__, et que ++[l’item du backlog passera dans l’état Prêt|/dotclear/index.php?post/2009/07/08/La-definition-de-PRET]++. Cela signifie que le Product Owner discutera avec les parties prenantes pour leur demander des informations, avec l’Équipe pour fournir une estimation de la complexité de l’implémentation, et avec toute personne nécessaire pour fournir de la clarté et de l’information. C’est un vrai boulot, et dans de grandes organisations, il n’est pas inhabituel de voir plusieurs personnes (souvent des analystes) tenir ce rôle.%%% > %%% > Grâce à cette étape explicite dans le flux, __il est maintenant possible de mesurer le niveau de performance du Product Owner__. L’équivalent de la vélocité dans le style flux/kanban est le __temps de cycle : le temps moyen nécessaire pour porter un item du backlog de l’état Nouveau à l’état Prêt__. Un item bloqué dans le backlog sera facilement reconnaissable puisqu’il restera dans l’étape Préparation plus longtemps que d’habitude. Cela permet également d’estimer la capacité du Product Owner. Comparer le temps de cycle avec le nombre d’items du backlog consommés par Sprint par l’équipe, aide à déterminer si le Product Owner est assez rapide pour maintenir un bon rythme.%%% > %%% > __La vitesse du Product Owner n’est pas mesuré en story points d’items du backlog mais en nombre d’items du backlog__ car la quantité de travail de chaque item est grossièrement la même : chaque item requiert des questions quel que soit sa taille. De grands items de backlog nécessite peut-être plus de travail, mais dans la plupart des cas ils seront divisés en plus petites tailles gérables par l’équipe. Ceci se traduit en un plus grand nombre d’items de backlog qu’au départ. Les grands items sont refactorés de cette manière.%%% > %%% > Lorsqu’un item du backlog est Prêt, il peut être déplacé dans la buffer Prêt.%%% > %%% > __Buffer priorisé : Prêt__%%% > %%% > J’ai trouvé très utile de considérer la liste des items Prêts comme un __buffer__. La productivité d’un Product Owner nécessite d’être telle que ce __buffer doit être suffisamment rempli pour que le prochain Sprint commence__. Observer la taille du buffer (en story points, puisque maintenant c’est la capacité de l’Équipe qui est pertinente) est un très bon moyen de voir si le Product Owner a des problèmes. Vous pouvez utiliser un burndown chart, un burnup chart, ou simplement __une courbe de suivi de la taille du buffer__, sachant que je pense qu’il est profitable pour un Product Owner d’accéder aux mêmes types d’information de suivi que les Équipes lorsqu’elles utilisent des burndown charts,%%% > %%% > On distingue deux niveaux pour l’état Prêt : chaque item du backlog nécessite d’être Prêt, mais le backlog nécessite aussi d’être Prêt, juste avant le prochain Sprint. Un Backlog Prêt signifie que le buffer Ready est __suffisamment rempli pour une quantité de travail équivalente à une itération, plus quelques tâches supplémentaires__ en cas de renégociation, décisions de dernière minute, idées ou changements de priorités. En pratique, une bonne cible est d’aller jusqu’à une quantité de travail équivalente entre 1,5 à 2 itérations. Le contraire est également vrai : si le buffer est vraiment plein, plus de 2 Sprints d’items Prêts, vous perdez probablement votre temps puisque la réalité va changer avant même que vous traitiez les derniers items du buffer (les items repassent dans l’état non prêt), vous contraignant à fournir plus de travail. Dans ce cas, il est plus intéressant d’augmenter la capacité de l’Équipe ou d’utiliser ce temps libre pour des activités de divination ou études de marché. ;-)%%% > %%% > __Tâches en cours (WIP) : Dans le Sprint en cours__%%% > %%% > Cette étape est bien évidemment relativement facile à décrire puisque c’est le moment où tout le matériel Scrum entre dans le paysage. 🙂 En tant que Product Owner, vous suivrez les items du Sprint en cours, mais votre travail ne s’arrête pas là. Pour reprendre une citation employée dans la conception : « une bonne conception ne dépend pas d’une seule grande décision, mais d’une centaine de petites décisions », __une Équipe a donc besoin que vous soyez présent à proximité pour les débloquer en prenant les bonnes décisions__. Durant un Sprint, une Équipe vous détaillera différents scénarios d’implémentation. Souvent, ces scénarios ont un impact sur le résultat final : il pourrait y avoir une option de facilité par rapport à ce qui avait été initialement discuté, ou une partie de l’implémentation est bien plus dure que prévue. Dans ce cas, vous devez être présent aux alentours pour aider l’Équipe à avancer.%%% > %%% > __Résumé__%%% > %%% > Le backlog peut être partitionné en 4 parties que l’on peut intégrer dans un flux (style kanban). Puisque ce billet commence à être trop long, j’en rédigerai un autre pour décrire comment outiller ce processus avec un tableau Kanban et des logiciels.%%% %%% —- ((/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 *