SCRUM, a ordem nascida do Caos - parte 3

Por Cesar Brod

Data de Publicação: 13 de Novembro de 2006

Stephen Covey em seu livro O Oitavo Hábito diz (e muitos concordam com ele, inclusive eu) que a melhor forma de aprender alguma coisa é tentando ensiná-la. Foi por isto que iniciei esta série de artigos sobre SCRUM, lembrando sempre da inspiração inicial do Alexandre Marcondes. Até começar a aprender sobre o SCRUM eu utilizava basicamente o e-Mail 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, chegou a olhar para mim de um jeito "eu te disse!" quando aprendemos que no SCRUM os e-Mails não substituem as reuniões diárias de 15 minutos. Praticamente a partir do início de nossa aprendizagem sobre esta metodologia já começamos a praticá-la, não sem fazer algumas adequações. Neste momento, estamos ampliando a experiência de seu uso também em projetos da Solis.

Uma coisa que chamou-me a 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, onde se define qual será o produto desejado ao final do projeto. A ficha começou a cair quando assisti uma pequena introdução ao SCRUM disponível no portal Scrum for Team System. Nesta apresentação de Ken Schwaber, autor do livro "Agile Project Management with Scrum", ele diz que apesar do 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 isto, para a definição do projeto que deve levar ao "product backlog" inicial, vale o que dizem outras metodologias que explicam melhor como fazer isto. É neste ponto, mais uma vez, que o Extreme Programming casa muito bem com o SCRUM. Em reuniões com o cliente, construa as "user stories" e tudo o mais que for necessário para definição do projeto. Depois, com seu time, comece a dividir a execução do projeto em sprints mensais.

A prática e muitas leituras ensinaram-me que um projeto é bem controlável se ele dura até três meses. Caso dure mais do que três meses, é melhor dividí-lo em mais projetos (ou em fases que durem até três meses). Como cada sprint dura um mês, ao final de cada três sprints podemos concluir cada projeto (ou suas fases). As ferramentas que o SCRUM recomenda, porém, não servem só para controlar projetos bem definidos e delimitados, mas até tarefas constantes e diárias. Isto deve tornar-se mais evidente quando mais adiante falarmos sobre as reuniões diárias e, no próximo artigo, exemplificarmos algumas planilhas de controle e acompanhamento de projetos.

O SCRUM começa a ser aplicado no product backlog, que irá traduzir em uma planilha que define as prioridades, a descrição breve e genérica de cada tarefa a ser executada, quem as executará e a estimativa de tempos. O product backlog pode ser alimentado a partir das user stories do Extreme Programming (para um exemplo de product backlog, veja o artigo anterior. Com isto em mãos, parte-se para a primeira reunião de planejamento do sprint.

Cada sprint deve ter um "tema" que identifique as principais tarefas que nele serão executadas. "Acompanhamento de pedidos através da web" foi o exemplo que utilizamos no artigo passado. A reunião de planejamento deve contar com a presença do patrocinador do produto, da equipe scrum, dos gestores de projeto e do cliente ou usuários do produto que está sendo desenvolvido. Nesta reunião serão discutidos e avaliados o que já está disponível (se esta é a primeira reunião, muito pouco ou nada), quais as capacidades da equipe e o que cada pessoa estará fazendo, tecnologias adotadas e quais os pontos do product backlog serão atendidos. O resultado da reunião será o objetivo do sprint (o que será produzido) e o sprint backlog (a lista de tarefas específicas deste sprint). Esta reunião pode ter um tempo de preparação, com o gestor de projeto (ScrumMaster) fazendo perguntas aos integrantes, buscando saber de suas necessidades e habilidades.

A partir daí, ocorrem reuniões diárias, extremamente curtas (entre 15 minutos e meia-hora, sempre buscando chegar mais perto dos 15 minutos), onde são feitas as seguintes perguntas para cada membro do time:

1. O que você fez ontem?
2. O que você fará hoje?
3. Quais os obstáculos que impedem (ou podem impedir) seu trabalho?

Caberá ao ScrumMaster (não se preocupe, falaremos mais sobre o ScrumMaster em outro artigo) remover estes obstáculos. Esta reunião deve ser presencial e não pode ser substituída por uma lista de discussões ou outra forma de encontro (ainda que eu não tenha encontrado nada sobre isto, creio que na absoluta impossibilidade de um encontro real, algum método de interação em tempo real - videoconferência, por exemplo - é aceitável). A idéia de reuniões diárias vem de nosso amigo Frederick Brooks (lembram do primeiro artigo desta série?). Em seu livro "The Mythical Man Month" ele dizia que os projetos deviam ser conduzidos "um dia de cada vez". Através das 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 acima (isto fecha também com a idéia de equipes pequenas. Imagine uma reunião poder durar 15 minutos com mais de cinco ou dez pessoas). Além disto, a presença ajuda a criar a pressão do compromisso de cada um fazer o que se comprometeu a fazer para todo o sprint e todos os dias. Reuniões diárias e curtas acabam por tornar desnecessá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 patrocinador do produto qual a interpretação deles de determinada tarefa ou função.

No próximo capítulo começaremos a exercitar o SCRUM em um projeto real, criando para ele um Product Backlog.