O que é Scrum?

Atualizado em 17/04/2021!

Conheço e aplico métodos ágeis desde 2010, principalmente o framework empírico Scrum. Durante o final da minha faculdade a empresa onde trabalhava, RedeHost, necessitava urgente de uma reorganização dos seus processos de desenvolvimento de software e queriam que eu me tornasse um de seus líderes de desenvolvimento.

Obviamente agarrei a oportunidade, que foi muito importante para minha carreira, e isso me rendeu uma ida à São Paulo participar da segunda turma de um treinamento latino-americano oficial da Scrum.org para desenvolvedores Scrum. O treinamento de uma semana foi incrível e me capacitou para tirar duas certificações na área de gerenciamento de projetos com métodos ágeis e passei a atuar como facilitador do framework Scrum na empresa, em treinamos e em consultorias (como esta).

No artigo de hoje resumo o famoso Scrum Guide, o livro de apenas 10 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. Ao longo deste artigo terá muitos links para outras referências, para que possa se aprofundar. Muitos mesmo.

O mesmo conteúdo deste artigo pode ser assistido neste vídeo abaixo, se preferir:

O que é Scrum?

A definição formal, cunhada pelos criadores Ken Schwaber e Jeff Sutherland, diz que:

Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor através de soluções adaptativas para problemas complexos.

Entenda um framework como uma caixa de ferramentas. Scrum não é algo pronto que resolve todos seus problemas, mas sim um conjunto de processos que norteiam o desenvolvimento de produtos complexos.

Apesar de leve e simples de entender, Scrum é extremamente difícil de dominar, uma vez que envolve rigidez em sua aplicação. Implementações de Scrum que não seguem as regras previstas em seu manual são o que chamamos de Scrum flácido, e tendem a não alcançar o potencial máximo da metodologia.

Mas por que confiar e seguir cegamente este framework?

Scrum é um processo empírico, baseado pura e simplesmente nas experiências passadas de seus criadores que desde o início da década de 90 aplicam Scrum em projetos de software com sucesso, já sendo uma das metodologias ágeis mais usadas no mundo. E uma vez que você se torna adepto do Scrum, o empirismo passa a fazer com que você respeite o processo cada vez mais e adicione novos processos e artefatos complementares baseados nas SUAS experiências com o mesmo.

Os Pilares

O Scrum se baseia em três pilares de sustentação, suas ideologias:

Transparência: aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.

Inspeção: os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas.

Adaptação: se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis ou produto não será inaceitável, o processo ou o material sendo produzido deve ser ajustado.

Existem ainda cinco valores: comprometimento, coragem, respeito, foco e abertura.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos, mas a partir deles, já temos o mínimo de agilidade que você aplicar em qualquer empresa.

Papéis

Os papéis dentro do time Scrum são somente 3, e caso prefira, assista o vídeo abaixo onde falo resumidamente deles.

Product Owner

É o responsável pelo ROI (retorne sobre o investimento) do projeto, é responsável por gerenciar e priorizar o Product Backlog (veja mais abaixo) e para que o Scrum funcione e ele consiga trabalhar, toda a organização deve respeitar as suas decisões. No mundo mais tradicional da gestão de projetos, o P.O. seria o Gerente de Produto (Product Manager), embora em grandes empresas, existam diferenças entre esses dois papéis.

O P.O. é membro do Time Scrum e deve estar presente e disponível para solucionar dúvidas do time em relação ao produto e ao backlog. Se esse papel for assumido por alguém da empresa do cliente, esta pessoa idealmente dever ter um canal de comunicação ininterrupto com o time de desenvolvimento, para que ele possa avançar sem atrasos.

Desenvolvedores

São os responsáveis por desenvolver o produto, independente da atividade necessária para isso. Os desenvolvedores (que não precisa e não deve ser composto apenas por programadores) são auto-gerenciáveis, multifuncionais e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

Os desenvolvedores é que decidem o quanto consegue entregar a cada iteração, para que haja comprometimento com a entrega.

Scrum Master

É o responsável por aplicar e garantir a adoção do Scrum dentro da equipe e até mesmo dentro da organização onde estão inseridos. Cabe ao Scrum Master, que é um líder-servidor, liderar o time para que os objetivos do Product Owner sejam alcançados e para que o time de desenvolvimento consiga avançar sem impedimentos, removendo-os quando necessário.

Geralmente os eventos Scrum são facilitados pelo Scrum Master da equipe no início, até que o time tenha maturidade suficiente para seguir executando o processo sem a sua ajuda.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos com limite de duração. Um evento pode ser encerrado em tempo menor do que o previsto, mas nunca maior, e o Scrum Master deve garantir isso enquanto facilitador dos eventos. Permitir a extrapolação cria um sentimento inconsciente de impunidade e faz com a equipe não respeite os objetivos e o planejamento da Sprint. Por sua vez, falhas constantes em entregar os objetivos de uma Sprint forçarão o time de desenvolvimento em serem mais eficientes no planejamento, focarem mais nos objetivos e se comprometerem de maneira mais coerente com as entregas.

Sprint

As sprints são time-boxes de 1 mês ou menos e são o coração do Scrum. Durante o período da Sprint um incremento utilizável do produto é criado. Mas nem só de desenvolvimento vive a Sprint, fazendo parte da mesma também o planejamento, as reuniões diárias, a revisão e a retrospectiva.

Sprint Planning

Time-box de 8h para uma sprint de um mês, ou menos tempo de acordo com o tamanho da Sprint. Nesta reunião é onde o Product Owner é ouvido em relação às prioridades e os objetivos desta Sprint. É nela também onde o time irá deliberar sobre o que conseguem fazer nesta sprint em relação às necessidades do P.O., formalizando o Sprint Backlog, ou lista de coisas que serão feitas no próximo mês.

É comum o uso de artefatos externos ao Scrum nesta fase, como o Planning Poker, usado para estimar o custo de tarefas a serem realizadas. O ideal é que independente da técnica usada para estimar (pontos de história, por exemplo), que cada tarefa não ocupe um membro do time por mais de um dia. Se isso acontecer, veja como pode quebrar a tarefa grande em tarefas menores.

Outro artefato muito popular, que também não é do Scrum, é o kanban (especialmente usando Trello ou Jira), um board onde temos colunas com cards, onde em cada card temos uma tarefa a ser realizada, previamente estimada. Cada coluna representa um estágio do ciclo de desenvolvimento de uma tarefa, tais como: TODO (para fazer), DOING (fazendo), Testing (testando) e DONE (pronto).

Daily Scrum

Time-box de 15 min que deve acontecer diariamente, de preferência no mesmo local e horário para gerar consistência e evitar perda de tempo. Geralmente em times novos, o Scrum Master facilita esta reunião. Nela, que popularmente é feita em pé (para evitar prolongamentos e distrações), cada Desenvolvedor costuma responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo. Você pode ter outras perguntas e dinâmicas, mas isto é o mais comum.

A reunião diária é o método mais eficaz de alinhamento dos membros do time que tive a oportunidade de experimentar. Ela permite a descoberta rápida de problemas e desvios de curso e suas respectivas correções, por isso deve ser respeitada.

Artefatos possíveis de serem usados (não necessariamente do Scrum) nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas versus tempo da Sprint . Um Burndown Chart sempre visível garante o dia inteiro, todos os dias, que todos sabem o quanto falta para terminarem a sprint, e caso estejam longe do seu objetivo, de resolverem os problemas. A ideia aqui não é analisar o Burndown Chart na reunião diária, que é curta e deve se manter assim, mas apenas acompanhar rapidamente, também de maneira diária, o progresso do time.

Sprint Review

Time-box de 4h para sprints de 1 mês onde o incremento do produto, que está pronto pra uso, é apresentado ao Product Owner (se ele não estava presente no dia a dia do desenvolvimento) e stakeholders, para apreciação. Também é na review (que geralmente é facilitada pelo Scrum Master) que o Product Owner apresentará os números, gráficos e tudo o mais que for importante à equipe saber sobre o produto. Novas prioridades, movimentos do mercado, etc, tudo focado em manter os objetivos coerentes ao longo das sprints.

Sprint Retrospective

Time-box de 3h para sprints de 1 mês onde o Time Scrum fala sobre os resultados obtidos na Sprint que passou e as lições tiradas a partir daí, para melhorar o processo, fortemente arraigado ao pilar de adaptação. Trato em mais detalhes desta importante reunião neste post.

Artefatos

O Scrum determina alguns poucos artefatos:

Product Backlog

Lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. De responsabilidade do Product Owner, que faz a sua gestão a todo momento, o product backlog deve ser mantido longe do dia a dia do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs. Já usei muito, mas atualmente uso só o o Jira.

Todo o trabalho sobre o Product Backlog deve ser feito tendo em mente o Product Goal, que é uma visão de médio prazo, entre os objetivos da sprints (curto prazo) e a visão do produto (longo prazo).

Sprint Backlog

Uma versão reduzida de backlog apenas com os itens que devem ser desenvolvidos nesta Sprint, retirados do backlog original e alinhados em um Sprint Goal (meta da Sprint). Também pode ser organizada em formato de kanban no Trello ou Jira, mas em um board separado do Product Backlog.

Cabe aos desenvolvedores montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade garantir que o Sprint Goal seja alcançado, geralmente associado à conclusão das atividades do Spritn Backlog. Neste processo, o Scrum Master serve como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Incremento

Todas funcionalidades, melhorias e ajustes realizados no software ao longo da sprint atual e que estejam DONE (conforme a Definição de Pronto), quer já tenham sido entregues em produção ou não. Esse é o artefato analisado na Sprint Review.

Conclusões

É isso. O Scrum Guide tem apenas 13 páginas e esse post menos de duas palavras. O Scrum é pequeno, mas difícil de ser posto em prática porque exige muita disciplina. Nos treinamentos que ministro aplico sempre um exercício prático aos alunos para enriquecer a experiência e vivenciar na prática, mesmo que por poucas horas, como funciona o ciclo de desenvolvimento de um produto usando Scrum.

E se quiser saber um pouco mais da minha trajetória com Scrum ao longo da carreira, assiste esse bate-papo aqui.

Boa sorte aplicando o Scrum em sua empresa!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto (banner abaixo)!