Partager via


Éléments de travail et flux de travail (CMMI)

Les équipes utilisent les types d'éléments de travail (WIT) fournis avec le modèle de processus CMMI Process Improvement 2013 (CMMI) pour planifier et suivre la progression des projets logiciels. Les équipes définissent des spécifications pour gérer le backlog puis, à l'aide du tableau kanban, suivent la progression en mettant à jour l'état des spécifications.

Types d'éléments de travail CMMI 7.0

Pour optimiser l'analyse dans un dossier de spécifications, les propriétaires de produits peuvent mapper les spécifications à des fonctionnalités. Quand des équipes travaillent en itérations, elles définissent des tâches qui se lient automatiquement aux spécifications.

À l'aide de Microsoft Test Manager et de Team Web Access (TWA), les testeurs peuvent créer et exécuter des cas de test et définir des bogues pour suivre les erreurs de code.

Pour prendre en charge des processus CMMI supplémentaires, les équipes peuvent suivre les demandes de modification, les risques, les problèmes et les remarques relevés au cours des réunions de révision.

Planifier un projet en définissant des spécifications et en évaluant l'effort

Créez les spécifications à partir du volet d'ajout rapide dans la page du backlog de produit. Vous pouvez également ajouter des spécifications en bloc avec Excel ou Project.

Panneau d'ajout rapide dans la page de Backlog de conditions requises

Par la suite, vous pourrez ouvrir chaque spécification pour fournir des détails supplémentaires et estimer sa taille.

Formulaire d'élément de travail Spécification

Les spécifications indiquent les fonctions et les éléments de produit que les équipes doivent créer. En général, les propriétaires de produits définissent et classent en pile les spécifications dans la page du backlog de produit. L'équipe évalue ensuite les efforts et le travail nécessaires pour livrer les éléments dont la priorité est la plus élevée.

En définissant la Taille des spécifications, les équipes peuvent utiliser la fonctionnalité de prévision et les graphiques de vélocité pour évaluer les itérations ou l'effort de travail à venir. Capturez les informations nécessaires à l'aide des champs et onglets suivants. Pour obtenir des instructions supplémentaires, consultez Planifier un projet.

Champ/onglet

Utilisation

Taille (voir la remarque 1)

Estimez la quantité de travail requise pour remplir une spécification avec l'unité de mesure privilégiée de votre équipe, comme une taille de T-shirt, des points de récit ou une durée.

Les graphiques de vélocité et les outils de prévision Agile font référence aux valeurs de ce champ. Ce champ est requis pour générer le graphique de vélocité.

Priorité [Obligatoire] (2)

Évaluation subjective de la spécification par rapport à l'activité. Les valeurs autorisées sont :

  • 1 : le produit ne peut pas être commercialisé sans l'élément.

  • 2 : le produit (par défaut) ne peut pas être commercialisé sans l'élément, mais le problème ne doit pas nécessairement être traité dans l'immédiat.

  • 3 : l'implémentation de l'élément est facultative et dépend des ressources, du temps et des risques.

Triage [Obligatoire] (2)

Indique le type de décision de triage en attente pour l'élément de travail. Utilisez ce champ lorsque l'élément de travail est dans l'état Proposé et spécifiez l'une des valeurs suivantes : En attente (par défaut), Informations, Informations reçues et En triage.

Bloqué (2)

Indique si un membre de l'équipe est bloqué dans sa progression vers l'implémentation d'une spécification ou d'une tâche, ou dans sa résolution d'un bogue, d'une demande de modification ou d'un risque. Si un problème a été ouvert pour effectuer le suivi d'un problème majeur, vous pouvez créer un lien vers celui-ci. Vous pouvez spécifier Oui ou Non.

Validé [Obligatoire] (2)

Indique si la spécification est validée ou non dans le projet. Vous pouvez spécifier Oui ou Non (valeur par défaut).

Rang dans la pile (1)

Permet de suivre le classement relatif des spécifications. La séquence des éléments sur la page du backlog de produit est déterminée en fonction de l'emplacement où vous avez ajouté ou déplacé les éléments sur la page. Lorsque vous faites glisser des éléments, un processus d'arrière-plan met le champ à jour, qui est affecté au type="Order" dans le fichier ProcessConfiguration.

(Spécification) Type [Obligatoire] (2)

Genre de la spécification à implémenter. Vous pouvez spécifier l'une des valeurs suivantes :

  • Objectif stratégique

  • Fonctionnalité (valeur par défaut)

  • Fonctionnel

  • Interface

  • Opérationnel

  • Qualité de service

  • Sécurité

  • Scénario

  • Sécurité

Description

Fournissez suffisamment de détails pour estimer la quantité de travail nécessaire pour implémenter la spécification. Déterminez à qui est destinée la spécification, quels utilisateurs sont concernés et pourquoi. Ne décrivez pas selon quelle méthode la spécification doit être développée. Fournissez des détails suffisant pour que votre équipe puisse rédiger les tâches et les cas de test pour l'implémentation de l'élément.

Dans les champs HTML, vous pouvez ajouter du texte enrichi et des images.

Analyse

(Évaluation de l'impact)

Impact subi par le client si cette spécification n'est pas implémentée. Vous pouvez inclure des détails du modèle Kano indiquant si cette spécification fait partie des catégories Surprise, Obligatoire ou Explicite. Entrez ces informations dans le champ HTML de texte enrichi qui correspond à l'évaluation de l'impact.

Autre

Les champs suivants, situés sur l'onglet Autre, ne sont pas requis.

  • Intégré dans : numéro de build du produit qui contient la spécification, la demande de modification, ou qui corrige un bogue.

  • Test d'acceptation utilisateur [Obligatoire] (2) : l'état du test d'acceptation utilisateur.

    • Correct

    • Échec

    • Non prêt (valeur par défaut)

    • Prêt

    • Ignoré

    • Informations reçues

    Spécifiez Non prêt lorsque la spécification est Active et Prêt lorsque la spécification est Résolue.

  • Estimation d'origine (3) : nombre d'heures ou de jours nécessaires pour accomplir une tâche.

  • Experts techniques : noms des membres de l'équipe qui sont familiarisés avec l'activité du client que représente cette spécification.

  • Date de début, Date de fin (3) : les dates cibles de début et de fin du travail. Ces champs sont renseignés par Microsoft Project quand vous l'utilisez pour la planification.

Remarques :

  1. Pour modifier l'assignation de champs, consultez Configurer et personnaliser les outils de planification Agile pour un projet d'équipe.

  2. Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.

  3. Vous pouvez spécifier le travail en heures ou en jours. Aucune unité de temps n'est associée à ce champ de manière inhérente.

    Si vous utilisez Microsoft Project pour assigner des ressources et suivre une planification, vous pouvez mettre à jour ces champs à l'aide de Project.

Suivre la progression

Les équipes peuvent utiliser le tableau Kanban pour suivre la progression des spécifications, et le tableau de tâches du sprint pour suivre la progression des tâches. Faire glisser des éléments vers une nouvelle colonne d'état met à jour les champs État et Raison.

Panneau kanban, Backlog de conditions requises

Vous pouvez personnaliser le tableau Kanban pour prendre en charge d'autres couloirs ou colonnes. Vous pouvez également personnaliser le flux de travail pour les types d'éléments de travail de spécification et de tâche, ce a pour effet de modifier les en-têtes de colonne par défaut.

Voici une progression classique de flux de travail pour une spécification :

  • Le propriétaire du produit crée une spécification dans l'état Proposé avec la raison par défaut, Nouvelle spécification.

  • Le propriétaire du produit met à jour l'état sur Actif lorsqu'il démarre le travail d'implémentation.

  • L'équipe met à jour l'état sur Résolu quand elle a terminé le développement du code et que les tests système ont réussi.

  • Enfin, l'équipe ou le propriétaire du produit fait passer la spécification à l'état Fermé lorsque le propriétaire du produit convient qu'elle a été implémentée conformément aux critères d'acceptation et a réussi tous les tests de validation.

Mapper les spécifications sur les fonctionnalités

Lorsque vous gérez une suite de produits ou d'expériences utilisateur, vous pouvez afficher la portée et la progression du travail sur tout le portefeuille de produits. Il suffit de définir des fonctionnalités et de mapper les spécifications sur ces fonctionnalités.

Dans la page du backlog des fonctionnalités, vous pouvez ajouter rapidement des fonctionnalités de la même façon que vous avez ajouté des spécifications.

Volet d'ajout rapide, page de Backlog de portefeuille de fonctionnalités

L'élément de travail Fonctionnalité comporte des champs similaires à ceux des spécifications et des champs supplémentaires, comme indiqué dans le tableau suivant.

Formulaire d'élément de travail Fonctionnalité pour CMMI

L'onglet Spécifications capture les liens vers les spécifications mappées.

Champ

Utilisation

Valeur commerciale

Spécifiez un nombre qui capture la valeur relative d'une fonctionnalité par rapport aux autres. Plus le nombre est élevé, plus la valeur commerciale est grande.

Date limite

Spécifiez la date à laquelle la fonctionnalité doit être implémentée.

Dans la page du backlog, quand le Mappage est activé, vous pouvez faire glisser les spécifications vers les fonctionnalités qu'elles implémentent.

Mapper une spécification à une fonctionnalité

Ce mappage crée des liens parent-enfant de la fonctionnalité vers les spécifications ; ils sont capturés dans l'onglet Spécifications.

Grâce aux backlogs du portefeuille, vous pouvez passer d'un backlog à l'autre pour afficher le niveau de détail souhaité. En outre, vous pouvez utiliser les backlogs du portefeuille pour afficher un cumul du travail en cours dans plusieurs équipes lorsque vous avez configuré une hiérarchie d'équipes.

Définir les tâches requises pour implémenter les spécifications et suivre la capacité et le burndown de l'équipe

Quand votre équipe gère son travail par séries d'itérations, elle peut utiliser la page du backlog des sprints pour fractionner le travail à effectuer en tâches distinctes.

Lien d'ajout de tâche dans une page de Backlog des sprints

Nommez la tâche et estimez le temps de travail qu'elle nécessitera.

Formulaire d'élément de travail Tâche CMMI

Lorsque les équipes estiment le travail, elles définissent des tâches et évaluent les heures ou les jours nécessaires pour les exécuter. Les équipes prévoient le travail et définissent des tâches au début d'une itération, et chaque membre de l'équipe effectue un sous-ensemble de ces tâches. Les tâches peuvent comprendre le développement, le test et d'autres genres de travaux. Par exemple, un développeur peut définir des tâches pour implémenter les spécifications et un testeur peut définir des tâches consistant à écrire et exécuter des cas de test. En liant les tâches aux spécifications et aux bogues, ils voient la progression de ces éléments. Pour obtenir des instructions supplémentaires, consultez Activités d'itération.

Champ

Utilisation

Type de tâche (voir la remarque 1)

Sélectionnez le type de tâche à implémenter à partir des valeurs autorisées :

  • Action corrective

  • Action d'atténuation

  • Planifié

Discipline (1)

Sélectionnez la discipline que représente cette tâche lorsque votre équipe estime sa capacité de sprint par activité.

  • Analyse

  • Développement

  • Test

  • Documentation utilisateur

  • Expérience utilisateur

Ce champ est également utilisé pour calculer la capacité par discipline. Il est assigné à type="Activity" dans le fichier ProcessConfiguration. (2)

Pour obtenir des instructions supplémentaires, consultez Implémenter des tâches de développement.

Estimation d'origine (3)

Décrit la quantité de travail estimée requise pour effectuer une tâche. En général, ce champ ne change pas une fois assigné.

Travail restant (3)

Indiquez le nombre d'heures ou de jours de travail restant pour l'exécution d'une tâche. À mesure que le travail progresse, mettez ce champ à jour. Il permet de calculer les graphiques de capacité, le burndown chart du sprint et le rapport Avancement et taux d'avancement, rapport (Agile).

Si vous divisez une tâche en tâches subordonnées, spécifiez les heures uniquement pour ces dernières. Vous pouvez spécifier le travail dans l'unité de mesure choisie par votre équipe.

Travail effectué (3)

Quantité de travail déployée pour l'implémentation d'une tâche.

Remarques :

  1. Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.

  2. Pour modifier l'assignation de champs, consultez Configurer et personnaliser les outils de planification Agile pour un projet d'équipe.

  3. Vous pouvez spécifier le travail en heures ou en jours. Aucune unité de temps n'est associée à ce champ de manière inhérente.

    Si vous utilisez Microsoft Project pour assigner des ressources et suivre une planification, vous pouvez mettre à jour ces champs à l'aide de Project.

Suivre la progression des tests sur les récits utilisateur et capturer les erreurs de code

Spécifications de test

Dans le Gestionnaire de tests ou TWA, vous pouvez créer des cas de test qui sont automatiquement liés à une spécification ou à un bogue.

Sélectionner la suite de tests et ajouter un cas de test

Le cas de test contient plusieurs champs dont la plupart sont automatisés et intégrés au Gestionnaire de tests et au processus de génération. Pour obtenir une description de chaque champ, consultez Référence des champs d'intégration de build et de tests.

Formulaire d'élément de travail du cas de test

L'onglet Spécifications testées répertorie toutes les spécifications et les bogues dans un cas de test. En utilisant la liaison, l'équipe peut suivre la progression du test de chaque élément ainsi que les informations qui s'affichent dans le rapport Aperçu des spécifications, rapport (CMMI).

Suivre les erreurs de code

Vous pouvez créer des bogues à partir de TWA, Visual Studio ou lors des tests avec le Gestionnaire de tests. Pour obtenir des instructions supplémentaires, consultez Suivre les bogues.

Bogue pour le projet d'équipe CMMI (formulaire d'élément de travail)

Champ/onglet

Utilisation

Cause première

Sélectionnez la cause de l'erreur à partir des valeurs autorisées :

  • Erreur de codage

  • Erreur de design

  • Erreur de spécification

  • Erreur de communication

  • Inconnu

Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.

Étapes à reproduire

Capturez suffisamment d'informations afin que les autres membres de l'équipe puissent comprendre l'impact complet du problème et savoir si les bogues ont été résolus. Cela inclut les actions entreprises pour rechercher ou reproduire le bogue et le comportement attendu.

Décrivez les critères que l'équipe doit utiliser pour vérifier si l'erreur de code est résolue.

Gravité

Faites une sélection parmi les valeurs autorisées qui représentent une évaluation subjective de l'impact d'un bogue sur le projet :

  • 1 - Critique

  • 2 - Élevé

  • 3 - Moyen

  • 4 - Faible

Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.

Informations système

Trouvé dans la build

Intégré dans la build

Lorsque le Gestionnaire de tests crée des bogues, il remplit automatiquement les champs Informations système et Trouvé dans la build avec les informations sur l'environnement logiciel et la sur build où le bogue est apparu. Pour en savoir plus sur la définition des environnements logiciels, consultez Configuration d'ordinateurs de test pour exécuter des tests ou collecter des données.

Lorsque vous résolvez le bogue, utilisez le champ Intégré dans la build pour indiquer le nom de la build qui contient le code permettant de résoudre le bogue.

Pour accéder à un menu déroulant de toutes les builds qui ont été exécutées, vous pouvez mettre à jour les définitions FIELD pour Trouvé dans la build et Intégré dans la build pour qu'elles fassent référence à une liste globale. La liste globale est mise à jour automatiquement à chaque exécution d'une build. Pour en savoir plus, consultez Champs prenant en charge l'intégration avec un test, une build et un contrôle de version.

Pour plus d'informations sur la définition des noms de builds, consultez Utiliser des numéros de build pour attribuer des noms pertinents aux builds terminées.

Suivre les demandes de modification, les risques, les problèmes, et les remarques relevés au cours des réunions de révision

Avec les WIT suivants, les équipes peuvent suivre les informations recommandées par le processus CMMI.

  • Créez une demande de modification chaque fois qu'une modification est proposée pour tout produit soumis au contrôle des modifications. Pour obtenir des instructions d'utilisation supplémentaires, consultez Gérer les modifications et Référence des champs de demande de modification (CMMI).

    Formulaire d'élément de travail de demande de modification CMMI - onglets

    Sous l'onglet Analyse, fournissez des détails sur l'impact de la demande de modification sur l'architecture, l'expérience utilisateur, le test, la conception et le développement ou les publications techniques.

  • Créez un problème pour effectuer le suivi d'un événement ou d'une situation susceptible de bloquer le travail relatif à un produit ou qui le bloque déjà. Les problèmes diffèrent des risques en ce sens que les équipes identifient spontanément les problèmes, en général pendant les réunions d'équipe quotidiennes.

    Formulaire d'élément de travail Problème CMMI - onglets

    Pour obtenir des instructions supplémentaires, consultez Gérer les problèmes et Référence des champs de bogues, problèmes et risques (CMMI).

  • Créez un risque pour effectuer le suivi d'un événement ou d'une situation susceptible de bloquer le travail sur le produit ou qui le bloque déjà. Les problèmes diffèrent des risques en ce sens que les équipes identifient spontanément les problèmes, en général pendant les réunions d'équipe quotidiennes.

    Formulaire d'élément de travail Risque CMMI - onglets

    Pour obtenir des instructions supplémentaires, consultez Gérer les risques et Référence des champs de bogues, problèmes et risques (CMMI).

  • Créez une révision pour documenter les résultats d'une révision de conception ou de code. Les membres de l'équipe peuvent capturer des détails relatifs à la façon dont le design ou le code sont conformes aux normes dans les domaines de la correction du nom, de la pertinence du code, de l'extensibilité, de la complexité du code, de la complexité algorithmique et de la sécurité du code.

    Formulaire d'élément de travail Révision CMMI - onglets

    Pour obtenir des instructions supplémentaires, consultez Implémenter des tâches de développement et Référence des champs de réunion de révision (CMMI).

Définir des champs et des onglets d'élément de travail communs

Les champs et les onglets suivants apparaissent dans la plupart des formulaires d'élément de travail. Chaque onglet est utilisé pour assurer le suivi d'informations spécifiques, telles que l'Historique, les Liens ou les Pièces jointes. Ces trois champs fournissent respectivement un historique des modifications, une vue des éléments de travail liés et la possibilité d'afficher et d'attacher des fichiers.

Le seul champ obligatoire est Titre. Lorsque l'élément de travail est enregistré, le système lui assigne un ID unique.

Champ/onglet

Utilisation

Titre (Obligatoire)

Entrez une description de 255 caractères ou moins. Vous pouvez toujours modifier le titre ultérieurement.

Assigné à

Assignez l'élément de travail au membre de l'équipe chargé d'effectuer le travail. Selon le contexte dans lequel vous travaillez, le menu déroulant répertorie les membres d'équipe ou les collaborateurs au projet d'équipe.

État

Utilisez d'abord la valeur par défaut. À mesure que le travail progresse, mettez ce champ à jour pour refléter l'état en cours.

Pour modifier la liste déroulante des états, consultez Modifier le flux de travail pour un type d'élément de travail.

Raison

Utilisez d'abord la valeur par défaut. Mettez-la à jour lorsque vous modifiez l'état. Chaque état est associé à une raison par défaut.

Pour modifier la liste déroulante des raisons, consultez Modifier le flux de travail pour un type d'élément de travail.

Zone

Sélectionnez le chemin de zone associé au produit ou à l'équipe, ou laissez-le vide jusqu'à ce qu'il soit assigné lors d'une réunion de planification.

Pour modifier la liste déroulante des zones, consultez Ajouter et modifier des chemins de zone et d'itération.

Itération

Choisissez le sprint ou l'itération au cours duquel le travail doit être terminé, ou laissez ce champ vide et remplissez-le ultérieurement, lors d'une réunion de planification.

Pour modifier la liste déroulante des itérations, consultez Ajouter et modifier des chemins de zone et d'itération.

Tous les liens

Ajoutez tous les types de liens, tels que les liens hypertexte, les ensembles de modifications, les fichiers sources, etc.

Cet onglet répertorie également tous les liens définis pour l'élément de travail, même ceux définis dans d'autres onglets de contrôle des liens.

Pièces jointes

Partagez des d'informations plus détaillées en ajoutant des fichiers à l'élément de travail, tel que des fils de messagerie électronique, des documents, des images, des fichiers journaux ou d'autres types de fichier.

Historique

Examinez le journal d'audit que le système a capturé et ajoutez des informations supplémentaires.

Chaque fois qu'un champ de l'élément de travail est mis à jour, ces informations sont ajoutées à l'historique. L'historique inclut la date de la modification, la personne qui a apporté la modification et les champs qui ont été modifiés. Vous pouvez également ajouter du texte mis en forme au champ d'historique.

Pour rechercher des informations sur d'autres champs, consultez l'Index des champs d'élément de travail.

Commencer à suivre le travail

Avant de commencer à suivre le travail, vous devez avoir un projet d'équipe. Accédez ici pour en créer un.

Pour commencer à suivre le travail, effectuez une ou plusieurs des tâches suivantes :

Q et R

Q : Quels sont les états de flux de travail pris en charge par CMMI ?

R : Ces diagrammes montrent les principaux états de progression et de régression des éléments Fonctionnalité, Spécification, Bogue et Tâche. Pour personnaliser le flux de travail, cliquez ici.

Fonctionnalité

États du flux de travail de la fonctionnalité, modèle de processus CMMI

Spécification

États du flux de travail des spécifications, modèle de processus CMMI

Bogue

États du flux de travail du bogue, modèle de processus CMMI

Tâche

États du flux de travail de la tâche, modèle de processus CMMI

Q : Comment résoudre un bogue comme doublon ?

R : Affectez la valeur Supprimé à l'État et spécifiez Doublon comme Raison.

Q : Comment établir une liaison à un bogue existant à partir de Test Runner ?

R: Voir Mettre à jour un bogue existant à l'aide de Test Runner.