Modelo de projeto ágil: estrutura para planejar e acompanhar
Um modelo de projeto ágil serve para escapar de dois extremos ruins. De um lado, o plano de projeto tradicional com oitenta páginas, que ninguém lê depois da aprovação e que fica desatualizado na segunda Sprint. Do outro, nenhum documento: só um quadro de tarefas e a promessa de que "no ágil a gente vai descobrindo". O patrocinador não sabe o que vai receber, o financeiro não sabe quanto vai gastar e o time não sabe quando o projeto termina.
O meio-termo é um documento curto, que responde às perguntas que não mudam toda semana (por que o projeto existe, quem decide, como o time trabalha, quais são os limites de prazo e dinheiro) e aponta para os artefatos que mudam o tempo todo, como o Product Backlog. Ele cabe em quatro ou cinco páginas e é revisado a cada Sprint Review.
Abaixo estão as dez seções, um texto para copiar, um exemplo preenchido e a rotina para manter o plano vivo.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que um modelo de projeto ágil precisa ter
O Guia do Scrum não exige plano de projeto. Ele define a Meta do Produto, o Product Backlog, a Sprint e os demais elementos do framework, e deixa de fora o que a organização precisa para financiar e governar o trabalho. Na vida real, quase todo projeto ágil precisa responder a um patrocinador, a um orçamento e, às vezes, a um contrato. O modelo existe para isso, e parte do que o guia completo de métodos ágeis e Scrum explica sobre papéis e eventos aparece aqui na forma de campos a preencher.
Três critérios separam um bom plano de projeto ágil de um plano tradicional encurtado:
- Descreve resultados, não tarefas. O plano diz qual problema será resolvido e como o sucesso será medido. A lista de itens fica no Product Backlog, que é dinâmico.
- Declara o que é fixo e o que é variável. Em geral, prazo e orçamento ficam fixos e o escopo varia. Se for o contrário, o plano precisa dizer.
- Tem dono e data de revisão. Um documento ágil sem rotina de atualização vira o mesmo plano esquecido de sempre.
A estrutura do modelo: as 10 seções
| Seção | Pergunta que responde | Quem preenche | Quando atualizar |
|---|---|---|---|
| 1. Contexto e problema | Por que este projeto existe agora? | Patrocinador e Product Owner | Só se o problema mudar |
| 2. Visão e Meta do Produto | Que resultado queremos e como saberemos que chegamos? | Product Owner | Quando a meta for atingida ou abandonada |
| 3. Partes interessadas e decisões | Quem decide o quê? | Product Owner e gerente do projeto, se houver | A cada mudança relevante de pessoas |
| 4. Time e responsabilidades | Quem faz parte do Scrum Team e com que dedicação? | Scrum Master | A cada mudança no time |
| 5. Restrições | Quais limites de prazo, orçamento, contrato e regulação valem? | Patrocinador | Quando a restrição mudar |
| 6. Roadmap | Em que ordem os resultados devem chegar? | Product Owner | A cada Sprint Review |
| 7. Product Backlog inicial | Quais itens temos hoje e onde ficam? | Product Owner com os Developers | Continuamente, no próprio backlog |
| 8. Regras de trabalho | Duração da Sprint, Definição de Pronto, ferramentas | Scrum Team | Na retrospectiva, quando mudar |
| 9. Acompanhamento | Que métricas e relatórios a organização recebe? | Scrum Master e Product Owner | A cada Sprint |
| 10. Riscos e premissas | O que pode atrapalhar e o que estamos supondo? | Todo o Scrum Team | A cada Sprint Review |
A seção 7 é a única que deliberadamente não fica no documento. O plano registra onde o backlog está (o quadro, a ferramenta, o link) e o tamanho aproximado dele no início. Copiar a lista de itens para o plano cria duas fontes de verdade, e a do documento sempre perde.
Modelo de projeto ágil para copiar
Copie o texto abaixo e preencha os campos entre colchetes.
PLANO DO PROJETO ÁGIL: [nome do projeto]
Versão: [n] Última revisão: [data da Sprint Review] Dono: [Product Owner]
1. CONTEXTO E PROBLEMA
Situação atual: [o que acontece hoje e quem sofre com isso]
Por que agora: [prazo legal, perda de receita, oportunidade]
2. VISÃO E META DO PRODUTO
Visão: [uma frase sobre o futuro desejado]
Meta do Produto: [objetivo mensurável de longo prazo]
Indicadores de sucesso: [2 ou 3 indicadores com valor atual e alvo]
3. PARTES INTERESSADAS E DECISÕES
Patrocinador: [nome] decide [orçamento, continuidade]
Product Owner: [nome] decide [ordem do backlog, aceite do incremento]
Outras partes: [área, interesse, como participa: Sprint Review, entrevista]
4. TIME
Scrum Master: [nome, dedicação]
Developers: [nomes, especialidades, dedicação]
5. RESTRIÇÕES
Prazo: [data e motivo] Orçamento: [valor ou capacidade do time]
Contrato e regulação: [cláusulas, normas, LGPD]
O que é fixo: [prazo / orçamento / escopo] O que é variável: [...]
6. ROADMAP
Trimestre 1: [resultado esperado]
Trimestre 2: [resultado esperado]
Marco externo: [data, entrega obrigatória]
7. PRODUCT BACKLOG
Onde fica: [ferramenta e link] Itens iniciais: [quantidade aproximada]
8. REGRAS DE TRABALHO
Duração da Sprint: [1 a 4 semanas] Dia de início: [dia da semana]
Definição de Pronto: [lista curta]
Horários dos eventos: [Planning, Daily, Review, Retrospectiva]
9. ACOMPANHAMENTO
Métricas: [incrementos entregues, progresso na Meta do Produto, previsão]
Relatório para a organização: [formato, frequência, destinatários]
10. RISCOS E PREMISSAS
Premissas: [o que supomos ser verdade]
Riscos: [risco, impacto, resposta, responsável]
Se você ainda não tem o projeto formalizado, comece pelo termo de abertura gratuito: ele organiza contexto, objetivos, patrocinador e restrições, que alimentam as seções 1, 2, 3 e 5 do modelo.
Exemplo preenchido de plano de projeto ágil
O exemplo abaixo é ilustrativo. A prefeitura, os números e os nomes de função foram criados para mostrar o raciocínio.
Contexto: uma prefeitura de médio porte atende pedidos de alvará de funcionamento só no balcão. O prazo médio de resposta é longo e o atendimento presencial está saturado.
Meta do Produto: permitir que pelo menos metade dos pedidos de alvará de baixo risco seja feita e acompanhada pela internet até o fim do ano. Indicadores: percentual de pedidos on-line (hoje zero), tempo médio de resposta, número de retornos ao balcão por falta de documento.
Decisões: o secretário de Desenvolvimento Econômico é o patrocinador e decide orçamento e continuidade. Uma servidora da área de licenciamento atua como Product Owner, com dedicação de três dias por semana, e decide a ordem do backlog. O setor jurídico participa das Sprint Reviews sempre que houver mudança de regra no formulário.
Restrições: o contrato com a empresa de software tem valor e vigência fixos; o escopo é variável dentro de uma lista de resultados esperados. A Lei Geral de Proteção de Dados (LGPD) se aplica aos dados dos requerentes.
Roadmap: primeiro trimestre, pedido on-line com envio de documentos para atividades de baixo risco; segundo trimestre, acompanhamento do pedido e notificações; terceiro trimestre, integração com o cadastro de contribuintes.
Regras: Sprints de duas semanas, começando na quarta-feira. A Definição de Pronto inclui teste com dois servidores do balcão, revisão do texto pelo jurídico quando o item mexe em regra e publicação em ambiente de homologação.
Acompanhamento: a cada Sprint Review, o Product Owner atualiza o roadmap e apresenta ao patrocinador o percentual de pedidos on-line, o que entrou em produção e a previsão para o próximo marco.
Para ver um projeto Scrum completo, da visão à primeira entrega, com o backlog inicial e as três primeiras Sprints, leia o exemplo de projeto Scrum na prática.
Como acompanhar o projeto com o modelo
O plano só funciona se a rotina de atualização estiver presa aos eventos que o time já faz. Uma rotina simples:
- Na Sprint Planning, o time confere a seção 8 (regras de trabalho) e a Meta da Sprint é escrita em relação à Meta do Produto da seção 2.
- Na Sprint Review, o Product Owner atualiza o roadmap (seção 6), a previsão de entregas e os riscos (seção 10) com as partes interessadas na sala.
- Na retrospectiva, o time revisa a Definição de Pronto e os horários dos eventos, se for o caso.
- Uma vez por mês, o patrocinador recebe um resumo de uma página: o que foi entregue, o progresso nos indicadores da Meta do Produto, a previsão para o próximo marco e as decisões pendentes.
Para a previsão, prefira dados reais a percentuais de conclusão. Um gráfico de entregas acumuladas por Sprint, comparado com o tamanho atual do backlog, mostra se o próximo marco está ao alcance. Só não transforme a velocidade do time em meta de produtividade: ela serve para prever, não para cobrar.
Modelo de gestão de projetos ágil em contratos e no setor público
Projetos com contrato fechado, licitação ou auditoria pedem uma seção extra de governança. Ela costuma ter:
- Marcos contratuais com critério de aceite por resultado, e não por lista de funcionalidades.
- Regra de troca de escopo: um item novo pode entrar no backlog se outro de tamanho parecido sair, sem alterar valor nem prazo do contrato.
- Registro de decisões: quem aprovou cada mudança relevante e em que data, para atender à fiscalização.
- Relatório formal no formato que o órgão ou o cliente já exige, preenchido com os dados das Sprints.
Quando o projeto mistura partes previsíveis, como infraestrutura e compras, com partes incertas, como o software, o plano passa a ter um cronograma macro ao lado do roadmap. Esse é o terreno do modelo híbrido de gestão de projetos, e o seletor de abordagem ajuda a decidir se o seu caso pede abordagem ágil, preditiva ou híbrida antes de escolher o modelo.
Erros comuns ao usar um modelo de projeto ágil
- Copiar o backlog para dentro do plano. Em duas Sprints, o documento diverge da ferramenta e ninguém sabe qual vale.
- Meta do Produto sem número. "Melhorar o atendimento" não permite saber se o projeto deu certo. Escreva o indicador e o alvo.
- Esconder o que é fixo. Se o prazo é legal e o escopo não pode cair abaixo de um mínimo, diga no plano. O time precisa saber onde não há negociação.
- Plano revisado só quando alguém cobra. Prenda a atualização à Sprint Review e coloque a data da última revisão no topo.
- Relatório de percentual concluído. O progresso se mede por incrementos utilizáveis e pelos indicadores da Meta do Produto.
Como começar o seu plano hoje
Reserve uma hora com o Product Owner e o patrocinador e preencha só as seções 1, 2, 3 e 5. Se não houver consenso sobre a Meta do Produto ou sobre o que é fixo, o projeto ainda não está pronto para começar, e é melhor descobrir isso antes da primeira Sprint. As demais seções o time completa na primeira semana. Para reunir o termo de abertura, os riscos e os demais documentos num arquivo único, o plano do projeto da Projeto Diário junta o que você preenche nas ferramentas gratuitas do site e gera o documento em Word, onde você acrescenta o roadmap e as regras de trabalho deste modelo.
