Até começar a aprender sobre o Scrum, eu utilizava basicamente o email para minha organização diária. Era um método que funcionava bem para mim, mas que, sou obrigado a reconhecer, pode não ser o ideal para todos. Minha sócia e colega de vários projetos, a Joice Käfer Marrero, chegou a olhar para mim de um jeito “eu te disse!” quando aprendemos que, no Scrum, os emails não substituem as reuniões diárias e rápidas, com o máximo de 90 segundos para cada membro da equipe.
Uma coisa que me chamou atenção no Scrum é que há uma série de práticas recomendadas para reuniões, mas não encontrei muita coisa sobre o que seria a reunião inicial, em que se define qual será o produto desejado ao final do projeto. A ficha começou a cair quando assisti a uma pequena introdução ao Scrum feita por Ken Schwaber. Nela, o autor do livro Agile Project management with Scrum e, junto com Jeff Sutherland, criador do Scrum, diz que, apesar de o Scrum ser muitas vezes chamado de “metodologia”, na verdade, ele não o considera como tal. Uma metodologia deveria dizer “o que fazer”. Comparado a um esporte ou a um jogo, o Scrum é um conjunto de regras para eles. Por isso, para a definição do projeto que deve levar ao Product Backlog inicial, vale o que dizem outras metodologias que explicam melhor como fazer isso. É nesse ponto, mais uma vez, que o Extreme Programming casa muito bem com o Scrum. Em reuniões com o cliente e potenciais usuários, é responsabilidade do Product Owner construir, em conjunto com eles, histórias de uso e tudo mais que for necessário para definição do projeto e suas principais versões. Depois, junto com seu time de desenvolvimento, a execução do projeto é dividida em Sprints. Na Parte II deste livro, trabalharemos técnicas de construção de um Product Backlog incluindo, dentre outras, o uso de mapas mentais.
A prática e muitas leituras me ensinaram que um projeto é bem controlável se ele durar até três meses. Caso dure mais do que três meses, é melhor dividi-lo em mais projetos (ou em fases, versões entregues em até três meses). Cada Sprint poderia, por exemplo, durar quatro semanas. Assim, ao final de cada três Sprints, podemos concluir cada projeto (ou uma de suas versões, por exemplo). As ferramentas que o Scrum recomenda, porém, não servem somente para controlar projetos bem definidos e delimitados, mas também tarefas constantes e diárias. Isso deve se tornar mais evidente quando falarmos, logo a seguir, sobre as reuniões diárias.
O Scrum começa a ser aplicado no Product Backlog, que traduzirá, em uma lista priorizada, as histórias que irão compor o produto e uma primeira estimativa do esforço para o seu desenvolvimento. Com isso em mãos, parte-se para a primeira reunião de planejamento do Sprint.
Cada Sprint deve ter um “tema” que reflita as principais histórias que serão desenvolvidas nele. “Integração com redes sociais” foi o tema da primeira versão do aplicativo web GiftWizz.com. A reunião de planejamento do Sprint deve contar com a presença obrigatória do Product Owner e da equipe Scrum. O Product Owner pode decidir convidar o cliente, principais patrocinadores e usuários do produto que está sendo desenvolvido. Nessa reunião, serão discutidos e avaliados o que já está disponível (se essa for a primeira reunião, muito pouco ou nada), quais as capacidades da equipe e o que cada pessoa fará, tecnologias adotadas e quais pontos do Product Backlog que serão atendidos, dentro da sua priorização. O resultado da reunião será o objetivo do Sprint (o que será produzido) e o Sprint Backlog (a lista de histórias específicas deste Sprint). É importante salientar que a decisão final sobre quais histórias irão compor o Sprint Backlog é da equipe de desenvolvimento.
Com o Sprint em andamento, acontecem as reuniões diárias, extremamente curtas (no máximo 90 segundos por participante e 15 minutos no total), em que são feitas as seguintes perguntas para cada membro do time:
- O que você fez ontem (que contribuiu para as entregas do Sprint)?
- O que você fará hoje (que contribuirá para as entregas do Sprint)?
- Quais os obstáculos que impedem (ou podem impedir) seu trabalho?
Caberá ao Scrummaster remover esses obstáculos. Essa reunião deve ser presencial e não pode ser substituída por uma lista de discussões ou outra forma de encontro (na absoluta impossibilidade de reuniões locais, algum método de interação em tempo real – videoconferência, por exemplo – é aceitável).
A ideia de reuniões diárias vem de nosso amigo Fred Brooks Jr. Em seu livro O mítico homem-mês ele diz que os projetos devem ser conduzidos “um dia de cada vez”. Por meio de reuniões diárias, todos os membros da equipe têm acesso ao cenário completo do estado do desenvolvimento, ao ouvir seus pares responderem às três perguntas anteriores (isso fecha também com a ideia de equipes pequenas: imagine como a duração dessa reunião aumentaria com mais de nove pessoas!). Além disso, a presença ajuda a criar a pressão do compromisso em cada um em fazer o que se comprometeu a fazer para todo o Sprint, todos os dias. Reuniões diárias e curtas acabam por tornar desnecessárias várias outras reuniões.
Outro aspecto importante das reuniões diárias é que elas não são destinadas à solução de problemas. Como não existe hierarquia entre os membros de um time Scrum, cada pessoa deve procurar resolver os problemas entre seus pares, acessando-os diretamente. Assim, se um desenvolvedor tem alguma dúvida sobre como implementar um determinado recurso, ele não precisa passar pelo Scrummaster ou qualquer outra pessoa: deve perguntar diretamente ao usuário, cliente ou ao Product Owner qual a interpretação deles para determinada história, tarefa ou função.
