Gráfico de Gantt para desenvolvimento de software

Um Gantt tem lugar no software, à altitude certa

A objeção é conhecida. Ponha um gráfico de Gantt à frente de uma equipa scrum e alguém vai chamar-lhe cascata disfarçada. Têm razão numa coisa e erram no resto. Têm razão em que agendar histórias individuais num Gantt é um erro, porque essas histórias mudam todos os dias e o gráfico estaria desatualizado à hora de almoço. Erram ao pensar que um gráfico de Gantt não tem lugar algum no software.

O truque é a altitude. Um backlog opera ao nível da história, onde o trabalho é pequeno, reordenado constantemente e guiado pelo fluxo e não por datas. Um Gantt opera um nível acima, ao nível do lançamento, onde se compromete com uma data de saída, coordena várias equipas e presta contas a partes interessadas que não leem o Jira. Mantenha o Gantt a essa altura e a tensão entre ele e o ágil simplesmente desaparece. Baixe-o ao nível da história e terá merecido todas as queixas que a equipa lhe atirar.

As cinco fases de um cronograma de software

A maior parte do trabalho de uma funcionalidade passa por cinco fases reconhecíveis, e um Gantt foi feito para mostrar exatamente este tipo de sequência. A descoberta esclarece o problema e o âmbito. O desenho define a interface, o modelo de dados e o contrato da API. A construção é o grosso da engenharia. O teste cobre a integração, o controlo de qualidade e a estabilização. O lançamento cobre a implantação, a migração e a entrada em produção em si. Cada fase apoia-se na anterior, que é precisamente a relação que um gráfico de barras torna visível.

Fases não são sprints. Uma só fase como a construção pode abranger três ou quatro sprints, enquanto a descoberta pode caber num. Não há problema nisso. O Gantt tem uma barra por fase, não uma por sprint e muito menos uma por ticket. É esta vista grosseira que permite a um responsável olhar para o gráfico e ver, num segundo, se a equipa ainda está em construção ou já a estabilizar para o lançamento. O backlog nunca lhe pode dar esse formato porque esconde as datas de propósito.

Onde um Gantt supera um backlog

Um backlog é uma lista plana ordenada por prioridade. É excelente a ordenar os próximos dias de trabalho e cego a três coisas de que um lançamento depende. Primeiro, a vista de lançamento. Uma parte interessada que pergunta quando sai o checkout quer uma imagem de todo o percurso, da descoberta até à saída, não um deslizar por 200 tickets. Um Gantt dá-lhe essa imagem num único quadro.

Segundo, os prazos. Uma cláusula contratual, uma demo numa conferência ou uma data de conformidade é um ponto fixo no tempo. Um backlog não tem noção de data de calendário, por isso não lhe pode dizer se a data prometida ainda é realista. Um Gantt ancora essas datas como marcos e mostra a folga, ou a falta dela, antes delas. Terceiro, as dependências. Quando uma equipa trava outra, essa relação nunca aparece no quadro de nenhuma das duas, mas é a razão mais comum para as datas de software derraparem. Um Gantt é o único artefacto que a torna óbvia.

Onde um backlog supera um Gantt

A honestidade vai nos dois sentidos, e há trabalho real que um Gantt nunca deveria tocar. O dia a dia agitado pertence a um quadro. Que ticket puxar a seguir, o que está bloqueado esta manhã, quantos pontos faltam no sprint, quem assume o teste instável que acabou de falhar: nada disto pertence a um Gantt, e forçá-lo ali é como os gráficos de Gantt ganham a sua má fama na engenharia.

O trabalho de quadro muda de hora a hora. As estimativas deslocam-se, as histórias dividem-se, os bugs furam a fila e as prioridades reorganizam-se depois de cada reunião diária. Um Gantt redesenhado com essa frequência é pior do que inútil, porque parece oficial enquanto está errado. O quadro foi feito para absorver essa volatilidade. Trata a mudança como fluxo normal e não como um desvio em relação a um plano. Por isso, deixe o detalhe ruidoso e veloz no quadro e deixe-o agitar-se. O Gantt só se importa com o resultado que cada sprint produz, não com o caminho minuto a minuto que a equipa tomou para lá chegar.

Gantt e backlog, lado a lado

As duas ferramentas quase não se sobrepõem, que é precisamente por isso que usa ambas. Alinhe as perguntas a que cada uma responde e a divisão de tarefas torna-se óbvia.

Pergunta	Backlog e quadro	Gantt de lançamento
O que construímos a seguir?	Sim, no topo do backlog	Não
O que está bloqueado agora?	Sim	Em parte
Vamos cumprir a data de saída?	Não	Sim
Que equipa trava a nossa?	Raramente visível	Sim, como dependência
Que fase vem depois desta?	Não	Sim
Quão volátil pode ser?	Muda a cada hora	Muda por sprint

Repare no pouco que as colunas partilham. Não está a escolher uma ferramenta em detrimento da outra. Está a cobrir dois conjuntos de perguntas diferentes com dois instrumentos diferentes.

As dependências entre equipas são a verdadeira razão

Se um Gantt de software merece o seu lugar por uma única coisa, são as dependências entre equipas. O trabalho de software está cheio de passagens que nenhum quadro isolado consegue mostrar. A API tem de expor um endpoint antes de a interface o poder chamar. A infraestrutura tem de aprovisionar o cluster antes de alguém poder implantar nele. A equipa de dados tem de entregar a migração antes de a funcionalidade ler o novo esquema. Cada uma destas é uma dependência fim a início que atravessa uma fronteira de equipa, e cada uma é invisível nos quadros das equipas envolvidas.

Num Gantt estas passagens são simples setas, e mudam a forma como gere o lançamento. Assim que consegue ver que a barra da interface não pode começar até a barra da API terminar, sabe que trabalho proteger e qual pode ceder. Deixa de tratar a derrapagem de cada equipa como igualmente urgente e começa a defender as passagens concretas que realmente condicionam a data. Essa é uma decisão que um backlog nunca pode fundamentar, porque o backlog não sabe que a outra equipa existe.

Exemplo prático: uma funcionalidade de checkout em dez semanas

Uma equipa compromete-se a entregar um checkout de autosserviço em dez semanas. A descoberta e o desenho correm primeiro, depois três equipas constroem em paralelo, e por fim tudo converge para teste e lançamento. O quadro trata dos tickets. O Gantt trata do lançamento. Eis como as fases e os responsáveis se projetam na linha de tempo.

Fase	Equipa	Semanas	Depende de
Descoberta e desenho	Produto, Design	1 a 2	Nada
API de pagamentos	API	3 a 5	Desenho
Infraestrutura e pipeline de implantação	Plataforma	3 a 4	Desenho
Interface de checkout	App	6 a 8	API de pagamentos
Teste e estabilização	QA, Todos	8 a 9	Interface, Infra
Lançamento e entrada em produção	Todos	10	Tudo o acima

A cadeia que define a sua data

No exemplo acima, a sequência desenho para API de pagamentos para interface de checkout para teste para lançamento é a cadeia mais longa de trabalho dependente. A infraestrutura corre em paralelo e termina cedo, por isso tem espaço para se mover. Essa cadeia mais longa é o seu caminho crítico, e é a única coisa que realmente define a data de saída. O trabalho de plataforma podia derrapar alguns dias e o lançamento sairia à mesma. A API de pagamentos não.

É aqui que um Gantt se paga a si próprio numa casa de engenharia. Um gráfico de velocidade diz-lhe quão depressa uma equipa avança. Não lhe pode dizer qual dos três fluxos de trabalho paralelos tem todo o lançamento refém. O caminho crítico pode, e deixa-o investir atenção onde uma derrapagem lhe custa mesmo a data, em vez de espalhar a preocupação por igual por todas as equipas. Estime as barras dessa cadeia com produtividade histórica real, não com otimismo, e leia o nosso guia sobre estimar durações antes de se comprometer com qualquer data que um cliente vá ouvir.

Combinar o Gantt de lançamento com a execução por sprints

O padrão que funciona é simples. O Gantt é dono do lançamento. Os sprints são donos do detalhe. Desenha o Gantt ao nível das fases e dos épicos, e depois deixa cada equipa planear as suas próprias histórias no quadro exatamente como faz hoje. Nada na cerimónia do sprint muda. O que muda é que em cada revisão de sprint atualiza a barra de fase correspondente: terminou, derrapou ou encolheu?

Planeie as fases próximas em detalhe porque as compreende, e mantenha as fases distantes como blocos grosseiros porque, honestamente, ainda não as compreende. Refine cada bloco à medida que se aproxima do sprint atual. Esta abordagem de onda progressiva mantém o Gantt verdadeiro sem fingir que conhece a semana 10 durante a semana 2. O Gantt não é um segundo lugar para gerir tarefas. É uma lente que transforma um trimestre de resultados de sprint numa única resposta sobre a data de saída. O quadro responde ao que construir a seguir. O Gantt responde se a soma de toda essa construção chega a tempo.

Construir o cronograma passo a passo

Não precisa de uma ferramenta pesada nem de uma certificação em projetos para construir um. Precisa das fases, das datas que já prometeu e de uma hora com os líderes de equipa. Eis a sequência.

1. Liste as fases e os épicos principais deste lançamento, não as histórias. Aponte para seis a doze barras.
2. Marque primeiro as datas fixas: a entrada em produção, qualquer demo e qualquer prazo de conformidade ou de contrato. Desenhe-as como losangos de marco que não se movem.
3. Dimensione cada fase com a sua produtividade real e depois coloque-a na linha de tempo.
4. Desenhe as dependências entre fases, sobretudo cada passagem que atravessa uma equipa. Este é o passo de maior valor.
5. Encontre a cadeia mais longa de fases dependentes. Esse é o caminho crítico que defende.
6. Atribua a uma única pessoa a atualização do gráfico em cada revisão de sprint, e em mais lado nenhum.

Abra um plano em branco no editor de Gantt, adicione uma linha por fase, ligue as dependências e tem uma vista de lançamento em menos de uma hora. Mantenha o detalhe dos tickets no quadro, onde pertence.

Mantenha-o grosseiro ou apodrece

A maior razão para um Gantt falhar numa equipa de software é o peso. Alguém constrói um gráfico lindíssimo com uma barra por cada ticket, fica desatualizado num sprint, e a equipa conclui que os gráficos de Gantt não funcionam. O gráfico não falhou. A granularidade falhou. Um Gantt de lançamento deve ser pequeno o suficiente para que uma pessoa o atualize em dez minutos na revisão de sprint, arrastando algumas barras e movendo uma data.

Um gráfico de Gantt construído uma vez e nunca tocado não é um plano, é um desejo. Atualize-o ou apague-o, mas nunca o deixe apodrecer numa unidade partilhada a fingir ser a verdade.

Quando dispensar o Gantt por completo

Nem todo o esforço de software precisa de um Gantt, e acrescentar um onde não rende nada é puro excesso. Se o seu trabalho é um fluxo contínuo de itens pequenos e independentes sem prazo externo e sem passagens entre equipas, um quadro chega e sobra. Um esquadrão de manutenção, uma fila de suporte ou uma única equipa que implanta em produção várias vezes por dia pouco ganha com uma camada de lançamento, porque não há lançamento a moldar.

Recorra a um Gantt quando três sinais surgem juntos: uma data externa fixa que prometeu, mais do que uma equipa cujo trabalho depende de outra, e uma parte interessada que precisa de todo o percurso numa só vista. Quando os três estão presentes, o backlog deixa perguntas reais por responder e o Gantt responde-lhes com clareza. Quando nenhum está presente, dispense-o de consciência tranquila. E se quiser um, também não tem de pagar por ele, já que a nossa seleção do melhor software gratuito de gráficos de Gantt cobre ferramentas que tratam exatamente disto.

Perguntas frequentes

Leia também

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

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