Se você já entrou em um time de desenvolvimento, provavelmente já ouviu falar em sprint, backlog, daily. Esses termos vêm do Scrum, o framework ágil mais usado no mundo para organizar o trabalho em equipe. E entender como ele funciona na prática, não só no discurso, faz diferença no seu dia a dia como desenvolvedor.
Este artigo reúne o essencial: origem, pilares, papéis, eventos e artefatos do Scrum, com base no Guia do Scrum de Jeff Sutherland e Ken Schwaber, os criadores do framework.
O Scrum surgiu em 1995, criado por Jeff Sutherland e Ken Schwaber. O nome é emprestado do rugby: no esporte, o scrum é a formação em que o time avança junto, como uma unidade. A ideia central é a mesma. Em vez de um time trabalhar em silos e passar tarefas adiante em etapas fixas, ele avança em conjunto, revisando o caminho a cada passo.
Antes do Scrum, o modelo dominante no desenvolvimento de software era o cascata (waterfall): requisitos definidos no início, um plano fechado, entrega só no final. Funcionava bem quando o problema era simples e previsível. Mas em projetos complexos, esse modelo trazia problemas recorrentes de prazo, orçamento e dificuldade de lidar com mudanças no meio do caminho.
O Scrum nasceu como resposta a isso. Em vez de tentar prever tudo antes de começar, o time trabalha em ciclos curtos, entrega algo funcional a cada ciclo e ajusta o rumo com base no que aprendeu. É um modelo pensado para ambientes de aprendizado contínuo, onde os requisitos mudam e a certeza total sobre o resultado final simplesmente não existe.
Vale reforçar que o Scrum não é exclusivo de desenvolvimento de software. É um framework multidisciplinar, usado em áreas como publicidade, saúde e gestão de projetos em geral. Qualquer trabalho complexo, com alto grau de incerteza, pode se beneficiar da abordagem.
Todo o funcionamento do Scrum se apoia em três pilares. Eles não são regras soltas, são a base que sustenta o restante do framework.
Transparência. O trabalho e o progresso precisam estar visíveis para todos os envolvidos, incluindo quem toma as decisões. Sem informação clara e acessível, não há como inspecionar nem adaptar nada com segurança.
Inspeção. O progresso precisa ser revisado com frequência, para identificar desvios em relação ao objetivo o quanto antes. Quanto mais cedo um problema é percebido, mais barato é corrigi-lo.
Adaptação. Quando a inspeção revela que algo está fora do esperado, o processo ou o produto precisam ser ajustados. De nada adianta inspecionar se o time não muda o plano quando necessário.
Esses três pilares se repetem em praticamente todos os eventos do Scrum, e é por isso que entendê-los ajuda a entender o resto.
O Scrum define três papéis dentro do time. Não são cargos hierárquicos, são responsabilidades diferentes dentro de um mesmo objetivo.
É quem tem contato direto com o cliente e atua como guardião da visão do produto. O Product Owner define o que precisa ser feito, cria e mantém o Product Backlog (a lista de tudo que pode ser desenvolvido) e prioriza esses itens com base no valor que geram para o negócio. Em resumo, é a pessoa responsável por maximizar o valor entregue pelo time.
É o facilitador do processo. O Scrum Master ajuda o time a entender e aplicar o Scrum corretamente, promove a colaboração, remove obstáculos que atrapalham o progresso e facilita a comunicação entre o time e as partes interessadas. Não é um gestor de pessoas, é alguém dedicado a fazer o processo funcionar.
São as pessoas que executam o trabalho, e o termo não se limita a programadores. Os Developers definem como o trabalho será feito, criam o plano da Sprint e ajustam esse plano ao longo do ciclo, sempre que necessário para atingir o objetivo combinado.
O ponto comum entre os três papéis é que cada pessoa precisa ter clareza sobre o que fazer. Sem essa clareza, o restante do framework perde o sentido.
O Scrum organiza o trabalho em cinco eventos, todos dentro da Sprint.
A Sprint é o coração do Scrum: um ciclo curto e de duração fixa, geralmente entre uma e quatro semanas (o mais comum na prática é duas semanas), em que o time produz um incremento de valor pronto para uso. Ao final de cada Sprint, existe algo concreto para testar e revisar. Esse formato de ciclo curto dá ao time liberdade para ser criativo, já que os próximos passos se ajustam conforme os requisitos mudam.
É o planejamento que abre a Sprint. O time define o Sprint Goal (o objetivo daquele ciclo) e monta o plano de trabalho necessário para alcançá-lo.
Uma reunião curta, de cerca de 15 minutos, feita todos os dias. O objetivo é simples: alinhar o time sobre o progresso em direção ao Sprint Goal e identificar o que está travando o avanço. Uma boa pergunta para guiar essa conversa é: o que nos aproxima do objetivo da Sprint, e o que nos impede de chegar lá?
Momento de apresentar o que foi entregue durante a Sprint, coletar feedback das partes interessadas e avaliar o progresso em relação ao objetivo definido. É também uma oportunidade para ajustar o Product Backlog com base no que foi aprendido.
O time olha para o próprio processo, não para o produto. É quando se discute o que funcionou bem, o que pode melhorar e quais ajustes fazer para a próxima Sprint. Pular esse evento é um dos erros mais comuns, e um dos que mais custam caro a médio prazo.
Os artefatos são os elementos que organizam o trabalho e garantem que todos estejam alinhados sobre o progresso.
Product Backlog. A lista completa e ordenada de tudo que pode ser necessário no produto. É um documento vivo, que muda conforme o entendimento do time e do mercado evolui.
Sprint Backlog. O conjunto de itens do Product Backlog selecionados para aquela Sprint, junto com o plano de execução. O Sprint Goal não muda ao longo do ciclo, mas o plano para alcançá-lo pode ser ajustado.
Incremento. É o que o time entrega ao final de cada ciclo, em um estado funcional e utilizável. Para ser considerado um incremento válido, o trabalho precisa atender à Definição de Pronto (Definition of Done), um conjunto de critérios combinado pelo time que define quando algo está realmente concluído, e não só "quase pronto".
Esse ciclo de entrega e ajuste contínuo é o que permite melhorar o desempenho do projeto aos poucos, sem precisar esperar até o fim para descobrir se algo deu certo.
Na prática, boa parte dos problemas com Scrum não vem do framework em si, vem de como ele é aplicado. Alguns erros aparecem com frequência:
Não é preciso dominar todos os detalhes do framework para começar a aplicar Scrum. O caminho mais direto é:
O mais importante é entender que o Scrum não é uma receita fixa. É um ciclo de aprendizagem ativo: você aplica, revisa o que funcionou, adapta o processo e segue para o próximo ciclo. Essa adaptação constante é, na prática, o próprio espírito do framework.
Nenhum comentário ainda. Seja o primeiro.
O git cherry-pick é um dos comandos mais poderosos e versáteis no Git, mas muitas vezes é mal compreendido ou subutilizado. Enquanto o comando git merge mescla todas as mudanças de uma branch para outra, o cherry-pick…
Artigo, GIT, Intermediários
O PostgreSQL 16 ainda não está disponível nos repositórios oficiais do Linux Mint 21, então usaremos o repositório oficial do PostgreSQL. O repositório da versão "Jammy" é compatível com o Linux Mint 21. Para seguir com…
Artigo, Avançados, Intermediários, Linux, Ubuntu