The Scrum Framework — Segunda edição

Este capítulo mantém o contexto histórico e prático de ensino da segunda edição. O currículo da terceira edição também está disponível no índice abaixo.

---

Exemplo Scrum: um caso real para equipas ágeis de excelência

Neste artigo, gostaríamos de apresentar um exemplo da metodologia Scrum que possa inspirar as suas equipas Scrum, outras partes interessadas do negócio e as pessoas ligadas aos projetos. Temos observado muitos casos em que empresas dispõem de profissionais Scrum formados, mas enfrentam dificuldades nas operações diárias e na implementação dos produtos devido à falta de experiência prática com Scrum.

Este problema impede frequentemente que as equipas Scrum atinjam a velocidade ideal e lancem os entregáveis a tempo e dentro do orçamento. É aqui que este exemplo da metodologia Scrum ganha importância.

Por isso, neste breve artigo procuraremos ajudá-lo a ver o panorama geral do framework Scrum: desde a construção de processos Scrum que criam um valor sem precedentes para os negócios, produtos e serviços e proporcionam grande agilidade aos clientes, até à configuração e utilização do gráfico de burndown para melhorar e manter a velocidade das equipas.

Com este exemplo da metodologia Scrum, ajudamo-lo a compreender como funciona uma equipa Scrum e como pode beneficiar a organização. Os dados sugerem que, na maioria das empresas, as equipas Scrum são normalmente compostas por um Product Owner, um Scrum Master e Developers, formando em conjunto a Scrum Team. Trabalham em iterações curtas, chamadas Sprints, para entregar Incrementos valiosos do produto. Esta abordagem iterativa permite flexibilidade, adaptação e feedback mais rápido.

Eis as personagens principais deste exemplo da metodologia Scrum:

• Alex, o Scrum Product Owner.
• Frank, o Scrum Master.
• A equipa Scrum.

Antes de iniciar o primeiro Sprint

Alex é designado Scrum Product Owner de um novo projeto de desenvolvimento de software. Uma das primeiras tarefas é iniciar a engenharia de requisitos. Regista os casos de utilização mais importantes e discute-os com arquitetos, representantes dos clientes e outras partes interessadas. Depois de recolher os casos de utilização e requisitos de alto nível, regista-os no Scrum Product Backlog e inicia uma sessão de estimativa e definição de prioridades com os arquitetos e alguns programadores séniores. Como resultado, todos os itens do Scrum Product Backlog recebem uma estimativa inicial aproximada e uma prioridade. Começa então a dividir os requisitos de alto nível em User Stories mais detalhadas. Com esta lista, convoca a primeira reunião de Sprint Planning.

Introdução a Scrum — Um exemplo real ao longo de várias fases e Sprints

Sprint 1 — Dia 0

Durante o Sprint Planning, Alex apresenta os itens do Scrum Product Backlog por ordem decrescente de prioridade. A equipa esclarece as questões em aberto e discute, para cada item, se dispõe de capacidade, dos conhecimentos necessários e de tudo o resto de que precisa. Depois desta discussão, compromete-se a concluir as histórias 1, 2, 3, 6, 7 e 8 até ao fim do Sprint. Os itens 4 e 5 não podem ser realizados neste Sprint, pois alguma infraestrutura técnica ainda não está disponível.

Depois do Sprint Planning, Frank, o Scrum Master da equipa, reúne-a para definir em pormenor como serão implementados os itens acordados. As tarefas resultantes são escritas em cartões no quadro de tarefas do Sprint já preparado. Agora, cada membro da equipa Scrum seleciona uma tarefa em que trabalhar.

Dica para equipas Scrum:

Alex, como Scrum Product Owner, lidera um novo projeto de desenvolvimento de software na organização. A sua função assemelha-se à de um maestro, em que cada pessoa desempenha uma parte. Esta função transversal traz uma responsabilidade significativa e centra-se na criação de estruturas ágeis de desenvolvimento de software auto-organizadas, nas quais a melhoria é contínua. Este framework não é uma solução universal, mas um percurso traçado para orientar os Developers no trabalho. Alex é o pulso da empresa, garantindo que os produtos finais criados correspondem às necessidades dos clientes. Uma abordagem ágil como esta repete continuamente o ciclo, promovendo o aperfeiçoamento constante dos produtos e métodos.

Em seguida, Alex promove uma sessão de estimativa e definição de prioridades com User Stories (saiba mais sobre User Stories Scrum) e story points como técnica de estimativa relativa. A visualização ao estilo Kanban pode complementar este trabalho, tornando as tarefas e o fluxo visíveis a toda a equipa. Como resultado, todos os itens do Scrum Product Backlog recebem uma estimativa inicial aproximada e uma prioridade. Alex recorre à experiência de gestão de projetos para dividir requisitos de alto nível em histórias centradas no utilizador, traduzindo eficazmente os requisitos em parcelas entregáveis. Estas User Stories, exemplos concretos do que os clientes querem, mostram caminhos para alcançar os objetivos do projeto. Com esta lista, convoca o primeiro Sprint Planning e promove uma cultura de colaboração próxima em toda a equipa de desenvolvimento de software.

Sprint 1 — Dia 1

De manhã, toda a equipa reúne-se para o Daily Scrum. Cada pessoa explica brevemente o que alcançou, atualiza a estimativa das horas restantes nos cartões do quadro de tarefas do Sprint, indica o que planeia fazer nesse dia e se existem impedimentos ao progresso. Hoje, um membro explica que precisa de uma nova licença de uma ferramenta de software que utiliza. Frank verifica se outros têm o mesmo problema e diz que tratará do assunto depois da reunião. Ao fim de 15 minutos, todos regressam ao trabalho.

Depois da reunião, Frank atualiza o burndown do Sprint. Em seguida, telefona ao fornecedor da ferramenta, encomenda as licenças e envia-as às pessoas que precisam delas.

Dica para equipas Scrum:

Durante o Sprint Planning, Alex apresenta os itens do Scrum Product Backlog por prioridade. É sua responsabilidade na organização garantir que todos compreendem o objetivo global do projeto. As reuniões de acompanhamento da equipa facilitam discussões abertas que esclarecem funções e resolvem possíveis problemas.

Frank, o Scrum Master, desempenha outro papel fundamental nesta equipa diversa. Apoia cada reunião diária de acompanhamento, ajudando a manter as conversas centradas no Sprint Goal quando necessário. Os Developers são responsáveis pelo plano e escolhem as tarefas em conjunto; Frank não lhes atribui trabalho.

Sprint 1 — Dia 2

De manhã, toda a equipa volta a reunir-se para o Daily Scrum. À tarde, um dos membros tem dúvidas sobre os pormenores de uma User Story. Telefona a Alex, o Scrum Product Owner, e discute com ele os pontos em aberto. Depois de descobrir o que fazer, pode continuar a implementação.

Sprint 1 — Dia 28

É o último dia do primeiro Sprint e Frank, o Scrum Master, convidou a equipa para a Sprint Review. A equipa preparou uma máquina com a implementação atual do software. Alex, o Scrum Product Owner, senta-se diante da máquina e verifica se a implementação corresponde às expectativas e se as funcionalidades estão documentadas conforme necessário. No fim da sessão, conclui:

• As histórias 1, 2, 6 e 7 estão concluídas conforme esperado.
• A história 3 não foi concluída a tempo e nem sequer foi apresentada.
• A história 8 tem alguns pontos que precisam de refatorização.

À tarde, a equipa reúne-se para a Sprint Retrospective e discute o que correu bem durante o Sprint e o que pode melhorar. Um dos comentários é que a equipa sente não conhecer suficientemente a arquitetura global do sistema. Frank assume a tarefa de convidar o arquiteto do sistema para uma apresentação mais detalhada.

Exemplo da metodologia Scrum

Dica para equipas Scrum:

Quando chega o último dia do primeiro Sprint, Frank orienta a equipa na Sprint Review. A colaboração consistente produz um protótipo concreto que reflete o compromisso e o empenho da equipa.

À tarde, a equipa reúne-se para a Sprint Retrospective. Partilha ideias sobre o progresso e revê os aspetos que exigem melhoria em futuros Sprints. Esta reunião revela-se um elemento fundamental da abordagem ágil, oferecendo um valor significativo ao projeto global.

No planeamento do próximo Sprint, o papel essencial de Alex como Scrum Product Owner volta a destacar-se quando acrescenta novos itens ao Scrum Product Backlog com base nas reuniões recentes com os clientes. Quando começa o segundo Sprint, é evidente que os princípios de trabalho em equipa, transparência e gestão eficaz de projetos continuam a impulsionar esta equipa orientada pela informação para o sucesso.

Sprint 2 — Dia 1

Alex, o Scrum Product Owner, acrescenta novos itens ao Scrum Product Backlog com base nas reuniões recentes com os clientes. Acrescenta também itens para a refatorização da história 8. Depois, convida a equipa para o Sprint Planning do Sprint 2. A equipa discute e compromete-se com histórias sob a orientação de Frank, o Scrum Master, e começa o segundo Sprint.

Dica para equipas Scrum:

O segundo Sprint põe em prática a aprendizagem da equipa: o Product Backlog revisto reflete o feedback dos clientes, o trabalho por concluir é reconsiderado e a colaboração continua em torno do próximo Sprint Goal.

Estudar exemplos e casos práticos Scrum é essencial para organizações que pretendem desenvolver equipas eficientes e de elevado desempenho. Analisar situações reais oferece informações valiosas sobre implementações bem-sucedidas e, igualmente importante, ajuda a identificar erros comuns a evitar. Ao aprender com estes exemplos, as equipas podem acelerar o percurso até um desempenho de excelência, aproveitando boas práticas, evitando erros e alcançando resultados positivos rápidos nas suas iniciativas Scrum.

Acompanhe mais situações reais e estudos de caso que enriquecerão a sua compreensão do framework Scrum e das suas aplicações práticas.