É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.
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.
Par la suite, vous pourrez ouvrir chaque spécification pour fournir des détails supplémentaires et estimer sa taille.
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 :
|
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). |
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 :
|
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 |
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.
|
Remarques :
Pour modifier l'assignation de champs, consultez Configurer et personnaliser les outils de planification Agile pour un projet d'équipe.
Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.
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.
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.
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.
L'onglet Spécifications capture les liens vers les spécifications mappées.
Champ |
Utilisation |
---|---|
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. |
|
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.
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.
Nommez la tâche et estimez le temps de travail qu'elle nécessitera.
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 :
|
Discipline (1) |
Sélectionnez la discipline que représente cette tâche lorsque votre équipe estime sa capacité de sprint par activité.
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. |
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 :
Pour modifier la sélection du menu, consultez Personnaliser une liste de choix.
Pour modifier l'assignation de champs, consultez Configurer et personnaliser les outils de planification Agile pour un projet d'équipe.
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.
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.
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.
Champ/onglet |
Utilisation |
---|---|
Sélectionnez la cause de l'erreur à partir des valeurs autorisées :
Pour modifier la sélection du menu, consultez Personnaliser une liste de choix. |
|
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. |
|
Faites une sélection parmi les valeurs autorisées qui représentent une évaluation subjective de l'impact d'un bogue sur le projet :
Pour modifier la sélection du menu, consultez Personnaliser une liste de choix. |
|
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).
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.
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.
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.
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. |
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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 :
Pour vous familiariser avec les tâches d'éléments de travail courantes, consultez Mise en route dans l'utilisation des éléments de travail.
Pour créer un backlog, utilisez TWA. Consultez Créer votre backlog.
Pour créer une structure de répartition du travail, utilisez Project ou Excel.
Pour en savoir plus sur le client à utiliser, consultez Choisir le client Team Foundation pour prendre en charge vos tâches.
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é |
Spécification |
Bogue |
Tâche |
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.