Lean Product Development - Guiando a Construção do MVP com Scrum e Kanban

Prévia do material em texto

Lean Product Development:
Guiando a Construção do MVP
com Scrum e Kanban
Paulo Caroli
This book is for sale at http://leanpub.com/lean-delivery
This version was published on 2019-11-13
This is a Leanpub book. Leanpub empowers authors and
publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.
© 2019 Paulo Caroli
http://leanpub.com/lean-delivery
http://leanpub.com/
http://leanpub.com/manifesto
Contents
Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . i
Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . ii
Sobre esse e-Book . . . . . . . . . . . . . . . . . . . . . . . . iii
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
A série Lean Strategy . . . . . . . . . . . . . . . . . . . . iv
O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 1
Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Lean Inception . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Conhecimento, relacionamento e comprometimento . . . 8
Calculando esforço, tempo e custo . . . . . . . . . . . . . . 12
O sequenciador . . . . . . . . . . . . . . . . . . . . . . . . 12
Template do sequenciador . . . . . . . . . . . . . . . . . . 14
As regras do sequenciador . . . . . . . . . . . . . . . . . . 15
Detalhando a amostra de funcionalidades em tarefas . . 16
Dimensionamento de tarefas . . . . . . . . . . . . . . . . 19
Entendendo custo e tempo . . . . . . . . . . . . . . . . . 21
Tirando a média . . . . . . . . . . . . . . . . . . . . . . . 22
CONTENTS
Somente Devs estimam? . . . . . . . . . . . . . . . . . . . . 27
Estimativa cascata ou ágil . . . . . . . . . . . . . . . . . . . 28
Time multi-funcional . . . . . . . . . . . . . . . . . . . . 29
Teste Antes, valide depois . . . . . . . . . . . . . . . . . . . 31
Puxe, não Empurre . . . . . . . . . . . . . . . . . . . . . . . . 33
Escopo funcional do MVP . . . . . . . . . . . . . . . . . . . 34
MVPs são pequenos . . . . . . . . . . . . . . . . . . . . . 37
MVP e o Fluxo de trabalho . . . . . . . . . . . . . . . . . 37
Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 38
Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
O MVP nas cerimônias do Scrum . . . . . . . . . . . . . . 42
Construindo MVP com Kanban . . . . . . . . . . . . . . . . 44
Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
O MVP no Kanban . . . . . . . . . . . . . . . . . . . . . . 47
MVP, Kanban e bugs . . . . . . . . . . . . . . . . . . . . . . . 57
Capacidade para lidar com os bugs . . . . . . . . . . . . . 58
Radar de Débito Técnico . . . . . . . . . . . . . . . . . . . . 60
Acompanhamento Lean . . . . . . . . . . . . . . . . . . . . . 63
O entendimento da iniciativa via MVP . . . . . . . . . . 63
O planejamento do produto e seus MVPs . . . . . . . . . 64
O acompanhamento da criação do produto via MVP . . 66
Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 70
Nome do time e ID do MVP . . . . . . . . . . . . . . . . . 71
Nome do MVP . . . . . . . . . . . . . . . . . . . . . . . . 71
Estado atual . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Data atual e data prevista . . . . . . . . . . . . . . . . . . 71
Lista de features do MVP . . . . . . . . . . . . . . . . . . 71
CONTENTS
Nível de incerteza da funcionalidade . . . . . . . . . . . . 72
Estado e % de completude da funcionalidade . . . . . . . 72
Detalhamento e texto descritivo . . . . . . . . . . . . . . 73
Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 74
Os eixos do burn up . . . . . . . . . . . . . . . . . . . . . 76
O ritmo da construção do MVP . . . . . . . . . . . . . . . 76
Verificando o progresso . . . . . . . . . . . . . . . . . . . 78
A linha de escopo do MVP . . . . . . . . . . . . . . . . . 80
Diagrama de Fluxo Cumulativo . . . . . . . . . . . . . . . . 82
Interpretando o CFD . . . . . . . . . . . . . . . . . . . . . 84
A fazer / Fazendo / Feito . . . . . . . . . . . . . . . . . . . 86
Quando estará pronto? . . . . . . . . . . . . . . . . . . . . 87
Mudança no escopo . . . . . . . . . . . . . . . . . . . . . 88
Trabalho em Andamento (WIP) . . . . . . . . . . . . . . 89
Tempo de atravessamento (Lead Time) . . . . . . . . . . 90
Taxa de transferência (Throughput) . . . . . . . . . . . . 91
Lei de Little . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Tempo de Ciclo (Cycle Time) . . . . . . . . . . . . . . . . 96
Estabilizando o sistema . . . . . . . . . . . . . . . . . . . 98
Sistema Puxado . . . . . . . . . . . . . . . . . . . . . . . . 99
Sistema Estável . . . . . . . . . . . . . . . . . . . . . . . . 100
Estabilidade no sistema . . . . . . . . . . . . . . . . . . . 101
Mantenha o CFD simples . . . . . . . . . . . . . . . . . . 104
Sobre o jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Objetivos do jogo . . . . . . . . . . . . . . . . . . . . . . . 106
Objetivo 1: planejar as entregas . . . . . . . . . . . . . . . 107
Objetivo 2: entregar o MVP e seus incrementos . . . . . 108
Sobre o Scrum no jogo . . . . . . . . . . . . . . . . . . . . 109
Sobre o Kanban no jogo . . . . . . . . . . . . . . . . . . . 110
Prep for Dev . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Ag-
ileBrazil, Paulo Caroli possui mais de vinte anos de experiência em
gestão e desenvolvimento de software, com passagem em varias
corporações no Brasil, Índia e EUA . Em 2000, conheceu o Extreme
Programming e, desde então, tem mantido seu foco em processos e
práticas de gestão e desenvolvimento ágil. Ingressou na Thought-
Works em 2006 e ocupou os cargas de agile coach, treinador, e
Gerente de Projetos. Possui os títulos de Bacharel em Ciência da
Computação e MS em Engenharia de Software, ambos da PUC
-Rio. Autor dos Livros ”Lean Inception: Como alinhar Pessoas e
Construir o Produto Certo” , e “Fun Retrospectives; activities and
ideas for making agile retrospectives more engaging”.
Paulo Caroli
Acompanhe Paulo Caroli no seu site e nas redes sociais:
Sobre a Editora Caroli
A Editora Caroli nasceu em 2017, quando Paulo Caroli decidiu
realizar todos os passos desde escrever um livro a impressão e venda
do mesmo. Este livro é O Mistério do Colégio Alipus, um livro de
ficção juvenil escrito por Paulo Caroli e sua filha Duda Chaieb —
na época com doze anos—; o livro foi premiado como destaque na
categoria na feira do livro de Porto Alegre em 2018; confira em
www.MisterioDoColegio.com .
Paulo Caroli seguemuito do seu aprendizado no Vale do Silício para
a criação de conteúdo e publicação de livros. Com um estilo Lean
StartUp (construir fazendo) nasceu a Editora Caroli.
Caroli constituiu uma editora para publicar seus livros e para ajudar
a publicar livros de amigos.
WIP (Writing In Progress)
A Editora Caroli apresenta uma nova proposta de trabalho, aprox-
imando autores dos seus leitores desde o início da geração do
conteúdo. Porque esperar o autor terminar de escrever para ver se o
conteúdo é bom? Nomundo atual isso não faz mais sentido. Então a
Editora Caroli promove o compartilhamento (gratuito sempre que
possível) do WIP (Writing In Progress) através dos formatos eBook
(pdf, mobi e epub). Desta forma, leitores tem acesso rápido as novas
ideias, e podem fazer parte da evolução da obra. Para os autores,
esse é uma forma efetiva de feedback e motivação para a geração
de conteúdo.
Este e outros eBooks estarão disponíveis no site http:
//caroli.org
http://caroli.org
http://caroli.org
Sobre esse e-Book
Esse e-book foi criado para complementar o treinamento de mesmo
nome. Saibamais sobre o treinamentoemhttps://caroli.org/treinamento/
lean-product-development
Depois de muitos anos facilitando Lean Inceptions, senti a necessi-
dade de esclarecer alguns assuntos correlacionados e demonstrar a
forma como times de sucesso trabalham.
As empresas e equipes que usam Lean Inception, geralmente se
utilizam de uma estratégia mais lean, planejam e acompanhas seus
MVPs com boas práticas de fluxo e interações.
Este e-book faz parte da série Lean Strategy, com o foco em
entender e melhorar o processo na etapa DO.
Se você busca algo mais técnico, com práticas de engenharia
de software (código, DevOps, trunk único, feature toggles, etc),
procure pelo e-book Lean Engineering.
Se você ainda não leu, confira o primeiro livro desta série, o Lean
Inception.
https://caroli.org/treinamento/lean-product-development
https://caroli.org/treinamento/lean-product-development
Disclaimer
Estou tratando esse E-Book como umMVP. Se já tem algo minima-
mente viável para passar a ideia, o conceito, então está disponível.
Por isso neste E-Book você vai encontrar erros de ortografia,
imagens em versões iniciais, e texto por escrever.
Mas como um bom MVP, estou muito interessado no seu feedback.
Abraços,
Paulo Caroli
A série Lean Strategy
Este e-book faz parte da série Lean Strategy, a qual é formada pelo
livro Lean Inception (best-seller na Amazom.com.br, publicado em
novembro de 2018) e outros livros e e-books correlacionados.
Dado que alguns desses e-books sãoWIP –Writing In Progress, você
pode encontrar textos repetidos entre esses e-books. Com o tempo
e a evolução dessa série, eu irei adicionando, alterando e revendo o
conteúdo dos livros e e-books.
Confiram em www.caroli.org/serie-lean-strategy este e os outros
conteúdos desta série.
O ciclo PDCA do Lean
Strategy
O PDCA do Lean Strategy
Esse é o ciclo do PDCA: Tudo começa a partir de um workshop
de OKR (em Inglês, Objectives and Key Results) para a Unidade de
Negócio (UN).
Então várias iniciativas (candidatas) da UN são consideradas em
um workshop de priorização relativa, onde essas são avaliadas
quantitativamente, considerando o valor e o esforço de cada uma
(PLAN).
O próximo squad disponível puxa a iniciativa priorizada (sistema
puxado) para um workshop de Lean Inception, onde todos juntos
(negócio, tecnologia e UX) compreendem e criam o plano para a
criação do MVP. Seguindo as práticas Scrum, Kanban e DevOps, o
squad constrói o MVP (DO).
Assim que o MVP está pronto, este é liberado para os seus usuários
O ciclo PDCA do Lean Strategy 2
finais. Os dados de uso são coletados e compilados como métricas
a serem analisadas (CHECK).
Comparando o resultado obtido com o resultado esperado do MVP,
decidimos como prosseguir com a iniciativa: pivotar, prosseguir,
ou cancelar. Esta decisão é realizada perante os resultados ap-
resentados por todas as iniciativas em andamento, seus MVPs,
a capacidade, o budget, os investimentos, e o alinhamento com
os OKRs da UN (ACT). Com base nesses parâmetros, decidimos,
estrategicamente, quais iniciativas começar, quais continuar, quais
pivotar, e quais cancelar.
O modelo Lean Strategy traz disciplina para priorizar, construir,
medir, e coordenar esforços para alcançar os objetivos estratégicos
do negócio.
Plan
Vamos planejar as ações estratégicas organizacionais para alcançar
nossos objetivos. Para tanto, vamos manter um portfolio dinâmico,
que nos permita compreender e agrupar as iniciativas, permitindo
tanto (1) uma priorização inicial quanto (2) o redirecionamento
baseado no feedback de cada iniciativa.
Do
Dado uma iniciativa priorizada, vamos compreendê-la, e executá-la
de forma enxuta, ágil e centrada no feedback dos nossos usuários.
Para tanto faremos entregas rápidas e frequentes.
O ciclo PDCA do Lean Strategy 3
Check
Medimos o uso de cada MVP. Essas métricas são essenciais para
validação de hipóteses e ajustes na evolução de nossas iniciativas,
baseado no feedback de uso.
Act
Decidimos como proceder com cada iniciativa: pivotar, prossegir,
ou cancelar. Vamos rever as hipóteses iniciais (PLAN) e os dados
de uso dos MVPs (CHECK). Iremos também comparar as diversas
iniciativas perante o orçamento da Unidade de Negócio (UN) e os
OKRs, os nossos direcionadores de negócio ativos, atualizados e
acionáveis.
Lean Inception
Lean Inception é um workshop colaborativo para alinhar um grupo
de pessoas a construir o produto certo.
Tipicamente um grupo de pessoas vai começar a trabalhar em um
produto digital. Vários podem ser os motivos para se trabalhar em
um produto digital:
• Alguém investiu na sua startup e você vai colocar a sua ideia
em execução
• A sua empresa está modernizando algo e vai refazer um
produto já existente
• Um grupo anterior fracassou para criar o produto, agora é
segunda tentativa, com mais pressão e menos dinheiro
• Pesquisas indicam um bom direcionamento de negócio, agora
o grupo busca o product-market fit
Antes de sair fazendo, o grupo participa de um workshop colab-
orativo com uma sequência de atividades para alinhar e definir
objetivos, estratégias e escopo do produto. Um workshop que usa
técnicas de Design Thinking com uma abordagem de Lean Startup:
o workshop de Lean Inception.
A forte influência de Lean StartUp é um dos dois motivos para
a palavra Lean no nome do workshop, Lean Inception.
O nome Inception vem do RUP (Rational Unified Process), um
processo de engenharia de software criado pela Rational** nos anos
90 para o desenvolvimento orientado a objetos, baseado no UML
(Unified Modeling Language).
Lean Inception 5
A Rational foi comprada pela IBM em 2003. E, nessa época, o
RUP era considerado um dos métodos ágeis, com sua proposta
de ciclos de entrega mais curtos (apesar de iterações atual-
mente consideradas longas, como três meses) e incrementais.
Inception é a primeira de quatro fases do RUP: Inception, Elabora-
tion, Construction e Transition. Na fase de Inception era realizado
a análise sobre os objetivos, a arquitetura e o planejamento do pro-
jeto. Isso acontecia via entrevistas com os stakeholders, convertidos
em requisitos descritos no formato de casos de uso.
Os casos de uso caíram em desuso e o povo dos métodos ágeis
adotou o formato de histórias do usuário, o que, como dizia o
próprio nome, era para os usuários. Isso aconteceu entre os anos
de 2006 a 2010.
O nome inception continuava a ser usado, mas o seu foco e
estilo alterou: foram adicionadas atividades sobre os usuários e
suas jornadas (influencia de design thinking e user-centric design);
muitas histórias dos usuários eram escritas, estimadas, arquitetadas
e colocadas em um plano: o plano de release do produto.
Eu participava de muitas inceptions. Eu adorava essa fase, esse
início de projeto, essa etapa, essas várias reuniões (muitas vezes,
ao longo de quatro semanas) para, enfim, chegar a um plano de
release do produto.
Mas em 2011 nasceu meu filho.
Daí você se pergunta; mas o que isso tem a ver com Lean Inception?
Tudo. Ele nasceu e eu nunca consegui ficar longe dele por mais de
uma semana. Mas eu era o facilitador de inceptions mais experiente
do meu escritório. Eu era chamado para facilitar inceptions em
outros países. E essas duravam algumas semanas, tipicamente de
Lean Inception 6
duas a quatro semanas, com reuniões no escritório do cliente que
contratava a Thoughtworks para a criação do produto digital.
Eu precisava reduzir o tempo de duração das inceptions, deixá-
las mais enxutas (Lean), para voltar para casa depois de uma
semana de trabalho no escritório do cliente, longe de casa.
E nesse mesmo ano, Eric Ries publicou o livro, agora o best-seller,
The Lean StartUp. Nesse livro eu encontrei a desculpa ideal para
voltar para casa em apenas uma semana: o MVP, o produto mín-
imo viável, engrenagem fundamental do ciclo Construir-Medir-
Aprender.
o ciclo Construir-Medir-Aprender
O produto mínimo viável, em Inglês Minimum Viable Product
(MVP), é a versão mais simples de um produto que pode ser
disponibilizada para o negócio. O MVP determina quais são as
funcionalidades mais essenciaispara que se tenha o mínimo de
produto funcional que possa agregar valor para o negócio (produto
mínimo) e que possa ser efetivamente utilizado e validado pelo
usuário final (produto viável).
Lean Inception 7
Pronto. Na inception, o foco era em gerar o plano de release do
produto, muitas vezes bem completo. Mas na Lean Inception o foco
é noMVP, nomínimo viável do produto. Pensamos no produto, mas
somente alinhamos e planejamos o MVP. Cansamos daquela época
que criávamos muita funcionalidade que não era usada (nossa,
como desperdiçamos tempo, e dinheiro!)
Esses são os dois motivos para o nome Lean Inception: (1) fazer a
inceptionmais rápida – enxuta ou Lean – para voltar logo para casa,
e (2) pela foco no MVP, peça-chave do movimento Lean StartUp.
O resultado de anos de experiência prática –a receita da Lean
Inception– está descrito no meu livro Lean Inception: Como Al-
inhar Pessoas e Construir o Produto Certo.
Conforme informado no capítulo Sobre este E-Book, este livro é
específico para a etapa DO do Lean Strategy, que começa com uma
Lean Inception.
Conhecimento,
relacionamento e
comprometimento
Conhecimento, relacionamento e comprometimento. Essas são os
três principais benefícios oriundos da semana da Lean Inception.
Quem participa da semana da inception adquire um alto nível de
conhecimento sobre o produto a ser criado.
Também cria uma aproximação e um bom relacionamento com
as outras pessoas envolvidas com a criação do produto.
Além de assumir um alto nível de comprometimento com as
datas e entregáveis acordados na inception.
Entretanto, a negativa também é verdadeira. Imagine alguém que
não participou da semana da Lean Inception. E , depois de algum
tempo – dias ou semanas, entra para o time que está trabalhando
na criação do MVP.
Esse novo integrante do time não tem o mesmo nível de con-
hecimento, relacionamento e comprometimento que aqueles que
participaram da semana da inception.
É muito importante ressaltar esse aspecto. Por mais que esse
novo integrante entenda rapidamente os detalhes do MVP a ser
construído, ele vai precisar de ajuda e tempo para consolidar
conhecimento, relacionamento e comprometimento, assim como os
outros integrantes do time (que estão juntos desde a inception).
Conhecimento, relacionamento e comprometimento 9
exemplo de artefatos, resultado de uma Lean Inception
A foto acima demonstra um resultado tangível da inception: o plano
de liberação do produto via MVP. Isso tem muito valor. Esse plano
está visível na foto (o sequenciador de features e o canvas MVP). O
novo integrante do time vai ver essa foto e entender esse plano.
Mas tem algo que não aparece na foto, no Jira, na planilha Excel,
ou nos flipcharts com post-its coloridos: conhecimento, relaciona-
mento e comprometimento. E esses também são resultados da
inception. Veja abaixo algumas fotos da interação entre as pessoas
durante a Inception:
Conhecimento, relacionamento e comprometimento 10
um time numa Lean Inception
outro time numa Lean Inception
Cuidado. Uma inception bem sucedida é somente o começo dessa
Conhecimento, relacionamento e comprometimento 11
jornada. Saindo da inception precisamos considerar outros aspectos
para assegurar o sucesso dessa empreitada.
Em relação aos integrantes do time:
• Evite grandes mudanças no time original, mas se isso for
inevitável, tente amenizar (quanto menos mudança, melhor).
• Apoie cada novo integrante para elevar o seu nível de con-
hecimento, relacionamento e comprometimento.
Os capítulos a seguir compartilhammais detalhes sobre como guiar
a entrega enxuta com fluxo e interações.
Calculando esforço,
tempo e custo
*Este capítulo contém conteúdo do livro Lean Inception, adaptado
e organizado para este livro.
A maioria das empresas que conheço está muito interessada em
responder a duas perguntas simples e diretas: O que devemos
construir? E quando estará pronto?
O sequenciador de funcionalidades responde à primeira pergunta.
Ele mostra o MVP e seus próximos incrementos. É um artefato
incrível gerado na Lean Inception. Muitos stakeholders ficarão
satisfeitas com a informação clara e direta sobre as funcionalidades
do MVP e os incrementos do produto.
Mas quando estará pronto? Algumas pessoas farão essa pergunta.
Quando oMVP vai estar pronto? E o próximo incremento? E quanto
a todas as funcionalidades no sequenciador?
Este capítulo compartilha uma técnica que tem ajudado muitas
equipes a responder esses questionamentos.
O sequenciador
Conforme descrito no livro Lean Inception, o sequenciador auxilia
na organização e na visualização das funcionalidades e da sequên-
cia de liberação de entrega incremental do produtomínimo e viável,
o MVP. O sequenciador organiza e planeja entregas do produto,
deixando claro as funcionalidades do MVP e os incrementos subse-
quentes.
Calculando esforço, tempo e custo 13
Além de mostrar os cartões de funcionalidades ordenados, o se-
quenciador mostra claramente o agrupamento de funcionalidades
para cada MVP. Isso é representado por post-its colados no sequen-
ciador, delimitando o MVP1, o MVP2 e assim por diante.
exemplo: Canvas MVP1 e Canvas MVP 2 ao lado do sequenciador de funcional-
idades
Segue abaixo um sequenciador, exemplo de resultado de uma Lean
Inception, que será usado para ilustrar a construção das funcional-
idades do MVP com Scrum e com Kanban nos capítulos a seguir.
Calculando esforço, tempo e custo 14
Sequenciador
Note no sequenciador apresentado que o MVP 1 é composto pelas
features F1, F2, F3, F4, F5 e F6.
Template do sequenciador
Imagine uma sequência de ondas, uma depois de outra, e elas são,
aproximadamente, do mesmo tamanho. Essas ondas estão numer-
adas: 1, 2, 3 e assim por diante. Esse é o template do sequenciador.
Calculando esforço, tempo e custo 15
sequenciador de funcionalidades
O intuito é executar o que é mais impactante o mais cedo possível,
logo nas primeiras ondas. E seguir trabalhando nas funcionalidades
do sequenciador, de onda em onda.
Para ajudar a decidir o que colocar em qual onda e normalizar o
tamanho das ondas, siga as regras do sequenciador.
As regras do sequenciador
Essas são as seis regras para adicionar cartões às ondas do se-
quenciador. Elas foram definidas depois de aplicar essa forma de
organização e priorização de funcionalidades inúmeras vezes.
• Regra 1: Uma onda pode conter, no máximo, três funcionali-
dades.
Calculando esforço, tempo e custo 16
• Regra 2: Uma onda não pode conter mais de uma funcionali-
dade em cartão vermelho.
• Regra 3: Uma onda não pode conter três funcionalidades
somente em cartões amarelos ou vermelhos.
• Regra 4: A soma de esforço das funcionalidades não pode
ultrapassar cinco “E”.
• Regra 5: A soma de valor das funcionalidades não pode ser
menos de quatro “$” e quatro corações.
• Regra 6: Se uma funcionalidade depende de outra, essa outra
deve estar em alguma onda anterior.
A regra 1 limita o número de funcionalidades que estão sendo
trabalhados ao mesmo tempo. Isso evita o acúmulo de itens de tra-
balho parcialmente completos, aumentando o foco para as poucas
funcionalidades priorizadas por onda. As regras 2, 3 e 4 evitam um
período de trabalho desequilibrado, com muita incerteza ou muito
esforço. A regra 5 garante o foco constante na entrega de alto valor
para o negócio e para os usuários. A regra 6 evita problemas de
dependência entre funcionalidades.
Note que essas regras geram ondas de tamanho similar. Isso simpli-
fica a estimativa do MVP e seus incrementos, pois nos permite usar
seu tamanhomédio de onda baseado em uma pequena amostragem.
Detalhando a amostra de
funcionalidades em tarefas
O tamanho das ondas é parecido. Logo, escolha duas ou três e use-
as para gerar informações detalhadas de esforço, tempo e custo.
Duas ou três ondas são suficientes para dar uma boa noção de tais
parâmetros e gerar uma média efetiva.
Passo a passo da atividade
Calculando esforço, tempo e custo 17
1. Selecione duas ou três ondas a serem detalhadas.
2. Selecione uma funcionalidade de uma dastrês ondas de
amostra.
3. Descreva, em outros cartões, os pedaços menores para a
funcionalidade selecionada.
4. Volte ao passo 2 e selecione outra funcionalidade até ter
detalhado todas as funcionalidades das ondas de amostragem.
Ao selecionar as ondas de amostragem (passo 1), lembre-se que
neste momento você está interessado na estimativa do todo e no
tamanho médio de uma onda, e não no detalhamento do tra-
balho em si. Por isso, as ondas a serem escolhidas devem prover
boa combinação do nível de confiança (marcados pelas cores dos
cartões), bem como uma boa variação na soma dos níveis de esforço
(marcados com “E” nas funcionalidades).
O pedaço menor (passo 3) deve ser algo que faz sentido para o time.
Times de desenvolvimento de software que seguem a metodologia
Scrum costumam usar histórias do usuário como tais pedaços
menores. Outros times preferem chamá-los de tarefas, e descrevê-
las sem um formato predefinido. O mais importante é que o time
esteja confortável com o detalhamento desses pedaços menores e,
logo, consiga estimar seu tamanho e esforço.
Segue abaixo o exemplo ilustrativo de uma funcionalidade detal-
hada em tarefas.
Calculando esforço, tempo e custo 18
funcionalidade detalhada em tarefas
No contexto deste livro, vou chamar de tarefas os pedaços menores
de uma funcionalidade. Normalmente, recomendo que as equipes
sejam muito específicas ao descrever essas tarefas, pois isso aju-
dará a atividade, mas não devem se preocupar em documentá-las
perfeitamente, pois isso deve ser feito depois, e não durante a Lean
Inception.
Durante o passo 3, faça umamarcação tanto no cartão da funcional-
idade, como nos cartões das tarefas de cada uma. Por exemplo,
marque F1 para todas tarefas da funcionalidade 1, F2 para as tarefas
da funcionalidade 2 e assim por diante. Nas atividades a seguir, os
cartões serão movidos, e tal marcação será utilizada para reagrupar
funcionalidades aos seus pedaços menores.
Ao final desta atividade, as funcionalidades selecionadas como
amostra estarão detalhadas com suas várias tarefas.
Calculando esforço, tempo e custo 19
Dimensionamento de tarefas
Esta atividade é muito simples, mas essencial para entender o
esforço relativo das tarefas.
Passo a passo da atividade
1. Escreva os seguintes tamanhos de camiseta em post-its: P, M
e G.
2. Coloque os post-its no canvas (normalmente uma mesa), o G
no canto superior esquerdo, o P no canto inferior esquerdo e
o M entre os outros dois.
3. Selecione duas tarefas e faça a seguinte pergunta: Como essa
tarefa se compara (em esforço) a essa outra? Ambas P? Uma
P, a outro M? G?
4. Coloque as duas tarefas no canvas, com suas posições relati-
vas indicando como elas se comparam em relação ao nível de
esforço (pequeno, médio ou grande). Coloque uma ao lado da
outra se ambas exigirem omesmo nível de esforço; ou coloque
uma abaixo da outra, indicando que uma exige mais esforço
do que a outra.
5. Defina os limites entre os tamanhos e reposicione as tarefas
para tornar seus tamanhos claros. Se necessário, considere
criar um tamanho extra de camiseta (XP ou XG, para extra-
pequeno ou extragrande)
6. Enquanto houver tarefas a serem comparadas, coloque-as no
canvas de acordo com o nível de esforço e repita as etapas 3
e 4.
Calculando esforço, tempo e custo 20
tarefas dimensionadas em P, M ou G
Ao final desta atividade, cada tarefa será associada a um tamanho
de camiseta: pequena, média ou grande.
As duas atividades anteriores (Detalhando a amostra de funcional-
idades em tarefas e Dimensionamento de tarefas) podem e devem
ser feitas aomesmo tempo, conforme ilustrado na próxima imagem.
Calculando esforço, tempo e custo 21
exemplo - detalhando e dimensionando as funcionalidades de amostragem
Nele, as tarefas são colocadas sob sua respectiva funcionalidade de
amostra, e próximo às tarefas de tamanhos similares (post-it com as
marcas P, M e G, respectivamente para pequeno, médio e grande).
Entendendo custo e tempo
Esta atividade é essencial para gerar números para o cálculo de
custo e de tempo para cada onda e para todo o sequenciador.
Passo a passo da atividade
1. Selecione uma tarefa pequena, e pergunte quanto tempo uma
pessoa leva para completá-la.
2. Selecione mais duas ou três tarefas do mesmo tamanho e
repita a pergunta.
3. Faça a média do tempo e anote-a.
4. Repita os passos anteriores para tarefas de outros tamanhos.
Calculando esforço, tempo e custo 22
Ao final desta atividade todas tarefas terão uma estimativa de
tempo e custo. Por exemplo, o seguinte resultado foi obtido numa
ocorrência desta atividade: um dia para tarefas pequenas, três dias
para tarefas médias e quatro dias para tarefas grandes.
As respostas de tempo irão influenciar o resultado final. Por isso,
seja bem enfático em relação à pergunta. Se possível, peça para
comparar com trabalhos passados, e tente entender a motivação e
a capacidade das pessoas respondendo a pergunta.
Desenvolvedores não gostam de responder “Quanto tempo leva
para uma pessoa completar tal tarefa?”.
Por isso, é muito importante que todos estejam muito à vontade
com a descrição da tarefa. Caso haja qualquer desconforto em
relação à ela, reescreva-a e considere quebrá-la em pedaços ainda
menores.
Outra forma de fazer tal pergunta é colocá-la no plural:
Considere uma dupla de desenvolvedores. Um sabe
mais do negócio, outro menos. Um mais sênior, outro
mais júnior. Um mais experiente na tecnologia, outro
mais novato. Quanto tempo leva para eles com-
pletarem tal tarefa?
Naminha experiência, todos ficammais à vontade dando a resposta
quando consideram uma dupla de desenvolvedores atuando em
conjunto para completar uma tarefa.
Tirando a média
A partir do entendimento de esforço da atividade anterior, so-
mamos o tempo estimado para cada tarefa de cada funcionalidade,
e, com isso, somamos a duração prevista por funcionalidades de
Calculando esforço, tempo e custo 23
cada onda escolhida do sequenciador. Dessa forma, chegamos a
uma média de esforço para cada onda, definido por pessoa e por
unidade de tempo.
As duas fotos a seguir demonstram como o cálculo foi realizado
para um time. As fotos mostram, respectivamente, as ondas escol-
hidas para amostragem e o cálculo realizado para obter a média do
tempo estimado por onda.
ondas e funcionalidades para amostragem
Note na foto anterior que as ondas 2, 3 e 4 foram selecionadas para
amostragem. Com isso, as funcionalidades detalhadas em tarefas
foram: F4, F5 (onda 2), F5, F6, F7 (onda 3), e F9, F10 e F11 (onda 4).
Calculando esforço, tempo e custo 24
tirando a média
A foto anterior mostra o cálculo realizado para obter a média
do tempo estimado por onda. Cada tarefa foi estimada em dias
para uma dupla de desenvolvedores. Nela, cada linha mostra o
somatório da duração prevista das tarefas de uma funcionalidade.
A medida de tempo estimada para cada tamanho de tarefa foi:
¼ de um dia (pequeno), meio dia (médio), dois dias (grande) ou
cinco dias (extragrande). Realizando a somatório de tarefas por
funcionalidade – e depois de funcionalidades por onda –, o time
alcançou os valores de onze dias, onze dias e meio e nove dias,
respectivamente para as ondas 2, 3 e 4. Após uma boa conversa
entre todas pessoas, aquele time decidiu considerar uma média de
dez dias para uma dupla de desenvolvedores por onda.
A seguir há mais um exemplo de resultado para outro time.
Calculando esforço, tempo e custo 25
exemplo de resultado
A figura anterior mostra outro resultado de uma Lean Inception
para duas ondas de amostra selecionadas: nove semanas e catorze
semanas. Depois de verificar este resultado, o principal stakeholder
disse: “Então, cada onda leva, aproximadamente, doze semanas
para um desenvolvedor. Como temos seis desenvolvedores nessa
equipe, parece que podemos entregar uma onda a cada duas se-
manas (doze semanas para um desenvolvedor equivale a duas
semanas de seis desenvolvedores), ou uma onda por Sprint, de
acordo com a terminologia do Scrum.” E continuou: “Como nosso
MVP está na onda 5, acredito quepreciso ajustar o planejamento”.
Calculando esforço, tempo e custo 26
outro exemplo de resultado
Na foto acima, há mais um exemplo de outra equipe. Nesse caso, a
média resultante foi de vinte unidades. Note o cálculo em post-its
no lado esquerdo, de três ondas de amostra.
No time em questão, a unidade utilizada era uma dupla de de-
senvolvedores por dia. Com essa informação, ficou fácil calcular
o esforço, tempo e custo de cada onda: “Podemos escolher tra-
balhar com uma dupla de desenvolvedores, e entregar uma onda
de funcionalidades em, aproximadamente, um mês (ou vinte dias
úteis). Outra opção seria dobrar o custo mensal, tendo duas duplas
de desenvolvedores e entregar, aproximadamente, duas ondas por
mês”.
Somente Devs estimam?
No capítulo anterior eu compartilhei uma forma para responder
quando o MVP vai estar pronto.
Alias, tal capítulo é originalmente do livro Lean Inception, já
publicado a bastante tempo. Por tal motivo, compartilho alguns
pontos para tentar responder a uma pergunta de alguns leitores:
só as pessoas desenvolvedoras estimam?
Esse assunto é controverso. Alias, a conversa relacionada a datas e
estimativa é controversa. De qualquer forma, vamos explorar esse
tópico um pouco mais.
Estimativa cascata ou
ágil
Ao final da Lean Inception, o squad realizou um cálculo por
amostragem para estimar a data de entrega dos MVPs. Isso é
necessário para dizer aos stakeholders quando oMVP estará pronto.
Na Lean Inception, as pessoas desenvolvedoras foram bem específi-
cas e te apresentaram a média esperada por onda do sequenciador;
isso “para todas as tarefas que precisam ser realizadas para ter
as funcionalidades em produção” (palavras do facilitador da Lean
Inception)
Mas por que não consideramos o tempo de teste? e o tempo de
análise?
A resposta é direta: Porque não trabalhamos em cascata, mas sim
de forma ágil.
No contexto deste livro, assumidos que o squad trabalha de forma
ágil — ao invés de uma cascata—, por isso o cálculo da data de
entrega do MVP é realizado de forma distinta de projetos em
cascata.
Estimativa cascata ou ágil 29
estimativa cascata versus estimativa ágil
Em projetos cascata, era comum somar todos os tempos das fases,
para, ao final chegar a uma data. Em projetos ágeis, após a Lean
Inception, consideramos o tempo da Sprint0, e realizamos um
cálculo para decidir a data que o MVP estará pronto.
Time multi-funcional
Times ágeis – squads – são multifuncionais. Isso significa que todos
membros do time se ajudam nas variadas tarefas, independente
dos seus conhecimentos e afazeres preferidos e cotidianos (devs
gostam de escrever código, testadores gostam de testar, UX gostam
de refletir sobre usabilidade, etc).
Mas, muitas vezes, uma pessoa que faz testes não necessariamente
sabe escrever código funcional. Assim como um PO, geralmente
não sabe escrever código funcional.
Em contra-partida uma pessoa desenvolvedora sabe ajudar com
análise e entendimento das funcionalidades e seus pedaçosmenores
(historias do usuário e tarefas), e também consegue ajudar com
testes exploratórios e manuais.
Estimativa cascata ou ágil 30
Pessoas desenvolvedoras em times ágeis ajudam tanto com a preparação
e análise do trabalho quanto com os testes e validação do mesmo.
Aliás, em times ágeis, é muito comum que todos se ajudem (muito)
em relação a preparação do trabalho e a validação do mesmo.
Teste Antes, valide
depois
Test driven development é uma das práticas do eXtreme Program-
ming, uma das metodologias precursoras de métodos ágeis. O livro
de eXtreme Programing é de 2000, um ano antes da criação do agile
manifesto ( e o termo Agile).
Times ágeis fazem TDD. Isso significa que os testes são escritos
antes do código funcional. Ou seja o código está pronto quando
a versão atualizada do produto (com a nova funcionalidade ou
história do usuário) passa por todos os testes do produto.
Todos os testes do produto, nesse momento, são: (1) os testes que
validam que o requisito em questão foi alcançado e (2) os testes
de regressão, aqueles que confirmam que todas funcionalidades
anteriores a essa continuam funcionando.
A grande maioria dos testes de regressão são testes automatizados.
Isso gera uma confirmação, em pouco tempo (minutos geralmente)
de que todo o produto está ok.
Mas, até hoje, eu nunca vi um local com 100% de automação, onde
não exista uma pessoa, um ser humano, realizando algum tipo
de validação mesmo após todos testes automatizados passarem.
Geralmente essas pessoas são chamadas de testadores.
Alguns times não possuem pessoas testadores, e tal validação é
realizada pelas pessoas desenvolvedoras e/ou o PO. Mas, alguns
times possuem pessoas testadores, que além de ajudar a analisar
o trabalho, ajudar os desenvolvedores com os critérios de aceite,
também fazem algumas tarefas de validação manual e exploratória
para confirmar o estado atual desejado do produto.
Teste Antes, valide depois 32
Na Lean Inception, quando o facilitador pede “todas as tarefas que
precisam ser realizadas para ter as funcionalidades em produção”,
o squad considera o tempo de: preparação dos dados de teste,
automação dos cenários de teste, scripts de integração e automação.
Ou seja, muito da preparação e validação do trabalho já está
comtemplado no ˜tempo de desenvolvimento˜
Puxe, não Empurre
Times ágeis não empurram trabalho adiante. Ao invés, o trabalho
é puxado da etapa mais próxima ao fim para a etapa anterior.
Por exemplo, pessoas desenvolvedoras em times ágeis evitam acu-
mular trabalho para ser validado depois. Assim que um trabalho de
desenvolvimento acaba, as pessoas desenvolvedores tentam colocá-
lo para validação. Mas, caso já tenha muita coisa na fila para
validação, ao invés de empilhar mais uma tarefa para validar, as
pessoas desenvolvedoras se oferecem para ajudar com a etapa de
validação. Dessa forma, o time (todos juntos) resolvem o gargalo
de validação, mantendo um sistema puxado saudável.
Ao trabalhar desta forma – time multifuncional e com sistema
puxado –, a etapa de validação puxa o próximo item ao invés das
pessoas desenvolvedoras empurrarem e empilharem trabalho.
Escopo funcional do MVP
O livro Lean Inception, além de compartilhar uma sequência de
atividades para ajudar um grupo de pessoas a alinhar sobre o
MVP, entra em detalhes sobre MVP –Minimum viable Product, em
Inglês –. Nele você encontra o histórico sobre MVP e as diversas
considerações sobre ele nas perspectivas do negócio, da tecnologia
e da experiência do usuário.
Conforme descrito no texto e no próprio título do capítulo anterior:
Conhecimento, relacionamento e comprometimento; esses são os
maiores benefícios da Lean Inception.
MVP, Design Thinking e Lean StartUp
O livro Lean Inception também apresenta o Canvas MVP, que
resume em um único canvas as perspectivas do design centrado no
usuário e do desenvolvimento baseado na validação de hipótese.
Você encontra mais detalhes sobre o Canvas MVP no livro Lean
Inception e no post www.caroli.org/o-canvas-mvp.
Escopo funcional do MVP 35
o canvas MVP
Os Sete blocos do Canvas MVP
O Canvas MVP é dividido em sete blocos. A seguir, as per-
guntas que devem ser respondidas em cada bloco, na ordem
indicada:
1. Proposta do MVP – Qual é a proposta deste MVP?
2. Personas segmentadas – Para quem é esse > MVP?
Podemos segmentar e testar este MVP em um grupo
menor?
3. Jornadas –Quais jornadas são atendidas oumelhoradas
com este MVP?
4. Funcionalidades – O que vamos construir neste MVP?
Que ações serão simplificadas oumelhoradas nesteMVP?
5. Resultado esperado – Que aprendizado ou resultado
estamos buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como
podemos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista
para a entrega deste MVP?
Escopo funcional do MVP 36
Antes de prosseguir com o objetivo e escopo deste livro (sinalizado
no título deste capítulo), preciso ser muito claro com os dois pontos
seguintes:
• Times e produtos de sucesso vão além do escopo funcional
do produto;esses dependem do foco nas pessoas, do conhec-
imento, relacionamento e comprometimento compartilhado
entre elas.
• Para elaborar e criar umMVP de sucesso você deve esclarecer
a proposta do MVP, as personas segmentadas, as jornadas, o
resultado esperado, as métricas para validar as hipóteses, o
custo e cronograma; além das funcionalidades a serem criadas
no MVP.
Mas, no contexto deste livro, para guiar a criação do MVP com
Scrum e Kanban, vou considerar somente o escopo funcional de
um MVP.
Jogo do treinamento Este livro possui um jogo que simula
um time trabalhando com Scrum e Kanban para construir um
produto incrementalmente, viaMVP. Nesse jogo não é definido
o que é o MVP, tão pouco as funcionalidades e suas tarefas.
Somente é definido MVP1, MVP2, respectivamente para o
MVP e para o incremento seguinte, e F1, F2, F3 e assim sucessi-
vamente para as funcionalidades 1, 2, 3. No jogo e no livro, vou
considerar somente o agrupamento de funcionalidades, suas
prioridades, suas tarefas e o fluxo de trabalho.
Confira a página do jogo emhttp::/caroli.org/jogo-lean-product-
development
Como o MVP promove a evolução incremental de um produto, vou
utilizar o artefato da Lean Inception que demonstra exatamente
isso: o sequenciador das funcionalidades a serem elaboradas.
http::/caroli.org/jogo-lean-product-development
http::/caroli.org/jogo-lean-product-development
Escopo funcional do MVP 37
MVPs são pequenos
O MVP fatia uma iniciativa em pedaços bem pequenos. Isso ajuda
de duas formas: (1) reduz o risco de insistir em uma iniciativa que
não se provou, ou seja, parecia uma boa iniciativa, mas que não
gerou bons resultados, e (2) maximiza o fluxo de trabalho.
MVP e o Fluxo de trabalho
Trabalhar com MVP ajuda na rápida validação do produto e das
hipóteses de negócio. Mas também tem outro grande benefício:
MVP promove um fluxo de trabalho mais eficiente. UmMVP é uma
pequena fatia do produto. Ë como se fosse um pequeno batch size,
quando comparado com o produto completo – um batch size bem
grande.
Em quanto tempo você bebe uma garrafa d’água de 300 ml? E um
garrafão de água de 5 litros?
O tamanho da garrafa representa o batch size. Um MVP é um
batch size pequeno. E isso ajuda com a eficiência do fluxo de
trabalho. Agora, mudando de água par uísque, eu tenho um bar de
uísque. Quanto menor a garrafa de uísque, mais rápido ela termina.
No capítulo Diagrama de Fluxo Cumulativo voce vai ler mais
detalhes sobre parâmetros de fluxo de trabalho e como eles afetam a
percepção sobre as entregas. Vou compartilhar mais detalhes sobre
meu bar de uísque e como isso te ajuda a entender o fluxo de
trabalho.
Construindo MVP com
Scrum
Dado que muitas equipes utilizam Scrum, vamos compartilhar
como temos combinado Scrum com a criação de MVPs. Para tanto,
vamos realizar uma introdução básico sobre o Scrum, e, em seguida
demostrar como encaixar Scum com MVP, features e histórias.
Scrum
Scrum é um framework ágil para a conclusão de projetos com-
plexos. Scrum foi inicialmente formalizado para projetos de de-
senvolvimento de software, mas tem sido aplicado para qualquer
âmbito de projetos complexos, e trabalhos inovadores.
O Scrum é especialmente adequado para projetos com requisitos
que mudam rapidamente ou são altamente emergentes.
A Equipe Scrum
Scrum fomenta uma equipe multi-funcional e auto-organizada. A
eficiência do time depende da capacidade dos membros trabal-
harem em conjunto, e fazer o melhor uso das habilidades dos
indivíduos. O time Scrum é auto-organizado pois não deve existir
um líder de equipe que decide quem vai fazer qual tarefa e como.
Tarefas e problemas são levantados por todos, e essas são questões
decididas pela equipe como um todo. Os times Scrum são apoiados
por dois papéis específicos: o Scrum Master e o Produt Owner (PO).
Construindo MVP com Scrum 39
Scrum Master
Scrum Master é alguém experiente com o framework Scrum que
pode ajudar o time a usar o processo para alcançar seus objetivos
de alto nível. Os melhores Scrum Masters são aquelas pessoas que
sentem mais satisfação de facilitar o sucesso dos outros do que
seus próprios. O Scrum Master deve se sentir confortável e seguro
com o framework a ponto de dar todo controle em relação ao
produto para o Product Owner (PO), e todo controle em relação
ao desenvolvimento a sua equipe.
Product Owner
OProduct Owner (PO) representa o negócio, os clientes ou usuários,
e orienta a equipe para a construção do produto certo. O PO deve
liderar o esforço de desenvolvimento, através de esclarecimentos e
priorizações sobre o trabalho.
Tipicamente, o PO trabalha com o Product Backlog, a lista mestre
dos requisitos do produto a ser criado. É sua função priorizar o
backlog com base no valor do negócio, e no alinhamento entre as
partes interessadas, tanto internas quanto externas a equipe Scrum.
Como tal, o PO deve estar disponível para a equipe para responder
a perguntas e direcionar o time a cada momento ou indagação.
Esta combinação de autoridade e disponibilidade para a equipe de
desenvolvimento faz com que o PO seja peça chave do framework.
Scrum valoriza a auto-organização e autonomia do time; portanto,
o PO deve respeitar o direcionamento e a capacidade da equipe para
criar o seu próprio plano de ação.
A Sprint
Sprint é uma iteração, um ciclo de trabalho repetitivo no qual o time
Scrum passa por todas as cerimônias do Scrum: planning, review e
retrospectiva. O tamanho da Sprint é fixo e definido pelo time (ou
Construindo MVP com Scrum 40
pela organização) ao começar a implantar Scrum. Duas semanas é
o tamanho de Sprint mais adotado por times de desenvolvimento
de Software.
Cerimônias da Sprint
A equipe Scrum – o Scrum Master, o PO e todos membros do
time (com suas variadas formações) – participam ativamente de
todas reuniões com um alto nível de autonomia, transparência e
comprometimento.
Cerimônias da Sprint
Na Sprint planning, a equipe decide o Sprint backlog, o qual é
acompanhado diariamente (Daily Scrum) e reavaliado na Sprint
review. Através da busca de melhoria continua (salientado nas
retrospectivas), tipicamente o time Scrum performa em níveis el-
evados de rendimento. Muito disso é alcançado pelo entrosamento
do time, do alinhamento cadenciado via Sprints, e da clareza de
cada papel e reunião.
Daily Sprint
Reunião diária do Scrum, onde basicamente todos os membros
do time ficam de pé (para que a reunião não demore demais) e
Construindo MVP com Scrum 41
respondem a três perguntas, as quais auxiliam o time a se auto-
organizar, buscando o alinhamento diário em relação ao trabalho
da Sprint. As três perguntas são: o que fiz ontem, o que vou fazer
hoje e o que está impedindo o progresso do meu trabalho.
Sprint Planning
Sprint Planning, ou reunião de planejamento do Scrum é uma
reunião de planejamento que acontece no início de cada Sprint. A
reunião de planejamento do Sprint é descrita em termos de metas
e resultado desejado. O resultado desejado é um compromisso com
um conjunto de funcionalidades a serem desenvolvidas no próximo
Sprint. Buscando assim o equilíbrio entre autonomia, flexibilidade
e comprometimento do time. Tal compromisso é revisitado ao final
da Sprint, na reunião de review.
Sprint Review
Reunião realizada ao final da Sprint com o objetivo de apresentar
o estado da arte do produto sendo criado, rever o progresso do
trabalho do time, e comparar com o planejamento apresentado na
Sprint planning.
Retrospectiva
A reunião de retrospectiva Scrum é um momento para a equipe re-
fletir sobre como estão trabalhando, e buscar maneiras de melhorar.
Tipicamente, o time Scrum realiza uma retrospectiva por Sprint.
Confira no site www.FunRetrospectives.com várias ideias e
atividades para deixar suas retrospectivas efetivas e divertidas.
Construindo MVP com Scrum 42
OMVP nas cerimônias do Scrum
Antes da reunião de planejamento, as próximas funcionalidades
devem ter sido analisadas em detalhe e detalhadas em histórias do
usuário. Isso tipicamente acontece na reunião de refinamento.
Sugestão: Durante a reuniãode refinamento, use o Product
Backlog Building para criar, de forma rápida e efetiva, as
histórias do usuário.
O planejamento da Sprint
Na reunião de planejamento da sprint, a equipe scrum vai decidir as
histórias a serem trabalhados na sprint, definindo o sprint backlog.
Para fazer tal decisão, a equipe deve consultar o canvas MVP.
Basicamente, a equipe deve selecionar as histórias relacionadas as
próximas funcionalidades do MVP em construção.
Durante o sprint a equipe vai trabalhar nas histórias do sprint
backlog.
Construindo MVP com Scrum 43
Durante a Sprint
Na reunião de revisão do sprint, a equipe scrum irá rever o trabalho
realizado durante o sprint. Neste momento, a equipe deve revisar
e atualizar tanto as histórias do sprint backlog, quanto as suas
respectivas funcionalidades no canvas MVP.
Revisão da Sprint
Com o canvas MVP atualizado, a equipe pode (e deve) verificar
quanto falta para terminar o MVP . E, se necessário, a equipe de
agir (ACT) para ou (1) alcançar, ou (2) realinhar as expectativas
de entrega do MVP. Tipicamente, as reuniões de retrospectiva
geram action items para o próximo Sprint. Assim que todas as
funcionalidades do MVP estiverem completas, o mesmo deve ser
disponibilizado para os usuários finais.
Construindo MVP com
Kanban
Dado que muitas equipes utilizam Kanban, vamos compartilhar
como temos combinado Kanban com a criação de MVPs. Para
tanto vamos realizar uma introdução básico sobre o Kanban, e, em
seguida demonstrar como encaixar Kanban com MVP, features e
histórias.
Kanban
Kanban é um método formulada por David J. Anderson¹ para
gestão do fluxo de trabalho de um processo incremental e evolutivo.
Influenciado pelo modelo Toyota Just-In-Iime², o método se baseia
em visualizar o fluxo de trabalho e, a partir disso, atuar no processo
para não sobrecarregar os membros da equipe.
Através de uma abordagem de gestão visual perante a cadeia de
valor, o processo, desde sua etapa inicial até a entrega do trabalho,
é exposto aos membros da equipe. Tipicamente a cadeia de valor é
representada em quadros brancos com post-it ou ferramentas on-
line. Processo, itens de trabalho, bem como os trabalhadores estão
visualmente representados nesses quadros, comumente chamados
de kanban boards, ou kanban (isso mesmo, o método e o nome do
quadro se confundem). A partir do kanban, fica mais fácil para a
equipe decidir o que, por quem, quando, e quanto produzir.
No desenvolvimento de software, normalmente uma pequena tarefa
¹Kanban: Successful Evolutionary Change for Your Technology Business by David Ander-
son, Blue Hole Press Inc (2013)
²Ohno, Taiichi. (1988) Toyota Production System. Productivity Press
Construindo MVP com Kanban 45
leva de horas à dias para ser concluída. Além disso, você não
consegue visualizar quantos requisitos estão atualmente em análise;
ou quantos requisitos estão atualmente sendo codificados ou tes-
tados. O fato é que não conseguimos “ver” o item de trabalho
relacionado ao software, e como este se move ao longo das etapas
de do processo, até que esteja pronto. Aqui é onde tudo começa:
kanban torna tais itens em construções visíveis!
Visualize o workflow
A ideia principal do kanban é colocar o fluxo de trabalho na frente
de todos. Por exemplo em um quadro branco, ou na própria parede.
Abaixo está uma foto tirada de um kanban de uma equipe de
desenvolvimento de software.
Exemplo de kanban – o workflow visível
Cartões na parede. Simples assim. Cartões (ou post-it) na parede
mostrando o processo e o trabalho da equipe. Uma descrição rápida
do processo e trabalho deste time seria: um item de trabalho está
em etapa In Analysis, cinco itens estão na etapa de Ready For
Dev, três itens estão na etapa In Dev, um outro item está na etapa
Ready for BA, três itens estão na etapa Ready for QA, cinco itens
estão na etapa In QA, e oito itens estão em etapa de Ready for
SAT. Também parece que a equipe usa fotos para representar as
Construindo MVP com Kanban 46
pessoas trabalhando nos itens. Os cartões têm um código de cores
(há três cores diferentes nos cartões na foto). Os cartões também
têm anotações escritas neles, um identificador numérico, e post-it
menores coloridos colados sobre eles.
Como a parede é uma superfície bidimensional, o kanban é apresen-
tado em um formato tabular, onde as etapas de trabalho são títulos
de colunas, e os items de trabalho, as fotos das pessoas, e outras
marcas relacionadas ao trabalho preenchem o espaço na parede.
Estes cartões podem ser organizados em uma linha horizontal ou
não. Tudo depende da equipe e como elas representam e organizam
o seu trabalho na parede.
Limite o WIP
Limitar o trabalho em andamento, ou WIP de work in progress
em Inglês, implica que o kanban segue um sistema puxado. O
trabalho em cada etapa do processo é limitado de forma que
um novo trabalho somente seja “puxado “ para a próxima etapa
quando há capacidade disponível dentro do limiteWIP de tal etapa.
As restrições de WIP identificam gargalos e áreas problemáticas
no processo, auxiliando o time a tomar decisões para resolvê-
los. Limitar WIP é o grande diferencial do método Kanban. Tal
artimanha é o divisor de aguas entre task boards, ou quadros visuais
– como eram conhecidos antes da influencia de David Anderson
com a divulgação do método Kanban—e o quadros kanban.
Construindo MVP com Kanban 47
ilustração de kanban com limites
Siga melhorando o fluxo de trabalho
Segundo David Anderson, o ponto principal de implantar um
kanban é criar uma mudança positiva. Antes de criar essa mudança
o time tem que saber o que mudar. O time precisa descobrir isso
olhando como itens de trabalho estão fluindo através do processo,
e analisando as áreas problemáticas em que o trabalho engargala.
Daí sim, realizar nomudanças no processo de trabalho para resolver
tais problemas.
E assim sucessivamente; identificando problemas, e agindo para
resolvê-los. Tudo isso baseado na visualização e limites WIP do
kanban. Melhorando o trabalho e o processo, na busca contínua
de maior eficiência.
OMVP no Kanban
O fluxo de trabalho do MVP é simples. Para cada MVP, temos
as features a serem trabalhadas, as features em construção e as
features prontas. Isso representa o seguinte fluxo, no nível de
funcionalidade: funcionalidade na fila -> funcionalidade em con-
strução -> funcionalidade pronta.
Uma vez que uma funcionalidade entra na etapa de funcionalidade
em construção, primeiro precisamos quebrar esta funcionalidade
Construindo MVP com Kanban 48
em pedaços menores (histórias ou tarefas, dependendo do estilo da
equipe). Desta forma teremos um conjunto de itens de trabalho a
ser realizado para cada funcionalidade, e cada um desses itens passa
pelo seguinte fluxo: a fazer -> fazendo -> feito.
Visualizando o fluxo para MVP, features e
itens de trabalho
O fluxo de trabalho do MVP com suas features, e das features com
seus itens de trabalho é representado no kanban abaixo.
Kanban de Features do MVP
Note neste Kanban os dois níveis de trabalho: (1) features do MVP,
e (2) histórias (ou tarefas) de uma funcionalidade. Este kanban
demonstra o workflow de MVP e features, e o progresso de cada
funcionalidade perante o andamento das suas histórias (ou tarefas,
representados pela letra W na figura).
Sugiro manter o sequenciador de funcionalidade próximo ao kan-
ban de features do MVP. Desta forma, todos podem verificar onde
está cada MVP e cada funcionalidade. Se já estão em construção,
prontos, ou ainda esperam na fila.
Construindo MVP com Kanban 49
O Sequenciador de Features, agora sem os cartões das features que foram para
o kanban
Segue uma sequência de imagens, demonstrando o Sequenciador
de features e o kanban, dia após dia.
Kanban no dia 1 – passo 1
Construindo MVP com Kanban 50
Kanban no dia 1 – passo 2
Kanban no dia 2
Kanban no dia 3
Construindo MVP com Kanban 51
Kanban no dia 4
Kanban no dia 5 – passo 1
Kanban no dia 5 – passo 2
Construindo MVP com Kanban 52
Kanban no dia 5 – passo 3
Kanban no dia 5 – passo 4
Kanban no dia 5 – passo5
Construindo MVP com Kanban 53
Kanban no dia 6
Kanban no dia 7 – passo 1
Kanban no dia 7 – passo 2
Construindo MVP com Kanban 54
Kanban no dia 7 – passo 3
Kanban no dia 7 – passo 4
Kanban no dia 8
Construindo MVP com Kanban 55
Kanban no dia 9
Kanban no dia 10 – passo 1
Kanban no dia 10 – passo 2
Construindo MVP com Kanban 56
Kanban no dia 10 – passo 3
Limite do WIP de Features
O Kanban apresentado tem um limite de três features no WIP.
Isso está explicitado pela quantidade de linhas neste kanban. Estas
imagens representam um kanban utilizado por um time cross-fun-
cional, com 8 pessoas com perfis e capacitações de desenvolvedor,
testador, ops e UX (User eXperience).
Não é intuito deste livro discutir como decidir o limite WIP de um
kanban, mas somente ilustrar como implementas um kanban para
o MVP e suas features.
MVP, Kanban e bugs
O time entregou o MVP, e segue trabalhando nas funcionalidades
do próximo incremento do produto. Mas agora começou a receber
feedback nas funcionalidades entregues: pequenos bugs e melho-
rias. Como lidar com esse feedback perante o que está planejado
como trabalho para o próximo incremento do produto?
Para isso, também sugiro kanban. Segue abaixo um kanban que
demonstra como um time pode lidar com tal situação.
Kanban com faixa para bugs
Note neste kanban que o time decidiu a capacidade alocada para
lidar com os bugs e para trabalhar no próximo incremento do
produto. Isso fica visível pelos limites de WIP das colunas Doing.
Note também que bugs e melhorias passam por uma etapa de pri-
orização antes de entrarem em Doing. Enquanto que as funcional-
idades do próximo incremento do produto (MVP2 na imagem)
seguem a ordem definida na Lean Inception.
MVP, Kanban e bugs 58
Capacidade para lidar com os bugs
O time deve decidir a capacidade alocada aos MVPs já em produção
perante aos próximos incrementos. Por exemplo 20 % / 80%. Esses
são os valores decididos no kanban exemplificado acima. Tal razão
é definida pelos limites WIPs (Work in Progress) identificados em
Doing.
Capacidade para lidar com os bugs
Ao decidir valores de WIP para bugs/feedback e WIP para as
features em construção, o time estará definindo a capacidade entre
pequenas alterações no que está pronto e na criação do que está por
vir.
MVP, Kanban e bugs 59
Exemplo de Kanban com planejamento de capacidade para buga
No exemplo apresentado, o time decidiu 20 % da sua capacidade
para bugs e feedback; ou seja uma de cinco tarefas em desenvolvi-
mento é relacionada a um bug ou feedback do produto já entregue.
Enquanto que quatro de cinco tarefas em desenvolvimento — 80%
da capacidade — é para o próximo incremento do produto, as novas
features.
Radar de Débito Técnico
Voce usa cartão de crédito? Sabe o que acontece quando não paga
toda a fatura no fim do mes?
Debito técnico funciona da mesma forma. As vezes o squad precisa
deixar algum debito para ser “pago”depois. Isso faz parte do dia-a-
dia ca criação do MVP. O foco é em validar logo seu MVP, por isso
algumas coisas vão ficar para depois. Não faz sentido ter o código
maravilhoso, para algo que talvez seja descartado. Usar o “cartão de
crédito” e comum para qualquer projeto de criação de um produto
digital, para um MVP, ainda mais.
Mas, ao mesmo tempo, se acumular débito demais, a conta (com
juros do cartão) fica muito cara. Por voce precisa fazer a gestão do
seu débito técnico.
Meu colega Glauco Vinicius, enquanto trabalhava em um projeto
que começou com uma Lean Inception, criou e utilizou algo que ele
chamou de radar de debito técnico.
Radar de Débito Técnico 61
Radar de Débito Técnico
Glauco Vinicius implementa o “radar de débitos técnicos“ (imagem
anterior) de forma simples e efetiva. Segue abaixo a explicação do
radar:
• Existem dois eixos: valor entregue para o negócio* (y) e
esforço (x).
• Tudo o que entrega pouco valor de negócio e requer muito
esforço, é despriorizado (não quer dizer que não será feito!)
• Tudo o que entrega muito valor de negócio e requer pouco
esforço é priorizado
• Tudo o que entrega pouco valor de negócio e requer pouco
esforço deve ser avaliado com mais cuidado
• Tudo o que entrega muito valor de negócio e requer muito
esforço deve ser avaliado com mais cuidado
Segundo Glauco, o radar deve ficar visível e acessível para que os
Radar de Débito Técnico 62
integrantes do time adicionem os débitos técnicos á medida em que
desenvolvem as histórias de usuário do MVP.
Após a entrega doMVP, o time deve planejar o incremento seguinte
(alguns times chama de incremento, outros de MVP). O resultado
desse planejamento é um canvas MVP. Ao decidir o que construir
nesse canvas MVP, o squad decide (1) as funcionalidades a acres-
centar e (2) quanto da dívida acumulada devem ser “pagas” com o
próximo incremento do produto.
Para (2), os post-its saem do radar da dívida técnica e viram tra-
balho: funcionalidades a serem entregues no próximo incremento
do produto. E o squad segue trabalhando desta forma: ao planejar o
próximoMVP decidem o que vão comprar de novo (novas features)
e decidem quanto pagar de débito técnico. Enquanto trabalham no
MVP, decidem, diariamente, quanto vão deixar acumular para a
próxima fatura do cartão (próximo MVP).
Eu já tinha visto alguns estilos de radar de débito técnico. Mas esse
é diferente dos outros. O Glauco utilizou as mesmas cores propostas
para as features da Lean Inception. Desta forma fica mais fácil
de se conversar sobre o que ficou para depois: verde, amarelo ou
vermelho, respectivamente: mais tranquilo, médio, e mais esforço
para pouco valor.
Acompanhamento Lean
Qual o status atual do seu MVP em construção? Você precisa
responder essa pergunta de forma clara e direta. Você precisa
informar os membros da equipe e as partes interessadas no MVP.
Projetos mais tradicionais usam relatórios e ferramentas de sta-
tus do projeto, mais tradicionais. Como este livro apresenta uma
solução para projetos mais ágeis e lean, apresento neste capítulo
um acompanhamento via um ferramental mais Lean.
O entendimento da iniciativa via
MVP
O workshop Lean Inception³ gerou o sequenciador de features, no
qual está mapeado o que o time estará construindo para a entrega
dos incrementos do produto enxuto, baseado nos MVPs.
³CAROLI, Paulo. Lean Inception: How to Align People and Build the Right Product, Editora
Caroli, 2017.
Acompanhamento Lean 64
exemplo de evolução de produto de forma enxuta
O planejamento do produto e seus
MVPs
Para cada MVP identificado no sequenciador de funcionalidade é
criado um canvas MVP, o qual responde claramente as indagações
de dois aspectos fundamentais sobre produto e MVP: (1) o que são
as funcionalidades, as personas, as jornadas, a proposta, o custo
e cronograma de entrega do MVP, e (2) que resultado é esperado
quando esse for entregue, e como validaremos tal resultado e
aprendizado.
Acompanhamento Lean 65
o canvas MVP
O Canvas MVP é dividido em sete blocos:
1. Proposta do MVP – Qual é a proposta deste MVP?
2. Personas segmentadas – Para quem é esse MVP? Podemos
segmentar e testar este MVP em um grupo menor?
3. Jornadas – Quais jornadas são atendidas ou melhoradas com
este MVP?
4. Funcionalidades – O que vamos construir neste MVP? Que
ações serão simplificadas ou melhoradas neste MVP?
5. Resultado esperado – Que aprendizado ou resultado estamos
buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como pode-
mos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista para
a entrega deste MVP?
O planejamento baseado em MVPs difere de planejamento tradi-
cional de produtos por aceitar que a entrega somente sinaliza o
momento em que dados de aprendizado começarão a ser coletados.
Acompanhamento Lean 66
Exemplo de Canvas MVP – o MVP do EasyBola
Com uma visão mais tradicional, o acompanhamento verifica o
quão próximo estamos de completar a construção das funcional-
idades de tal MVP. Enquanto, com uma visão mais moderna,
o acompanhamento é baseado no aprendizado,na validação de
hipóteses do negócio, em um estilo mais arrojado, digno das start-
ups do Vale do Silício.
Misturando construção com adaptação, convergência comdivergên-
cia, controle com experimentação, o planejamento baseado no
Canvas MVP auxilia a criação de produtos enxutos equilibrando
inovação e entrega.
O acompanhamento da criação do
produto via MVP
Devemos fazer o acompanhamento periódico (por exemplo sem-
anal, ou a cada Sprint – para das equipes usando Scrum) em relação
Acompanhamento Lean 67
a criação do produto. Tal acompanhamento deve ser realizado
comparando o estado atual com o que estava planejado no canvas
MVP. Para tanto artefatos devem ser apresentados:
1. Status report do MVP
2. Burn up do MVP em construção
3. O Diagrama de Fluxo Cumulativo
Status report do MVP
modelo de status report do MVP
Uma lista pequena com poucas e visíveis informações. Assim deve
ser um status report efetivo. Por se tratar de features de um MVP,
tal status report não somente é possível, como indicado!
Um status report simples auxilia no entendimento comum sobre
o andamento da criação do MVP. Informações simples e diretas:
Qual nome e o que compõe este MVP? Qual data prevista? Quantas
features já terminaram?
Acompanhamento Lean 68
Burn up do MVP em construção
o burn-up de MVP
O Burn-up de funcionalidades do MVP ajuda com o gerenciamento
de tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
funcionalidades do MVP.
Ao final do planejamento, o gráfico burn-up demonstra a visão
compartilhada do que deve ser alcançado. E isto fica claramente
visível traçando uma linha horizontal de escopo e uma linha
vertical de data de entrega do MVP. A interseção dessas linhas
representa o resultado no tempo esperado.
O gráfico é atualizado conforme as funcionalidades são construídas:
a data atual, e o total de funcionalidades completas são alterados.
Desta forma permite-se identificar possíveis desvios na duração
esperada para a construção do MVP.
Acompanhamento Lean 69
Diagrama de Fluxo Cumulativo
o Diagrama de Fluxo Cumulativo
O Diagrama de Fluxo Cumulativo (CFD – Cumulative Flow Dia-
gram, em Inglês) fornece uma representação gráfica do andamento
do trabalho, esclarecendo gargalos, e alertando sobre possíveis
instabilidades do sistema. É uma ferramenta simples, porém muito
informativa, que descreve o trabalho em andamento (WIP – Work
in Progress, em inglês), taxa de entrada, taxa de saída, tempo de
atravessamento , taxa de transferência, tempo decorrido, trabalho
completo, trabalho restante e escopo total do trabalho.
O Diagrama de Fluxo Cumulativo é uma valiosa ferramenta de
gerenciamento para rastrear e prever a realização de todas as fun-
cionalidades planejadas. Ele apresenta uma visão mais abrangente
que o burn-up e o status report do MVP, complementando-os com
a visão de fluxo contínuo.
Após entregar o MVP, muito provavelmente, a equipe continua as
criar os incrementos do produto. O burn-up e o status repost do
MVP podem ter chegado ao fim, mas o CFD não. Nele a equipe
mantém o foco no fluxo de trabalho, antes, durante e depois da
entrega do MVP e os incrementos do produto.
Status report do MVP
Segue um modelo de status report para acompanhamento e moni-
toramento da criação das features do MVP.
modelo de status report de MVP
Neste modelo você pode verificar as seguintes partes, listadas na
figura abaixo.;
modelo de status report de MVP – todos itens
Status report do MVP 71
Nome do time e ID do MVP
O nome do time a identificador do MVP.
Nome do MVP
O nome do MVP é utilizado dentre várias conversas, desde a sua
concepção, passando pela criação, até a entrega, coleta de feedbacks
e validações de hipóteses. Ter um nome claro e específico é essencial
para evitar quaisquer confusão sobre o MVP em questão.
Estado atual
Qual situação atual desteMVP? Tudo ok para o término das features
do MVP na data prevista? Sim (verde), médio (amarelo), ou não
(vermelho).
Data atual e data prevista
Os relatórios de status report de MVP são úteis para o acompan-
hamento e decisões atuais, bem como para o histórico da criação
do produto como um todo. Além disso a demonstração de ambas
as datas (atual e prevista) deixa claro o tempo remanescente para
alcançar a entrega na data planejada.
Lista de features do MVP
Uma tabela contendo a lista de features prevista para o MVP, com
as seguintes informações para cada funcionalidade: descrição, nível
Status report do MVP 72
de incerteza, estado, e % de completude.
Nível de incerteza da funcionalidade
Descrição e nível de incerteza da funcionalidade são dados prove-
nientes desde a concepção dos MVPs. O nível de incerteza da
funcionalidade refere-se ao grau em que a funcionalidade é incerta,
a partir do ponto de vista do entendimento de negócio e do
entendimento técnico. Isso é indicado pela cor os quais são verde,
amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza,
respectivamente.
O nível de incerteza da funcionalidade não é alterado. Tal infor-
mação serve para relembrar a todos o entendimento original sobre
tal funcionalidade. Todos e quaisquer riscos ou ações relacionadas
ao MVP devem ser listadas nos campos de detalhamento e texto
descritivo do status report (item 8 abaixo).
Estado e % de completude da
funcionalidade
O estado e % de completude da funcionalidade representam o
estado atual da funcionalidade em relação a sua completude. Esses
parâmetros devem ser alterados nos relatórios, refletindo o estado
atual de cada funcionalidade.
O estado varia entre: não começou -> em construção -> pronto.
O % de completude varia entre 0 e 100%. É comum que times deci-
dam valores arredondados e pré-definidos como 0%, 25%, 50% 75%
e 100%. Alguns times utilizam fórmulas para calcular tais valores,
enquanto outros decidem tais valores com menos matemática. O
importante é que o racional do valor demonstrado seja o mesmo
entre diferentes features.
Status report do MVP 73
Detalhamento e texto descritivo
Todas e quaisquer anotações relevantes sobre o MVP e suas fun-
cionalidade que não foram claramente demonstradas nos itens
anteriores. Por exemplo: dependências externas, riscos, problemas,
e ações realizadas.
Burn-up de Features do
MVP
O Burn-up de Features do MVP ajuda com o gerenciamento de
tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
features do MVP. É uma ferramenta essencial para dar visibilidade
ao planejamento e para realizar o acompanhamento da construção
das features do MVP.
A sequência de imagens mostra um exemplo de burn-up em mo-
mentos diferentes. Começando no dia 30/06, quando o burn-up foi
criado com o planejamento de acordo com o ritmo esperado de
construção das features. Seguindo com instantâneos do burn-up
nos dias 08/07, 18/07 e 28/07, quando todas as features do MVP
terminaram, e o mesmo foi entregue.
burn-up de features do MVP no dia 30/06
Burn-up de Features do MVP 75
burn-up de features do MVP no dia 08/07
burn-up de features do MVP no dia 18/07
burn-up de features do MVP no dia 28/07
Burn-up de Features do MVP 76
Os eixos do burn up
O eixo vertical é a quantidade de features para o MVP, e é medido
em unidades, por exemplo 9 features. O eixo horizontal representa
o tempo, normalmente medido em dias ou semanas.
exemplo de burn-up de MVP iniciado em 30/06 e planejado para 30/07
O ritmo da construção do MVP
Avantagemda gráfico burn-up é a visão compartilhada do que deve
ser alcançado. E isto fica claramente visível traçando uma linha
horizontal de escopo e uma linha vertical de data de entrega do
MVP. A intersecção dessas linhas representa o resultado no tempo
esperado.
Ao desenhar uma linha diagonal a partir do ponto de partida (o
início do tempo para a construção da primeira funcionalidade do
MVP) para o resultado no tempo esperado, você tem uma indicação
do ritmo linear de construção do MVP. Na figura abaixo, este
ritmo está representadocomo a linha diagonal , representando um
planejamento de ritmo linear.
Burn-up de Features do MVP 77
exemplo de burn-up com ritmo linear
Entretanto o ritmo de término de features de um MVP não é linear.
A figura abaixo demonstra uma curva que melhor representa o
ritmo de entrega esperado.
exemplo de burn-up com ritmo não linear
Equipes ágeis experientes lidam com tal curva de duas formas: (1)
Iteração ou Sprint 0, ou (2) entendimento do tempo de atravessa-
mento inicial.
Iteração ou Sprint 0 é um termo comum utilizado para ressaltar
que não haverá entrega de funcionalidade numa primeira iteração
ou Sprint. O gráfico abaixo demonstra como tal artimanha (Sprint
0) alinha a expectativa de entrega de funcionalidade com o ritmo
inicial ainda por começar.
Burn-up de Features do MVP 78
exemplo de burn-up com Sprint 0
A construção de uma funcionalidade tem um tempo mínimo de
atravessamento (ou lead time, em inglês). Por exemplo, o mínimo
que se leva para criar uma funcionalidade são 5 dias. Por tal
motivo é impossível ter o término de qualquer funcionalidade nos
primeiros cinco dias. Esse fato explica a barriga da curva do ritmo
esperado. Após a entrega das primeiras funcionalidades, o ritmo de
entrega vai ser estabelecido, e a curva tende a virar uma reta na
qual o ritmo de entrega fica estabelecido.
Verificando o progresso
De tempos em tempos você deve verificar a quantidade de features
já construídas e a quantidade total de features planejadas para o
MVP. A distância entre as linhas horizontais marcando as features
atualmente prontas e a última funcionalidade a ser construída é a
indicação da quantidade de features restantes.
Burn-up de Features do MVP 79
features construídas e restantes
Quando as duas linhas se encontram, todas features doMVP estarão
completas. A distância entre essas linhas é uma medida poderosa
de quão perto você está de completar o MVP.
verificando progresso
Verificar regularmente o progresso é uma parte importante da
gestão da construção do MVP. Há duas atualizações básicos para
o burn-up de features do MVP: (1) o tempo mudou; a seta que
representa a data atual deve ser movido para a direita até a posição
que representa a data atual, e a linha da data atual deve ser ajustada;
e (2) terminou a construção de uma funcionalidade; o total de
features completas deve ser alterado, e a linha de total de features
completas deve ser ajustada.
Burn-up de Features do MVP 80
atualizações no burn-up: data atual e funcionalidade construída
Este mecanismo de atualizações do total de features construídas e
da data atual permite identificar de imediato, um desvio na duração
esperada para a construção do MVP. Assim que constatado, este
problema deve ser discutido e ações corretivas devem ser tomadas
ainda em um estágio inicial, e não quando é tarde demais.
A linha de escopo do MVP
Uma informação importante do gráfico burn-up é a linha de escopo
doMVP, a linha horizontal contabilizando o total de features plane-
jadas para o MVP. Essa linha define claramente se e quando novas
features foram adicionados ou removidos durante a construção
do MVP. Ela também permite que você visualize a intersecção
desta linha horizontal para a linha vertical, que representa a data
planejada para a entrega do MVP.
Todas partes a serem construídas para umMVP devem ser features.
Se novas features surgem, elas devem ser adicionados à lista de
features e a linha de escopo deve ser ajustada. Dessa forma, a
nova linha permite identificar facilmente quando features estão
sendo adicionadas, o que poderá afetar o tempo de conclusão do
MVP. O ato de adicionar uma nova funcionalidade é um sinal
importante de que o tempo restante para a construção doMVP deve
Burn-up de Features do MVP 81
ser repensado. A linha de escopo também rastreia onde features
estão sendo removidos para cumprir um prazo fixo. Este cenário
é ilustrado na figura abaixo. Novamente, é importante entender
como a remoção de uma funcionalidade doMVP vai afetar as outras
features, e é algo que precisa e deve ser claramente discutido com
todos.
exemplo de burn-up de MVP após redução de duas features
Diagrama de Fluxo
Cumulativo
O Diagrama de Fluxo Cumulativo é uma ferramenta valiosa de
gerenciamento para: 1) rastrear e prever a realização de itens do
trabalho; e 2) indicar a necessidade de agir sobre o fluxo e o processo
de melhoria.
O Diagrama de Fluxo Cumulativo (ou em Inglês Cumulative Flow
Diagram, e por isso abreviado para CFD) fornece uma represen-
tação gráfica do andamento do trabalho no sistema, esclarecendo
gargalos, e alertando sobre possíveis instabilidades do sistema. É
uma ferramenta simples, porém muito informativa, que descreve
o trabalho em andamento (WIP – Work in Progress, em inglês),
taxa de entrada, taxa de saída, tempo de atravessamento , taxa
de transferência, tempo decorrido, trabalho completo, trabalho
restante e escopo total do trabalho.
Abaixo, uma sequência que mostra CFDs nas primeiras nove sem-
anas de um projeto.
CFD na semana 2
Diagrama de Fluxo Cumulativo 83
CFD na semana 5
CFD na semana 7
CFD na semana 10
Diagrama de Fluxo Cumulativo 84
Interpretando o CFD
Abaixo, está um CFD com muitos de seus parâmetros. Cada um
deles será explicado em detalhes nas próximas seções.
parâmetros de fluxo em um Diagrama de Fluxo Cumulativo
Antes de tudo, você deve entender como o CFD é construído.
O CFD apresentado é construído baseado em uma tabela que
é atualizada semanalmente. Abaixo, está a tabela com seu CFD
correspondente.
Diagrama de Fluxo Cumulativo 85
modelo em Excel do CFD
Essa tabela descreve o fluxo de trabalho do sistema como: escopo
->WIP -> pronto; ou, em outras palavras, a fazer -> fazendo -> feito.
Muitas ferramentas constroem o CFD automaticamente para você,
poupando o trabalho manual para a criação do mesmo. Entretanto,
para o seu aprendizado, eu recomendo que você construa um CFD
simulando o que acontece em um projeto real. O CFD apresentado
neste artigo foi gerado pelo Excel. Você pode fazer o download deste
modelo em http://www.caroli.org/cumulative-flow-diagram/.
Itens de trabalho
O número em cada célula da tabela apresentada representa a
quantidade de itens de trabalho naquela etapa para tal semana.
É importante esclarecer que o item de trabalho é uma unidade
que faz sentido para quem vai ler o CFD. Exemplos comuns
de itens de trabalho na área de desenvolvimento de software
são: funcionalidades, ponto de função, histórias, ponto de
http://www.caroli.org/cumulative-flow-diagram/
Diagrama de Fluxo Cumulativo 86
histórias, bugs, tarefas. Outra consideração essencial é que não
se misture diferentes itens de trabalho em um mesmo CFD.
Ou seja, um CFD de funcionalidades deve conter somente
funcionalidades, enquanto que um CFD de pontos de histórias
deve conter somente pontos de histórias.
A fazer / Fazendo / Feito
Apesar de os CFDs poderem e serem comumente usados para fluxos
de trabalho com muitas fases, eu recomendo começar com um sim-
ples fluxo a fazer -> fazendo -> feito para entender completamente
o CFD. Depois, quando você já tiver dominado o CFD e sentir a
necessidade de mais dados, considere dividir a fase “fazendo” em
um fluxo de trabalho mais detalhado.
A quantidade de trabalho em relação aos itens a fazer / fazendo /
feito é descrita no CFD na imagem abaixo.
A fazer / fazendo / feito no CFD
Diagrama de Fluxo Cumulativo 87
Quando estará pronto?
Quando todo o trabalho estará pronto? Esta é a pergunta mágica
que todo mundo tenta responder. Ao usar o CFD, há duas maneiras
simples de responder a essa questão: 1) graficamente; ou 2) matem-
aticamente.
taxa de conclusão
Neste momento específico (representado pela seta azul na semana
6), você sabe a quantidade de trabalho que está pronta, e você sabe o
tempo decorrido. Com esses dois parâmetros, você pode desenhar
a linha da taxa de conclusão (a seta amarela na próxima figura).
Você tem que responder a questão estendendo a linha da taxa de
conclusão até que ela alcance o total da linha do escopo de trabalho.