Esse tal Scrum

Quem não conhece nem nunca ouviu falar de Scrum deve ter ficado ausente de todas as discussões sobre desenvolvimento de software nos últimos 10 anos. O nome Scrum é uma referência a uma jogada no rugby,  onde os times se juntam para alcançar um objetivo. O Scrum foi concebido em 1995 por Jeff Sutherland e Ken Schwaber. O Jeff inclusive escreveu o livro Scrum: A Arte de fazer o dobro do trabalho na metade do tempo, leitura obrigatória para todos que trabalham ou querem trabalhar com Scrum.

No livro ele cita os muitos problemas do método tradicional de desenvolver software, onde investimos muito tempo planejando cada detalhe de maneira que tudo pareça perfeito, mas na prática, enfrentamos inúmeros desafios que torna muito difícil senão impossível seguir aquele plano. Ele aponta o que todos nós sabemos, ou deveríamos saber, que a mudança é inevitável, então o melhor que podemos fazer é estarmos preparados para ela e adaptarmos nosso trabalho para que ela aconteça e seja bem vinda.

Sabe o PDCA? Pois é, no Scrum nós Planejamos (Plan), Fazemos (Do), Agimos (Act)  e Verificamos os resultados (Check) e o mais importante, fazemos isso regularmente garantindo que estamos sempre melhorando. Quando encontramos um erro já o corrigimos imediatamente, não é necessário, nem inteligente, esperar até nada dar certo pra ver que precisamos corrigir os erros, isso só vai agravar os erros tornando-os mais difíceis de serem corrigidos.

Os times Scrum são enxutos porém completos, tendo todos os perfis necessários para realizar uma entrega. Esse time deve ser motivado e ter autonomia para trabalhar eficazmente por um objetivo. E para termos um time assim tão motivado e eficaz, precisamos garantir que ele tenha plena capacidade de exercer suas habilidades, isso significa que não dá pra exaurir todo mundo com longas jornadas de trabalho acrescidas de horas e mais horas extras. Trabalhar além da conta nos induz a cometer erros, e erros geram retrabalho, diminuindo a produtividade do time. Lembrando que muitas vezes o trabalho excessivo ocorre devido ao mal planejamento e a definição de metas irreais. No Scrum devemos ter objetivos desafiadores, porém não impossíveis.

A grande sacada é manter um fluxo continuo e funcional. Uma forma de ter esse fluxo saudável e cumprir as metas sem horas extras é refletir sobre tudo que se faz desnecessariamente, quantos documentos, reuniões, e-mails ou procedimentos inúteis estamos produzindo. Vamos planejar apenas o que é necessário e mudar sempre que for preciso, sem apego. Por isso a priorização é tão importante em um time Scrum, uma coisa nova que tenha mais valor pode entrar no lugar daquilo que estava planejado sem problema nenhum, desde que ela exija o mesmo esforço para ser realizada.

E pra organizar todo o trabalho o Scrum conta com algumas caixas de tempo fixas que usualmente chamamos de time boxes. Abaixo teremos as principais time boxes do Scrum e um breve resumo de cada uma.

Sprint

Sprint é um período pré determinado que vai de uma a quatro semanas, sendo mais comumente utilizado o período de duas semanas, onde o trabalho é realizado visando atender uma meta. O tamanho da Sprint deve ser estabelecido e respeitado, sendo possível modificá-lo apenas para uma nova Sprint, ou seja, não tem como incluir uns dias a mais na Sprint para cumprir uma meta, pois ela já não deu certo.

Planning

A primeira atividade da Sprint é o planejamento dela, nessa reunião que deve ter duração de até 5% do tempo total da Sprint, é onde a meta deve ficar clara para todo o time, que fará a discussão técnica e realizará a estimativa de cada item que será trabalhado na Sprint.

Daily

É o momento de comunicação entre o time. Essa reunião deve ocorrer diariamente sempre no mesmo horário e local, para que todos saibam onde e quando ela vai acontecer sem precisar de nenhum convite especial. A duração não deve ultrapassar os 15 minutos e, por isso, pode ser realizada em pé. Na daily, cada membro do time fala sucintamente sobre o que realizou no dia anterior, o que realizará hoje e se há algum impedimento, sendo que todas essas questões devem ser respondidas  pensando sempre no objetivo da Sprint. Uma boa daily normalmente acontece na frente de um quadro contendo todas as tarefas do time, onde todos possam ver como está o andamento da Sprint.

Review

É o momento em que mostramos o resultado da Sprint, a ideia aqui é mostrar a coisa funcionando mesmo e não um conjunto de slides com prints de tela. Vamos ficar atentos ao manifesto ágil e entregar software em funcionamento. A Review ou Reunião de Demonstração deve ser objetiva, tendo a duração de até 2,5 % do tempo total da Sprint.

Retrospectiva

É o último time box da Sprint, é nesse momento que vai acontecer a reflexão sobre tudo o que aconteceu de bom ou de ruim numa Sprint e as ideias de como podemos melhorar para a próxima. É um dos momentos mais importantes do time, pois é através da reflexão constante que corrigimos os erros e evoluímos. O tempo de duração ideal desta cerimônia é entre 2,5 e 5% da Sprint.

Todos esses time boxes, assim como os papéis existentes no Scrum, serão detalhados em posts futuros aqui no blog. Além disso, no livro encontramos muito mais detalhes sobre tudo que falamos aqui, e também outros conceitos e exemplos bem bacanas sobre aplicação de Scrum, então recomendo fortemente a leitura dele. Também recomendo a leitura do Scrum Guide, onde há todas as informações necessárias para se trabalhar com Scrum de maneira satisfatória.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s