Ajout et modification de champs d'éléments de travail pour prendre en charge la création de rapports
Vous utilisez les champs d'éléments de travail pour assurer le suivi des données d'un type d'élément de travail, définir les critères de filtre des requêtes et vous les utilisez dans les rapports. Tout champ, à l'exception des champs système, que vous souhaitez voir apparaître dans un rapport doit être défini dans le fichier de définition pour les types d'éléments de travail que le champ suivra. Les champs système sont définis automatiquement pour chaque type d'élément de travail. Toutefois, ils doivent être inclus dans le formulaire d'élément de travail pour prendre en charge l'entrée de données.
Pour prendre en charge la création de rapports, vous pouvez ajouter des champs ou modifier les attributs de champs existants. Lorsque vous ajoutez ou modifiez des champs, vous devez appliquer des conventions d'affectation de noms systématiques pour vous assurer que ces données sont regroupées logiquement dans des dossiers du cube SQL Server Analysis Services.
Dans cette rubrique
Meilleures pratiques
Utiliser un champ existant
Répertorier les champs définis pour une collection de projets d'équipe
Attributs de champs signalables
Modifier un attribut signalable pour un champ
Ajouter des champs pour prendre en charge la création de rapports
Vérifier les modifications apportées aux attributs de champs signalables
Meilleures pratiques pour l'assignation de noms de référence de création de rapports
Champs signalables définis dans les modèles de processus MSF
Meilleures pratiques
Avant d'ajouter ou de modifier un champ, consultez les meilleures pratiques suivantes :
Déterminez si vous pouvez utiliser un champ déjà défini dans la collection de projets d'équipe qui contient votre projet d'équipe. L'utilisation d'un champ existant prend en charge la création de rapports interprojets.
Déterminez si vous pouvez utiliser un champ déjà défini dans une autre collection de projets dans le déploiement de Visual Studio Team Foundation Server. L'utilisation d'un champ existant prend en charge la création de rapports interprojets.
Au maximum, vous pouvez avoir 1 024 champs dans chaque collection de projets et 1 024 champs signalables uniques dans toutes les collections de projets d'un déploiement de Team Foundation Server. Les champs fusionnés comptent comme un champ signalable.
Instituez une procédure standard et passez en revue le processus permettant d'ajouter et de modifier des champs dans les modèles de processus, les projets d'équipe ou les collections de projets.
Utilisez des conventions d'affectation de noms systématiques lorsque vous donnez des étiquettes aux champs pour la création de rapports. Lorsque vous assignez des noms de référence de façon systématique à travers toutes les collections de projets d'équipe d'un déploiement de Team Foundation Server, vous garantissez la cohérence et la facilité d'utilisation de l'entrepôt et du schéma de cube, et vous évitez les conflits de schéma dans l'entrepôt. Pour plus d'informations, consultez Résolution de conflits de schéma qui se produisent dans l'entrepôt de données.
Vous pouvez assigner jusqu'à quatre attributs d'étiquette à un champ d'élément de travail :
Notes
Aucun nom de création de rapports ou nom de référence de création de rapports n'est assigné aux champs définis dans les modèles de processus pour Microsoft Solutions Framework. Par défaut, les attributs de nom et de nom de référence sont utilisés.
name. Nom convivial du champ qui apparaît dans les menus déroulants des requêtes d'éléments de travail. Le nom convivial doit être unique à travers tous les champs définis dans un projet d'équipe. De même, le nom convivial peut être différent de l'étiquette affichée qui est assignée au champ sur le formulaire d'élément de travail. Pour plus d'informations, consultez Référence des éléments XML Control.
refname. Étiquette unique assignée au champ, qui le distingue de tous les autres champs définis dans la collection de projets d'équipe. La valeur assignée à refname ne peut pas être modifiée.
Pour connaître les spécifications et restrictions sur les noms conviviaux et noms de référence des champs, consultez Conventions d'affectation de noms pour les objets de suivi des éléments de travail.
reportingname. Attribut facultatif. Nom utilisé pour identifier un champ dans les rapports. S'il n'est pas explicitement défini, la valeur assignée à l'attribut name est utilisée.
reportingrefname. Attribut facultatif. Étiquette unique assignée à un champ signalable, qui le distingue de tous les autres champs signalables définis dans toutes les collections de projets d'équipe. S'il n'est pas explicitement défini, la valeur assignée à l'attribut refname est utilisée. Pour connaître les conventions d'affectation de noms recommandées, consultez Meilleures pratiques pour l'assignation de noms de référence de création de rapports plus loin dans cette rubrique.
Notes
Les noms de référence de création de rapports sont uniquement visibles à partir d'un rapport PivotTable ou du cube Analysis Services.
Utiliser un champ existant
Vous devez utiliser un champ déjà défini s'il correspond aux informations pour lesquelles vous souhaitez effectuer un suivi et créer des rapports. Pour utiliser un champ existant, exécutez les étapes suivantes :
Identifiez le champ que vous souhaitez utiliser. Utilisez la commande witadmin listfields pour identifier les champs et leurs attributs définis pour toutes les collections de projets. Pour plus d'informations, consultez Répertorier les champs définis pour une collection de projets d'équipe plus loin dans cette rubrique.
Déterminez si le champ est signalable et si les attributs signalables satisfont vos besoins de création de rapports.
Si le champ n'est pas signalable, utilisez witadmin changefield pour modifier l'attribut signalable pour les collections de projets dans lesquelles il est utilisé. Pour plus d'informations, consultez Modifier un attribut signalable pour un champ plus loin dans cette rubrique.
Pour la collection de projets dans laquelle le champ n'est pas défini, ajoutez ce dernier aux fichiers de définition XML pour les types d'éléments de travail que vous souhaitez utiliser pour suivre les données. Pour plus d'informations, consultez Ajouter des champs pour prendre en charge la création de rapports plus loin dans cette rubrique.
Répertorier les champs définis pour une collection de projets d'équipe
Vous pouvez utiliser la commande witadmin listfields pour répertorier les champs et leurs attributs. Vous pouvez répertorier un champ spécifié ou tous les champs définis dans une collection de projets. La commande witadmin listfields a la syntaxe suivante :
witadmin listfields /collection:CollectionURL /n:RefName
Pour plus d'informations, consultez Répertorier des champs d'élément de travail et afficher les attributs assignés aux champs.
Attributs de champs signalables
Les champs signalables ont une valeur d'attribut reportable égale à Detail, Dimension ou Measure. Les attributs suivants déterminent la façon dont les champs d'éléments de travail sont exportés et traités vers les bases de données d'entrepôt de données :
reportingtype. Pour inclure un champ dans les rapports, vous devez assigner l'une des valeurs suivantes à l'attribut reportable :
Assignez Detail pour exporter le champ vers la base de données relationnelle de l'entrepôt, mais pas vers le cube. Comme dans l'exemple suivant, utilisez uniquement le type Detail pour les champs Entier, Double, Chaîne ou DateTime :
<FIELD refname="MyCorp.Summary" name="Summary" type="String" reportable="detail">Assignez Dimension pour exporter le champ à la fois vers la base de données relationnelle de l'entrepôt et le cube. Comme dans l'exemple suivant, utilisez uniquement Dimension pour les champs Entier, Double, Chaîne ou DateTime. Cette valeur est utile pour inclure des champs utilisés pour filtrer les rapports (par exemple, des champs qui ont des listes de valeurs valides).
<FIELD refname="MyCorp.Category" name="Category" type="String" reportable="dimension">Assignez Measure pour prendre en charge le traitement de valeurs précalculées dans le cube. Utilisez uniquement le type Measure pour les champs Integer et Double.
Lorsque vous assignez Measure comme reportingtype, vous devez assigner sum comme formula, comme dans l'exemple suivant :
<FIELD refname="MyCorp.Cost" name="Cost" type="Integer" reportable="measure" formula="sum">
reportingrefname. Vous pouvez assigner un autre nom de référence à un champ marqué comme signalable. Si aucune valeur n'est spécifiée, la valeur assignée à l'attribut refname est utilisée.
Vous pouvez utiliser cet attribut pour fusionner ou différencier des champs inclus dans les rapports. Pour fusionner deux champs ayant des noms de référence distincts et étant définis dans des collections de projets différentes, vous assignez le même attribut reportingrefname à ces deux champs. Pour différencier deux champs ayant le même nom de référence et étant définis dans des collections de projets différentes, vous assignez un attribut reportingrefname distinct à chacun d'eux.
Vous devez fusionner les champs dès que possible pour réduire le nombre de champs dans l'entrepôt et le conserver sous la limite des 1 024 champs signalables. Vous pouvez générer des rapports intergroupes avec des champs fusionnés.
reportingname. Vous pouvez assigner une étiquette différente à un champ qui est utilisé pour afficher des données dans les rapports. Si aucune valeur n'est spécifiée, le nom convivial assigné pour l'attribut name est utilisé. La valeur assignée à l'attribut reportingname s'affiche dans le cube. La valeur assignée à l'attribut reportingrefname ne s'affiche pas.
Important
Vous devez utiliser les meilleures pratiques pour assigner des étiquettes aux champs de création de rapports afin qu'ils soient regroupés dans les rapports PivotTable. Pour plus d'informations, consultez Meilleures pratiques pour l'assignation de noms de référence de création de rapports.
Modifier un attribut signalable pour champ d'élément de travail
Vous pouvez rendre un champ existant signalable en modifiant les assignations d'attribut du champ définies pour une collection de projets. Un champ existant est défini dans une ou plusieurs définitions de type d'élément de travail. De même, vous pouvez modifier tous les attributs qui déterminent la façon dont un champ est traité dans les entrepôts de données.
Vous pouvez utiliser la séquence suivante d'étapes pour modifier l'assignation d'attribut d'un champ :
Vous pouvez utiliser la commande witadmin changefield pour modifier une assignation d'attribut à un champ. Vous appliquez cette commande pour une collection de projets d'équipe. Utilisez la syntaxe suivante :
witadmin changefield /collection:CollectionURL /n:RefName [/name:NewName] [/syncnamechanges:true | false] [/reportingname:ReportingName] [/reportingrefname:ReportingRefName] [/reportingtype:Type] [/reportingformula:Formula] [/noprompt]Pour rendre un champ existant signalable, modifiez le reportingtype. Par exemple, pour rendre le champ AW.Common.TeamPriority disponible pour le filtrage des rapports, assignez-lui la valeur Dimension :
witadmin changefield /collection:http://AdventureWorksServer:8080/AWTeam/Collection1 /n:AW.Common.TeamPriority /reportingtype:dimensionPour plus d'informations, consultez Gestion des champs d'éléments de travail (witadmin).
(Facultatif) Si vous avez plusieurs collections de projets, vous pouvez apporter des modifications semblables au champ d'élément de travail défini dans cette collection. Pour éviter les conflits de schéma lorsque vous exportez et traitez des données vers les bases de données de l'entrepôt de données, vous devez assigner les mêmes valeurs à ces attributs à travers toutes les collections :
Type de champ (la valeur pour ce champ ne peut pas être modifiée pour un champ existant).
Type de création de rapports.
Nom de création de rapports.
Pour plus d'informations, consultez Résolution de conflits de schéma qui se produisent dans l'entrepôt de données.
Après avoir apporté toutes les modifications aux champs d'éléments de travail que vous souhaitez utiliser pour la création de rapports, vous devez traiter les bases de données de l'entrepôt de données. Vous pouvez utiliser les services Web ProcessAnalysis et ProcessWarehouse, disponibles via le WarehouseControlWebService.
Cette étape garantit que les personnes qui utilisent les rapports ne voient pas d'erreur lorsque vous modifiez les attributs d'un champ. Pour plus d'informations, consultez Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server.
Pour plus d'informations, consultez Gestion des champs d'éléments de travail (witadmin).
Ajouter des champs pour prendre en charge la création de rapports
Vous pouvez ajouter des champs à la définition d'un type ou de plusieurs types d'éléments de travail. Lorsque vous ajoutez le champ, vous devez ajouter la même définition d'élément de champ à tous les types d'éléments de travail pour lesquels le champ prendra en charge la création de rapports. Si vous souhaitez que le champ prenne en charge la création de rapports interprojets, le champ doit être ajouté à tous les types d'éléments de travail de tous les projets d'équipe qui feront l'objet de rapports.
Pour plus d'informations, consultez les rubriques suivantes :
Vérifier les modifications apportées aux attributs de champs signalables
Vous pouvez vérifier les modifications que vous avez apportées aux attributs de champs signalables en traitant les entrepôts de données à la demande, puis en vérifiant que les rapports sont mis à jour. Sinon, vous pouvez attendre l'exécution des travaux de l'adaptateur d'entrepôt. Par défaut, la base de données relationnelle est traitée à quelques minutes d'intervalle. En revanche, le cube est traité toutes les deux heures par défaut.
Notes
Pour plus d'informations sur le WarehouseControlWebService, consultez Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server.
Traitez l'entrepôt de données relationnelles à la demande à l'aide du ProcessWarehouse WarehouseControlWebService.
Traitez le cube à la demande à l'aide du ProcessAnalysisDatabase WarehouseControlWebService.
Vérifiez que les rapports sont mis à jour. Consultez un rapport via le tableau de bord ou le Gestionnaire de rapports. Pour plus d'informations, consultez Tableaux de bord (Agile) ou Rapports (Agile).
Meilleures pratiques pour l'assignation de noms de référence de création de rapports
Pour les noms de référence de création de rapports, vous pouvez assigner des étiquettes pour trouver facilement les champs dans le rapport PivotTable et le cube. Pour cela, vous pouvez appliquer des conventions d'affectation de noms systématiques afin que les champs soient regroupés dans une séquence logique. De plus, si les champs ne sont pas regroupés de façon utile, vous pouvez modifier le nom de référence de création de rapports d'un champ.
L'application d'une convention d'affectation de noms systématique devient de plus en plus importante parce que toutes les données signalables de tous les projets d'équipe définis dans toutes les collections de projets sont écrites vers un entrepôt de données relationnelles unique. Les données de cet entrepôt sont ensuite traitées et écrites vers le cube. Étant donné que les champs d'éléments de travail sont gérés distinctement pour chaque collection de projets, des étiquettes différentes peuvent être appliquées et peuvent générer un ensemble de champs qui n'est pas bien organisé pour prendre en charge la création des rapports.
Les champs d'éléments de travail qui ont un type signalable de dimension correspondent à des attributs de dimension du cube. Les attributs de dimension sont organisés dans des dossiers en fonction du nom de référence de création de rapports assigné dans le modèle de processus ou la définition du type d'élément de travail. Les types de mappages suivants se produisent :
Les champs ayant le préfixe « Système » sont intrinsèques et répertoriés directement sous la dimension Élément de travail, avec la mention « Élément de travail ».
Les autres champs sont placés sous les dossiers dont les noms correspondent aux préfixes de leur nom de référence. Par exemple, les champs qui ont le préfixe « Microsoft.VSTS.Common » apparaissent sous le dossier étiqueté « Microsoft VSTS Common ».
Comme dans l'illustration suivante, un dossier est ajouté pour chaque groupe de préfixes de champs qui partagent un préfixe commun :
.png "Structure du dossier dans le cube de données OLAP")
Le tableau suivant répertorie les champs dont les noms de référence commencent par « Système » et qui sont répertoriés dans le rapport PivotTable avec le préfixe « Élément de travail ». Ces champs sont placés directement sous la dimension Élément de travail. Tous les autres champs sont placés sous les dossiers dont les noms correspondent aux préfixes de leur nom de référence.
Notes
Les déploiements qui n'utilisent pas la version d'entreprise de SQL Server Analysis Services n'ont pas accès aux fonctionnalités de traduction fournies par cette version. Dans ces déploiements, les champs sont identifiés par leur nom de référence complet dans le cube, avec « . » remplacé par « _ » (par exemple, « System_Id » et « System_Title »).
Nom dans le rapport PivotTable et dans le cube |
Nom de la référence |
Type de données |
|---|---|---|
Work Item.Area Path |
System.AreaPath |
TreeType |
Work Item.Assigned To |
System.AssignedTo |
Chaîne |
Work Item.Changed By |
System.ChangedBy |
Chaîne |
Work Item.Changed Date |
System.ChangedDate |
DateTime |
Work Item.Created By |
System.Created By |
Chaîne |
Work Item.Created Date |
System.CreatedDate |
DateTime |
Work Item.ID |
System.Id |
Entier |
Work Item.Iteration Path |
System.IterationPath |
TreeType |
Work Item.Previous State |
System.PreviousState |
Chaîne |
Work Item.Reason |
System.Reason |
Chaîne |
Work Item.Rev |
System.Rev |
Entier |
Work Item.State |
System.State |
Chaîne |
Work Item.Title |
System.Title |
Chaîne |
Work Item.Work Item Type |
System.WorkItemType |
Chaîne |
Le tableau suivant répertorie les champs qui s'affichent dans le rapport PivotTable dans le dossier étiqueté « Microsoft.VSTS.Common » sous la dimension Élément de travail. Ces champs ont des noms de référence qui commencent par « Microsoft.VSTS.Common ».
Nom dans le rapport PivotTable et dans le cube |
Nom de la référence |
Type de données |
|---|---|---|
Work Item.Activated By |
Microsoft.VSTS.Common.ActivatedBy |
Chaîne |
Work Item.Activated Date |
Microsoft.VSTS.Common.ActivatedDate |
DateTime |
Work Item.Closed By |
Microsoft.VSTS.Common.ClosedBy |
Chaîne |
Work Item.Closed Date |
Microsoft.VSTS.Common.ClosedDate |
DateTime |
Work Item.Created By |
Microsoft.VSTS.Common.CreatedBy |
Chaîne |
Work Item.Created Date |
Microsoft.VSTS.Common.CreatedDate |
DateTime |
Work Item.Resolved By |
Microsoft.VSTS.Common.ResolvedBy |
Chaîne |
Work Item.Resolved Date |
Microsoft.VSTS.Common.ResolvedDate |
DateTime |
Work Item.Resolved Reason |
Microsoft.VSTS.Common.ResolvedReason |
Chaîne |
Work Item.Priority |
Microsoft.VSTS.Common.Priority |
Entier |
Work Item.Severity |
Microsoft.VSTS.Common.Severity |
Chaîne |
Work Item.Stack Rank |
Microsoft.VSTS.Common.StackRank |
Double |
Champs signalables définis dans les modèles de processus MSF
Les tableaux suivants répertorient les champs définis dans les modèles de processus Microsoft Solutions Framework (MSF) et les assignations par défaut des champs. Ces champs s'affichent uniquement pour les projets d'équipe créés avec la version 5.0 d'un modèle de processus MSF. Seuls les champs configurés pour être signalables sont répertoriés.
Champs Détails
Champs Dimension
Champs Mesure
Pour obtenir une liste complète des champs définis dans les modèles de processus MSF, consultez Utilisation de champs système et de champs définis par les modèles de processus MSF. Si vous avez mis à niveau un projet d'équipe, vous devrez peut-être effectuer des tâches supplémentaires pour pouvoir travailler avec certains de ces champs. Pour plus d'informations, consultez Mise à jour d'un projet d'équipe mis à niveau pour accéder à de nouvelles fonctionnalités.
Champs Détails
Nom du champ |
Description |
Nom de la référence |
Type de données |
Statut Automation |
Statut d'un cas de test. Vous pouvez spécifier les valeurs suivantes :
|
Microsoft.VSTS.TCM.AutomationStatus |
Chaîne |
Champs Dimension
Nom du champ |
Description |
Nom de la référence |
Type de données |
ID |
Identificateur unique assigné à un élément de travail. Les ID d'élément de travail sont uniques pour l'ensemble des projets d'équipe et éléments de travail définis dans une collection de projets. |
System.Id |
Entier |
Titre |
Brève description qui résume l'élément de travail et aide les utilisateurs à le différencier des autres éléments de travail d'une liste. |
System.Title |
Chaîne |
Projet d'équipe |
Projet d'équipe auquel appartient cet élément de travail. |
System.TeamProject |
Chaîne |
Type d'élément de travail |
Nom du type d'élément de travail. |
System.WorkItemType |
Chaîne |
Zone |
Regroupe les éléments de travail dans des fonctionnalités de produit ou des zones d'équipe. La zone doit être un nœud valide dans la hiérarchie de projet. |
System.AreaPath |
TreePath |
Itération |
Regroupe les éléments de travail par durées ou périodes de sprint nommées. L'itération doit être un nœud valide dans la hiérarchie de projet. |
System.IterationPath |
TreePath |
Modifié par |
Nom du membre de l'équipe qui a modifié l'élément de travail en dernier. |
System.ChangedBy |
Chaîne |
Activité |
Type d'activité requise pour effectuer une tâche. |
Microsoft.VSTS.Common.Activity |
Chaîne |
Rév |
Numéro assigné à la révision historique d'un élément de travail. |
System.Rev |
Entier |
Date d'échéance |
Date d'échéance prévue à laquelle une tâche doit être exécutée. |
Microsoft.VSTS.Scheduling.DueDate |
DateTime |
Date de fin |
Date et heure indiquées dans la planification pour la fin de la tâche. |
Microsoft.VSTS.Scheduling.FinishDate |
DateTime |
Date de début |
Date et heure indiquées dans la planification pour le début de la tâche. |
Microsoft.VSTS.Scheduling.StartDate |
DateTime |
Trouvé dans |
Numéro de build de produit, également appelé révision, dans lequel un bogue a été trouvé. |
Microsoft.VSTS.Build.FoundIn |
Chaîne |
Build d'intégration |
Numéro de build de produit qui incorpore le code ou corrige un bogue. |
Microsoft.VSTS.Build.IntegrationBuild |
Chaîne |
Assigné à. |
Nom du membre de l'équipe qui possède actuellement l'élément de travail. |
System.AssignedTo |
Chaîne |
Motif |
Raison pour laquelle l'élément de travail se trouve dans l'état actuel. Les valeurs sont spécifiques à l'état et au type d'élément de travail. Le champ n'est pas suivi pour les cas de test ou les étapes partagées. |
System.Reason |
Chaîne |
État |
État actuel de l'élément de travail. Les valeurs valides de l'état sont spécifiques à chaque type d'élément de travail. |
System.State |
Chaîne |
Activé par |
Nom du membre de l'équipe qui a activé ou réactivé l'élément de travail. |
Microsoft.VSTS.Common.ActivatedBy |
Chaîne |
Date d'activation |
Date et heure auxquelles l'élément de travail a été activé ou réactivé. |
Microsoft.VSTS.Common.ActivatedDate |
DateTime |
Fermé par |
Nom du membre de l'équipe qui a fermé l'élément de travail. |
Microsoft.VSTS.Common.ClosedBy |
Chaîne |
Date de fermeture |
Date et heure auxquelles un élément de travail a été fermé. |
Microsoft.VSTS.Common.ClosedDate |
DateTime |
Créé par |
Nom du membre de l'équipe qui a créé l'élément de travail. |
Microsoft.VSTS.Common.CreatedBy |
Chaîne |
Date de création |
Date et heure auxquelles un élément de travail a été créé. |
Microsoft.VSTS.Common.CreatedDate |
DateTime |
Résolu par |
Nom du membre de l'équipe qui a résolu le bogue ou le récit utilisateur. |
Microsoft.VSTS.Common.ResolvedBy |
Chaîne |
Date de résolution |
Date et heure auxquelles le bogue ou le récit utilisateur a été résolu. |
Microsoft.VSTS.Common.ResolvedDate |
DateTime |
Motif de résolution |
Raison pour laquelle le bogue a été résolu (par exemple, il a été résolu). |
Microsoft.VSTS.Common.ResolvedReason |
Chaîne |
Priorité |
Évaluation subjective du bogue, du problème, de la tâche ou du cas de test par rapport à l'activité. Vous pouvez spécifier les valeurs suivantes :
|
Microsoft.VSTS.Common.Priority |
Entier |
Rang |
Évaluation subjective du récit utilisateur, de la tâche, du problème ou du bogue par rapport à d'autres éléments de travail du même type. Un élément de rang inférieur doit être corrigé avant tout autre élément de rang supérieur. |
Microsoft.VSTS.Common.Rank |
Double |
Points de récit |
Unité de mesure subjective qui indique la taille d'un récit utilisateur. Si vous assignez davantage de points à un récit utilisateur, vous indiquez qu'un travail supplémentaire est nécessaire pour l'implémenter. |
Microsoft.VSTS.StoryPoints |
Double |
Risque |
Évaluation subjective de l'incertitude relative à l'achèvement du récit utilisateur. Vous pouvez spécifier les valeurs suivantes :
|
Microsoft.VSTS.Common.Risk |
Chaîne |
Gravité |
Évaluation subjective de l'effet d'un bogue sur le projet. Vous pouvez spécifier les valeurs suivantes :
|
Microsoft.VSTS.Common.Severity |
Chaîne |
Date d'échéance |
Date prévue à laquelle un problème sera résolu. Ce champ est applicable uniquement aux éléments de travail Problème. |
Microsoft.VSTS.Scheduling.DueDate |
DateTime |
Champs Mesure
Nom du champ |
Description |
Nom de la référence |
Type de données |
Estimation d'origine |
Nombre d'heures requises pour effectuer une tâche. |
Microsoft.VSTS.Scheduling.OriginalEstimate |
Double |
Restant |
Nombre d'heures qui restent pour terminer une tâche. |
Microsoft.VSTS.Scheduling.RemainingWork |
Double |
Terminé |
Nombre d'heures passées sur une tâche. |
Microsoft.VSTS.Scheduling.CompletedWork |
Double |
Voir aussi
Référence
Gestion des champs d'éléments de travail (witadmin)
Concepts
Utilisation des champs d'élément de travail
Création, personnalisation et gestion de rapports pour Visual Studio ALM
Autres ressources
Traiter manuellement l'entrepôt de données et le cube Analysis Services pour Team Foundation Server
Résolution de conflits de schéma qui se produisent dans l'entrepôt de données