Agile e diagramas de Gantt: como usar os dois juntos

Sim, eles coexistem. Aqui está a resposta honesta

Faça a mesma pergunta a um purista de scrum e a um líder de entrega e você receberá respostas opostas. O purista diz que um diagrama de Gantt é cascata disfarçada. O líder diz que um backlog não consegue dizer a um cliente quando a funcionalidade é lançada. Ambos têm metade da razão. Um diagrama de Gantt e agile não são rivais, operam em altitudes diferentes. O agile cuida do trabalho do dia a dia dentro de cada sprint. Um Gantt descreve o formato da versão acima dos sprints: as fases, as datas firmes e as entregas entre equipes que nenhum backlog sozinho consegue mostrar.

O verdadeiro erro é forçar uma ferramenta a fazer os dois trabalhos. Planeje um sprint de duas semanas em um Gantt e você o redesenhará toda manhã à medida que as histórias se movem. Prometa uma data de lançamento só com um backlog e você estará adivinhando a velocidade. Coloque cada ferramenta onde ela encaixa e a velha tensão desaparece sem alarde.

Duas ferramentas, duas altitudes

Um quadro e um backlog são feitos para o fluxo. Eles respondem ao que uma equipe deve puxar a seguir, ao que está bloqueado hoje e a quanto falta no sprint atual. São deliberadamente cegos às datas do calendário, porque datas não são a forma de conduzir um sprint. Um Gantt é feito para o tempo. Ele responde a quando uma fase começa, a quais equipes precisam terminar antes que outra possa começar e a se a versão ainda cai na data prometida.

Pergunta	Quadro e backlog	Gantt da versão
O que construímos a seguir?	Sim, o topo do backlog	Não
Estamos bloqueados hoje?	Sim	Em parte
Vamos cumprir a data de lançamento?	Não	Sim
Qual equipe condiciona a nossa?	Raramente visível	Sim, como uma dependência
Qual é a fase depois desta?	Não	Sim

Note que as colunas quase não se sobrepõem. É esse o ponto. Você não está escolhendo entre elas, está cobrindo dois conjuntos de perguntas diferentes.

As três camadas de um plano agile

Uma entrega agile saudável funciona sobre três camadas, e só uma delas é o sprint. Mantê-las separadas é o que permite que um Gantt e um quadro convivam sem pisar um no outro.

• Camada de roteiro. Trimestres e temas. O que importa neste semestre e, grosso modo, em que ordem. É uma visão de estratégia, não um cronograma.
• Camada de versão. É aqui que o Gantt vive. Uma única versão é um conjunto de fases ao longo de vários sprints, com datas reais, marcos e dependências entre equipes. É aqui que você se compromete com os clientes.
• Camada de sprint. O quadro e o backlog. Histórias, pontos, fluxo diário. As estimativas mudam aqui o tempo todo e tudo bem, porque a camada acima absorve a variação.

Quando alguém diz que diagramas de Gantt matam a agilidade, geralmente quer dizer que alguém tentou conduzir a camada de sprint em um Gantt. Suba o Gantt para a camada de versão e a objeção se evapora.

O que um Gantt acrescenta e que um backlog não consegue

Um backlog é uma lista plana, ordenada por prioridade. É excelente para ordenar o trabalho e péssimo em três coisas das quais uma versão depende. Primeiro, as dependências entre equipes. Quando a equipe de API precisa entregar um gateway antes que a equipe do app possa construir o checkout, essa relação é invisível no backlog de qualquer uma das duas, mas óbvia como uma dependência em um Gantt. Segundo, os prazos firmes. Uma feira, uma cláusula contratual ou uma data regulatória é um ponto fixo que um backlog simplesmente não representa. Terceiro, a visão da versão: uma única imagem que mostra a uma parte interessada todo o percurso do design ao lançamento.

Um backlog diz a uma equipe o que fazer a seguir. Um Gantt diz à organização se a soma de todo esse trabalho chega a tempo. Não são a mesma pergunta, e um plano de versão precisa das duas respondidas.

Usar um Gantt para a versão, sprints para o detalhe

O padrão que funciona é o planejamento em ondas sucessivas. Você desenha o Gantt da versão no nível de fases e épicos, grosso modo uma barra por épico ou por sprint, não uma barra por história. O curto prazo é detalhado porque você o conhece. O longo prazo é um bloco grosseiro porque, honestamente, você ainda não o conhece, e fingir o contrário é como os diagramas de Gantt ganham sua má fama.

Em cada sprint, a equipe planeja suas histórias no quadro como de costume. Nada disso muda. O que muda é que, ao fim do sprint, você atualiza a barra correspondente no Gantt: o épico terminou, atrasou ou encolheu? O Gantt não é um segundo lugar para gerenciar tarefas. É uma lente que transforma oito semanas de resultados de sprint em uma única resposta sobre a data da versão. Estime as barras grosseiras com a velocidade real da sua equipe, não com contas ilusórias, e leia nosso guia sobre estimar durações antes de comprometer as datas.

Exemplo prático: versão 2.0 ao longo de quatro sprints

Uma equipe de pagamentos se compromete a entregar um checkout de autoatendimento em oito semanas, quatro sprints de duas semanas. O quadro cuida das histórias. O Gantt cuida da versão. Veja como os épicos se mapeiam nos sprints e onde está o risco.

Épico	Equipe	Sprints	Depende de
Integração do gateway de pagamento	API	1 a 2	Nada
Interface do checkout	App	3 a 4	Gateway (fim para início)
Regras antifraude	Risco	2 a 3	Gateway (início para início)
Lançamento e aval de conformidade	Todas	4	Tudo acima

A cadeia que define sua data

No exemplo acima, a sequência gateway, depois checkout, depois lançamento é o caminho mais longo de trabalho dependente. Todo o resto, como as regras antifraude rodando em paralelo, tem folga para se mover. Essa cadeia mais longa é o seu caminho crítico, e é a única coisa que de fato define a data de lançamento. As regras antifraude poderiam atrasar alguns dias e a versão ainda sairia. O gateway não.

É aqui que um Gantt se paga numa operação agile. Gráficos de velocidade dizem a que velocidade uma única equipe se move. Eles não conseguem dizer qual de quatro fluxos de trabalho paralelos é o que mantém toda a versão refém. O caminho crítico consegue, e ele deixa você gastar sua atenção onde um atraso de fato custa a data, em vez de espalhar a preocupação por igual entre todas as equipes.

Objeções comuns, respostas honestas

A resistência é previsível, e boa parte dela é justa quando um Gantt é mal usado. Aqui estão as objeções que uma equipe scrum vai levantar e a resposta honesta a cada uma.

Objeção	Resposta honesta
Diagramas de Gantt são cascata	Só se você planejar histórias neles. Na camada de versão são apenas uma visão de dependências e datas.
As estimativas mudam a cada sprint	Verdade, então mantenha as barras no nível de épico e atualize-as depois de cada sprint. Não desenhe histórias.
Vai ficar desatualizado	Vai, se ninguém for dono dele. Atribua um responsável que o atualize em cada revisão de sprint, não antes.
O quadro já mostra os bloqueios	Dentro de uma equipe, sim. Os portões entre equipes e as datas fixas, não.
As partes interessadas deveriam ler o backlog	Não vão. Um Gantt da versão é o artefato que executivos e clientes de fato entendem.

Nenhuma dessas objeções sobrevive ao contato com um Gantt mantido na altitude certa. Quase todas são, na verdade, queixas sobre Gantts mantidos na errada.

Como construir um Gantt da versão em uma tarde

Você não precisa de uma ferramenta pesada nem de uma certificação. Você precisa dos épicos, das datas com que já se comprometeu e de uma hora com os líderes de equipe. Esta é a sequência.

1. Liste os épicos desta versão, não as histórias. Mire entre cinco e doze barras.
2. Marque primeiro as datas fixas: lançamento, demos, prazos contratuais. São marcos, desenhados como losangos, e não se movem.
3. Dimensione cada épico em sprints usando sua velocidade real, depois coloque-o na linha do tempo.
4. Desenhe as dependências entre épicos, sobretudo as que cruzam equipes. Este é o passo de maior valor.
5. Encontre a cadeia mais longa de épicos dependentes. Esse é o caminho que você defende.
6. Atribua um responsável para atualizar o gráfico em cada revisão de sprint, e em nenhum outro momento.

Abra um plano em branco no editor de Gantt, adicione uma linha por épico, ligue as dependências e você terá uma visão da versão em menos de uma hora. Mantenha o detalhe das histórias no seu quadro, onde ele pertence.

Mantenha-o leve ou ele morre

A maior razão pela qual um Gantt fracassa numa equipe agile é o peso. Alguém constrói um belo gráfico de cem linhas, ele fica desatualizado em um sprint, e a equipe conclui que diagramas de Gantt não funcionam. O gráfico não falhou, a granularidade falhou. Um Gantt da versão deve ser pequeno o bastante para que uma pessoa o atualize em dez minutos na revisão de sprint, arrastando algumas barras e movendo uma data.

Acompanhe a versão como você acompanha qualquer plano diante da realidade, comparando onde você disse que cada épico estaria com onde ele de fato caiu. Uma rápida conferência de linha de base em cada revisão diz se a data está derivando muito antes de virar uma crise. Um diagrama de Gantt construído uma vez e nunca tocado não é um plano, é um desejo. Atualize-o ou apague-o, mas não o deixe apodrecer num drive compartilhado fingindo ser a verdade.

Quando pular o Gantt por completo

A honestidade corta nos dois sentidos. Nem todo esforço agile precisa de um Gantt, e adicionar um onde ele não rende nada é só sobrecarga. Se o seu trabalho é um fluxo contínuo de itens pequenos e independentes, sem prazo externo e sem entregas entre equipes, um quadro basta. Uma equipe de manutenção pura, uma fila de suporte ou um único esquadrão que entrega em produção todos os dias ganham pouco com uma camada de versão, porque não há versão a moldar.

Recorra a um Gantt quando três sinais aparecerem juntos: uma data externa fixa que você prometeu, mais de uma equipe cujo trabalho depende do de outra e uma parte interessada que precisa ver todo o percurso de uma vez. Quando os três estão presentes, o backlog deixa perguntas reais sem resposta e o Gantt as responde. Quando nenhum está, pule-o de consciência tranquila e deixe o quadro fazer o seu trabalho.

Perguntas frequentes

Leia também

• O método do caminho crítico explicado
• As dependências entre tarefas explicadas
• Marcos e tarefas
• Voltar aos guias

Este artigo também está disponível em inglês.