Partager via


Génération et la gestion du journal des travaux en souffrance du produit

De Mitch Lacey.Propriétaire, Mitch Lacey & Associates, Inc, un société de conseils spécialisée dans les adoptions et améliorations Agile et Scrum.

Janvier 2012

Dans cet article, Mitch Lacey explique l'importance d'un journal des travaux en souffrance du produit, décrit ce qui fait un bon journal des travaux en souffrance, et fournit quelques meilleures pratiques pour créer et mettre à jour votre journal des travaux en souffrance.

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Dans cet article :

  • Introduction

  • Journal des travaux en souffrance du produit

    • Récits utilisateur

    • Estimation

    • Définition de priorités

  • Journal des travaux en souffrance du produit actif

    • Nettoyage
  • Conclusion

Un journal des travaux en souffrance du produit est une liste classée par ordre de priorité de toutes les fonctions et fonctionnalités nécessaires pour terminer un projet.Un journal des travaux en souffrance du produit correct est au cœur de toute équipe agile qui fonctionne bien, et possède les caractéristiques suivantes :

  • Il est classé par ordre de priorité pour garantir que l'équipe commence par générer les fonctionnalités les plus importantes.

  • Il est apprécié par l'équipe pour apporter de la clarté au propriétaire du produit et lui permettre de répondre à des questions telles que « Quand ces récits seront-ils réalisés ? »

  • Il inclut tout le travail nécessaire pour exécuter le projet.

  • Il s'agit d'un document actif qui connaît un perpétuel changement et une évolution constante pour refléter les réalités actuelles du projet.

Un journal des travaux en souffrance du produit correct ne garantit pas automatiquement un logiciel de qualité.Toutefois, l'absence d'un bon journal des travaux en souffrance du produit est souvent causé par un logiciel incomplet qui ne répond pas aux besoins de vos clients ni de vos parties prenantes.

La gestion du journal des travaux en souffrance constitue un travail à plein temps.Des techniques simples peuvent aider à remplacer un processus inutile, prenant beaucoup de temps par un processus itératif, interactif qui engage efficacement les membres de l'équipe, les clients et les parties prenantes.Par conséquent, il est essentiel d'apprendre des techniques solides pour vous aider à générer, classer par ordre de priorité et mettre à jour votre journal des travaux en souffrance du produit.

Journal des travaux en souffrance du produit

Le journal des travaux en souffrance du produit est une liste principale classée par ordre de priorité et évolutive de toutes les fonctionnalités nécessaires pour exécuter le projet.Les journaux des travaux en souffrance du produit sont en général des récits utilisateur de spécifications (par.. exemple) spécifications, des bogues, des tâches de recherche (pics) et les améliorations d'ingénierie.Ces éléments sont estimés en unités abstraites souvent appelées points de récit.

Les journaux des travaux en souffrance du produit incluent tout le travail dont celui-ci a besoin et évolue au fil du temps.Ainsi, ils contiennent non seulement les nouvelles fonctionnalités d'un produit, mais également les résolutions de bogue et la recherche, tout ce qui prend du temps à l'équipe.Tout le travail que l'équipe effectuera doit provenir du journal des travaux en souffrance du produit, qui est la porte d'entrée du projet.Si le journal des travaux en souffrance du produit inclut tout le travail, le propriétaire du produit, l'équipe et la gestion ont une meilleure image du travail restant et réduit les surprises de dernière minute.

Au début d'un projet, il est peu probable que vous ayez une liste claire d'éléments de journal des travaux en souffrance du produit prêts à être estimés et classés par ordre de priorité.Au lieu de cela, vous aurez probablement une pile de cartes de notes de récits et peut-être une ou deux spécifications fonctionnelles.En tant que propriétaire de produit, il vous appartient de faire un peu de l'ordre afin que l'équipe puisse commencer à évaluer le journal des travaux en souffrance.

Hh765980.collapse_all(fr-fr,VS.110).gifRécits utilisateur

La première étape consiste à convertir toutes les idées et les remarques en récits utilisateur, à savoir les fonctionnalités souhaitées par l'utilisateur final (ce que le logiciel doit faire) mais pas les détails d'implémentation (comment créer un logiciel qui réponde à ces exigences).Le titre de chaque récit utilisateur doit suivre le format, « En tant que <utilisateur>, je souhaite obtenir <fonctionnalité> pour <raison> ».

Exemple de scénarios en images

Comme le journal des travaux en souffrance du produit lui-même, chaque récit utilisateur évoluera au fil du temps.Au cours du projet, votre équipe classera par ordre de priorité et estimera ces récits, y ajoutera des informations détaillées, puis les divisera en récits plus petits ou les supprimera complètement.Ceux qui sont introduits dans les Sprints sont implémentés et fournis à vos clients.

Pour plus d'informations sur les récits utilisateur, consultez Créer un journal des travaux en souffrance ou y ajouter des éléments et Table de montage séquentiel un élément de journal des travaux en souffrance à l'aide de PowerPoint.

Après avoir converti toutes les idées et remarques en récits utilisateur, il est temps de les estimer et de les classer par ordre de priorité.

Hh765980.collapse_all(fr-fr,VS.110).gifEstimation

Par définition, l'évaluation est imprécise.Toutefois, vous pouvez vous améliorer dans la création d'estimations relativement exactes avec le temps, la pratique et la participation de toute votre équipe. La première étape consiste à rassembler l'équipe pour fournir des estimations sur les éléments du journal des travaux en souffrance du produit.Lorsque l'équipe évalue chaque récit, elle fait une évaluation de sa taille relative avec une unité de mesure abstraite, appelée point de récit.

Les estimations sont essentielles pour deux raisons :

  1. Elles permettent de répondre à la question « Quand cette tâche sera-t-elle terminée ? »

  2. Elles permettent au propriétaire du produit de déterminer la priorité de chaque élément.

Les évaluations fournissent au propriétaire du produit et à l'équipe correspondante une idée du coût du récit spécifique, qui, ensuite, permet au propriétaire du produit de classer par ordre de priorité les récits connexes.Plus l'estimation de l'élément est élevée, plus elle est coûteuse à implémenter en termes de temps et de ressources.Par conséquent, un élément qui peut être très important pour un propriétaire de produit peut voir sa priorité diminuer si son coût est élevé.

L'équipe peut utiliser la technique du planning poker, celle du grand mur, ou d'autres techniques pour estimer le travail en termes de points de récit.Pour plus d'informations sur les techniques d'évaluation et une leçon rapide sur les points de récit, consultez Estimation et Nettoyer et estimer le journal des travaux en souffrance.

Une fois que l'équipe a estimé tous les récits, il est temps de les classer par ordre de priorité.

Hh765980.collapse_all(fr-fr,VS.110).gifDéfinition de priorités

Tous les journaux des travaux en souffrance du produit sont classés par ordre de priorité en termes de valeur commerciale et de risque.Le propriétaire du produit compare chaque élément de journal des travaux en souffrance par rapport aux autres pour déterminer sa priorité relative.Pour cela, le propriétaire du produit prend en compte la taille de chaque élément, sa valeur pour l'entreprise et tout risque associé.Les éléments sont ensuite triés par ordre de priorité décroissant.Les éléments de haute priorité s'affichent en haut ou proche du haut du journal des travaux en souffrance du produit, et les éléments de priorité plus basse résident en bas ou proche du bas.Les équipes choisissez le travail relatif au sprint suivant parmi les éléments de priorité les plus élevée, afin que les éléments les plus importants soient terminés en premier.

Tous les éléments du journal des travaux en souffrance n'ont pas la même taille.Certaines peuvent être effectuées dans un Sprint, mais d'autres sont si importantes que l'équipe n'est pas vraiment sûre des personnes impliquées ou du temps qu'il faudra pour les implémenter.C'est correct.Au fur et à mesure que les éléments se rapprochent du haut du journal, les membres de l'équipe les rendent plus petits et plus concentrés afin que chacun ait une connaissance du travail qu'il devra effectuer dans les sprints suivants.

Comme pour l'évaluation, le classement par priorité du journal initial des travaux en souffrance du produit peut être intimidant.Comment équilibrez-vous efficacement les demandes des parties prenantes en concurrence, en prenant en compte le produit final, les risques et les coûts ?Heureusement, plusieurs techniques existent qui facilitent la tâche, y compris les jeux d'innovation et le poids relatifs.Pour plus d'informations sur ces techniques et d'autres, consultez Planification de sprint et Nettoyer et estimer le journal des travaux en souffrance.

Quelle que soit la technique de priorité choisie, vous devez classer le travail pour garantir que l'équipe génère des fonctionnalités qui apportent le plus de valeur à l'entreprise, aux parties prenantes et aux clients.Si vous ne classez pas le travail par ordre de priorité, vous augmentez le risque de fournir des récits utilisateur de priorité inférieure au lieu d'en avoir d'une priorité supérieure, ainsi que des récits utilisateur incomplets lorsque les ressources et les planifications changent.

(Pour plus d'informations sur la nature des éléments du journal des travaux en souffrance, consultez Créer un journal des travaux en souffrance ou y ajouter des éléments et Planification et itérations Agile).

Journal des travaux en souffrance du produit actif

Jusqu'à présent, je me suis employé à décrire comment passer de rien à un journal des travaux en souffrance du produit estimé et classé par ordre de priorité.Contrairement à un document des besoins, les journaux des travaux en souffrance du produit ne sont pas créés au début du projet, puis laissés sur une étagère.Au lieu de cela, le journal des travaux en souffrance du produit évolue, se développant et se contractant avec les réalités du projet.Certains éléments du journal des travaux en souffrance du produit deviendront inutiles et devront être supprimés.D'autres bouillonneront à la surface et doivent être divisés en récits plus petits.De nouveaux récits utilisateur seront ajoutés, estimés, et classés par ordre de priorité au fur et à mesure que des spécifications supplémentaires émergent.

L'équipe et les parties prenantes interviennent dans la création et la gestion du journal des travaux en souffrance du produit, mais le propriétaire du produit en a la responsabilité finale.Le propriétaire du produit doit garantir que le journal des travaux en souffrance est propre, classé par ordre de priorité et à jour, afin que les clients et l'équipe aient une image claire du plan de travail pour la version finale du projet.Même lorsque le projet est en plein rendement, les propriétaires de produit s'efforcent toujours de conserver le journal des travaux en souffrance du produit en forme :

  • Ajout et classement par priorité de nouveaux récits

  • Demandez à l'équipe d'évaluer de nouveaux récits et de réévaluer les récits précédents car ils sont mieux compris

  • Examen des prochains récits utilisateur avec l'équipe pour décomposer des éléments requis, si nécessaire

  • Réunion avec les clients et les parties prenantes pour examiner et ajouter des spécifications

N'importe qui peut ajouter des éléments au journal des travaux en souffrance du produit à tout moment, mais seul le propriétaire du produit peut les classer par ordre de priorité.Le propriétaire du produit est également la seule personne habilitée à assigner une priorité à un récit.Tous les autres membres de l'équipe, et les parties prenantes, doivent laisser la priorité vide lorsqu'ils ajoutent un récit, même s'ils utilisent un outil électronique qui leur demande cette information.

Lorsqu'un récit est ajouté, le propriétaire du produit fait une estimation préliminaire de sa priorité selon sa compréhension de celle-ci.Il abordera le récit avec son créateur pour mieux le comprendre afin qu'il puisse, ensuite, répondre aux questions de l'équipe.À un moment prédéterminé au cours de chaque sprint, le propriétaire du produit rencontrera l'équipe pour discuter des nouveaux récits et les évaluer de manière collégiale pour lui permettre de les classer plus précisément par rapport à d'autres récits dans le journal des travaux en souffrance.Ce processus est appelé nettoyage du journal.

Hh765980.collapse_all(fr-fr,VS.110).gifNettoyage

Le nettoyage du journal des travaux en souffrance du produit, comme indiqué précédemment, doit se produire régulièrement.

Dans Scrum, l'équipe doit passer 5 % à 15 % de son temps pour chaque sprint dans des activités de nettoyage.L'équipe doit comprendre ce qui s'annonce et ce qui évolue, afin de pouvoir décomposer les récits volumineux dont la priorité augmente, estimer les récits qui ont été créés, procéder aux conceptions et aux planifications nécessaires pour les récits à venir.Pour garantir que cela se produit, le propriétaire du produit et l'équipe doivent, au cours de chaque réunion de planification des sprints, réserver un certain temps pendant le sprint pour réviser ensemble le journal des travaux en souffrance.Pour plus d'informations sur la planification des sprints, consultez Planification de sprint et Planifier une itération.

Dans le cadre d'un sprint de deux semaines, j'aime tenir cette réunion pendant la deuxième semaine.Cela laisse au propriétaire du produit assez de temps pour avoir des conversations explicites avec les clients et les parties prenantes, pour comprendre les modifications de l'entreprise et pour clarifier les récits utilisateur et les récits qui sont nouveaux ou dont la priorité a augmenté.C'est également un moment logique du sprint où commencer à anticiper les sprints suivants.Vous pouvez déterminer quand tenir la réunion.La chose d'important consiste à accorder assez de temps pendant le Sprint aux activités complètes de nettoyage.

Lors d'une réunion de nettoyage classique, le propriétaire du produit répertorie les nouveautés, ce qui a changé et son plan pour les sprints à venir.Outre l'estimation de nouveaux récits et la décomposition de ceux qui doivent être effectués bientôt, l'équipe prend son temps lors de cette réunion pour examiner l'architecture actuelle du système et organiser ou concevoir les prochaines fonctionnalités.Pendant ce processus, les estimations des récits changent souvent et les nouveaux récits ont tendance à apparaître comme de grands récits qui sont décomposés en plus petits récits.

Ce processus peut sembler simple, mais se révéler difficile.Pour que tout se passe au mieux, le propriétaire du produit doit être disposé à répondre aux questions.Un conflit peut se produire si, par exemple, le propriétaire du produit planifie un récit à réaliser dans le sprint suivant, mais ne donne pas assez d'explications à l'équipe pour qu'elle puisse fournir une estimation correcte.Si cela se produit au cours des réunions de planification des sprints, le Scrum Master doit indiquer au propriétaire du produit les informations, issues des clients et des parties prenantes, qu'il doit fournir à l'équipe.

À la fin de chaque réunion de nettoyage, le propriétaire du produit doit publier les modifications pour les parties prenantes et les clients afin que chacun puisse connaître les nouveautés présentes et à venir et le plan de version mis à jour.

Un journal des travaux en souffrance du produit correct aide à garantir que le logiciel que vous générez contient les fonctionnalités les plus importantes telles qu'elles sont identifiées dans vos conversations avec les clients et les parties prenantes, et définies dans vos récits utilisateur.Pour créer et mettre à jour un bon journal des travaux en souffrance du produit, vous devez rester activement engagé à la fois dans le groupe des parties prenantes/clients et dans l'équipe de manière régulière pour chaque sprint.

La génération d'un journal des travaux en souffrance ne garantit pas un bon système, mais sans journal, vous pouvez être sûr que votre système n'exécute pas ce que les clients attendent.En d'autres termes, ne pas conserver le journal des travaux en souffrance résulterait presque toujours à un échec de projet.

Être propriétaire de produit est un travail à plein temps. Il est responsable du journal des travaux en souffrance.Prenez le rôle sérieusement.Conservez le journal des travaux en souffrance en bon état. Vos clients vous en remercieront.

Voir aussi

Concepts

Effectuer une mise en route en tant qu'équipe

Planification et itérations Agile

Commentaires des parties prenantes de demande et de processus à l'aide de team Web access

Faire le suivi d'un travail et gérer le flux de travail

Autres ressources

Préparation de l'utilisation d'une installation sur un seul serveur [Didacticiel]

Guide de processus et modèles de processus pour Team Foundation Server