Azure Boards armazena relacionamentos de cronograma como links Predecessor e Sucessor, mas não possui visualização de Gantt de caminho crítico integrada. Use o Dependency Tracker ou um agendador conectado e verifique quais links o conector realmente importa.
Como as dependências de Azure DevOps aparecem em um gráfico de Gantt?
Azure Boards registra dependências de entrega com links direcionais de item de trabalho Predecessor e Successor, mas Azure Boards não fornece um gráfico de Gantt de caminho crítico integrado. A extensão Dependency Tracker da Microsoft oferece listas, visualizações de risco e um cronograma beta. Um agendador conectado pode fornecer barras de tarefas e CPM — mas apenas se importar ou recriar os links de dependência.
Atualmente, GanttFather importa itens de trabalho, datas, atribuições, status e hierarquia pai/filho de Azure DevOps para um projeto de Gantt. Ele não importa links do Predecessor/Sucessor do Azure como dependências de Gantt. Após o pull, adicione os relacionamentos de agendamento em GanttFather; esses links locais direcionam setas de dependência e análise de caminho crítico e não são substituídos por pulls posteriores.
Comportamento verificado: 30 de agosto de 2026 em relação à documentação da Microsoft e ao contrato de recurso atual de GanttFather Azure DevOps.
Qual tipo de link Azure DevOps representa uma dependência?
Use Predecessor/Sucessor para pedido de entrega. Um antecessor é o produtor que deve vir primeiro; um sucessor é o consumidor que dele depende. Azure DevOps evita relacionamentos circulares para esta topologia de dependência e oferece suporte a links um-para-muitos.
| Azure DevOps relacionamento | Significado | É uma dependência de cronograma? | Interpretação de Gantt |
|---|---|---|---|
| Antecessor | O item vinculado deve terminar antes do item atual | Sim | Geralmente o lado predecessor de um link FS |
| Sucessor | O item vinculado deve acontecer depois do item atual | Sim | Geralmente lado sucessor de um link FS |
| Pai/Filho | Hierarquia de portfólio ou backlog | Não | Linha de resumo/linha secundária |
| Relacionado | Associação geral | Não | Apenas referência |
| Produz para/consome de | Dependência direcional entre organizações | Sim, para itens de trabalho remoto | Dependência externa que requer mapeamento explícito |
Gasoduto dependsOn | Ordem de execução de estágio ou trabalho em YAML | Somente pipeline | Não é um link de item de trabalho |
Pai/Filho e Predecessor/Sucessor respondem a perguntas diferentes. Pai/Filho diz “O recurso 12 contém a história do usuário 34”. O antecessor/sucessor diz que “o contrato de API deve terminar antes do início da integração móvel”. Não infira a ordem de agendamento a partir do aninhamento do backlog.
Como você cria dependências de itens de trabalho em Azure Boards?
- Abra o item de trabalho que deve aguardar.
- Abra a seção Links e escolha Adicionar link.
- Selecione Predecessor.
- Encontre o item de trabalho que deve acontecer primeiro e salve.
- Abra o outro item de trabalho e confirme o link recíproco Sucessor.
- Adicione datas de iteração significativas ou campos de agendamento se o relacionamento for mostrado em uma linha do tempo.
A Microsoft recomenda o Predecessor/Sucessor para tarefas que devem ser concluídas em sequência. Esses links podem cruzar projetos, embora a orientação de importação/exportação do Excel da Microsoft recomende links de predecessores do mesmo projeto quando a viagem de ida e volta do Excel for importante.
Os links de dependência de item de trabalho do Azure não armazenam todos os detalhes clássicos de CPM por si só. Um link Predecessor/Sucessor comunica ordem, mas um agendador externo ainda pode precisar de durações, calendários, atrasos e um mapeamento explícito para FS, SS, FF ou SF.
O que Azure DevOps pode visualizar sem outro agendador?
Azure DevOps oferece diversas superfícies semelhantes a linhas do tempo, mas cada uma responde a uma pergunta diferente.
| Superfície azul | Melhor uso | Mostra relacionamentos de dependência | Agendamento completo de Gantt/caminho crítico |
|---|---|---|---|
| Quadros e pendências | Fluxo, prioridade, hierarquia | Links visíveis em cada item | Não |
| Planos de entrega | Iterações entre equipes e cronograma do roteiro | Não é um agendador de rede de dependência | Não |
| Extensão do Rastreador de Dependência | Risco de dependência do consumidor/produtor | Sim; visualizações de lista, gráfico e linha do tempo | Não há CPM; a linha do tempo está documentada como beta |
| Consulta WIQL de links diretos | Auditar itens de trabalho vinculados | Sim, como resultados da consulta | Sem cronograma |
| Agendador de Gantt externo | Datas, barras, setas, análise de cronograma | Depende do contrato do conector | Sim, quando existem links e durações |
A Microsoft afirma que Azure Boards não possui uma maneira integrada de mostrar o caminho crítico. O Dependency Tracker pode sinalizar o fluxo correto ou incorreto com base no tempo do antecessor e do sucessor, mas seu cronograma depende dos itens de trabalho atribuídos a caminhos de iteração cujas datas de início e término estão configuradas.
Como você transfere Azure DevOps trabalho para GanttFather?
O fluxo de trabalho atual do GanttFather é um pull controlado, não um espelho contínuo:
- Conexão: insira a URL da organização e o Personal Access Token e conclua Testar conexão.
- Projeto: escolha o projeto Azure DevOps acessível pelo token.
- Origem: escolha uma consulta salva ou quadro da equipe e, para quadros, um nível ou a árvore completa.
- Tipos: revise os tipos de item de planejamento que serão importados.
- Datas e esforço: mapeie Início, Fim e campos de esforço opcionais para cada tipo incluído.
- Status: mapeie os estados Azure detectados para os estados exatos do projeto GanttFather e revise o estado usado pelo Push.
- Destino: escolha a tarefa pai, revise o resumo e salve. Salvar inicia o primeiro Pull.
Adicionar origem reutiliza a conexão e o projeto salvos, começa em Origem e segue os cinco últimos passos. Configurar campos usa o mesmo modelo, mas abre em Datas e esforço (passo 3 de 5); Voltar alcança Tipos e Origem. Após o primeiro Pull, revise datas e hierarquia e adicione dependências Gantt.
Para capturas de tela e detalhes de mapeamento de campo, use o Documentação de integração de Azure DevOps e o mais amplo Azure DevOps Guia de configuração do Gantt.
Quais campos GanttFather importa de Azure DevOps?
| Azure DevOps dados | Resultado de GanttFather | Comportamento importante |
|---|---|---|
System.Title | Nome da tarefa | Volta para o ID do item de trabalho quando ausente |
System.Description | Descrição da tarefa | HTML tags foram removidas |
System.State | Status do projeto | Usa mapeamento de estado padrão ou configurado |
| Prioridade | Prioridade da tarefa | Os valores 1–4 do Azure são mapeados para Alto/Médio/Baixo |
| Campo inicial configurado | Início da tarefa | Volta para a data de criação quando ausente |
| Campo Destino/Fim configurado | Fim da tarefa | Volta para um dia após o início quando ausente |
| Pontos da história/estimativa configurada | Estimativa | Opcional |
| Atribuído a | Atribuição de membro ou recurso virtual | Resolvido a partir de identidades conhecidas |
System.Parent | Tarefa pai | Resolvido somente quando o pai está na mesma fonte de sincronização |
| Relações antecessor/sucessor | Não importado | Adicione e mantenha dependências de Gantt localmente |
Um pull repetido atualiza a tarefa mapeada existente em vez de duplicá-la. Se a revisão de um item de trabalho do Azure não tiver sido alterada, GanttFather ignora-o. Quando um item de trabalho mapeado sai da consulta ou do quadro, GanttFather fecha a tarefa local em vez de excluí-la, a menos que outra fonte na mesma conexão ainda o rastreie.
Como você deve modelar dependências após a importação?
Traduza a restrição de entrega, não apenas o rótulo do link do Azure. A maioria das relações Predecessor/Sucessor do Azure são finish-to-start, mas o trabalho real pode exigir outro tipo.
| Situação | Dependência de Gantt | Exemplo |
|---|---|---|
| O sucessor começa após o antecessor terminar | FS | Implantar após análise de segurança |
| Duas tarefas podem começar juntas | SS | Implementação de back-end e front-end |
| Duas tarefas devem terminar juntas | FF | Documentação e lançamento de recursos |
| Uma tarefa só termina depois que outra começa | SF | Descontinuar o suporte antigo após o início do novo suporte |
| Período de espera após um evento | FS com atraso positivo | Comece a medição dois dias após o lançamento |
| Sobreposição intencional | Tipo apropriado com atraso negativo | Inicie o controle de qualidade dois dias antes do término da implementação |
GanttFather impõe regras de dependência entre tarefas irmãs, rejeita ciclos e links entre projetos e suporta atraso de -365 a 365 dias corridos. Leia os quatro tipos de dependência de Gantt antes de traduzir um relacionamento complexo do Azure.
Crie dependências somente após verificar as datas importadas. Uma barra padrão de um dia causada por uma data-alvo do Azure ausente pode fazer com que uma rede de dependência tecnicamente válida produza um caminho crítico sem sentido.
O que acontece quando Azure DevOps ou GanttFather mudam posteriormente?
O Pull revisado compara os campos mapeados antes de alterar a linha do tempo. Alterações apenas no Azure ficam selecionadas; uma data ou status local em conflito permanece local com a opção padrão Manter minhas alterações. Ao abrir Pull normalmente, o resumo permanece compacto e Avançado fica recolhido; Manter minhas alterações e Restaurar do Azure aparecem em Avançado. O atalho do Azure no cabeçalho do projeto e Dados e sincronização mostram apenas as duas ações cotidianas, Pull do Azure e Push para o Azure. A importação inicial ocorre durante a configuração, enquanto a operação completa e separada Sincronizar fonte continua sendo uma ação de manutenção nas Configurações. Nenhum dos fluxos substitui dependências locais ou a ordenação das tarefas.
No atalho, em Configurações ou em Dados e sincronização, abrir Pull ou Push depois que a comparação anterior terminar solicita uma nova comparação criada pelo servidor, para que a revisão inclua as alterações mais recentes do Azure. Somente uma solicitação ainda em andamento é compartilhada quando a mesma origem é aberta novamente durante essa verificação.
Push é o fluxo separado e revisado de publicação. Datas e status locais elegíveis, inclusive conflitos, ficam selecionados por padrão; confirmar substitui esses valores Azure mapeados mais recentes e fazer Pull primeiro é opcional. Revisar Pull abre Avançado imediatamente para que Manter minhas alterações e Restaurar do Azure fiquem visíveis no mesmo diálogo. Um Pull ou Push bem-sucedido fecha o diálogo; Manter minhas alterações · Fechar o fecha sem operação. Estimativas e dependências locais nunca são enviadas. Publicar exige PAT com Itens de trabalho: leitura e gravação.
Se uma data de início ou fim selecionada formar um intervalo inválido com a outra data atual no Azure, Enviar ficará desativado antes da publicação e nada será gravado no Azure. Revisar Pull abre Avançado para restaurar um intervalo de datas coerente; também é possível fechar o diálogo e ajustar as datas locais.
Não há agendador ou webhook para a integração. Se o plano do Azure mudar diariamente, atribua um proprietário ou administrador para executar uma cadência acordada e registar a última sincronização bem-sucedida antes das revisões do agendamento.
Como as extensões de mercado se comparam a uma ferramenta Gantt externa?
Use o Dependency Tracker quando Azure DevOps deve permanecer a única superfície de gerenciamento de trabalho e a equipe precisa principalmente de risco de consumidor/produtor entre equipes. Preserva links nativos e reduz a duplicação.
Use uma ferramenta Gantt externa quando a equipe precisar de barras datadas arrastáveis, tipos de dependência, atraso, caminho crítico, compartilhamento das partes interessadas ou um cronograma que inclua trabalho não-Azure. Antes de escolher qualquer conector, verifique exatamente estas questões:
- Ele importa links Predecessor/Sucessor ou apenas hierarquia Pai/Filho?
- Quais campos de data e duração são válidos?
- A sincronização é automática, programada ou manual?
- Em que direção posso escrever e há uma etapa de revisão?
- O que acontece quando um item sai da consulta de origem?
- Ele pode tipo de dependência de ida e volta e atraso sem perdas?
GanttFather é sincero no primeiro ponto: seu atual conector do Azure importa a hierarquia, mas não os links de dependência do Azure. Isso torna o GanttFather adequado quando você deseja construir a rede de planejamento localmente; não é uma réplica de manutenção zero do gráfico de links do Azure.
São YAML dependencies o mesmo que dependências de itens de trabalho?
Não. Azure Pipelines usa dependsOn, dependenciese stageDependencies para controlar a execução do estágio/trabalho e ler as saídas anteriores. Essas expressões são conceitos de tempo de execução de pipeline. Eles não criam links Predecessor/Sucessor entre itens de trabalho Azure Boards e não aparecem automaticamente em um gráfico de Gantt.
Por exemplo, $[ dependencies.Build.outputs['setVersion.value'] ] lê a variável de saída de um trabalho anterior. Não diz nada sobre as datas agendadas de um recurso ou história de usuário. Use o da Microsoft referência de expressões de pipeline para erros YAML e a referência do link do item de trabalho para relacionamentos de planejamento.
Quando GanttFather é útil junto com Azure DevOps?
Use GanttFather quando Azure DevOps deve permanecer como backlog e sistema de registro de entrega, enquanto um grupo menor possui o cronograma entre equipes. O conector pode extrair campos de item de trabalho mapeados e hierarquia pai/filho em um projeto de Gantt; após cada extração manual, os planejadores podem adicionar FS, SS, FF e SF dependências com atraso, calcular o caminho crítico e compartilhar o resultado ao vivo com espectadores ou convidados.
Este não é um espelho de dependência: os links do Predecessor/Sucessor do Azure não são importados ou reescritos, e um Proprietário ou Administrador deve acionar e revisar a atividade de integração no aplicativo. O nível gratuito cobre um projeto próprio com duas licenças de editor e espectadores e convidados ilimitados. Se essa divisão controlada se adequar ao seu processo, crie um projeto GanttFather grátis e valide uma consulta do Azure antes de construir a rede local completa.
O que mais as pessoas perguntam sobre as dependências de Azure DevOps?
Azure DevOps tem um gráfico de Gantt nativo?
Azure Boards tem roteiros e superfícies de linha do tempo baseadas em extensões, mas a Microsoft não fornece um gráfico de Gantt clássico integrado com análise de caminho crítico. Dependency Tracker inclui um cronograma beta para fluxo de dependência; Os Planos de Entrega concentram-se no planejamento entre equipes baseado em iteração.
GanttFather importa links do Predecessor/Sucessor do Azure?
Não. O conector atual importa campos de item de trabalho e hierarquia pai/filho da mesma origem. Os links do Predecessor/Sucessor do Azure não são convertidos em dependências de Gantt. Adicione esses relacionamentos de agendamento em GanttFather após a importação; pull pulls repetidos preservam o conjunto de dependências locais.
GanttFather pode enviar dependências de volta para Azure DevOps?
N.º O Push revisto abrange campos de itens de trabalho mapeados explicitamente selecionados, e não links de relação do Azure. Ele não cria, atualiza ou exclui relacionamentos Predecessor/Sucessor. Mantenha o gráfico de links do Azure autoritário quando esses links nativos forem exigidos por outras ferramentas do Azure.
Azure DevOps pode mostrar um caminho crítico?
A Microsoft afirma que Azure Boards não possui visão de caminho crítico integrada. Um agendador externo pode calcular um depois de ter datas de tarefas válidas, durações e uma rede de dependência completa. Um gráfico baseado apenas na hierarquia Pai/Filho não pode produzir um caminho crítico defensável.
Um agente de IA pode acionar a sincronização de Azure DevOps por meio de GanttFather MCP?
Não. O servidor MCP de GanttFather não possui ferramentas de integração do Azure. Um proprietário ou administrador deve configurar a conexão, acionar Pull, revisar comparações e confirmar Push no aplicativo. Depois que as tarefas estiverem presentes, um agente autorizado poderá trabalhar com as tarefas GanttFather e as dependências locais.
Comportamento do produto verificado: 30 de agosto de 2026.
Fontes
