APRENDER. PRATICAR. EVOLUIR.Empirismo, valores e melhoria
Scrum organiza aprendizagem e criação de valor perante problemas complexos. O empirismo usa observações para decidir: transparência torna o estado compreensível, inspeção permite detetar diferenças e adaptação altera o trabalho em resposta. Num serviço de reconciliação, compara a capacidade utilizável com o objetivo e decide o próximo passo. Os valores são compromisso, foco, abertura, respeito e coragem. Reportar uma falha de qualidade exige abertura e coragem; ouvir quem a encontrou demonstra respeito. Construir por incrementos e rever iterativamente pode antecipar feedback, limitar investimento numa hipótese errada e tornar problemas de integração visíveis mais cedo. Retirar a review perde contacto com resultados; retirar a retrospective deixa problemas de colaboração sem uma oportunidade regular de melhoria. Relaciona estas escolhas com colaboração com o cliente, resposta à mudança, interação entre pessoas e software funcional no Manifesto Ágil.
A equipa e as decisões
O Product Owner orienta valor e Product Backlog; os Developers planeiam e executam o trabalho para criar um incremento utilizável; o Scrum Master ajuda a estabelecer Scrum e a melhorar a eficácia da equipa. No início de uma integração, o PO explica a necessidade de negócio, os Developers avaliam uma fatia realizável e o Scrum Master ajuda a tornar dependências visíveis. Uma equipa multifuncional reúne as competências necessárias, sem exigir que cada pessoa domine todas. A autogestão permite decidir internamente quem faz o quê, quando e como. Pode reduzir esperas por distribuição externa de tarefas, aproximar decisões de quem conhece o trabalho e aumentar aprendizagem entre especialidades. Não elimina restrições de segurança ou autoridades externas: torna necessário esclarecer como trabalhar com elas.
Cadência e escolha da duração
Uma Sprint tem duração fixa de um mês ou menos e a seguinte começa logo após a anterior. Durante esse intervalo, o trabalho deve avançar para o objetivo e criar valor utilizável. Escolhe a duração considerando rapidez do feedback, incerteza e capacidade de concluir uma fatia útil. Uma dependência externa de seis semanas não autoriza uma Sprint de seis semanas; exige tratar a dependência e procurar uma fatia que possa ser concluída dentro da cadência. O timebox limita o custo de uma conversa, incentiva preparação e foco e cria um ponto previsível de inspeção. Não serve para fingir uma decisão quando faltam dados essenciais. Regista a informação em falta, o responsável e o próximo passo sem prolongar automaticamente o evento ou reduzir a qualidade.
Eventos: finalidade, participantes e limites
Sprint Planning inicia a Sprint: toda a Scrum Team colabora no porquê, no que selecionar e no plano de realização. Pode convidar pessoas para aconselhar. O limite é oito horas numa Sprint de um mês. O Daily Scrum é um evento de 15 minutos dos Developers em cada dia de trabalho, para inspecionar progresso para o Sprint Goal e adaptar o plano; PO e Scrum Master participam como Developers se estiverem a trabalhar ativamente em itens do Sprint Backlog. A Sprint Review reúne Scrum Team e stakeholders relevantes perto do fim para inspecionar resultados e mudanças no contexto e decidir adaptações futuras; o máximo é quatro horas numa Sprint de um mês. A Sprint Retrospective termina a Sprint: a Scrum Team procura melhorar qualidade e eficácia, até três horas numa Sprint de um mês. Planning, Review e Retrospective são normalmente mais curtas em Sprints menores; isso não impõe uma divisão matemática obrigatória. Refinement é atividade contínua, não um evento formal adicional.
Artefactos e compromissos observáveis
O Product Backlog é a lista ordenada, emergente e transparente do trabalho necessário para melhorar o produto; o Product Goal orienta a evolução pretendida. O Sprint Backlog contém Sprint Goal, itens selecionados e plano: é visível, atualizado durante a Sprint e gerido pelos Developers. O Sprint Goal mantém coerência quando o detalhe do trabalho muda. O Increment é utilizável, acrescenta-se aos anteriores e está verificado para funcionar com eles; a Definition of Done estabelece a referência de qualidade. Num serviço batch, o quadro de tarefas não é o incremento e um relatório de horas não demonstra valor utilizável. Pede à equipa que mostre o fluxo concluído e a evidência dos critérios de qualidade. Os três compromissos apoiam a inspeção; não são três documentos de aprovação por um gestor.
Refinement e adaptação do plano
Refinement pode dividir um item, clarificar a descrição e discutir tamanho e ordem. Uma descrição útil explica a necessidade; ordem indica a posição nas escolhas; tamanho ajuda os Developers a avaliar capacidade. Dedicar tempo a esta atividade reduz ambiguidades antes da seleção e revela dependências antes de se tornarem urgentes. Não exige uma especificação completa de todo o futuro. Se uma API responde de modo diferente do esperado, os Developers atualizam o Sprint Backlog e colaboram com o PO para renegociar âmbito preservando o Sprint Goal. O objetivo não muda apenas para acomodar tarefas novas: mantém o propósito comum. Se se tornar obsoleto, o PO pode cancelar a Sprint. Novas observações podem também alterar a ordem do Product Backlog; emergente não significa desorganizado.
Qualidade que evolui sem ocultar trabalho
Podem existir vários incrementos numa Sprint. Uma capacidade que cumpre a Definition of Done pode ser entregue antes da Review, respeitando as condições operacionais aplicáveis; a Review não é uma aprovação obrigatória para release. A Definition of Done pode evoluir com aprendizagem e exigências organizacionais. Tornar um teste de recuperação obrigatório exige planear como o cumprir e revelar trabalho que ficou em falta; não permite baixar qualidade durante a Sprint nem reclassificar silenciosamente falhas como Done. Equipas no mesmo produto precisam de uma Definition of Done comum para interpretar conclusão da mesma forma e verificar a integração entre os seus resultados. No handover, usa a mesma evidência para quem constrói e para quem suporta. Conteúdo adaptado e exemplos originais a partir do Scrum Guide de novembro de 2020, de Ken Schwaber e Jeff Sutherland, disponibilizado sob CC BY-SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/
Uma falha de integração exige ajustar o plano e expor o trabalho pendente, mantendo o objetivo e os critérios de qualidade.
Armadilhas comuns
Tratar a Review como aprovação de release; alterar o objetivo para caber mais trabalho; confundir o máximo de um mês com quatro semanas fixas.
Tópicos relacionados: Transparência, qualidade e accountabilities · Eventos que levam a adaptação
Mantém visíveis o propósito, o estado utilizável e a decisão de adaptação; escolhe técnicas que respeitem a estrutura.
Referência: The Scrum Guide · CSM learning objectives January 2022 (formatted February 2024), current linked syllabus; Scrum Guide November 2020; no numbered exam revision published