O que é scrum e como começar

As pessoas pensam com frequência que o Scrum e a agilidade são a mesma coisa porque o Scrum é centrado na melhoria contínua, que é o princípio fundamental da agilidade. No entanto, o Scrum é uma estrutura para concluir tarefas, e a agilidade é uma filosofia. A filosofia ágil gira em torno da melhoria incremental contínua por meio de lançamentos pequenos e frequentes. Você não consegue "se tornar ágil" de repente, visto que isso demanda dedicação de toda a equipe para mudar a forma de pensar sobre como entregar valor aos clientes. Contudo, você pode usar uma estrutura como o Scrum como ajuda para começar a pensar dessa forma e a praticar o desenvolvimento dos princípios ágeis na comunicação e no trabalho do dia a dia.

A diferença entre agilidade e a definição de Scrum pode ser encontrada no guia Scrum e no Manifesto Ágil. O Manifesto Ágil descreve quatro valores:

• Pessoas e interações em vez de processos e ferramentas
• Software funcional mais do que documentação abrangente
• Colaboração com o cliente mais do que negociação de contrato
• Resposta a mudanças em vez de planos a serem seguidos

A definição de Scrum é baseada no empirismo e no pensamento enxuto. O empirismo diz que o conhecimento vem da experiência e que as decisões são tomadas com base no que é observado. O pensamento enxuto reduz o desperdício e se concentra no essencial. A estrutura do Scrum é heurística. Ela é baseada no aprendizado contínuo e na adaptação aos fatores variáveis. O Scrum reconhece que a equipe não sabe tudo no início do projeto e que vai evoluir com a experiência. Ele é estruturado para ajudar as equipes a se adaptar com naturalidade às mudanças e aos requisitos do usuário, com repriorização integrada no processo e ciclos curtos de liberação para que a equipe aprenda e melhore sempre.

Embora o Scrum seja estruturado, ele não é rígido por completo. Ele pode ser adaptado às necessidades de qualquer empresa. Há diversas teorias sobre o modo exato de como as equipes do Scrum devem trabalhar para se tornar bem-sucedidas. No entanto, após mais de uma década ajudando as equipes de agilidade a concluírem trabalhos na Atlassian, a gente aprendeu que a comunicação clara, a transparência e a dedicação ao aprimoramento contínuo devem sempre ficar no centro de qualquer estrutura que você escolher. E o resto é com você.

• O backlog do produto é a principal lista do trabalho que precisa ser feita e mantida pelo proprietário do produto ou gerente de produtos. É uma lista dinâmica de funções, requisitos, aprimoramentos e correções que atua como a entrada para o backlog do sprint. Em essência, ela é a "lista de afazeres" da equipe. O backlog do produto é sempre revisto, repriorizado e mantido pelo proprietário do produto porque, conforme aprimoramos o conhecimento ou o mercado muda, os itens podem não ser mais relevantes ou os problemas podem ser resolvidos de outras formas.
• O backlog do sprint é a lista de itens, histórias de usuários ou correções de bugs selecionada pela equipes de desenvolvimento para a implementação no ciclo atual de sprint. Antes de cada sprint, durante a reunião de planejamento de sprint (que abordaremos posteriormente neste artigo), a equipe escolhe quais itens funcionarão para o sprint a partir do backlog do produto. Um backlog do sprint pode ser flexível e se desenvolver durante um sprint. No entanto, a meta fundamental do sprint, ou seja, o que a equipe deseja alcançar com o sprint atual, não pode ser comprometida.
• Incremento (ou meta de sprint) é o produto final utilizável, proveniente de um sprint. Na Atlassian, nós normalmente apresentamos o "incremento" durante a demonstração de final de sprint, na qual a equipe exibe o que foi concluído no sprint. Talvez você não escute a palavra "incremento" por aí, visto que ela costuma ser citada como a definição de "Concluído" dada pela equipe, como um marco, a meta de sprint ou, até mesmo, uma versão completa ou um epic lançado. Depende apenas de como as equipes definem "Concluído" e como você define suas metas de sprint. Por exemplo, algumas equipes optam por lançar algo para seus clientes no final de cada sprint. Dessa forma, para elas, a definição de "Concluído" pode ser "lançado". No entanto, essa definição pode não ser plausível para outros tipos de equipes. Vamos supor que você trabalhe em um produto baseado em servidor que só pode ser lançado para seus clientes a cada trimestre. Você ainda pode optar por trabalhar em sprints de duas semanas, mas sua definição de "concluído" pode ser o acabamento de uma versão maior que pretende lançar junto. Mas é claro que, quanto mais demorar para lançar o software, maior o risco de ele errar o alvo.

Como você pode perceber, a sua equipe tem muitas alternativas na hora de fazer as escolhas, inclusive em relação aos artefatos. É por isso que é importante permanecer aberto para desenvolver o modo como você mantém até mesmo seus artefatos. Talvez, a sua definição de "concluído" cause um estresse irreversível à sua equipe e você precise retroceder para escolher uma nova definição.

Veja abaixo uma lista de todas as principais cerimônias das quais uma equipe do Scrum pode participar:

1. Organizar o backlog: algumas vezes conhecido como "preparação do backlog", esse evento é responsabilidade do proprietário do produto. As principais tarefas do proprietário é orientar o produto em direção à visão do produto e acompanhar constantemente o mercado e o cliente. Dessa forma, ele mantém a lista usando o feedback dos usuários e da equipe de desenvolvimento para ajudar a priorizar e manter a lista clara e pronta para ser trabalhada a qualquer momento. Você pode ler mais sobre como manter um backlog favorável, aqui.

2. Planejamento de sprints: o trabalho que vai ser realizado (escopo) ao longo do sprint atual é planejado durante essa reunião por toda a equipe de desenvolvimento. A reunião é conduzida pelo mestre do Scrum e é nela que a equipe decide a meta de sprint. Histórias do usuário específicas são, então, acrescentadas ao sprint a partir do backlog do produto. Essas histórias sempre se alinham à meta e também são aceitas pela equipe do Scrum como sendo viáveis para a implementação durante o sprint.
   
   No final da reunião de planejamento, cada membro do Scrum precisa esclarecer o que pode ser apresentado no sprint e como o incremento pode ser entregue.

3. Sprint: um sprint é o período real em que a equipe do Scrum trabalha em conjunto para concluir um incremento. A duração mais comum de sprint é de duas semanas, embora algumas equipes prefiram uma semana por ser mais fácil de realizar um escopo ou um mês por ser mais fácil de entregar um incremento de valor. Dave West, da Scrum.org, adverte que, quanto mais complexo e incerto for o trabalho, menor deve ser o sprint. Mas esse período fica realmente a critério da sua equipe, e você não deve ter medo de mudá-lo se não estiver funcionando. Durante essa fase, o escopo pode ser renegociado entre o proprietário do produto e a equipe de desenvolvimento, se necessário. Isso constitui a essência da natureza empírica do Scrum.
   
   Todos os eventos, desde o planejamento à retrospectiva, ocorrem durante o sprint. Assim que um determinado intervalo de tempo é estabelecido para o sprint, ele precisará permanecer consistente durante todo o período de desenvolvimento. Isso ajuda a equipe a aprender com experiências passadas e a aplicar esse insight aos sprints futuros.

4. Scrum diário ou reunião rápida diária: é uma reunião diária bem rápida que ocorre na mesma hora (em geral de manhã) e local para manter a simplicidade. Muitas equipes tentam concluir a reunião em 15 minutos, mas isso é apenas uma diretriz. Ela também é chamada de “reunião rápida diária” para enfatizar que precisa ser breve. A meta do Scrum diário é fazer com que todos os integrantes da equipe estejam atualizados com as mesmas informações e alinhados com a meta do sprint para chegarem a um planejamento para as próximas 24 horas.
   
   A reunião rápida é o momento de exprimir qualquer preocupação que você tenha a respeito de cumprir a meta do sprint ou quaisquer bloqueadores.
   
   Uma forma comum de conduzir uma reunião rápida é solicitar que cada membro da equipe responda a três perguntas sobre o cumprimento da meta do sprint:
   
   • O que eu fiz ontem?
   • O que eu planejo fazer hoje?
   • Há algum obstáculo?
   
   No entanto, já vimos reuniões se transformando em pessoas lendo agendas para falarem sobre o dia anterior ou seguinte. A teoria por trás da reunião rápida é que ela deixa a conversa fiada para uma reunião diária. Dessa forma, a equipe pode focar o trabalho no restante do dia. Portanto, se a reunião se transformar em uma leitura de agendas, não hesite em usar a criatividade para mudar um pouco as coisas.

5. Análise de sprint: no final do sprint, a equipe se reúne para uma sessão informal a fim de ver uma demonstração ou fazer inspeção do incremento. A equipe de desenvolvimento mostra os itens de backlog que estão "concluídos" para partes interessadas e aos colegas de equipe para que eles possam dar o feedback. O proprietário do produto pode decidir se vai lançar ou não o incremento, embora, na maioria das vezes, o incremento seja lançado.
   
   É também nessa reunião de análise que o proprietário do produto reformula o backlog com base no sprint atual. Esse backlog pode orientar a próxima sessão de planejamento de sprint. Para um sprint de um mês, considere encaixar intervalos para a análise de sprint de, no máximo, quatro horas.

6. Retrospectiva de sprint: a retrospectiva é o momento em que a equipe se reúne para documentar e discutir o que funcionou e o que não funcionou em um sprint, em um projeto, nas pessoas ou nos relacionamentos, nas ferramentas ou, até mesmo, em determinadas cerimônias. A ideia é criar um local em que a equipe possa focar o que foi bem e o que precisa melhorar para a próxima vez, sem ficar ressaltando o que deu errado.