FAQ Azure Boards

En tant que membre d’un projet Azure Boards, vous pouvez utiliser la plupart des fonctionnalités pour suivre le travail. Les limitations de sélection des fonctionnalités dépendent du niveau d’accès et du groupe de sécurité affectés à l’utilisateur. D’autres limitations peuvent être imposées en fonction des autorisations de suivi du travail ou des règles personnalisées définies. Pour plus d’informations, consultez Autorisations par défaut et accès pour Azure Boards.

Vous pouvez restreindre l’accès en définissant des autorisations pour un chemin de zone à une zone. Pour plus d’informations, consultez les articles suivants :

• Définir les autorisations de suivi du travail et de plan
• Accorder ou restreindre des autorisations pour sélectionner des tâches

Oui. Les règles conditionnelles basées sur l’appartenance d’un utilisateur ou d’un groupe sont mises en cache pour votre navigateur web. Si vous vous trouvez dans l’impossibilité de mettre à jour un élément de travail, vous avez probablement été confronté à l’une de ces règles. Pour obtenir plus d’informations sur les règles conditionnelles, consultez Règles et évaluation des règles. Si votre cache stocke des règles obsolètes, vous pouvez attendre que le cache du client expire dans les trois jours, ou vous pouvez effacer le cache.
Pour effacer le cache, exécutez la commande suivante dans la fenêtre de commande du navigateur, puis actualisez le navigateur : window.indexedDB.deleteDatabase(« wit »)

Consultez Outils et clients qui se connectent à Azure DevOps.

Pour une présentation des éléments de travail, consultez À propos des éléments de travail.

Pour afficher tous les éléments de travail définis dans un projet, ouvrez une requête et ajoutez deux clauses :

• Work Item Type = [Any]
• State = [Any]

À partir de là, vous pouvez ajouter des filtres pour affiner la requête. Si vous souhaitez obtenir plus d’informations, consultez Créer et enregistrer des requêtes mangées avec l’éditeur de requête.

Non. Les éléments de travail ne peuvent être attribués qu’à un seul utilisateur. En outre, vous pouvez uniquement ajouter un utilisateur disponible à partir du sélecteur de personnes.

La méthode principale pour regrouper le travail consiste à l’affecter au même chemin de zone. Les chemins de zone sont utilisés pour regrouper des éléments de travail par produit, fonctionnalité ou domaine d’activité, et pour prendre en charge les équipes responsables du travail affecté à ces domaines. En outre, vous pouvez regrouper le travail sous un élément de travail parent à l’aide de liens parent-enfant, ce qu’on appelle regroupement hiérarchique.

Pour une présentation de ces deux utilisations et des outils pris en charge, consultez Configuration et personnalisation d’Azure Boards, chemins de zone, équipes produit et gestion de portefeuille.

Les marqueurs de jalon ne sont pas utilisés dans le suivi du travail Azure Boards, à l’exception des plans de livraison. Les plans de livraison fournissent un affichage en calendrier et vous permettent de définir un marqueur de jalon. Pour plus d’informations, consultez Passer en revue les plans de livraison de l’équipe.

Toutefois, vous pouvez utiliser une ou plusieurs des options suivantes pour marquer un élément de travail comme jalon :

• Ajouter le mot Jalon au début ou à la fin du titre de votre élément de travail
• Ajouter une balise d’élément de travail étiquetée Jalon
• Ajouter un champ personnalisé intitulé Jalon et le remplir avec une liste de sélection de jalons
• Lier des éléments de travail à l’aide du type de lien Prédécesseur/Successeur ou Connexe à un élément de travail de jalon
• Affecter l’élément de travail de jalon au sprint dans lequel il est destiné à être terminé.

Vous pouvez suivre les dépendances entre les éléments de travail en les liant à l’aide d’un type de lien connexe ou autre. Consultez Lier des éléments de travail à d’autres objets.

Si vous effectuez le suivi des dépendances entre une ou plusieurs organisations, vous pouvez utiliser le suivi de dépendance.

Chaque processus définit quatre niveaux de backlog par défaut : le backlog d’itération, le backlog des exigences, les backlogs de fonctionnalités et les backlogs de portefeuille d’épopées. Les types d’éléments de travail ajoutés à chaque niveau de backlog sont les types d’éléments de travail naturels pour former une relation parent-enfant et regrouper les éléments de travail dans une hiérarchie. Si vous souhaitez obtenir plus d’informations, consultez Organiser votre backlog, mapper les éléments de travail enfants aux parents. Pour personnaliser le processus, consultez Personnaliser vos backlogs ou tableaux, Modifier ou renommer le backlog des exigences.

Consultez Modifier en bloc des éléments de travail, Modifier en bloc des champs de texte enrichi.

Oui, vous pouvez définir votre niveau de backlog pour inclure deux règles différentes. La première règle à définir le parent comme actif lorsqu’un de ses enfants est défini sur actif. La deuxième règle consiste à attribuer au parent la valeur « résolu » ou « fermé » lorsque tous les enfants sont fermés. Ces règles peuvent être configurées pour le niveau du backlog. Pour plus d’informations, consultez Automatiser les transitions d’état d’élément de travail

Les éléments de travail changent automatiquement l’état après que l’administrateur de votre équipe a configuré des règles d’automatisation sur le backlog. Créez des règles pour définir automatiquement l’état sur « actif » ou « fermé » en fonction du changement d’état de ses enfants. Pour plus d’informations, consultez Automatiser les transitions d’état d’élément de travail.

Les règles se déclenchent uniquement lorsque l’état de l’élément enfant passe de Nouveau à Actif ou Clôturé. Les règles ne se déclenchent pas lorsque l’état de l’élément enfant passe de Clôturé à Actif. Il s’agit actuellement d’une conception.

Non, les règles sont appliquées à tous les types d’éléments de travail de ce niveau de backlog. Nous utilisons des catégories d’état au lieu d’états, car les catégories d’état sont cohérentes entre tous les types d’éléments de travail.

Oui, les règles sont configurées par niveau de backlog. Les règles d’automatisation du backlog des récits utilisateur n’affectent pas les fonctionnalités ou les épopées. Mais vous pouvez également configurer des règles séparément pour ce qui est des caractéristiques et des épopées. Pour plus d’informations, consultez Automatiser les transitions d’état d’élément de travail.

Les règles se déclenchent uniquement si les parents et les enfants appartiennent à la même équipe. Nous ne voulons pas que les règles soient automatiquement déclenchées pour les éléments appartenant à d’autres équipes. Pour plus d’informations, consultez Automatiser les transitions d’état d’élément de travail.

Chaque backlog et chaque tableau représente un ensemble filtré d’éléments de travail en fonction des affectations de chemin de zone d’équipe et d’itération. Les backlogs répertorient les éléments de travail, les tableaux affichent les éléments de travail sous forme de cartes. Pour comprendre comment le filtrage est appliqué, consultez À propos des équipes et des outils Agile, Valeurs par défaut de l’équipe référencées par les backlogs et les tableaux.

Pour ajouter un backlog ou un tableau, vous ajoutez une équipe. Chaque équipe est configurée avec son propre ensemble de backlogs et de tableaux, comme décrit dans À propos des équipes et des outils Agile. Chaque équipe peut personnaliser ces outils Agile.

Azure DevOps impose des limites, comme le nombre d’éléments de travail qui s’affichent sur un backlog ou un tableau, le nombre d’équipes que vous pouvez définir, etc. Pour obtenir la liste complète, consultez Suivi du travail, processus et limites du projet.

Consultez Migration et intégration d’Azure Boards.

Chaque backlog répertorie un ensemble filtré d’éléments de travail en fonction du chemin de zone sélectionné, des chemins d’itération et des types d’éléments de travail de l’équipe.

• Backlog de produit : répertorie par défaut les récits utilisateur (Agile), les problèmes (Basic), les éléments et les bogues du backlog de produit (Scrum) ou les exigences (CMMI). Fournit des options pour afficher les éléments enfants Parents, Prévisions et En cours ou Terminé.
• Backlog de portefeuille : répertorie par défaut les fonctionnalités (tous les modèles de processus) pour le backlog Fonctionnalités, et les épopées (Agile, Scrum et CMMI) pour le backlog Épopées. Fournit des options pour afficher les éléments enfants Parents et En cours ou Terminé.
• Backlog de sprint : par défaut, répertorie tous les éléments de backlog de produit affectés à l’itération sélectionnée, quel que soit l’état. Fournit des options pour afficher les Détails du travail.

Oui. Vous pouvez affecter des sprints aux éléments de travail et filtrer votre tableau Kanban en fonction du chemin d’itération. Pour plus d’informations, consultez Filtrer votre tableau Kanban.

Non. Les listes de contrôle des tâches prennent uniquement en charge le type d’élément de travail de tâche.

Azure DevOps ne fournit pas une vue native du chemin critique. En partie, car les méthodologies Agile privilégient un produit minimum viable (MVP) par rapport à la gestion du chemin critique (CPM). En utilisant MVP, vous identifiez le chemin et les dépendances les plus courts en hiérarchisant les épopées, les fonctionnalités, les récits et les tâches.

Cela dit, nous vous recommandons d’utiliser des plans de livraison pour afficher les dépendances et une vue en calendrier du travail.

Si votre organisation prend en charge la connexion à Microsoft Project, vous trouverez peut-être plus d’extensions de la Place de marché qui prennent en charge la connexion d’Azure DevOps à Microsoft Project.

Pour plus de contexte, consultez Le chemin critique sur les projets Agile et Diriger une start-up efficace sur Azure DevOps.

Non. Les données entrées pour la capacité d’une équipe ne sont pas stockées dans les magasins de données classiques.

Non. Cette fonctionnalité n'est pas prise en charge. Il s’agit d’une fonctionnalité suggérée, pour laquelle vous pouvez voter en accédant à notre page Developer Community.

Oui, consultez Requête par affectation ou modifications de workflow, Requêtes de modification du tableau Kanban.

Oui, en ajoutant l’extension Tableaux basés sur les requêtes de la Place de marché.

Oui, en ajoutant l’extension Azure Boards Kanban Tools de la Place de marché.

Oui, vous pouvez suivre les déplacements de colonne sur un tableau Kanban à l’aide des champs Colonne de tableau et Colonne de tableau terminée.

Si vous rencontrez l’erreur suivante lorsque vous ouvrez votre tableau Kanban, vous devez corriger la configuration. La principale raison de cette erreur est que les états du workflow des types d’élément de travail qui ont été ajoutés à la catégorie Exigence ne sont pas mappés à la colonne.

Sélectionnez Corriger maintenant pour ouvrir la boîte de dialogue Paramètres. Dans l’exemple suivant, deux nouveaux états sont ajoutés : En cours de triage pour un bogue et Examiner pour un récit utilisateur. Chaque état est ensuite mappé à une colonne existante ou nouvelle. Une fois chaque état mappé à une colonne, le tableau Kanban affiche les éléments de travail affectés à ces états.

Oui, vous pouvez ajouter ou supprimer des couloirs sur votre tableau Kanban. Vous pouvez également configurer des règles de couloir, où, lorsque certaines conditions sont remplies, Azure Boards déplace automatiquement les éléments de travail dans des voies spécifiques.

Vous pouvez définir des modèles d’élément de travail pour les équipes auxquelles vous appartenez. Pour définir des modèles d’éléments de travail afin de spécifier les valeurs par défaut pour les champs sélectionnés, consultez Utiliser des modèles pour ajouter et mettre à jour des éléments de travail.

La fonctionnalité permettant de définir un modèle par défaut pour une équipe n’est pas prise en charge pour le moment.

Non. Cette fonctionnalité n’est pas prise en charge pour l’instant.

Exemple de requête : lors de la création d’un modèle, je souhaite que le récit utilisateur parent soit défini par défaut. Il n’y a pas de champ prédéterminé dans le modèle. Cette fonction peut-elle se trouver sous une sélection définie par l’utilisateur ?

Non, il n’existe aucune prise en charge native pour la création de modèles de hiérarchie. En particulier, vous ne pouvez pas spécifier un élément de travail parent par défaut. Toutefois, vous pouvez rapidement copier des tâches, des bogues et d’autres éléments à l’aide d’Excel pour appliquer des liens parent-enfant dans une arborescence. Vous pouvez également utiliser un tableau Kanban pour ajouter des tâches enfants, des éléments de backlog ou des fonctionnalités. Pour en savoir plus, consultez :

• Ajouter des listes de contrôle de tâches
• Ajouter, exécuter et mettre à jour des tests inline
• Ajouter des fonctionnalités et des épopées

Dans la page du type d’élément de travail, choisissez l’icône d’actions d’un modèle existant, puis sélectionnez l’option Supprimer.

Azure Boards s’intègre à GitHub pour Azure DevOps Server 2019 et versions ultérieures. Si vous souhaitez obtenir plus d’informations, consultez Azure Boards et GitHub.

Non. Cette fonctionnalité n’est pas prise en charge pour l’instant.

La configuration et la personnalisation d’Azure Boards s’effectuent au niveau du projet et de l’équipe. Pour obtenir une vue d’ensemble de ce que vous pouvez configurer et personnaliser pour répondre aux besoins de votre entreprise, consultez Configuration et personnalisation d’Azure Boards.

Pour accéder à la FAQ sur la configuration et la personnalisation, consultez FAQ Azure Boards sur la configuration et la personnalisation.

Articles connexes

• Questions fréquentes (FAQ) sur les requêtes
• Limites du suivi du travail, des processus et des projets
• FAQ sur la configuration et la personnalisation d’Azure Boards
• Questions fréquentes (FAQ) : Utilisation d’Excel avec une connexion à Azure Boards
• Questions fréquentes (FAQ) sur l’ensemble des projets
• Extensions Azure Boards
• À propos des équipes et des outils Agile