SCRUM, a ordem nascida do Caos - parte 2

Por Cesar Brod

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

Previously, on Lost! Tirando quem acaba de voltar de uma longa viagem fora do sistema solar, todos os demais já assistiram ou ao menos ouviram falar do seriado Lost. É a história dos sobreviventes de um desastre aéreo que acabam em uma ilha não exatamente deserta. Sempre que parece que a ordem é estabelecida alguma surpresa acontece. O personagem John Locke - que casualmente, ou não, tem nome de filósofo - é o ScrumMaster da ilha. Ainda na primeira temporada, com o ataque surpresa de javalis, o homem teve a idéia de caçar e carnear os bichos. No seriado isto não é explícito, mas é evidente que Locke é gaúcho!

Quem já trabalhou em qualquer projeto em que a especificação resultou em algo que era exatamente o que o cliente queria, parabéns! Na maioria dos casos isto não acontece. Não por culpa do cliente, mas porque os projetos são desenvolvidos ao longo de um tempo onde as necessidades podem mudar e a própria interação entre a equipe de desenvolvimento e o cliente pode mostrar que existem soluções melhores do que as que foram pensadas inicialmente - e é um erro ater-se a especificações iniciais quando uma possibilidade melhor, mais simples ou mais econômica de atender o problema aparece. As metodologias ágeis levam isto em conta. Tudo muda a todo o tempo! É o caos! Como colocar ordem neste caos? No princípio era o caos, diz a bíblia, mas em seis dias o criador deu um jeito e ainda descansou no sétimo. Deus também é ScrumMaster certificado.

No primeiro artigo desta série falamos sobre o livro The New Product Development Game, de Hirotaka Takeuchi e Ikujiro Nonaka. Outros nomes estão envolvidos na conceituação e desenvolvimento da metodologia, dentre eles Peter DeGrace e Leslie Hulet Stahl, autores de Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms (onde o termo SCRUM foi especificamente associado a software). Jeff Sutherland, Ken Schwaber e Mike Beedle são outros nomes pelos quais você pode procurar no Google se quiser aprofundar seu conhecimento no assunto.

O SCRUM é um método de trabalho para equipes pequenas e tempos curtos de desenvolvimento de projeto. Você trabalha com uma grande equipe e projetos que duram anos? Sem problemas, divida as pessoas em equipes menores (entre cinco e dez pessoas) e seu projeto em subprojetos. O SCRUM trabalha com o conceito de "sprints", que é o progresso do projeto no período de um mês. Os requerimentos dos projetos são trabalhados em uma lista de tarefas a serem cumpridas (product backlog). As reuniões com as pessoas da equipe são diárias e não devem durar mais do que quinze minutos. Nelas são discutidas o acompanhamento das tarefas (product backlog) e, preferencialmente, cada tarefa deve ser realizada dentro de um dia (se levar mais de um dia, deve ser dividida em mais tarefas). Isto se faz para manter as coisas o mais simples possíveis. Quando aumenta a complexidade, aumentam as dúvidas e o ruído na comunicação, o que atrasa o projeto e arrisca os resultados finais. O coordenador geral do projeto é o ScrumMaster, responsável por garantir a aplicação da metodologia e atuar como o representante do "cliente do projeto" quando ele não está presente. A principal tarefa do ScrumMaster, porém, é a de remover obstáculos, independente de sua natureza.

Uma equipe SCRUM terá membros com especialidades variadas, de acordo com a necessidade do projeto. Todos trabalham na equipe em tempo integral (talvez com a exceção do ScrumMaster, que pode estar coordenando mais de uma equipe, ou membros que executem tarefas acessórias ao time mas que devam estar comprometidas com o projeto). Os membros da equipe discutem entre si e se auto-gerenciam. Não há níveis hierárquicos dentro de uma equipe. Durante cada sprint (o período de um mês de projeto) os membros não serão trocados.

A principal razão de se dividir as entregas de um projeto em sprints mensais é justamente a questão de manter-se o controle sobre as surpresas. Dentro de um período de um mês, uma parte do sistema será projetada, codificada, testada e entregue ao cliente. Neste período não serão admitidas mudanças de requisitos, pois isto ampliaria o tempo de desenvolvimento. Ao final do sprint, porém, podem ser revistos os requisitos e uma nova lista de tarefas pode ser criada para a adequação do produto dentro de um novo sprint. Isto tende a fazer com que os requisitos passem a ser cada vez melhor definidos e a codificação para o atendimento dos mesmos cada vez mais refinada. As partes acabam chegando em acordos de requisitos mínimos e imutáveis, com os quais todos se comprometem pelo período de um mês.

A lista de tarefas (product backlog) é a lista de tudo o que é necessário no projeto (independente do número de sprints que o irá compor). Ela deve contemplar o que no Extreme Programming chamamos de User Stories (se não lembra disto, volte ao artigo sobre este assunto). Se no Extreme Programming dissemos que as User Stories eram Use Cases "diet", na lista de tarefas elas são ainda mais enxutas. Na medida do possível, os itens da lista devem contemplar o que o cliente (ou o usuário) deseja junto com as tarefas necessárias para atender estes desejos, de forma bastante sintética. As tarefas são priorizadas de acordo com o que o patrocinador (aquele que está "pagando" pelo produto) deseja. Isso deve ser feito da forma mais simples possível, permitindo a busca textual por tarefas, em um documento que possa ser acessado e alterado por todos os membros do projeto. Desde um quadro branco até um wiki ou planilha servem para isto. Clicando aqui você encontra um pouco mais de informações e um exemplo bem simples de uma lista de tarefas. O importante é que esta lista seja clara para você e para os membros de sua equipe. A forma como ela é implementada não interessa.

Com o Product Backlog em mãos, agora o mesmo será subdividido em Sprint Backlogs. Como você já imaginou, o Sprint Backlog são listas de tarefas que ocorrerão dentro de cada sprint, para uma determinada equipe. Nada impede que você subdivida as tarefas entre equipes distintas e tenha sprints diversos ocorrendo simultaneamente. Com o Product Backlog devidamente priorizado, busque subdividí-lo em temas que darão nome aos sprints. Imagine que você está montando um portal dinâmico para a sua empresa. Uma das tarefas é a disponibilização de um serviço de acompanhamento de pedidos para os clientes da empresa. O sistema já existe mas os clientes só podem acessá-lo através do telefone. Este sprint pode se chamar "Acompanhamento de pedidos através da web". Sua lista de tarefas incluirá o design da interface para o cliente, a conexão com o sistema ou a base de dados existente para o acompanhamento, testes, documentação e o que mais for necessário. Estas decisões são tomadas na reunião de planejamento do sprint, com a presença da equipe scrum, do ScrumMaster, o patrocinador do cliente, representantes dos usuários e gestores envolvidos no processo. Em sua apresentação An Overview of Scrum a Mountain Goat Software apresenta exemplos do Product Backlog, Sprint Backlog e dá boas dicas sobre a reunião de planejamento do sprint. Melhor ainda, a empresa permite que a apresentação seja usada e modificada livremente por qualquer interessado, desde que seja mantida a referência de autoria.

Na próxima semana, dentre outras coisas, falaremos sobre as reuniões diárias e o porquê delas não poderem ser substituídas por e-Mails.