Azure Boards stocke les relations de planification sous forme de liens Prédécesseur et Successeur, mais il n'a pas de vue Gantt de chemin critique intégrée. Utilisez Dependency Tracker ou un planificateur connecté et vérifiez quels liens le connecteur importe réellement.
Comment les dépendances Azure DevOps apparaissent-elles dans un diagramme de Gantt ?
Azure Boards enregistre les dépendances de livraison avec des liens directionnels entre les éléments de travail prédécesseur et successeur, mais Azure Boards ne fournit pas de diagramme de Gantt de chemin critique intégré. L’extension Dependency Tracker de Microsoft propose des listes, des vues des risques et une chronologie bêta. Un planificateur connecté peut fournir des barres de tâches et CPM, mais uniquement s’il importe ou recrée les liens de dépendance.
GanttFather importe actuellement les éléments de travail, les dates, les affectations, le statut et la hiérarchie parent/enfant de Azure DevOps dans un projet Gantt. Il n’importe pas les liens Azure Predecessor/Successor en tant que dépendances du Gantt. Après l’extraction, ajoutez les relations de planification dans GanttFather ; ces liens locaux pilotent les flèches de dépendance et l’analyse du chemin critique et ne sont pas écrasés par les extractions ultérieures.
Comportement vérifié : 30 août 2026 par rapport à la documentation Microsoft et au contrat de fonctionnalités Azure DevOps actuel de GanttFather.
Quel type de lien Azure DevOps représente une dépendance ?
Utilisez Prédécesseur/Successeur pour le bon de livraison. Un prédécesseur est le producteur qui doit venir en premier ; un successeur est le consommateur qui en dépend. Azure DevOps empêche les relations circulaires pour cette topologie de dépendance et prend en charge les liens un-vers-plusieurs.
| Relation Azure DevOps | Signification | Est-ce une dépendance d’horaire ? | Interprétation du Gantt |
|---|---|---|---|
| Prédécesseur | L’élément lié doit se terminer avant l’élément actuel | Oui | Généralement côté prédécesseur d’un lien FS |
| Successeur | L’élément lié doit apparaître après l’élément actuel | Oui | Généralement côté successeur d’un lien FS |
| Parent/Enfant | Hiérarchie du portefeuille ou du backlog | Non | Ligne récapitulative/ligne enfant |
| En rapport | Association générale | Non | Référence seulement |
| Produit pour / Consomme à partir de | Dépendance directionnelle interorganisationnelle | Oui, pour les éléments de travail à distance | Dépendance externe nécessitant un mappage explicite |
Pipeline dependsOn | Ordre d’exécution des étapes ou des tâches dans YAML | Pipeline uniquement | Il ne s’agit pas d’un lien vers un élément de travail |
Le parent/enfant et le prédécesseur/successeur répondent à des questions différentes. Le parent/enfant dit : « La fonctionnalité 12 contient la user story 34. » Le prédécesseur/successeur indique que « le contrat API doit se terminer avant le début de l’intégration mobile. » Ne déduisez pas l’ordre de planification de l’imbrication du backlog.
Comment créer des dépendances d’éléments de travail dans Azure Boards ?
- Ouvrez l’élément de travail qui doit attendre.
- Ouvrez la section Liens et choisissez Ajouter un lien.
- Sélectionnez Prédécesseur.
- Recherchez l’élément de travail qui doit être exécuté en premier et enregistrez-le.
- Ouvrez l’autre élément de travail et confirmez le lien Successeur réciproque.
- Ajoutez des dates d’itération significatives ou des champs de planification si la relation doit être affichée sur une chronologie.
Microsoft recommande Prédécesseur/Successeur pour les tâches qui doivent être effectuées dans l’ordre. Ces liens peuvent traverser des projets, bien que les conseils d’importation/exportation Excel de Microsoft recommandent des liens prédécesseurs du même projet lorsque l’aller-retour Excel est important.
Les liens de dépendance des éléments de travail Azure ne stockent pas eux-mêmes tous les détails classiques de CPM. Un lien Prédécesseur/Successeur communique l’ordre, mais un planificateur externe peut toujours avoir besoin de durées, de calendriers, de décalages et d’un mappage explicite vers FS, SS, FF ou SF.
Que peut visualiser Azure DevOps sans un autre planificateur ?
Azure DevOps propose plusieurs surfaces de type chronologie, mais chacune répond à une question différente.
| Surface azurée | Meilleure utilisation | Affiche les relations de dépendance | Planification Gantt complète / chemin critique |
|---|---|---|---|
| Tableaux et arriérés | Flux, priorité, hiérarchie | Liens visibles sur chaque article | Non |
| Plans de livraison | Itérations inter-équipes et calendrier de la feuille de route | Pas un planificateur de réseau de dépendances | Non |
| Extension du suivi des dépendances | Risque de dépendance consommateur/producteur | Oui ; vues de liste, de graphique et de chronologie | Non CPM ; la chronologie est documentée en version bêta |
| Requête WIQL de liens directs | Auditer les éléments de travail liés | Oui, comme résultat de la requête | Pas de chronologie |
| Planificateur de Gantt externe | Dates, barres, flèches, analyse du planning | Dépend du contrat de connecteur | Oui, lorsque des liens et des durées existent |
Microsoft déclare que Azure Boards n’a aucun moyen intégré d’afficher le chemin critique. Dependency Tracker peut signaler un flux correct ou incorrect en fonction du timing du prédécesseur et du successeur, mais sa chronologie dépend des éléments de travail attribués aux chemins d’itération dont les dates de début et de fin sont configurées.
Comment extraire Azure DevOps de travail dans GanttFather ?
Le flux de travail GanttFather actuel est une extraction contrôlée, pas un miroir continu :
- Connexion : saisissez l’URL de l’organisation et le Personal Access Token, puis terminez Tester la connexion.
- Projet : choisissez le projet Azure DevOps accessible avec le jeton.
- Source : choisissez une requête enregistrée ou un tableau d’équipe et, pour un tableau, un niveau ou l’arbre complet.
- Types : vérifiez les types d’éléments de planification à importer.
- Dates et effort : mappez Début, Fin et les champs d’effort facultatifs de chaque type inclus.
- États : mappez les états Azure détectés aux états exacts du projet GanttFather et vérifiez l’état utilisé par Push.
- Destination : choisissez la tâche parente cible, vérifiez le résumé et enregistrez. L’enregistrement lance le premier Pull.
Ajouter une source réutilise la connexion et le projet enregistrés, commence à Source et suit les cinq dernières étapes. Configurer les champs utilise le même modèle en cinq étapes, mais s’ouvre à Dates et effort (étape 3 sur 5) ; Retour permet d’atteindre Types et Source. Après le premier Pull, vérifiez les dates et la hiérarchie et ajoutez les dépendances Gantt.
Pour les captures d’écran et les détails de mappage de champ, utilisez le Documentation d’intégration Azure DevOps et le plus large Azure DevOps Guide de configuration du Gantt.
Quels champs GanttFather importe-t-il à partir de Azure DevOps ?
| Azure DevOps de données | GanttFather résultat | Comportement important |
|---|---|---|
System.Title | Nom de la tâche | Revient à l’ID de l’élément de travail en cas d’absence |
System.Description | Description de la tâche | HTML balises sont supprimées |
System.State | Statut du projet | Utilise le mappage d’état par défaut ou configuré |
| Priorité | Priorité des tâches | Les valeurs Azure 1 à 4 correspondent à Élevé/Moyen/Faible |
| Champ de démarrage configuré | Début de la tâche | Revient à la date de création en cas d’absence |
| Champ Cible/Fin configuré | Fin de la tâche | Revient à un jour après le début en cas d’absence |
| Story points / estimation configurée | Estimation | Facultatif |
| Attribué à | Affectation de membre ou de ressource virtuelle | Résolu à partir d’identités connues |
System.Parent | Tâche parentale | Résolu uniquement lorsque le parent se trouve dans la même source de synchronisation |
| Relations prédécesseur / successeur | Non importé | Ajouter et gérer les dépendances du Gantt localement |
Une extraction répétée met à jour la tâche mappée existante plutôt que de la dupliquer. Si la révision d’un élément de travail Azure n’a pas changé, GanttFather l’ignore. Lorsqu’un élément de travail mappé quitte la requête ou le tableau, GanttFather ferme la tâche locale plutôt que de la supprimer, à moins qu’une autre source dans la même connexion ne le suive toujours.
Comment modéliser les dépendances après l’importation ?
Traduisez la contrainte de livraison, pas seulement l’étiquette du lien Azure. La plupart des relations Azure prédécesseur/successeur sont finish-to-start, mais le travail réel peut nécessiter un autre type.
| Situation | Dépendance du Gantt | Exemple |
|---|---|---|
| Le successeur commence après la fin du prédécesseur | FS | Déployer après examen de sécurité |
| Deux tâches peuvent commencer ensemble | SS | Implémentation back-end et front-end |
| Deux tâches doivent se terminer ensemble | FF | Documentation et version des fonctionnalités |
| Une tâche se termine seulement après le début d’une autre | SF | Retirer l’ancien support après le début du nouveau support |
| Délai d’attente après un événement | FS avec décalage positif | Commencez les mesures deux jours après le déploiement |
| Chevauchement intentionnel | Type approprié avec décalage négatif | Démarrez le contrôle qualité deux jours avant la fin de la mise en œuvre |
GanttFather applique des règles de dépendance entre les tâches sœurs, rejette les cycles et les liens entre projets, et prend en charge un décalage de -365 à 365 jours calendaires. Lire les quatre types de dépendances du Gantt avant de traduire une relation Azure complexe.
Créez des dépendances uniquement après avoir vérifié les dates importées. Une barre d’un jour par défaut provoquée par une date cible Azure manquante peut amener un réseau de dépendances techniquement valide à produire un chemin critique dénué de sens.
Que se passe-t-il lorsque Azure DevOps ou GanttFather change plus tard ?
Pull révisé compare les champs mappés avant de modifier la chronologie. Les modifications propres à Azure sont sélectionnées ; une date ou un état local en conflit reste local avec l’option par défaut Conserver mes modifications. Lors d’une ouverture normale, le résumé reste compact et Avancé est replié ; Conserver mes modifications et Restaurer depuis Azure apparaissent sous Avancé. Le raccourci Azure dans l’en-tête du projet et Données et synchronisation n’affichent que les deux actions courantes, Extraire depuis Azure et Envoyer vers Azure. L’importation initiale a lieu pendant la configuration, tandis que l’opération complète et distincte Synchroniser la source reste une action de maintenance dans les Paramètres. Aucun des parcours n’écrase les dépendances locales ni l’ordre des tâches.
Depuis le raccourci, Paramètres ou Données et synchronisation, ouvrir Pull ou Push après la fin de la comparaison précédente demande une nouvelle comparaison produite par le serveur afin d’inclure les dernières modifications Azure. Seule une autre ouverture de la même source pendant que cette vérification est encore en cours partage la requête en cours.
Push est le parcours de publication distinct et révisé. Les dates et états locaux éligibles, conflits compris, sont sélectionnés par défaut ; confirmer remplace ces valeurs Azure mappées plus récentes et extraire d’abord est facultatif. Réviser Pull ouvre immédiatement Avancé afin que Conserver mes modifications et Restaurer depuis Azure soient visibles dans la même boîte de dialogue. Un Pull ou Push réussi ferme la boîte de dialogue ; Conserver mes modifications · Fermer la ferme sans lancer d’opération. Les estimations et dépendances locales ne sont jamais envoyées. Publier exige un PAT avec Éléments de travail : lecture et écriture.
Si une date de début ou de fin sélectionnée forme une plage invalide avec l’autre date actuelle dans Azure, Envoyer est désactivé avant publication et aucune écriture n’est envoyée à Azure. Réviser Pull ouvre Avancé pour restaurer une plage de dates cohérente ; vous pouvez aussi fermer la boîte de dialogue et corriger les dates locales.
Il n’y a pas de planificateur ni de webhook pour l’intégration. Si le plan Azure change quotidiennement, désignez un propriétaire ou un administrateur pour appliquer une cadence convenue et enregistrer la dernière synchronisation réussie avant de planifier les révisions.
Comment les extensions Marketplace se comparent-elles à un outil Gantt externe ?
Utilisez Dependency Tracker lorsque Azure DevOps doit rester la seule surface de gestion du travail et que l’équipe a principalement besoin de risques consommateur/producteur inter-équipes. Il préserve les liens natifs et réduit la duplication.
Utilisez un outil Gantt externe lorsque l’équipe a besoin de barres datées déplaçables, de types de dépendances, de décalages, de chemins critiques, de partage entre parties prenantes ou d’un planning incluant des tâches non-Azure. Avant de choisir un connecteur, vérifiez ces questions exactes :
- Importe-t-il des liens Prédécesseur/Successeur ou uniquement la hiérarchie Parent/Enfant ?
- Quels champs de date et de durée font autorité ?
- La synchronisation est-elle automatique, planifiée ou manuelle ?
- Dans quelle direction peut-on écrire et y a-t-il une étape de révision ?
- Que se passe-t-il lorsqu’un élément quitte la requête source ?
- Peut-il effectuer un type de dépendance aller-retour et être en retard sans perte ?
GanttFather est franc sur le premier point : son connecteur Azure actuel importe la hiérarchie mais pas les liens de dépendance Azure. Cela rend GanttFather approprié lorsque vous souhaitez construire le réseau de planification localement ; il ne s’agit pas d’une réplique sans maintenance du graphique de liens d’Azure.
Sont YAML dependencies la même chose que les dépendances des éléments de travail ?
N° Azure Pipelines utilise dependsOn, dependencies, et stageDependencies pour contrôler l’exécution de l’étape/du travail et lire les sorties précédentes. Ces expressions sont des concepts d’exécution de pipeline. Ils ne créent pas de liens Prédécesseur/Successeur entre Azure Boards éléments de travail et n’apparaissent pas automatiquement dans un diagramme de Gantt.
Par exemple, $[ dependencies.Build.outputs['setVersion.value'] ] lit la variable de sortie d’un travail précédent. Il ne dit rien sur les dates prévues d’une fonctionnalité ou d’une user story. Utilisez celui de Microsoft référence aux expressions de pipeline pour les erreurs YAML et la référence du lien d’élément de travail pour les relations de planification.
Quand GanttFather est-il utile aux côtés d’Azure DevOps ?
Utilisez GanttFather lorsque Azure DevOps doit rester le système de backlog et d’enregistrement des livraisons tandis qu’un groupe plus petit est propriétaire du calendrier inter-équipes. Le connecteur peut extraire les champs d’éléments de travail mappés et la hiérarchie Parent/Enfant dans un seul projet Gantt ; après chaque extraction manuelle, les planificateurs peuvent ajouter des dépendances FS, SS, FF et SF avec décalage, calculer le chemin critique et partager le résultat en direct avec les téléspectateurs ou les invités.
Il ne s’agit pas d’un miroir de dépendances : les liens prédécesseur/successeur d’Azure ne sont ni importés ni réécrits, et un propriétaire ou un administrateur doit déclencher et examiner l’activité d’intégration dans l’application. Le niveau gratuit couvre un projet détenu avec deux sièges d’éditeur et un nombre illimité de spectateurs et d’invités. Si cette répartition contrôlée correspond à votre processus, créez un projet GanttFather gratuit et validez une requête Azure avant de créer le réseau local complet.
Que demandent d’autre les gens à propos des dépendances Azure DevOps ?
Est-ce que Azure DevOps a un diagramme de Gantt natif ?
Azure Boards dispose de feuilles de route et de surfaces chronologiques basées sur des extensions, mais Microsoft ne fournit pas de diagramme de Gantt classique intégré avec analyse du chemin critique. Dependency Tracker comprend une chronologie bêta pour le flux de dépendances ; Les plans de livraison se concentrent sur la planification inter-équipes basée sur les itérations.
GanttFather importe-t-il les liens Azure Prédécesseur/Successeur ?
Non. Le connecteur actuel importe les champs d’éléments de travail et la hiérarchie Parent/Enfant de même source. Les liens Azure Prédécesseur/Successeur ne sont pas convertis en dépendances du Gantt. Ajoutez ces relations de planification dans GanttFather après l’importation ; les extractions répétées préservent l’ensemble de dépendances local.
GanttFather peut-il repousser les dépendances à Azure DevOps ?
Non. Le Push révisé couvre les champs d’éléments de travail mappés explicitement sélectionnés, et non les liens de relation Azure. Il ne crée, ne met pas à jour ou ne supprime pas les relations prédécesseur/successeur. Conservez le graphique de liens Azure faisant autorité lorsque ces liens natifs sont requis par d’autres outils Azure.
Azure DevOps peut-il afficher un chemin critique ?
Microsoft déclare que Azure Boards n’a pas de vue de chemin critique intégrée. Un planificateur externe peut en calculer un après avoir défini des dates de tâches, des durées et un réseau de dépendances complet. Un graphique basé uniquement sur la hiérarchie Parent/Enfant ne peut pas produire un chemin critique défendable.
Un agent IA peut-il déclencher la synchronisation Azure DevOps via GanttFather MCP ?
Non. Le serveur MCP de GanttFather ne dispose pas d’outils d’intégration Azure. Un propriétaire ou un administrateur doit configurer la connexion, déclencher Pull, examiner les comparaisons et confirmer Push dans l’application. Une fois les tâches présentes, un agent autorisé peut travailler avec les tâches GanttFather et les dépendances locales.
Comportement du produit vérifié : 30 août 2026.
Sources


