Scrum, uma metodologia ágil

Scrum, muito simples de usar

A metodologia Scrum está entrando na moda aqui no Brasil, após já haver conquistado inúmeras empresas da indústria de software na América do Norte.

O Scrum é uma proposta extremamente prática e honesta. Prática pela facilidade de compreensão e aplicação em nosso ambiente de desenvolvimento de software. Honesta pela fidelidade entre a proposta do método e o resultado que podemos obter após aplicá-lo.

Scrum, nome utilizado inicialmente pelos japoneses Hirotaka Takeuchi e Ikujiro Nonaka, descrevia um tipo de processo de desenvolvimento de produto utilizado no Japão. Também o nome Scrum foi escolhido pela similaridade entre o jogo de Rugby e o tipo de desenvolvimento de produto comentado. Ambos são adaptativos, rápidos e promovem a auto-organização.

A seguir é apresentada uma estratégia que foi usada pelo Ken Schwaber em seu livro chamado Agile Project Development with SCRUM.

Iniciando um projeto, há uma formalização de todas as coisas que se pretende fazer ou que se precisa construir no projeto. Cada item desta lista representa um requisito funcional, um requisito não funcional, ou uma questão de tecnologia / infra-estrutura. Esta lista é denominada Product Backlog.

Podemos traduzir Product Backlog como uma lista de todos os requisitos de um produto priorizados, ou, em outras palavras, é qualquer coisa que represente um trabalho que precisa ser feito para o produto. Os itens com maior prioridade nesta lista são os requisitos mais desejados pelo produto. No projeto real, o Product Backlog nunca é finalizado. Existe uma natural evolução e maturidade dos requisitos nesta lista. Requisitos novos podem aparecer, requisitos existentes podem perder prioridade e podem até serem eliminados. Apesar de se permitir que áreas usuárias manifestem seus pedidos nesta lista, somente o Product Owner pode priorizar o Backlog.

Product Owner possui a responsabilidade de definir a ordem que os requisitos serão produzidos pela equipe de desenvolvimento. Esta equipe deve ser pequena, multi-disciplinar e capaz de desenvolver todos os requisitos. Esta equipe recebe o nome de Scrum Team. A preparação dos trabalhos é denominada Sprint Planning.

Sprint Planning é composta dos seguintes itens: o Product Backlog, a capacidade de desenvolvimento da equipe, as condições e as exigências do negócio, as características da tecnologia a ser usada e o comprometimento em entregar produtos executáveis incrementais. A mistura disto é forma revisões, administração e organização. Os resultados são Sprint Goal e Sprint.

O Scrum Team deve desenvolver os itens separados pelo Product Owner em um determinado prazo previamente combinado. Este prazo é definido como Time Box e o trabalho de desenvolver os itens separados neste time box é denominado Sprint. Estes itens separados do Product Backlog fazem parte de uma nova lista. Esta lista, chamada Sprint Backlog, será de total responsabilidade do Scrum Team, que deverá mantê-la e organizá-la de tal forma a atender os objetivos do Sprint específico.

É permitido ter mais de um Scrum Team trabalhando no mesmo Product Backlog, por isso os requisitos são devidamente separados em Sprint Backlogs distintos por equipe. Uma idéia deste ciclo é verificada na imagem abaixo.

Ciclo demonstrando Sprint

A liderança destas equipes é exercida por um papel denominado Scrum Master. O Scrum Master é um facilitador da gestão dos requisitos e direcionador da gestão das equipes. Este papel deve garantir a correta utilização das práticas de Scrum, deve ajudar a equipe a tomar decisões e apoiar a equipe para adquirir os recursos necessários para o desenvolvimento do produto.

Este método de liderança é exercido através de 3 recorrentes tipos de reunião: Scrum Daily Meeting, Sprint Review e Retrospective. Começando pelo Sprint Review que é a reunião típica de final de Sprint (alguns Scrum Teams também a fazem no meio do Sprint) para validar o produto executável que a equipe conseguiu incrementar.

Explicando a Retrospective: é uma reunião que também acontece ao final do Sprint com o objetivo de fortalecer a unidade de ação da equipe. Três perguntas deverão ser respondidas com seriedade por todos os membros do Scrum Team:

1- O que você fez e gostou neste sprint?
2- O que você fez e não gostou neste sprint?
3- O que você vai fazer diferente no próximo sprint?

O desenvolvimento de projetos de software é um desafio constante, é uma atividade complexa. Todo processo complexo exige uma intensa comunicação entre todos os membros do projeto. Então o Scrum Daily Meeting é a resposta para promover a comunicação da equipe.

Todos os dias, obrigatoriamente, todo o Scrum Team irá se reunir por 15 minutos aproximadamente para responder a 3 importantes perguntas.

As perguntas são:
1- O que eu fiz desde a última Scrum Daily Meeting até agora?
2- O que eu vou fazer hoje?
3- O que pode me impedir?

Adicionalmente às técnicas apresentadas neste texto, a utilização de Kanban (ver figura abaixo) ajuda a maximizar o compromentimento da equipe e a comunicação de todos os comprometidos e envolvidos com o projeto.

Exemplo de implementação de Kanban. As cores amarela e laranja representam diferentes complexidades das atividades. A cor rosa representa atividades não planejadas no Sprint que foram incluídas por motivo de força maior.

Para saber mais, é recomendável ler os livros:
- Agile Project Management, de Jim Highsmith;
- Agile Software Development with SCRUM, de Ken Schwaber e Mike Beedle;
- Agile Project Management with SCRUM, de Ken Schwaber;
- Treinamento MSF Agile + Scrum + Agile Methods em http://www.fcamara.com.br.

Considerações Finais

Todos os projetos são diferentes. A tecnologia destes projetos são diferentes. As pessoas, os requisitos são diferentes.

Na grande maioria das consultorias para fins de crescimento dos resultados qualitativos e produtivos de equipes de desenvolvimento de software, encontram-se pessoas que utilizando-se de métodos tradicionais ou simplesmente de improviso diário (também denominado "ausência de métodos") revelam uma estranha e frustante sensação, a Síndrome do Trabalho Vazio.

A STV é a sensação que ocorre depois de um intenso dia de trabalho repleto de aborrecimentos e de atividades urgentes, e quando percebe-se que no final todas as atividades planejadas para aquele dia não puderam ser implementadas. É uma constatação que se é uma espécie de marionete do tempo, da empresa e dos clientes.

A utilização de métodos ágeis, com a adequação mental conforme os princípios estabelecidos pelas metodologias ágeis, mudam a vida profissional perante o cenário anteriormente descrito. É possível conseguir fazer atividades planejadas, priorizar atividades importantes e ter um pequeno índice de atividades urgentes no dia-a-dia. Dá para ser protagonista do próprio dia.

As metodologias ágeis são uma positiva proposta para as empresas desgastadas com os resultados proporcionados por "waterfall approach to software development" ou pela ausência de métodos. Para iniciantes em metodologias ágeis, é recomendável o Scrum. Para praticantes de métodos ágeis que não conhecem o Scrum, permitam-se mais uma evolução.