Azure Boards memorizza le relazioni di pianificazione come collegamenti Predecessore e Successore, ma non dispone di una visualizzazione Gantt del percorso critico incorporata. Utilizza Dependency Tracker o uno scheduler connesso e verifica quali collegamenti vengono effettivamente importati dal connettore.
Come vengono visualizzate le dipendenze di Azure DevOps in un diagramma di Gantt?
Azure Boards registra le dipendenze di consegna con collegamenti direzionali agli elementi di lavoro Predecessore e Successore, ma Azure Boards non fornisce un diagramma di Gantt del percorso critico integrato. L’estensione Dependency Tracker di Microsoft offre elenchi, visualizzazioni dei rischi e una sequenza temporale beta. Uno strumento di pianificazione connesso può fornire barre delle attività e CPM, ma solo se importa o ricrea i collegamenti di dipendenza.
GanttFather attualmente importa Azure DevOps elementi di lavoro, date, assegnazioni, stato e gerarchia padre/figlio in un progetto Gantt. Non importa i collegamenti predecessore/successore di Azure come dipendenze Gantt. Dopo il pull, aggiungi le relazioni di pianificazione in GanttFather; questi collegamenti locali guidano le frecce di dipendenza e l’analisi del percorso critico e non vengono sovrascritti da pull successivi.
Comportamento verificato: 30 agosto 2026 rispetto alla documentazione Microsoft e all’attuale contratto di funzionalità Azure DevOps di GanttFather.
Quale tipo di collegamento Azure DevOps rappresenta una dipendenza?
Utilizza Predecessore/Successore per l’ordine di consegna. Un predecessore è il produttore che deve venire prima; un successore è il consumatore che dipende da esso. Azure DevOps impedisce le relazioni circolari per questa topologia di dipendenza e supporta i collegamenti uno-a-molti.
| Relazione di Azure DevOps | Significato | È una dipendenza dalla pianificazione? | Interpretazione di Gantt |
|---|---|---|---|
| Predecessore | L’elemento collegato dovrebbe terminare prima dell’elemento corrente | Sì | Di solito il lato predecessore di un collegamento FS |
| Successore | L’elemento collegato dovrebbe trovarsi dopo l’elemento corrente | Sì | Di solito il lato successore di un collegamento FS |
| Genitore/Figlio | Gerarchia del portafoglio o del backlog | No | Riga di riepilogo/riga secondaria |
| Relativo | Associazione generale | No | Solo riferimento |
| Produce per/consuma da | Dipendenza direzionale tra organizzazioni | Sì, per gli articoli di lavoro remoto | Dipendenza esterna che richiede la mappatura esplicita |
Conduttura dependsOn | Ordine di esecuzione della fase o del lavoro in YAML | Solo pipeline | Non un collegamento a un elemento di lavoro |
Genitore/Figlio e Predecessore/Successore rispondono a domande diverse. Il genitore/figlio dice “La funzione 12 contiene la User Story 34”. Il predecessore/successore afferma che “il contratto di API deve terminare prima che inizi l’integrazione mobile”. Non dedurre l’ordine di pianificazione dall’annidamento del backlog.
Come si creano le dipendenze degli elementi di lavoro in Azure Boards?
- Aprire l’oggetto di lavoro che deve attendere.
- Apri la sezione Link e scegli Aggiungi link.
- Seleziona Predecessore.
- Trova l’elemento di lavoro che deve essere eseguito per primo e salva.
- Aprire l’altro oggetto di lavoro e confermare il collegamento reciproco Successore.
- Aggiungi date di iterazione significative o campi di pianificazione se la relazione verrà mostrata su una sequenza temporale.
Microsoft consiglia Predecessore/Successore per le attività che devono essere completate in sequenza. Questi collegamenti possono incrociare progetti, anche se le linee guida sull’importazione/esportazione di Excel di Microsoft consigliano collegamenti predecessori dello stesso progetto quando Excel andata e ritorno è importante.
I collegamenti di dipendenza degli elementi di lavoro di Azure non archiviano da soli tutti i dettagli classici di CPM. Un collegamento Predecessore/Successore comunica l’ordine, ma uno scheduler esterno potrebbe comunque aver bisogno di durate, calendari, ritardo e una mappatura esplicita su FS, SS, FF o SF.
Cosa può visualizzare Azure DevOps senza un altro scheduler?
Azure DevOps offre diverse superfici simili a timeline, ma ognuna risponde a una domanda diversa.
| Superficie azzurra | Miglior utilizzo | Mostra le relazioni di dipendenza | Pianificazione completa del Gantt/percorso critico |
|---|---|---|---|
| Board e arretrati | Flusso, priorità, gerarchia | Collegamenti visibili su ciascun articolo | No |
| Piani di consegna | Iterazioni tra team e tempistiche della roadmap | Non uno scheduler di rete dipendente | No |
| Estensione Tracker delle dipendenze | Rischio di dipendenza consumatore/produttore | Sì; visualizzazioni elenco, grafico e sequenza temporale | Nessun CPM; la sequenza temporale è documentata come beta |
| Query WIQL con collegamenti diretti | Controllare gli elementi di lavoro collegati | Sì, come risultati della query | Nessuna cronologia |
| Pianificatore Gantt esterno | Date, barre, frecce, analisi del programma | Dipende dal contratto del connettore | Sì, quando esistono collegamenti e durate |
Microsoft afferma che Azure Boards non dispone di un modo integrato per mostrare il percorso critico. Il tracciatore delle dipendenze può contrassegnare il flusso corretto o errato in base alla tempistica del predecessore e del successore, ma la sua sequenza temporale dipende dagli elementi di lavoro assegnati ai percorsi di iterazione le cui date di inizio e fine sono configurate.
Come si inserisce il lavoro di Azure DevOps in GanttFather?
L’attuale flusso di lavoro di GanttFather è un pull controllato, non un mirroring continuo:
- Connessione: inserisci l’URL dell’organizzazione e il Personal Access Token e completa Test connessione.
- Progetto: scegli il progetto Azure DevOps accessibile dal token.
- Origine: scegli una query salvata o una bacheca del team e, per le bacheche, un livello o l’albero completo.
- Tipi: verifica i tipi di elementi di pianificazione da importare.
- Date e impegno: associa Inizio, Fine e i campi di impegno facoltativi per ogni tipo incluso.
- Stati: associa gli stati Azure rilevati agli stati esatti del progetto GanttFather e verifica lo stato usato da Push.
- Destinazione: scegli l’attività padre, verifica il riepilogo e salva. Il salvataggio avvia il primo Pull.
Aggiungi origine riutilizza la connessione e il progetto salvati, parte da Origine e segue gli ultimi cinque passaggi. Configura campi usa lo stesso modello ma si apre su Date e impegno (passaggio 3 di 5); Indietro raggiunge Tipi e Origine. Dopo il primo Pull, verifica date e gerarchia e aggiungi le dipendenze Gantt.
Per screenshot e dettagli sulla mappatura dei campi, utilizzare il file Documentazione di integrazione di Azure DevOps e quello più ampio Azure DevOps Guida all’impostazione del Gantt.
Quali campi importa GanttFather da Azure DevOps?
| Azure DevOps dati | Risultato di GanttFather | Comportamento importante |
|---|---|---|
System.Title | Nome dell’attività | Ritorna all’ID dell’elemento di lavoro quando manca |
System.Description | Descrizione del compito | I tag HTML sono stati rimossi |
System.State | Stato del progetto | Utilizza la mappatura dello stato predefinita o configurata |
| Priorità | Priorità del compito | I valori di Azure da 1 a 4 vengono mappati su Alto/Medio/Basso |
| Campo Inizio configurato | Inizio attività | Ritorna alla data di creazione quando assente |
| Campo Target/Fine configurato | Fine del compito | Ritorna a un giorno dopo l’inizio in caso di assenza |
| Punti della storia/stima configurata | Stima | Facoltativo |
| Assegnato a | Assegnazione di membri o risorse virtuali | Risolto da identità conosciute |
System.Parent | Compito del genitore | Risolto solo quando il genitore si trova nella stessa origine di sincronizzazione |
| Relazioni predecessore/successore | Non importato | Aggiungi e mantieni le dipendenze Gantt localmente |
Un pull ripetuto aggiorna l’attività mappata esistente anziché duplicarla. Se la revisione di un elemento di lavoro di Azure non è cambiata, GanttFather la salta. Quando un elemento di lavoro mappato lascia la query o la bacheca, GanttFather chiude l’attività locale anziché eliminarla, a meno che un’altra origine nella stessa connessione non la tenga ancora traccia.
Come dovresti modellare le dipendenze dopo l’importazione?
Tradurre il vincolo di recapito, non semplicemente l’etichetta del collegamento di Azure. La maggior parte delle relazioni predecessore/successore di Azure sono finish-to-start, ma il lavoro reale potrebbe richiedere un altro tipo.
| Situazione | Dipendenza da Gantt | Esempio |
|---|---|---|
| Il successore inizia al termine del predecessore | FS | Distribuire dopo il controllo della sicurezza |
| Due attività possono iniziare insieme | SS | Implementazione backend e frontend |
| Due compiti devono finire insieme | FF | Documentazione e rilascio di funzionalità |
| Un’attività termina solo dopo l’inizio di un’altra | SF | Ritirare il vecchio supporto dopo l’inizio del nuovo supporto |
| Periodo di attesa dopo un evento | FS con ritardo positivo | Inizia la misurazione due giorni dopo l’implementazione |
| Sovrapposizione intenzionale | Tipo appropriato con ritardo negativo | Avvia il QA due giorni prima del termine dell’implementazione |
GanttFather applica regole di dipendenza tra attività di pari livello, rifiuta cicli e collegamenti tra progetti e supporta un ritardo da -365 a 365 giorni di calendario. Leggi i quattro tipi di dipendenza Gantt prima di tradurre una relazione complessa di Azure.
Crea dipendenze solo dopo aver controllato le date importate. Una barra predefinita di un giorno causata da una data di destinazione di Azure mancante può far sì che una rete di dipendenze tecnicamente valida produca un percorso critico senza significato.
Cosa succede quando Azure DevOps o GanttFather cambiano in seguito?
Il Pull revisionato confronta i campi associati prima di modificare la timeline. Le modifiche solo Azure sono selezionate; una data o uno stato locale in conflitto resta locale con l’opzione predefinita Mantieni le mie modifiche. Aprendo Pull normalmente, il riepilogo resta compatto e Avanzate è chiuso; Mantieni le mie modifiche e Ripristina da Azure compaiono sotto Avanzate. Il collegamento Azure nell’intestazione del progetto e Dati e sincronizzazione mostrano solo le due azioni quotidiane, Pull da Azure e Push ad Azure. L’importazione iniziale avviene durante la configurazione, mentre l’operazione completa e separata Sincronizza origine resta un’azione di manutenzione nelle Impostazioni. Nessuno dei flussi sostituisce le dipendenze locali o l’ordine delle attività.
Dal collegamento, da Impostazioni o da Dati e sincronizzazione, aprire Pull o Push dopo il completamento del confronto precedente richiede un nuovo confronto generato dal server, così la revisione include le ultime modifiche Azure. Solo un’altra apertura della stessa origine mentre la verifica è ancora in corso condivide la richiesta in corso.
Push è il flusso separato e revisionato di pubblicazione. Date e stati locali idonei, inclusi i conflitti, sono selezionati per impostazione predefinita; la conferma sovrascrive quei valori Azure associati più recenti e fare prima Pull è facoltativo. Rivedi Pull apre subito Avanzate, così Mantieni le mie modifiche e Ripristina da Azure sono visibili nello stesso dialogo. Un Pull o Push riuscito chiude il dialogo; Mantieni le mie modifiche · Chiudi lo chiude senza operazioni. Stime e dipendenze locali non vengono mai inviate. La pubblicazione richiede un PAT con Elementi di lavoro: lettura e scrittura.
Se una data di inizio o fine selezionata crea un intervallo non valido con l’altra data corrente in Azure, Invia viene disabilitato prima della pubblicazione e non viene eseguita alcuna scrittura in Azure. Rivedi Pull apre Avanzate per ripristinare un intervallo di date coerente; in alternativa, chiudi il dialogo e modifica le date locali.
Non esiste uno scheduler o un webhook per l’integrazione. Se il piano di Azure cambia ogni giorno, assegna a un proprietario o un amministratore il compito di eseguire una cadenza concordata e registrare l’ultima sincronizzazione riuscita prima di pianificare le revisioni.
Come si confrontano le estensioni del marketplace con uno strumento Gantt esterno?
Utilizzare Dependency Tracker quando Azure DevOps dovrebbe rimanere l’unica superficie di gestione del lavoro e il team necessita principalmente del rischio consumatore/produttore tra team. Preserva i collegamenti nativi e riduce la duplicazione.
Usare uno strumento Gantt esterno quando il team ha bisogno di barre della data trascinabili, tipi di dipendenza, ritardo, percorso critico, condivisione delle parti interessate o una pianificazione che includa lavoro non di Azure. Prima di scegliere qualsiasi connettore, verifica queste esatte domande:
- Importa i collegamenti Predecessore/Successore o solo la gerarchia Padre/Figlio?
- Quali campi di data e durata sono autorevoli?
- La sincronizzazione è automatica, pianificata o manuale?
- Quale direzione può scrivere e c’è una fase di revisione?
- Cosa succede quando un elemento lascia la query di origine?
- È possibile eseguire il tipo di dipendenza di andata e ritorno e ritardare senza perdite?
GanttFather è sincero sul primo punto: il suo attuale connettore Azure importa la gerarchia ma non i collegamenti di dipendenza di Azure. Ciò rende GanttFather adatto quando si desidera costruire la rete di pianificazione localmente; non è una replica che non richiede manutenzione del grafico dei collegamenti di Azure.
Sono YAML dependencies lo stesso delle dipendenze degli elementi di lavoro?
No. Azure Pipelines utilizza dependsOn, dependencies, e stageDependencies per controllare l’esecuzione di fasi/lavori e leggere gli output precedenti. Tali espressioni sono concetti di runtime della pipeline. Non creano collegamenti Predecessore/Successore tra gli elementi di lavoro Azure Boards e non vengono visualizzati automaticamente in un diagramma di Gantt.
Ad esempio, $[ dependencies.Build.outputs['setVersion.value'] ] legge la variabile di output di un lavoro precedente. Non dice nulla sulle date pianificate di una funzionalità o di una user story. Usa quelli di Microsoft riferimento alle espressioni della pipeline per gli errori YAML e il riferimento al collegamento dell’elemento di lavoro per le relazioni di pianificazione.
Quando GanttFather è utile insieme ad Azure DevOps?
Utilizza GanttFather quando Azure DevOps dovrebbe rimanere il sistema di arretrato e record di consegna mentre un gruppo più piccolo possiede la pianificazione tra team. Il connettore può inserire campi di elementi di lavoro mappati e gerarchia padre/figlio in un progetto Gantt; dopo ogni pull manuale, i pianificatori possono aggiungere dipendenze FS, SS, FF e SF con ritardo, calcolare il percorso critico e condividere il risultato in tempo reale con spettatori o ospiti.
Non si tratta di un mirror delle dipendenze: i collegamenti predecessore/successore di Azure non vengono importati o riscritti e un proprietario o amministratore deve attivare ed esaminare l’attività di integrazione nell’app. Il livello gratuito copre un progetto di proprietà con due postazioni editor e spettatori e ospiti illimitati. Se questa suddivisione controllata si adatta al tuo processo, crea un progetto GanttFather gratuito e convalida una query di Azure prima di creare la rete locale completa.
Cos’altro chiedono le persone sulle dipendenze di Azure DevOps?
Azure DevOps dispone di un diagramma di Gantt nativo?
Azure Boards dispone di roadmap e superfici della sequenza temporale basate su estensioni, ma Microsoft non fornisce un diagramma di Gantt classico integrato con analisi del percorso critico. Dependency Tracker include una sequenza temporale beta per il flusso delle dipendenze; Delivery Plans si concentra sulla pianificazione tra team basata sull’iterazione.
GanttFather importa i collegamenti predecessore/successore di Azure?
No. Il connettore corrente importa campi elemento di lavoro e gerarchia Principale/Figlio della stessa origine. I collegamenti predecessore/successore di Azure non vengono convertiti in dipendenze Gantt. Aggiungi queste relazioni di pianificazione in GanttFather dopo l’importazione; i pull ripetuti preservano il set di dipendenze locali.
GanttFather può riportare le dipendenze a Azure DevOps?
No. Il Push revisionato riguarda i campi degli elementi di lavoro mappati selezionati in modo esplicito, non i collegamenti alle relazioni di Azure. Non crea, aggiorna o elimina le relazioni Predecessore/Successore. Mantenere autorevole il grafico dei collegamenti di Azure quando tali collegamenti nativi sono richiesti da altri strumenti di Azure.
Azure DevOps può mostrare un percorso critico?
Microsoft afferma che Azure Boards non dispone di una visualizzazione del percorso critico incorporata. Uno scheduler esterno può calcolarne uno dopo che ha date e durate delle attività valide e una rete di dipendenze completa. Un grafico basato solo sulla gerarchia Padre/Figlio non può produrre un percorso critico difendibile.
Un agente AI può attivare la sincronizzazione di Azure DevOps tramite GanttFather MCP?
No. Il server MCP di GanttFather non dispone di strumenti di integrazione di Azure. Un proprietario o un amministratore deve configurare la connessione, attivare Pull, rivedere i confronti e confermare Push nell’applicazione. Una volta presenti le attività, un agente autorizzato può lavorare con le attività GanttFather e le dipendenze locali.
Comportamento del prodotto controllato: 30 agosto 2026.
Fonti
- Microsoft Learn, Utilizzare l’estensione Dependency Tracker
- Microsoft Learn, Riferimento sui tipi di collegamento
- Microsoft Learn, Gestione dei requisiti per i team Agile
- Microsoft Learn, sintassi di WIQL per i collegamenti a elementi di lavoro
- GanttFather, Azure DevOps documentazione di integrazione
