Partager via

Nettoyer et estimer le journal des travaux en souffrance

  • Article

Conformément à les pratiques agiles, après que le propriétaire du produit a créé un plan supérieur du produit, votre équipe se réunit pour toiletter journal et estimer les éléments.Vous toilettez un journal en définissant des éléments plus précis, ajoutez des éléments pour représenter le travail supplémentaire, telles que la recherche, ou pour résoudre les bogues en attente.Avant d'estimer le niveau d'effort, votre équipe doit accepter sur la signification de le succès pour chaque élément.

Cette rubrique se poursuit didacticiel qui suit les membres de l'équipe factice de fibres de Fabrikam telle qu'elle crée un journal des travaux en souffrance du produit et exécute un cycle de sprint conformément à les pratiques agiles.L'équipe utilise des pages de panneau du journal et de travail de team Web access.

Julia, comme le propriétaire du produit, a capturé la vision et calendrier de lancement de niveau supérieur du portail du support technique en une série d'éléments du journal comme décrit dans Créer un journal des travaux en souffrance ou y ajouter des éléments.L'équipe est prête à toiletter et estimer le journal des travaux en souffrance.

[!REMARQUE]

Si vous utilisez le modèle de processus scrum 2,0 de Visual Studio, vous créez élément de journal des travaux en souffrance du produit pour décrire un récit utilisateur, une spécification, ou une partie livrable du projet.Si vous utilisez MSF for Agile Software développement, vous créez récit utilisateur.Si vous utilisez MSF for CMMI Process Improvement, vous créez spécification.

Dans cette rubrique

  • Critères d'acceptation de révision et effort d'évaluation

  • Pics de capture ou travail non récits dans le journal des travaux en souffrance

  • Ressources supplémentaires pour prendre en charge les efforts estimer

Configuration requise

Pour suivre les procédures de cette rubrique, vous devez disposer des éléments suivants :

  • Visual Studio Premium, Visual Studio Ultimate ou Visual Studio Test Professional.

  • Vous devez être membre de l'équipe, et vous devez disposer de l'autorisation Modifier les éléments de travail dans ce nœud à Autoriser.Par défaut, tous les membres de l'équipe ont cette autorisation, car le groupe d'équipe est membre du groupe Collaborateurs du projet d'équipe.

  • Pour afficher la page Journal, vous devez appartenir au groupe d'accès Complet dans team Web access.

Pour plus d'informations, consultez Gestion de Mon profil et affichage de mes autorisations et Accès aux fonctionnalités dans Team Web Access.

Critères d'acceptation de révision et effort d'évaluation

Fournissez autant de détails que vous le souhaitez pour décrire non seulement l'élément ou le bogue du journal, mais également décrire les critères que vous utiliserez pour vérifier si l'élément a été accompli ou le bogue a été résolu.Une fois que les critères d'acceptation sont précis, votre équipe peut ensuite en collaboration estimer chaque élément de journal des travaux en souffrance en fonction de n'importe quel processus elles ont adopté.

Critères d'acceptation et effort dans l'élément du journal des travaux en souffrance

  1. Ouvrez Team Web Access, accédez à la page d'accueil de votre projet d'équipe ou team, puis choisissez Afficher le journal des travaux en souffrance.

  2. Double-cliquez sur l'élément de travail que vous souhaitez examiner, ou choisissez- le et appuyez sur entrée.

  3. Révisez et mettez à jour les champs Description et de Critères d'acceptation avec le consensus de l'équipe pour l'élément ou le bogue du journal.

    ConseilConseil

    Les noms de ces champs peuvent être différents sur le modèle de processus utilisé pour créer votre projet d'équipe, par exemple, Description et critères d'acceptation ou Description.

    Sur les critères d'acceptation: À la fin d'une itération ou d'un sprint, vos clients ou le propriétaire du produit recevront le récit utilisateur comme terminé ou le rejetteront.Avant le démarrage du sprint, les critères d'acceptation du client doivent être décrits aussi clairement que possible.Naturellement, un récit utilisateur ne peut pas être accepté pour les raisons qui n'ont pas été anticipés.Toutefois, les conversations entre votre équipe et les clients pour définir les critères d'acceptation aideront à garantir que votre équipe inclut les attentes de vos clients.Les critères d'acceptation peuvent être utilisés comme base pour les tests d'acceptation afin que vous puissiez évaluer plus efficacement si vous avez terminé un récit utilisateur.

  4. Selon la méthode d'évaluation votre équipe utilise, entrez une valeur pour Effort.Au début du projet, vous avez uniquement besoin d'une évaluation grossière.

    [!REMARQUE]

    Les noms de ces champs peuvent être différents sur le modèle de processus utilisé pour créer votre projet d'équipe, par exemple, Effort scrum, Points de récit for agile, et Taille pour CMMI.

    Sur les points de récit: Dans son livre, l'évaluation et la planification agiles, Mike Cohn définit les points de récit de la façon suivante : Les « points de récit est une unité de mesure pour exprimer la taille générale d'un récit utilisateur, fonctionnalité ou un autre exemple de l'ouvrage ». Cohn explique que les points de récit sont des valeurs connexes qui ne traduisent pas directement en nombre spécifique d'heures.Au lieu de cela, les points de récit aident l'équipe à quantifier la taille générale du récit utilisateur.Ces estimations relatives sont moins précises ; elles nécessitent donc moins d'efforts et résistent mieux au temps qui passe.En estimant des points de récit, votre équipe fournit la taille générale des récits utilisateur dès le début et développe ultérieurement l'estimation plus détaillée des heures de travail, lorsque les membres de l'équipe sont sur le point d'implémenter les récits utilisateur.Pour plus d'informations, consultez Estimation.

  5. Choisissez le bouton Enregistrer et fermer .

Pics de capture ou travail non récits dans le journal des travaux en souffrance

Votre équipe devra parfois effectuer le travail qui n'est pas une implémentation directe d'un récit utilisateur ou une spécification de produit.Ce travail est appelé un pic d'activité.Les trois types courants de pics d'activité sont les recherches, le nombre de bogues et les améliorations de processus ou d'ingénierie.Pour créer un pic d'activité dans Team Foundation, créez un élément de journal des travaux en souffrance ou un récit utilisateur, incluez éventuellement « pics » dans le titre, et classez- par ordre de priorité le dans le journal des travaux en souffrance du produit avec les autres récits utilisateur.

Ajouter un volet sur la page du journal des travaux en souffrance du produit

  1. Dans le panneau d'ajouter dans la page de journal des travaux en souffrance du produit, entrez une description dans le domaine Titre pour les travaux de pics ou non récit qui doivent être terminés, puis choisissez le bouton Ajouter .

    ConseilConseil

    Si le panneau d'ajouter n'apparaît pas, cliquez sur le lien ajoutez des éléments en fonction pour activer l'affichage.

    Envisagez de définir le travail non récit pour les activités suivantes :

    • Recherche: Lorsque votre équipe a des questions ouvertes relatives à un récit utilisateur qui doit être répondu avant que le récit utilisateur puisse être entièrement décomposé en tâches et être estimé, vous devez estimer la recherche requise pour répondre à la question.Par exemple, considérez au moment une équipe détermine que le récit, « en tant que voyageur fréquent, je peux réserver un voyage de récompense » a plusieurs problèmes sans réponse.L'équipe crée l'élément, « en tant que membre de l'équipe, je peux comprendre ce que « signifie voyage de récompense de livre ». » pour représenter le pic d'activité.L'équipe estime le travail de recherche requis dans les mêmes unités qu'elles estiment d'autres éléments du journal.

      Important

      Aucun des éléments du journal qui requièrent la recherche ne doit être ajouté à l'itération actuelle jusqu'à ce que l'équipe effectue la recherche.Le travail de recherche et l'élément de journal des travaux en souffrance doivent être planifiés pour se produire dans les futures itérations distinctes.

    • Nombre de bogues: Le meilleur moment de corriger un bogue est lorsque vous recherchez.Si vous ne pouvez pas la résoudre le même niveau que vous la recherche, créez un élément de travail Bogue pour vous assurer que vous ne perdez pas le suivi de celle-ci.Évitez d'accumuler les bogues.Si votre équipe accumule des bogues, créez un récit utilisateur, et liez les bogues au pic d'activité afin que le pic d'activité puisse être estimé et classés par ordre de priorité avec d'autres récits utilisateur et pics.

    • Améliorations de processus ou d'ingénierie: Votre équipe entreprendra les améliorations de processus ou d'ingénierie qui aident à la piloter vers le succès.Ces améliorations sont souvent identifiées pendant un sprint rétrospectif ou pendant les réunions de scrum.Par exemple, votre équipe devra peut-être améliorer la couverture du code à l'aide des tests unitaires ou réduire le temps de génération sur le serveur de l'intégration continue.

  2. Pour chaque élément de travail de pics ou non récit que votre équipe capture, exécutez les étapes 2 à 5 comme décrit dans « Critères d'acceptation de révision et effort d'évaluation » pour garantir l'équipe inclut le travail à exécuter et estime le travail.Pour plus d'informations, consultez Créer un journal des travaux en souffrance ou y ajouter des éléments.

Ressources supplémentaires pour prendre en charge l'évaluation

Vous pouvez accéder aux informations supplémentaires sur les pratiques agiles d'évaluation des ressources suivantes :

Rubriques connexes dans ce tutorial

Début | Créez un journal | Afficher et gérer votre journal des travaux en souffrance avec un panneau de Kanban | Planifier une itération | Exécutez une itération | Terminez une itération

Voir aussi

Concepts

Planification et itérations Agile