O que Agile significa mesmo, como o Scrum funciona na prática, os papéis e eventos que fazem as equipas entregar mais depressa, e as métricas que o provam.
AgileScrumProdutoFrameworksSprint
7 min de leitura
Agile é uma das palavras mais mal usadas no mundo dos negócios. Há equipas que se dizem Agile enquanto ainda planeiam em waterfall com um ano de antecedência. Gestores usam vocabulário Scrum em reuniões sem nunca correr um único sprint. A palavra tornou-se um chavão, o que faz esquecer facilmente que por trás dela está um conjunto genuinamente poderoso de ideias sobre como construir bem sob incerteza.
Este guia corta o ruído e constrói um modelo mental claro: o que Agile significa de facto, porque existe o Scrum, como a framework funciona na prática, e o que distingue as equipas que operam mesmo de forma iterativa das que apenas têm daily standups.
Fundação
Agile é uma mentalidade, não uma metodologia
Em 2001, dezassete profissionais de software reuniram-se no Utah e produziram o Manifesto Agile, quatro declarações de valor que desafiaram a forma dominante de construir software na altura. Estes quatro valores continuam a ser o núcleo de tudo o que é Agile:
Indivíduos e interações
acima de processos e ferramentas. O melhor processo não vale nada se as pessoas que o usam não conseguem comunicar nem colaborar de forma eficaz.
Software a funcionar
acima de documentação exaustiva. Um produto a funcionar à frente dos utilizadores diz-te mais do que um documento de especificação perfeito alguma vez dirá.
Colaboração com o cliente
acima da negociação de contratos. Os requisitos mudam. A relação com o cliente deve ser construída para absorver isso, não para o resistir.
Responder à mudança
acima de seguir um plano. Os planos são úteis. Mas o mundo muda. Uma equipa que não se adapta está a construir para uma realidade que já não existe.
Repara na formulação: "acima de", não "em vez de". O Agile não rejeita processos, documentação ou planeamento. Repriorisa. O lado direito continua a ter valor; o lado esquerdo tem mais. Esta distinção importa: Agile bem feito é disciplinado e estruturado, não caótico.
Contexto
Porque o Agile substituiu o Waterfall na maioria do software
O Waterfall organiza o trabalho em fases sequenciais (requisitos, design, construção, testes, deployment) em que cada fase tem de estar concluída antes de a seguinte começar. Isto funciona bem quando os requisitos são totalmente conhecidos à partida e não mudam. Na construção ou na indústria, é muitas vezes verdade. No software, quase nunca é.
Waterfall
Requisitos recolhidos uma vez, à partida. Design completo antes de qualquer código. Testes só no fim. O utilizador vê o produto na entrega.
Funciona quando: Os requisitos são fixos e totalmente conhecidos. As mudanças são raras e caras de acomodar. Aplicam-se restrições regulatórias ou físicas.
Falha quando: Os requisitos evoluem. Os utilizadores precisam de dar feedback a meio do processo. O mercado move-se mais depressa do que o plano.
Agile
Os requisitos evoluem através da colaboração. Design e código em ciclos curtos. Testes contínuos. O utilizador vê e reage a software a funcionar cedo.
Funciona quando: Os requisitos são incertos ou propensos a mudar. O feedback rápido é possível e valioso. A equipa é multidisciplinar e co-localizada (ou bem coordenada à distância).
Falha quando: Não há acesso real a utilizadores ou stakeholders. As equipas são grandes ou distribuídas de mais, sem estruturas de comunicação fortes.
Os bugs mais caros são os descobertos no fim de um projeto Waterfall, quando o sistema está completo e arranjar uma coisa parte outras dez. Os ciclos curtos do Agile fazem emergir estes problemas cedo, quando são baratos de corrigir.
A Framework
Scrum: a framework Agile mais usada
Agile é um conjunto de valores. Scrum é uma framework específica para implementar esses valores. É a abordagem Agile mais adotada, usada pela maioria das equipas de software no mundo. O Scrum organiza o trabalho em iterações de duração fixa chamadas Sprints, com papéis, eventos e artefactos claros que dão estrutura às equipas sem rigidez.
O Scrum assenta em três pilares:
Transparência
O trabalho, o progresso e os problemas são visíveis para toda a equipa: sem trabalho escondido, sem backlogs privados.
Inspeção
Revisão regular do produto e do processo. Estamos a construir a coisa certa? Estamos a construí-la bem? A equipa está saudável?
Adaptação
Quando a inspeção revela que algo está mal, a equipa ajusta. Planos, prioridades ou processos mudam, antes de o problema se agravar.
Estes três pilares explicam porque existem os eventos do Scrum. A Daily Scrum inspeciona o progresso diário. A Sprint Review inspeciona o produto. A Retrospetiva inspeciona o processo da equipa. Cada evento é uma oportunidade estruturada de ver o que é real e adaptar em conformidade.
Papéis
A Scrum Team: três papéis, um objetivo
Uma Scrum Team é pequena (tipicamente 3–9 pessoas), multidisciplinar (com todas as competências necessárias para entregar o produto) e auto-gerida (a equipa decide como fazer o trabalho, não apenas o quê). Tem exatamente três papéis:
Product Owner
Responsável pelo valor do produto. É dono e prioriza o Product Backlog, define o que se constrói e por que ordem, e representa a voz do cliente e dos stakeholders. Um bom PO é decisivo, acessível e disposto a dizer não a trabalho de baixo valor. Há exatamente um PO por equipa.
Scrum Master
Responsável pela eficácia da equipa. Faz coaching da equipa em Scrum, remove impedimentos que bloqueiam o progresso e facilita os eventos. Não é um gestor de projeto nem um team lead. O Scrum Master não tem autoridade sobre os developers. A sua função é ajudar a equipa a ajudar-se a si própria.
Developers
Responsáveis por entregar o Increment. Toda a gente que faz o trabalho de construir o produto: engenheiros, designers, testers, analistas de dados. Em Scrum, "developer" significa qualquer pessoa da equipa que cria, não só programadores. Auto-organizam-se: ninguém fora da equipa atribui tarefas.
Eventos
Os cinco eventos do Scrum
O Scrum tem cinco eventos formais, todos desenhados para criar oportunidades regulares de inspeção e adaptação. Não são cerimónias opcionais. Saltá-los corrói a transparência de que o Scrum depende.
01
O Sprint
Uma time-box fixa de 1–4 semanas (tipicamente 2) durante a qual a equipa cria um Increment de produto utilizável. Os Sprints têm duração consistente. Não se fazem mudanças que ponham em risco o Sprint Goal.
02
Sprint Planning
Abre cada Sprint. A equipa seleciona itens do Product Backlog e cria um plano para o Sprint. O output é um Sprint Goal e um Sprint Backlog. Time-box de 8 horas para um Sprint de 4 semanas.
03
Daily Scrum
Sincronização diária de 15 minutos para os Developers. Inspecionar o progresso face ao Sprint Goal, adaptar o Sprint Backlog se preciso. Não é um relatório de estado, mas uma reunião de coordenação. O Scrum Master não a preside; são os developers que a conduzem.
04
Sprint Review
A equipa apresenta o Increment aos stakeholders e recolhe feedback. Não é uma demo para aprovação, mas uma sessão de trabalho para inspecionar o que foi construído e adaptar o backlog com base no que se aprendeu.
05
Retrospetiva
A equipa inspeciona-se a si própria: como as pessoas, as relações, os processos e as ferramentas funcionaram neste Sprint. Identifica melhorias e compromete-se com pelo menos uma mudança no Sprint seguinte. O evento de Scrum mais subvalorizado.
Artefactos
Os três artefactos do Scrum
O Scrum tem três artefactos, cada um representando um compromisso que garante transparência e foco.
Product Backlog
A lista ordenada de tudo o que pode ser necessário no produto. Pertence ao Product Owner. É sempre um documento vivo. Evolui à medida que o produto e o mercado evoluem. O compromisso é o Product Goal.
Sprint Backlog
Os itens selecionados para este Sprint, mais o plano para os entregar. Pertence aos Developers. Visível e atualizado diariamente. O compromisso é o Sprint Goal: porque é que este Sprint importa.
Increment
A soma de todos os itens do Product Backlog concluídos neste Sprint e em todos os anteriores. Tem de cumprir a Definition of Done. Tem de ser utilizável, quer o PO decida lançá-lo ou não. O compromisso é a Definition of Done.
Escrever o Trabalho
User stories e a Definition of Done
As user stories são o formato mais comum para exprimir itens de backlog. Descrevem um requisito da perspetiva do utilizador, tornando o objetivo e o contexto explícitos para toda a equipa:
"Como [tipo de utilizador], quero [fazer algo] para que [obtenha este benefício]."
O formato obriga-te a articular quem é o utilizador, o que quer fazer e porquê, antes de escrever uma única linha de código.
Boas user stories seguem os critérios INVEST: Independent (pode ser construída sozinha), Negotiable (não é um contrato), Valuable (entrega valor ao utilizador), Estimable (a equipa consegue dimensioná-la), Small (cabe num Sprint), Testable (consegues verificar que está feita).
Igualmente importante é a Definition of Done, um acordo partilhado sobre o que "completo" significa. Sem ela, "feito" significa coisas diferentes para pessoas diferentes e os bugs escapam. Uma DoD típica inclui: código escrito, testes unitários a passar, testado em integração, revisto e em staging.
Medir o Progresso
Métricas Agile que dizem algo real
O Agile produz sinais mensuráveis que permitem às equipas melhorar. As métricas mais úteis acompanham o fluxo, a previsibilidade e a qualidade, não apenas a velocidade.
Velocity
Story points concluídos por Sprint. Útil para previsão: "à nossa velocity atual, concluímos esta funcionalidade em 3 Sprints". Não é uma métrica de desempenho para comparar entre equipas: o dimensionamento de story points é específico de cada equipa.
Burndown Chart
Trabalho restante ao longo do tempo dentro de um Sprint. Mostra se a equipa está no caminho de cumprir o Sprint Goal. Um burndown plano significa que o trabalho não está a ser feito; uma queda tardia e abrupta sugere má decomposição do trabalho.
Cycle Time
Quanto tempo um item de trabalho demora a passar de "iniciado" a "feito". Um indicador antecipado de eficiência da equipa. Cycle times longos sinalizam bloqueios, requisitos pouco claros, ou trabalho grande demais para concluir depressa.
Escaped Defects
Bugs encontrados pelos utilizadores após o lançamento, não apanhados durante o Sprint. Muitos escaped defects sinalizam uma Definition of Done fraca ou testes insuficientes. É a métrica que mostra se "andar depressa" está, na verdade, a criar dívida técnica.
Conclusão
O Agile funciona quando a equipa o faz seu
A razão mais comum para o Agile falhar não é uma má compreensão da framework. É ser imposto às equipas em vez de adotado por elas. As cerimónias de Scrum tornam-se check-the-box. As retrospetivas não produzem mudança real. Os standups tornam-se relatórios de estado para a gestão em vez de coordenação entre pares.
O Agile funciona quando as equipas o usam para ficar melhores a construir coisas, não para parecerem mais modernas. A cadência do sprint, as cerimónias, os artefactos, tudo isto existe para criar oportunidades frequentes de aprender e ajustar. As equipas que percebem isto usam o Scrum como ferramenta. As que não percebem usam-no como fantasia.
O output real
Não são sprints concluídos. Não são números de velocity. É um produto que fica mensuravelmente melhor para os utilizadores a cada duas semanas.
A parte mais difícil
Retrospetivas que produzem mudança real, não só discussão. Inspecionar, adaptar, repetir, com segurança psicológica suficiente para ser honesto.
O sinal-chave
A equipa tem um produto a funcionar no fim de cada Sprint? Se não, algo estrutural está partido, não só o processo.