Scrum, perguntas e respostas

Por Cesar Brod

Data de Publicação: 31 de outubro de 2007

Meus artigos sobre Scrum, produzidos para o Dicas-L, estão entre os que têm maior "taxa de retorno" nas estatísticas de acesso. Isto motivou uma série de perguntas muito interessantes, que também incentivaram-me a pesquisar mais sobre o assunto. Não havia pensado em retomar este assunto, até que comecei a trocar alguns e-Mails com o Bruno Mello e o Raul Kist, que trabalham comigo no Innovation Center Unicamp/Microsoft, sobre o assunto. Quando percebi, este artigo estava pronto!

Pergunta 1: Para utilizar o Scrum você precisa saber aonde quer chegar. E quando pegamos aqueles clientes que não sabem o que querem e constantemente tiram e colocam as mesmas coisas em um projeto ? Outra pergunta tão inquietante é: como precifica-se um projeto em algo que não sabemos o que vai virar o fim, sem saber direito o tamanho do projeto? (já que prioridades e requisitos são desbravados aos poucos, em fases).

Um projeto novo, sendo interno ou externo, começa com os "user stories", com foco total em quem usará o sistema (ou uma nova funcionalidade dele) a ser desenvolvido. A partir destas "histórias", estima-se o tempo de desenvolvimento e os recursos necessários, que entram no Product Backlog e no Burndown Chart.

A partir do Product Backlog é que estima-se o preço do projeto. Mas aí há uma questão... O Scrum (assim como o XP e metodologias ágeis em geral) são para projetos de curta a média duração. Três meses é o período mágico máximo. Se um projeto durar mais do que três meses, ele deve ser dividido em dois ou mais projetos. Ficando nestes três meses, a precificação e a "visão" do que será feito no período é relativamente fácil. Se passar disto, começa o exercício do "achismo". Em metodologias mais clássicas, independente do tempo que o projeto levará, uma fase extensa de planejamento irá determinar recursos e cronogramas, com o efeito colateral de que a própria fase de planejamento irá adicionar tempo e custos ao projeto, coisas que as metodologias ágeis buscam evitar -- na metodologia ágil, o planejamento e controle não devem ser sobrecarga no projeto. Eu busco resolver isto da seguinte forma: começo, sim, com os "user stories", tratando-os de forma mais ampla, como uma "lista de desejos". Com base também em projetos anteriores (ajuda se eles existirem), estimo o tempo de desenvolvimento e multiplico por dois (sim! e isto é uma recomendação do Fred Brooks, do The Mithycal Man Month). Faço um Product Backlog prévio, que incluirá de forma geral o que irá compor os demais Product Backlogs, e aí precifico. Isto antes de começar o projeto e o primeiro Product Backlog e Burndown Chart. Mas claro que o melhor é sempre manter o projeto no escopo visível de uns poucos meses.

O Burndown Chart simplesmente lista as horas a serem consumidas pelos recursos. Pode ser montado de forma global (prefiro) ou para cada recurso a ser consumido. O ideal é que as horas previstas sejam equivalentes às consumidas. Se as consumidas forem menores, menos mal. Se maiores, o projeto está consumindo recursos além dos que foram propostos. Ele serve, historicamente, para avaliar nossa capacidade de prever os recursos, e como guia para que a ajustemos.

Temos que saber o que vai dar no fim sim, independente de mudanças de prioridades posteriores. O "fim" tem que estar descrito no Product Backlog inicial.

Pergunta 2: O Scrum utitiliza uma teoria de membros auto-gerenciáveis, onde os esforço do ScrumMaster é quase unicamente facilitar e dar subsídios para a equipe (e não necessariamente resolver os problemas existentes). Mas existem aqueles casos em que a equipe, nem por reza brava, entra em acordo. O Scrum tem alguma saída nesse caso, dado que o ScrumMaster não deve gerenciar estas pessoas?

Se for um conflito "técnico", o ScrumMaster resolve, em último caso, ditatorialmente mesmo. Se for algo relativo à funcionalidade, aí é o dono do projeto (patrocinador, pagante) quem decide.

Pergunta 3: O SCRUM leva em consideração equipes que tem contato constante. Mas se isso não for tão ideal? Se os contatos (por horários, por exemplo) não forem tão acopláveis?

O contato "físico" imprescindível são as "stand up meetings", que deveriam ser diárias e com a duração máxima de 15 minutos. Em alguns casos, isto pode ser inviável. Aí vale-se de meios eletrônicos mesmo, como um diário de bordo em que, assincronicamente, um possa verificar e interferir no trabalho do outro. Um "wiki" ou um documento no Google Docs podem ajudar neste sentido. Aí já não é da metodologia, mas da aplicação prática dela. Eu e a Joice trabalhamos, quase sempre, um turno por dia juntos. As "stand-up meetings" ocorrem naturalmente e mais do que uma vez por dia. Por vezes até pensamos em normalizar isto, oficializando um horário, mas como está sendo produtivo assim, mantemos desta forma. Além disso, temos uma "Lista de Tarefas" no Google Docs, acessível por ambos, onde registramos as coisas mais importantes a serem feitas, quer estejamos trabalhando juntos ou separados. Na nossa "lida", essa lista acabou virando um borrão eficaz de um Sprint Backlog. E sempre vale a máxima do Extreme Programming: se a metodologia não couber ao trabalho, adequa-se a metodologia e não o trabalho que está dando certo. Claro que a metodologia ajuda a avaliar se o trabalho está, ou não, dando certo.

Pergunta 4: Em uma empresa que desenvolve projetos internos (para si mesma) e externos (para clientes), cheguei a uma conclusão: Scrum é mais eficiente em projetos internos. Digo isso pois, os riscos de um projeto interno normalmente são menores (nem sempre, admito) mas principalmente porque cliente (própria empresa), ScrumMaster e time de desenvolvimento estão juntos, com contato mais próximo. Estou errado? Até porque um sprint pode não sair se demasiadamente uma atividade depender do cliente, e o cliente resolver sumir por algum tempo.

Quando se adota o Scrum, o cliente deve estar envolvido e estar sempre presente. No mínimo, ao alcance de um e-Mail ou telefone. Não pode "sumir". Por isto deve estar ciente disto. Quanto a funcionar melhor para projetos internos ou externos, acho que não faz diferença, mas isto não com base em minha experiência, mas na documentação de outros autores.

Na semana que vem, vamos falar um pouco mais sobre "User Stories". Abraços ao nosso pessoal dos Microsoft Innovation Centers na UFRGS e Unicamp!