Olá pesoal!
Recentemente publiquei um post relacionado às Versões do Scrum e Cronogramas Macros de Projeto apresentado como uma das dificuldades encontradas pelos usuários na adoção do Scrum. Falei um pouco da nossa experiência prática em projetos de nossos clientes, com os quais desenvolvemos um trabalho de capacitação e implantação do Scrum em seus processos de desenvolvimento de software.
Vimos que para atender a essa demanda no Scrum, normalmente após a definição e estimativa do backlog inicial, podemos estimar o tempo restante com base na velocidade definida para a equipe na primeira sprint e elaborar um cronograma com essas estimativas.
Ainda sobre essas estimativas e, descendo um pouco mais no nível de abstração sobre como realizá-las, li há algum tempo um post no blog do Mike Pearce que propõe dois caminhos para estimativas macros de projeto: um baseado em pontos e outro baseado em horas, sendo esse último o que nos interessa, pois está alinhado, de alguma forma, com a abordagem discutida.
Não trabalhamos exatamente dessa maneira, mas caso seja possível adotá-la, achei a proposta bem organizada e interessante.
Muito bem! Tomemos como exemplo a definição e estimativa de um backlog inicial com 240 pontos de histórias. Vamos estimar o tempo do projeto considerando a velocidade da equipe que foi definida para a primeira sprint (20 pontos). Como resultado teremos 12 sprints com base em pontos de história, ou seja, 24 semanas. Evidentemente, trata-se de uma ideia muito aproximada do tempo de duração do projeto, mas nada nos impede de elaborar um cronograma com essas estimativas.
Então, veremos a seguir o passo à passo (adaptado de Mike Pierce), assumindo-se que já existe um backlog ordenado por prioridades e agrupado em sprints :
- Peça a cada membro da equipe para estimar um número máximo e mínimo de horas que eles podem trabalhar por dia no projeto (ex: Wakim: 4 – 5; Diego: 5-6 e Pedro: 6-7). Isto irá funcionar como horas por sprint. Por exemplo, Wakim poderá fazer 40-50 horas por sprint e a equipe de 140-180 horas por sprint;
- Reponha todas as histórias no backlog ordenadas por prioridade;
- Pegue a primeira história e pergunte a equipe: “Podemos fazer essa história em uma sprint?” Se a equipe disser que sim, agrupe-a. Se a equipe discordar se uma história cabe ou não na sprint, assumir que não;
- Em seguida, quebre essa história em tarefas e estime essas tarefas em horas;
- Execute os passos 3 e 4 até que a equipe diga que não cabe mais histórias na sprint com base no número total de horas (somando-se todas as tarefas) e suas horas de trabalho estimadas por sprint (ou seja: 140-180 horas por sprint). Como margem de risco deve-se parar na média de 160 horas;
- Some o número de horas estimadas e agora teremos quantas horas a equipe pode realizar em uma sprint;
- Some os pontos de história para a sprint, e teremos a velocidade da equipe.
Com isso, o gerente do produto pode ter uma estimativa do número mínimo e do número máximo de sprints do projeto estimada em horas (assumindo-se que as sprints têm duas semanas de duração):
- (Total de horas para o projeto) / (menor estimativa horas semanais) = número máximo de sprints
- Ex: 1920h / 140h = 14 sprints (aproximadamente)
- (Total de horas para o projeto) / (superior estimativa horas semanais) = número mínimo de sprints
- Ex: 1920h / 180h = 11 sprints (aproximadamente)
É sempre bom lembrar que os projetos são planejados para semanas, meses ou anos e, em nenhuma das abordagens (tradicional ou ágil) sabemos exatamente o que acontecerá no final. A melhor coisa a fazer é fornecer atualizações contínuas para o gerente do produto.
Depois de ter realizado algumas sprints, teremos uma idéia melhor de velocidade da equipe e devemos rever e re-estimar o backlog, sempre que possível, para manter as estimativas de entrega atualizadas.
E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?
Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.
Encontro vocês num próximo post. Até lá!
