Segue o resumo dos 9 passos para decidir a data de entrega do produto (e seu MVP), baseado na Lean Inception:
- Crie o sequenciador de Funcionalidades
- Selecione duas linhas do sequenciador
- Descreva as tarefas de cada funcionalidade
- Agrupe as tarefas por tamanho
- Decida o tempo cara cada tamanho de tarefa
- Calcule o tempo médio por linha do sequenciador
- Faça o cálculo da capacidade da equipe
- Decida o tempo da Sprint 0
- Mostre as datas e os entregáveis
Esse resumo está descrito em detalhes no livro sobre Lean Inception e neste post, onde respondo uma das perguntas mais recorrentes sobre as Lean Inceptions.
Pergunta: Eu adoro o livro Lean Inception. Mas eu tenho uma pergunta muito importante: meu cliente quer saber quando o MVP e todo o produto estará pronto. Como estimar?
Resposta: Esta é a pergunta de um milhão de dólares. Segue a explicação de como tento ajudar com isso.
Há sempre alguém que quer saber o cronograma, as datas de entrega. E, normalmente, querem saber isso para o MVP e para todas as funcionalidades previstas para o produto (uma contradição, pois sabemos que o produto vai mudar –pivotar– à medida que recebemos e atuamos no feedback de uso do mesmo).
Pivotar, pivotar e pivotar; esse é o lema para quem trabalha com Lean StartUp e MVP
Geralmente eu não converso sobre datas de entrega e estimativa em palestras e no treinamento Lean Inception. Esse assunto gera muita confusão; até mesmo uma certa contradição (como assim? ser ágil e trabalhar com MVP, mas com escopo fechado?!).
O livro Direto ao Ponto tem um capítulo sobre isso (por muito pouco eu não retirei esse capítulo – aliás, outros capítulos saíram do livro, para enxugá-lo… esse ficou, por pouco).
1. Crie o sequenciador de Funcionalidades
Eu uso o Sequenciador de Funcionalidades para essa “estimativa” (não gosto dessa palavra nem das lembranças que ela me traz; sou proponente do movimento NoEstimates). No livro Lean Inception, eu chamo o capítulo que descreve isso de: Calculando esforço, tempo e custo. Em uma Lean Inception, quando necessário, eu uso a seguinte sequência de atividades para ajudar a equipe a decidir sobre as datas.
2. Selecione duas linhas do sequenciador
Para começar, peço à equipe para escolher duas ou três linhas no Sequenciador de Funcionalidades.
3. Descreva as tarefas de cada funcionalidade
Então, eu peço para descreverem todas as tarefas necessárias para completar essas funcionalidades.
Geralmente eu digo isso:
Imagine que completamos uma funcionalidade com a qualidade desejada, com todos os testes necessários, com automação, com os scripts necessários, com os requisitos não funcionais, etc. Vamos escrever todas as tarefas que precisamos fazer para alcançar isso.
A equipe irá escrever as tarefas para cada funcionalidade. Então eu vou usar essas tarefas detalhadas para obter a “estimativa”.
4. Agrupe as tarefas por tamanho
Na sequencia, eu peço para a equipe agrupar as tarefas por tamanho relativo: pequeno, médio e grande.
5. Decida o tempo cara cada tamanho de tarefa
Então, eu pergunto à equipe quanto tempo leva para entregar algumas dessas tarefas. Geralmente, tarefas de um mesmo tamanho relativo levam um tempo parecido (as tarefas foram agrupadas previamente por tamanho relativo, é natural que isso aconteça; é um bom momento para revisar se alguma tarefa deve ser repensada, reescrita e reconsiderada).
Em seguida, peço à equipe para me ajudar a escolher uma duração para cada grupo de tarefas. Por exemplo, as respostas para pequenas tarefas são: 3 horas, 3 horas, 2 horas, 4 horas, 3 horas, 5 horas, 4 horas, 4 horas, 3 horas, 5 horas, 2 horas, 3 horas, 2 horas, 4 horas; Eu vou perguntar se a equipe está confortável considerando uma pequena tarefa levando cerca de 4 horas.
Eu faço o mesmo para cada grupo de tarefas – pequeno, médio e grande.
6. Calcule o tempo médio por linha do sequenciador
Em seguida, somamos a duração de todas as tarefas e depois dividimos por duas (duas linhas no sequenciador de funcionalidades).
Com isso, chegamos a um número. Por exemplo: 200 horas por dev por linha.
Opcionalmente, você pode fazer o cálculo para chegar ao tempo médio para um E (uma funcionalidade tem de um a três Es).
7. Faça o cálculo da capacidade da equipe
Depois eu começo a conversa sobre capacidade da equipe:
Considere a capacidade da equipe: o número de desenvolvedores trabalhando nessas tarefas; se a equipe é dedicada; férias e feriados; licença por doença e percentagem de ausências (por exemplo: percentagem de ausências durante o inverno em Porto Alegre deve ser mais alta do que na primavera, dado a quantidade de gente que tem gripe e resfriado nessa época).
Então eu faço os cálculos e escrevo o resultado, como uma data.
Por exemplo, a equipe tem 4 devs, trabalhando com 80% da capacidade dedicada (férias, feriados e suporte nível 2 para correções de bugs em outro produto)
• 200 horas para 1 dev => 50 horas para 4 devs
• 50 horas a 100% da capacidade => 62,5 horas a 80% da capacidade (50 horas * 100% / 80%)
• Cada linha no sequenciador de funcionalidades deve consumir 62,5 horas para a nossa equipe
8. Decida o tempo da Sprint 0
Converse sobre a Sprint 0 ou quantas Sprints – quanto tempo – a equipe precisa para preparar a infraestrutura mínima dar início ao trabalho funcional, a primeira funcionalidade da linha 1 do sequenciador.
9. Mostre as datas e os entregáveis
Com o tempo da Sprint 0 e o tempo por linha do sequenciador, podemos estimar as datas para os entregáveis. Normalmente, as pessoas que pagam pela construção do produto adoram essa atividade. Eles obtêm uma data para o MVP e podem extrapolar o cálculo para todo o produto (todas as linhas no Sequenciador).
Segue abaixo um exemplo de resultado. Note nesta imagem que a equipe usou a nomenclatura V1 e V2 ao invés de MVP e incremento. note também que a equipe decide manter um par de Devs para as melhorias da V1. Ambas essas decisões tem a ver com o contexto da empresa. E isso é essencial. Siga esses passos, mas adeque a realidade do seu contexto atual.
Entregue o MVP!
Talvez os desenvolvedores fiquem receosos por ter uma data (eu era desenvolvedor e sou um agilista, entendo quem já se queimou por causa de datas e prazos fixos). Mas isso não é ruim para os desenvolvedores. Muito pelo contrário. Eles têm algo para ajudá-los: o MVP com suas funcionalidades.
O ponto é que o resultado do Lean Inception, como descrito no Sequenciador, descreve as funcionalidades do MVP. Mas não detalha como essas serão criadas (as tarefas descritas nesse post, foram usadas apenas para amostragem).
Portanto, a equipe pode (e deve) ser criativa e responsável por entregar o MVP na data prevista. Repensando como entregar as funcionalidades com tarefas mais simples, que requerem menos trabalho, para alcançar o produto mínimo viável.
[content_block id=3005 slug=inception-mvp-e-diretoaoponto]
