Metodologia ágil no desenvolvimento de software: como aplicar
Uma metodologia ágil de desenvolvimento de software organiza a construção do sistema em ciclos curtos, cada um terminando com uma parte funcionando que alguém pode usar, avaliar e criticar. Em vez de levantar todos os requisitos, projetar tudo, programar tudo e testar no fim, o time entrega pedaços pequenos com frequência e corrige o rumo a cada entrega, com o cliente perto.
A ideia parece simples, e é por isso que tantas equipes dizem que "são ágeis" sem colher o resultado. Elas adotam as reuniões do Scrum, colocam um quadro na parede e continuam com integração manual, testes no fim e homologação de três semanas. O ritmo de entrega não muda porque a parte técnica não acompanhou a parte de gestão.
Abaixo está o que define o desenvolvimento ágil, as três camadas que precisam funcionar juntas e um passo a passo para aplicar num projeto de software.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é uma metodologia ágil de desenvolvimento de software
O termo ganhou forma em fevereiro de 2001, quando dezessete pessoas se reuniram no resort de esqui de Snowbird, em Utah, nos Estados Unidos, e escreveram o manifesto que deu nome ao movimento, conhecido como Manifesto Ágil. Estavam lá representantes de métodos que já existiam, como Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development e Pragmatic Programming. O manifesto não criou um método; ele registrou o que esses métodos tinham em comum.
Alguns dos doze princípios mostram bem o que muda no software:
- Entregar software funcionando com frequência, de poucas semanas a poucos meses, com preferência pelo prazo mais curto.
- Software funcionando é a principal medida de progresso.
- Aceitar mudanças de requisitos, mesmo tarde no desenvolvimento.
- Pessoas de negócio e desenvolvedores trabalhando juntas diariamente.
- Atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
Os valores e princípios estão explicados um a um em Manifesto Ágil: os 4 valores e os 12 princípios. Para o panorama de todos os métodos, veja o guia completo de métodos ágeis e Scrum.
O que muda em relação ao desenvolvimento em cascata
| Aspecto | Cascata | Ágil |
|---|---|---|
| Requisitos | Levantados e aprovados no início | Detalhados aos poucos, a partir de um backlog ordenado |
| Entrega | Uma grande entrega no fim | Incrementos frequentes, utilizáveis |
| Testes | Fase própria, depois da construção | Contínuos, boa parte automatizada |
| Mudança | Controlada como exceção, com custo alto | Esperada e absorvida a cada ciclo |
| Medida de progresso | Percentual de fases e documentos concluídos | Software funcionando e resultado para o usuário |
| Papel do cliente | Aprova no início e homologa no fim | Participa das revisões a cada ciclo |
A cascata ainda faz sentido quando o requisito é estável e conhecido, como uma integração com regras fixadas por norma. Nesses casos, um modelo híbrido costuma funcionar melhor: requisitos fixos tratados com plano detalhado, o resto em ciclos curtos.
As três camadas do desenvolvimento ágil
Na prática, o desenvolvimento ágil funciona quando três camadas andam juntas. Faltando uma, o time sente o atrito.
1. Gestão do trabalho: Scrum ou similar
Define papéis, ciclos e momentos de inspeção. O Scrum é o framework mais usado: Sprints de até um mês, um Product Owner que ordena o backlog, Developers que decidem como construir, e eventos para planejar, acompanhar, revisar o produto e melhorar o processo.
2. Práticas de engenharia: XP e afins
É a camada que mais falta. O Extreme Programming, criado por Kent Beck, reúne práticas como testes automatizados escritos antes do código, integração contínua, refatoração, programação em par e entregas pequenas. Sem elas, entregar a cada duas semanas vira acúmulo de defeitos e de dívida técnica. As práticas estão detalhadas em o que é XP (Extreme Programming).
3. Gestão do fluxo: Kanban
O Kanban Guide propõe três práticas: definir e visualizar o fluxo de trabalho, gerenciar ativamente os itens no fluxo e melhorar o fluxo. Ele traz também quatro medidas de fluxo: trabalho em andamento (WIP), vazão, idade do item e tempo de ciclo. Times Scrum usam essas medidas para descobrir onde o trabalho trava, por exemplo na revisão de código ou na homologação. A aplicação em equipes de tecnologia está em Kanban em projetos de TI.
Como aplicar metodologia ágil num projeto de software: passo a passo
- Defina o produto e o objetivo. Quem usa, que problema resolve e qual resultado o projeto precisa alcançar. No Scrum, isso vira a Meta do Produto.
- Monte um time multidisciplinar e estável. Quem analisa, programa, testa e cuida da infraestrutura no mesmo time, com dedicação real. Time montado e desmontado a cada demanda não aprende junto.
- Escolha quem decide prioridade. Uma pessoa com autoridade para ordenar o backlog e disponível para o time. Sem isso, a prioridade vira disputa entre áreas.
- Crie o backlog inicial. Liste as capacidades em épicos e detalhe só o que vai entrar nas primeiras Sprints.
- Combine a Definição de Pronto. Inclua código revisado, testes automatizados passando, integração no ramo principal e implantação em ambiente de homologação. É a Definição de Pronto que impede o "pronto, só falta testar".
- Monte a esteira técnica cedo. Integração contínua, testes automatizados e implantação automatizada no primeiro mês. Cada semana sem esteira aumenta o custo de entregar.
- Trabalhe em ciclos curtos. Sprints de uma a duas semanas são comuns em software. Em cada uma, entregue algo utilizável, mesmo que pequeno.
- Mostre para usuários reais. A revisão ao fim de cada ciclo precisa de quem vai usar o sistema, não só de gestores.
- Meça o fluxo e o resultado. Tempo de ciclo e vazão mostram a saúde do processo; uso e satisfação mostram se o produto serve.
- Melhore um ponto por vez. Na retrospectiva, escolha uma melhoria concreta e acompanhe na Sprint seguinte.
Exemplo ilustrativo: sistema de chamados de uma secretaria
Uma secretaria municipal precisa substituir o atendimento por e-mail e telefone por um sistema de chamados para as escolas da rede. O exemplo é ilustrativo.
Produto e objetivo: diretores de escola abrem e acompanham chamados de manutenção sem ligar para a secretaria.
Time: cinco pessoas de desenvolvimento e testes, uma pessoa de infraestrutura em meio período e uma servidora da área de manutenção como Product Owner, com tempo reservado na agenda.
Primeiras Sprints (duas semanas cada): na primeira, o diretor abre um chamado simples e a equipe de manutenção recebe por e-mail; na segunda, o diretor acompanha o andamento; na terceira, a manutenção prioriza chamados por urgência. Cada Sprint termina com o sistema em uso por três escolas piloto.
Esteira: desde a primeira Sprint, cada alteração passa por testes automatizados e vai para o ambiente de homologação sem intervenção manual.
Aprendizado: na revisão da segunda Sprint, os diretores pedem para anexar fotos do problema. O item entra no backlog e o Product Owner o coloca acima do relatório gerencial, que perde prioridade. Num plano em cascata, essa descoberta apareceria na homologação final.
Erros comuns ao adotar desenvolvimento ágil
- Só a camada de gestão. Eventos do Scrum sem testes automatizados e integração contínua produzem Sprints que terminam sem nada utilizável.
- Sprints como miniprojetos em cascata. Análise na primeira semana, código na segunda e testes "na próxima Sprint".
- Product Owner sem tempo ou sem autoridade. O time fica esperando decisões ou recebe prioridades conflitantes.
- Medir horas em vez de entrega. Relatórios de horas trabalhadas não dizem se o software serve.
- Escopo fechado com discurso ágil. Se tudo precisa ser entregue exatamente como especificado, o ganho do ágil some. Combine com o cliente o que é fixo e o que é negociável.
O que fazer agora
Avalie o seu time nas três camadas: gestão, engenharia e fluxo. Escolha a mais fraca e defina uma mudança para o próximo ciclo, como incluir testes automatizados na Definição de Pronto ou medir o tempo de ciclo dos últimos vinte itens. Se o time usa o Jira, configurar bem o quadro, os tipos de item e os relatórios ajuda a enxergar o fluxo real. O curso Jira Avançado da Projeto Diário trata da configuração de fluxos, quadros, automações e relatórios no Jira para times de entrega.
