Treinamento Scrum em um post

Conheço e aplico métodos ágeis há pelo menos 6 anos, 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 post de hoje resumo o famoso Scrum Guide, o livro de apenas 19 páginas que detalha tudo o que você precisa saber sobre o Scrum antes de passar a aplicá-lo em seu time de produto. No fim do post você encontra os slides do treinamento que aplico, disponíveis no Slideshare. Caso queira saber mais sobre o meu trabalho com Scrum, dê uma olhada em meu livro.

rugby-scrum

O que é Scrum?

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

Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível.

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.

Sobre estes pilares o framework Scrum divide-se em papéis, eventos e artefatos.

Papéis

Os papéis dentro do time Scrum são:

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).

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. O time de desenvolvedores (que não precisa e não deve ser composto apenas por desenvolvedores) é auto-gerenciável, multifuncional e compartilham a responsabilidade pelo sucesso ou fracasso do projeto.

O time de desenvolvimento é quem decide 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.

Todos os eventos Scrum são facilitados pelo Scrum Master da equipe, que idealmente não deve ter outra função paralela no time Scrum.

Eventos

O Scrum chama seus eventos de time-boxes, uma vez que são eventos de duração fechada. 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-boxe 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 função, 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.

planningpoker

Outro artefato muito popular também é o kanban (especialmente usando Trello), 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).

kanban-board-e60650d1-1

Daily Scrum

Time-boxe de 15 min que deve acontecer diariamente, sempre no mesmo local e horário para gerar consistência e evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e que popularmente é feita em pé (para evitar prolongamentos e distrações), cada membro do time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo me impedindo.

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.

burndown-chart-formula

Artefatos passíveis de serem usados nessas reuniões incluem um Burndown Chart, que nada mais é do que um gráfico de features a serem desenvolvidas (eixo y, vertical) versus tempo da Sprint (eixo x, horizontal). O gráfico começa no alto do eixo y (ou seja, faltam todas features) e no ponto 0 do eixo x (ou seja, ainda tem todo o tempo da sprint sobrando) e deve ser atualizado diariamente com o progresso do time. 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.

Esse evento é um dos que representam o pilar de inspeção do Scrum.

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 para apreciação. Também é na review (que deve ser 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.

Essa é o evento que melhor representa o pilar de inspeção do Scrum.

Sprint Retrospective

Time-box e 3h para sprints de 1 mês onde o time de desenvolvedores e o Scrum Master (que atua apenas como facilitador) falam 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. Gerenciado única e exclusivamente pelo Product Owner, que o faz a todo momento, o product backlog deve ser mantido longe do time de desenvolvimento, para evitar dispersão.

Muitas empresas tem usado a ferramenta Trello para seus products backlogs.

project-management-trello

Sprint Backlog

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

Cabe ao time de desenvolvimento montar o Sprint Backlog com base nas prioridades do Product Owner e é sua responsabilidade dar cabo de todos itens até o fim da sprint, servindo o Scrum Master como um facilitador para que nada interrompa o ciclo de desenvolvimento.

Conclusões

É isso. O Scrum Guide tem apenas 19 páginas e esse post umas 2000 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. Não encontrei uma boa maneira de colocar o exercício aqui, mas se puder filmar da próxima vez que aplicar o treinamento, vou incluir o vídeo 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 clicando no banner abaixo pra aprender muito mais!

O que achou desse artigo?
[Total: 1 Média: 5]