Hoje é comum vermos muitas empresas falando que trabalham com Scrum, que estão implementando Scrum, que seguem Scrum à risca, etc. É bacana ver o quanto a ideia vem sendo aplicada e o quanto está difundida no mercado. Porém, há uma confusão no que se diz respeito ao que é ou não Scrum, não raro vemos afirmações como:
“Nós trabalhamos com ciclos de entregas menores, não fazemos um planejamento de 2 anos e passamos esses anos desenvolvendo um produto para só no final realizar uma grande entrega com tudo.”
Isto não necessariamente é Scrum, isso apenas indica que ao invés de trabalharmos com o modelo em cascata de desenvolvimento de software, estamos adotando um modelo iterativo de desenvolvimento.
“Nós não fazemos um planejamento, toda semana podemos redefinir completamento as nossas prioridades e o que estamos fazendo, trabalhamos com Sprints de 1 semana!”
Em Scrum trabalhamos geralmente em Sprints com duração de 2 a 4 semanas. O escopo durante o Sprint é fechado e não muda. Essa característica de escopo aberto e repriorização semanal das demandas se assemelha muito mais com eXtreme Programming, uma outra metodologia de desenvolvimento de software criada por Kent Beck.
“Sim, trabalhamos com Scrum. Temos um quadro branco com cartões de tarefas e colunas com as etapas de desenvolvimento, conseguimos identificar gargalos e calcular o lead time de nossas atividades.”
Esta é a confusão mais comum de todas. A descrição acima diz respeito ao Kanban, um sistema de sinalização para controlar fluxos de produção que foi evoluído dentro do Sistema Toyota de Produção.
“Estamos rodando Scrum na empresa, fazemos Continuous Deployment e tudo que desenvolvemos vai para produção imediatamente!”
Continuous Deployment é uma técnica apresentada em Lean Startup, um outro conceito desenvolvido por Eric Eies.
“Todas as nossas demandas estão atreladas a um objetivo e temos indicadores para acompanhar o nosso progresso.”
Neste caso, provavelmente estamos falando de algo parecido com OKR (Objectives and Key Results), um método criado na Intel e disseminado por John Doerr, que vem ganhando destaque devido a diversos cases famosos de utilização como o do Google.
“Nós adotamos a ideia de sempre escrever testes antes da implementação do código e…”
Isso é TDD, uma prática muito valorizada em eXtreme Programming…
“Nós trabalhamos muito com testes A/B e coletamos muitas métricas sobre as mudanças que fazemos no software.”
Voltamos a falar de Lean Startup, agora com uma pitada de Growth Hacking.
Poderia citar infinitos outros exemplos aqui de afirmações sobre a utilização de Scrum falando de técnicas e rotinas que na prática não possuem nada a ver com a essência do que é Scrum.
E, importante frisar, não existe problema nenhum em trabalhar com qualquer um dos exemplos acima. Todas as metodologias, frameworks, técnicas, sistemas, etc. podem e devem ser utilizadas, muitas vezes mesclando e adaptando o que faz mais sentido para cada contexto de trabalho.
O “problema” está quando afirmamos cegamente que estamos trabalhando com Scrum e/ou tentamos implementar Scrum em algum ambiente de trabalho sem saber do que de fato se trata. Se queremos defender a bandeira de alguma metodologia e tentar implementá-la, o mínimo que precisamos é entender o que ela é e como diferenciá-la de outras coisas.
Não precisamos necessariamente seguir tudo à risca. Podemos adaptar e fazer combinações de ideias. Kanban e eXtreme Programming por exemplo agregam muito a Scrum e podem ser adaptados e utilizados em conjunto, assim como qualquer outra coisa. O que precisamos é ter consciência do que estamos falando.
Se nada disso é Scrum, o que é então?
Scrum é uma metodologia que trabalha em cima do desenvolvimento iterativo de um projeto e se baseia nas seguintes etapas:
Elaboração do Product Backlog
Inicialmente temos o pepel do(a) Product Owner, que é a pessoa responsável por definir tudo o que precisa ser desenvolvido no projeto. Tais definições formam uma lista de funcionalidades que compõem o chamado Product Backlog.
O Product Backlog então nada mais é do que uma lista de todos itens a serem feitos pelo time de desenvolvimento.
Sprint Planning Meeting
No Sprint Planning Meeting temos a presença do(a) Product Owner, do(a) Scrum Master e do Scrum Team.
O Scrum Team é o grupo de desenvolvedores que participará do desenvolvimento do projeto.
O Scrum Master é a pessoa responsável por dar suporte ao time durante o progresso do projeto, estando atento à saúde dos processos e disposto a resolver todos os conflitos e impedimentos que possam surgir.
No Sprint Planning Meeting o Product Owner apresenta os principais itens do Product Backlog e deixa claro quais são os itens de maior prioridade.
Após tal apresentação, todos em conjunto definem qual será o objetivo do Sprint, como é chamado o ciclo de trabalho que será realizado dentro de um tempo definido. A duração de um Sprint geralmente gira em torno de 2 a 4 semanas.
Com os objetivos e tempo de duração do Sprint definidos, o Scrum Team se reúne separadamente e os desenvolvedores decidem entre eles quais itens apresentados pelo Product Owner podem ser desenvolvidos durante o Sprint. Tal escolha leva em conta a capacidade de entrega do time e as prioridades definidas pelo Product Owner.
Tais itens formam o Sprint Backlog, que são todos os itens que serão desenvolvidos e entregues durante o período do Sprint. Ele não deve mudar durante a execução do Sprint, que possui um escopo fechado durante a sua duração.
Execução do Sprint
Durante o período de duração do Sprint, diariamente o time realiza uma Daily Scrum que nada mais é que uma pequena reunião com todos os membros do Scrum Team com a participação do Scrum Master e demais pessoas interessadas.
Tal reunião tem o objetivo de relatar o que foi realizado no dia anterior, informar qualquer problema ou impedimento encontrado em alguma tarefa e dizer o que pretende-se fazer a seguir.
É importante ressaltar que esta reunião deve ser curta, focada nestes pontos. Após os relatos de cada um, se necessário mais diálogo sobre um assunto específico, as pessoas relevantes para a discussão devem se reunir após a Daily Scrum para realizar a conversa, evitando assim tomar o tempo de todo o time. É recomendável que a reunião seja feita com todos em pé e com um cronômetro para ajudar o time a ser sucinto nas informações.
O Scrum Master durante o Sprint participa da Daily Scrum e sempre busca ajudar a resolver impedimentos encontrados, dúvidas e demais dificuldades. É o seu papel também acompanhar a saúde do processo e garantir que tudo está indo bem.
Sprint Review Meeting
Ao final de um Sprint, temos a Sprint Review Meeting que reúne o Product Owner, o Scrum Master, o Scrum Team e todos os interessados na entrega do projeto, como gerência, diretores, etc.
Esta reunião tem como objetivo demostrar tudo o que foi desenvolvido durante o Sprint e avaliar se o objetivo determinado foi atingido, finalizando assim o ciclo de desenvolvimento do Sprint.
Sprint Retrospective
Após a apresentação dos resultados na Sprint Review Meeting, o Scrum Team se reúne com o Scrum Master e demais interessados para refletir sobre como foi o trabalho realizado durante o Sprint.
Uma Sprint Retrospective costuma ressaltar todos os pontos positivos para que o time busque mantê-los e todos os pontos negativos para discutir e aprender sobre os erros, melhorando assim o processo de desenvolvimento.
É comum ao final da reunião formular uma lista de planos de ação com uma série de coisas a serem feitas para melhorar todos os pontos negativos encontrados e garantir que os pontos positivos continuem existindo.
Iteração
Após a Sprint Retrospective, o ciclo se completa e o time deve realizar uma nova Sprint Planning Meeting e repetir todo o processo para dar continuidade ao projeto.
Para esta nova reunião, com base em todo o aprendizado e feedback obtido no Sprint anterior, o Product Backlog é reavaliado e novamente priorizado para atender a realidade do momento e responder às possíveis mudanças ocorridas com relação ao que se espera do software.
E assim, a cada Sprint o ciclo se repete, permitindo que a cada iteração o cliente obtenha valor com a entrega de software e possa adaptar o rumo do projeto às suas necessidades que evoluem e se modificam ao decorrer do tempo.
Concluindo
Esta foi uma descrição sucinta do que é Scrum e como esta metodologia funciona na prática. Scrum vem evoluindo ao longo dos anos e se adaptando com o tempo. Existem assuntos não citados aqui como backlog refinement e Scrum ofScrums por exemplo que são extensões da metodologia.
Mas a sua essência continua sendo a mesma e não devemos fazer confusões com coisas que são evidentemente diferentes depois que entendemos o que cada uma delas significa.
Para quem deseja se aprofundar no assunto e entender melhor sobre este mundo, deixo algumas recomendações de leitura:
- Agile Software Development with Scrum
- Ken Schwaber, Mike Beedle
- Extreme Programming Explained: Embrace Change
- Kent Beck, Cynthia Andres
- The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
- Eric Ries
Até a próxima! 🙂
