SlideShare uma empresa Scribd logo
1 1
Métricas acionáveis de projeto
Kleitor Franklint
Lean PMO consulting
Agile Coach
Clipzen.blog
2 2
Esta apresentação faz parte do conjunto de dois
cursos:
1. Métricas acionáveis de projeto
2. Práticas avançadas com métricas acionáveis
Métricas acionáveis de projeto
3 3
O que veremos?
 Gestão probabilística de projetos
 Fluxo: influência e impacto
 Coleta de métricas acionáveis
 Visualização e análise do fluxo de
trabalho
 Previsão para itens individuais
 Previsão para múltiplos itens
Métricas acionáveis de projeto
4 4
Como estamos lidando com a incerteza:
faturamento e satisfação do cliente?
Fonte: https://clipzen.blog/2017/11/28/noestimates-my-way-to-do/
PREVER
5 5
Sua vez agora!!
Por que estimar?
Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
6 6
Porque clientes pergutam: quanto tempo demorará e
quanto custará para nos entregar?
Eles precisam de uma data de entrega e uma estimativa
orçamentária.
Por que estimar?
Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
7 7
Quanto tempo demorará e quanto custará para nos
entregar?
Esta pergunta é melhor respondida com uma estimativa
ou com uma previsão?
Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
8 8
Diferença entre estimativa e previsão
Imagem: http://blog.crisp.se/tag/estimating
9 9
Definições essenciais
PONTO DE DEPARTIDA: Um ponto específico em que uma unidade de
trabalho se transforma de uma idéia arbitrária em um item de trabalho
que deve ser imediatamente atualizado e completado.
PONTO DE CHEGADA: Definido como entrega para um usuário final ou
entrega para algum outro time ou processo.
TRABALHO: Qualquer unidade discreta ou indireta de trabalho de valor
de cliente é um candidato de trabalho - nomeado como item de trabalho
(história, épico, característica, requisito, caso de uso, aprimoramento, ...)
Imagem: https://www.infoq.com/articles/noestimates-monte-carlo
10 10
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Exercício 1- item 1
11 11
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Entender as fronteiras ajuda a entender
o custo do tempo
12 12
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Conceitos essenciais
1. Quanto tempo leva cada um desses itens para passar por nosso
processo?
2. Quanto tempo para completar?
3. Quando isso será feito?
TEMPO DO CICLO ( CYCLE
TIME): A quantidade de
tempo decorrido que um
item de trabalho gasta como
trabalho em andamento. É
sobre “quanto tempo”.
Também pode ser usado como preditor de custo
 A quantidade de tempo que leva para obter feedback dos clientes
 Conhecido também como “service time”.
13 13
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Exercício 2- itens 2 e 3
14 14
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Coletando dados
De onde se extrai os dados?
Pra que coletar dados?
15 15
Coletando quatro grandes áreas
QUALIDADE
(QUÃO BEM)
• Demanda de falha.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Percentis
16 16
Exercício 3: coletando tempo do fluxo
Item 4
QUALIDADE
(QUÃO BEM)
• Demanda de falha.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Percentis
17 17
Definições essenciais
TAXA DE TRANSFERÊNCIA (THROUGHPUT):
Takt, Cycle, Lead time
Quantidade de unidades (WIP) concluídas num determinado período.
Taxa na qual o sistema atinge seu objetivo.
Por exemplo: 10 histórias por semana, 5 clientes por hora, etc.
Ajudam a responder perguntas tais como:
Quantos itens completos por unidade de tempo?
Quantos recursos eu preciso na próxima versão?
Compreender throughput em cada
etapa ajudará a identificar as
restrições no fluxo de trabalho e a
encontrar pontos para melhorias de
processo
18 18
Exercício 4: coletando produtividade
Item 6
QUALIDADE
(QUÃO BEM)
• Demanda de falha.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Percentis
19 19
Principal opção para muitos. Equipes
trabalhando mais horas incluindo os
fins de semana e tentando roubar
recursos de outros projetos, além da
possibilidade contratar mais pessoal.
Tentar impactar o Throughput desta
maneira aumenta o WIP mais rápido
que a taxa de entrega, e os tempos do
ciclo de entrega só aumentarão.
Padrões para aumentar a previsibilidade do lançamento
Aumentar a taxa de transferência
20 20
Carga de falha ( Demanda de falha)
Controla quantos itens de trabalho o sistema processa devido a má
qualidade. Isso inclui defeitos de produção (bugs) no software e novos
recursos solicitados pelos usuários devido a uma usabilidade fraca ou a
uma incapacidade de antecipar adequadamente as necessidades dos
usuários.
Os defeitos representam o custo de
oportunidade e afetam o tempo de
entrega e o throughput do sistema
Kanban.
21 21
Exercício 5: coletando qualidade da produtividade
Item 6
QUALIDADE
(QUÃO BEM)
• Demanda de falha.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Percentis
22 22
Percentis e intervalo de confiança
Faixa de valores possíveis para a magnitude (risco relativo) real do efeito.
Temos X% de chance do intervalo conter o verdadeiro valor da média
populacional.
Em vez de estimar o parâmetro por um único valor, é dado um
intervalo de estimativas prováveis.
23 23
Intervalo de confiança
Estimar pra quê?
Fonte: “By the power of metrics”, Wolfgang Wiedenroth
Percentis e intervalo de confiança
24 24
Percentis e intervalo de confiança
Estimar pra quê?
Previsão é melhor
Aproximadamente certo é melhor que exatamente
errado
Ao invés de "que data está pronto?" pergunte, "Qual
é a probabilidade de terminar este pedido dentro de
tantos dias?"
25 25
Exercício 6: calcule o possível período de entrega com
intervalos de confiança. (ITEM 7)
QUALIDADE
(QUÃO BEM)
• Demanda de falha.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Percentis
26 26
Previsibilidade da entrega
Estabilidade e transação
X
Variabilidade e retenção
http://theprocessconsultant.com/classifying-different-process-types/
27 27
Por que é importante estabilizar a entrega?
1. Para criar previsibilidade
2. Ritmo sustentável
3. Identificar capacidade do time
28 28
Por que gestão de fluxo?
29 29
Definições essenciais
FLUXO: movimento e a entrega de valor ao cliente através
de um processo. Portanto, todo o nosso processo deve ser
orientado em torno do fluxo otimizado.
30 30
É sobre ler o seu sistema para tomar as melhores
decisões possíveis com a informação disponível na
busca do ROI mais alto.
Gestão de fluxo
31 31
Ferramenta para o alinhamento, não um critério de sucesso, ele
mede seu fluxo para determinar se você ainda está alinhado
Planos
Imagem: https://thedigitalprojectmanager.com/project-plan-guide/
32 32
Para fins de planejamento, é melhor modelar
projetos como um fluxo de itens de trabalho
através de um sistema.
Planos
Mas, por que?
33 33
O que significa
para você?
Projeto terminado na metade do tempo?
Projeto terminado no dobro do tempo?
Gestão de fluxo
https://www.15five.com/blog/4-scientifically-proven-methods-increase-productivity/
34 34
Fazer na metade do tempo não significa metade do custo nem
ser mais produtivo. Pode haver (entre outros) custos de
qualidade não levados em conta.
Dobro do tempo não é o dobro do custo: muitos dos custos
podem ser desperdícios, incluindo custo de retenção.
SÓ O TEMPO NÃO DIZ MUITO
Por que gestão de fluxo?
35 35
PORQUE AS FILAS INFLUENCIAM?
Gestão de fluxo
Imagem: http://godschildfoundation.org/?tag=queue
36 36
PORQUE AS FILAS INFLUENCIAM
 Sem filas o sistema se move para frente em direção
do fluxo e o valor é entregue sem demora
 Filas criam delay na entrega
Por que gestão de fluxo?
37 37
Dentre as causas estão:
1. variabilidade:
2. sobrecarga de capacidade humana;
3. grandes lotes e descoberta tardia de surpresas
Mas em geral só o segundo tipo é visto como fila no
desenvolvimento de produto.
FILAS
Por que gestão de fluxo?
38 38
Em que instante surge o
atraso e a sobrecarga?
Por que gestão de
fluxo?
Em que instante o projeto precisa ser
melhor monitorado?
https://chrisandsusanbeesley.com/how-to-overcome-information-overload/overload/
39 39
A relação de utilização com o tamanho da
fila não é linear.
O atraso e a sobrecarga podem ocorrer
em qualquer período e percentual de
utilização. A velocidade diminui bem
antes da capacidade ser alcançada.
Por que gestão de fluxo?
40 40
Em uma rodovia, por exemplo, a desaceleração torna-se perceptível
entre 50 em 100% de utilização e as filas crescem.
Por que gestão de fluxo?
41 41
Limpar a fila demora mais que
construí-la.
Por que gestão de fluxo?
A variação e aleatoriedade com
probabilidade nos mostra que o
modelo não é determinista, mas
estocástico.
42 42
O IMPACTO NO CYCLE TIME NÃO É LINEAR
Há quem creia que quanto mais trabalho atribuído mais
será entregue e que somente quando o recurso chegar a
100% de utilização haverá degradação da velocidade e
qualidade.
43 43
O IMPACTO NO CYCLE TIME NÃO É LINEAR
Fonte: https://less.works/less/principles/queueing_theory.html
44 44
Multitarefa e
desaparecimento artificial
das filas
 Tempos mais longos no ciclo de entrega
 Produz ritmo insustentável
 Aumenta a complexidade da gestão
 Aumenta aumento do número de defeitos oriundos do impacto
humano
 Aumento de custos pela mudança de contexto tornando a equipe
menos efetiva.
45 45
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
“se você tiver um problema que requer mais de uma
semana de horas extras, você tem um problema que
não deveria ser corrigido com horas extras de forma
alguma".
Ken Beck (criador do XP)
46 46
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
1. Sem cycle time previsível e estável não se pode usar métricas para
previsões futuras
2. Ao escolher a cadência de entrega deve-se estar ciente do custo
econômico da escolha.
• Custo de transação associado ao release
• Custo de retenção associado a entrega.
Previsibilidade e o custo da retenção
47 47
Estabilize a entrega
Cadência e feedback x retenção e inércia
Muitas equipes ágeis maduras geram releases com um clique,
mas ainda esperam 3 semanas antes de obter feedback de
seus clientes ( internos e externos)
Imagem: http://www.humanresourcesonline.net/retain-young-talent-pr-world/
48 48
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Por que o custo da retenção é ruim?
1. Mais itens agrupados  menor custo da transação  maior
custo de retenção.
2. Cada recurso aguarda mais tempo gerando perda comercial
3. Colabora para feedback desatualizado
4. Decisões desatualizadas
5. Menor envolvimento do cliente
49 49
0
0,5
1
1,5
2
2,5
3
3,5
29/11/2017
30/11/2017
01/12/2017
02/12/2017
03/12/2017
04/12/2017
05/12/2017
06/12/2017
07/12/2017
08/12/2017
Pronto
Linear (Pronto)
Visualizando o fluxo do sistema.
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
0,5
1
1,5
2
2,5
3
3,5
0 0 1 4 8 18 21 24 Mais
Freqüência
% cumulativo
50 50
Por que visualizar o fluxo?
51 51
QUANDO O QUADRO KANBAN NÃO É
SUFICIENTE.
Olhar no quadro de kanban em um dia específico não facilita a
resposta a perguntas como estas:
• Quanto tempo demora para completar itens de trabalho nesta
etapa do processo?
• Com que frequência vemos filas nesta etapa? Por quanto tempo
elas duram?
• Essas filas são um evento especial ou acontecem regularmente?
52 52
Visualizando o fluxo do sistema.
Rastrear a avançar com precisão
53 53
O termo estatístico implica que você usará análise estatística no
gráfico para obter melhor visão e tendências reais.
GRÁFICOS SPC (Controle de processo estatístico)
Mostram tendências de como o processo está indo ao longo do
tempo.
54 54
Quais e quantos dados você precisa para desenhar um?
GRÁFICOS SPC
55 55
HISTOGRAMAS DE CYCLE TIME
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
0,5
1
1,5
2
2,5
3
3,5
0 0 1 4 8 18 21 24 Mais
Freqüência
% cumulativo
Representação gráfica (um gráfico de barras verticais ou
barras horizontais) da distribuição de frequências de um
conjunto de dados quantitativos contínuos.
http://www.portalaction.com.br/estatistica-basica/16-histograma
56 56
2. Mostram a distribuição do fluxo de trabalho
3. Mostram frequência ( numero de ocorrências) de um cicle time
específico
4. Mostra como seria a distribuição excluindo itens bloqueados
5. Mostram medidas de tendência central
6. Mostram a forma dos dados ajudando a melhor compreender os
padrões de Cycle Time
HISTOGRAMAS DE CYCLE TIME
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
0,5
1
1,5
2
2,5
3
3,5
0
0
1
4
8
18
21
24
Mais
Freqüência
% cumulativo
1. Fornecem uma visão espacial e
condensada com base na
freqüência de ocorrência dos
tempos de um ciclo.
57 57
2. O cycle time é visível no eixo X
3. Conhecer a visão subjacente dos dados não é necessário para
previsões
4. Ajudar a visualizar o cycle time como uma forma, nao como um
número.
HISTOGRAMAS DE CYCLE TIME
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
0,5
1
1,5
2
2,5
3
3,5
0
0
1
4
8
18
21
24
Mais
Freqüência
% cumulativo
58 58
HISTOGRAMAS DE CYCLE TIME
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
0,5
1
1,5
2
2,5
3
3,5
0
0
1
4
8
18
21
24
Mais
Freqüência
% cumulativo
Componentes
O eixo dos X é o tempo de ciclo ( lead, takt, cycle)
O eixo Y são o numero de itens do backlog ( tickets finalizados)
Linhas percentis verticais (como no diagrama de dispersão)
Etapas
Criar classes de distribuição
Inserir histograma
Usar distribuição ou classes de intervalo.
Aplicar Curva S
59 59
Histograma
 Fornece informações sobre tendências e
comportamentos
 Permite análise da variabilidade
 Mostra a forma da distribuição: normal, não normal
http://www.portalaction.com.br/probabilidades/62-distribuicao-normal
https://support.minitab.com/pt-br/minitab/18/help-and-how-to/quality-and-process-
improvement/capability-analysis/how-to/capability-analysis/nonnormal-capability-
analysis/interpret-the-results/all-statistics-and-graphs/graphs/
60 60
Formato dos dados e variabilidade
Distribuição Weibull
Seu cycle time não é uma distribuição normal
61 61
Exercício 7 – Histograma do cycle time
Item 8
62 62
0
0,5
1
1,5
2
2,5
3
3,5
29/11/2017
30/11/2017
01/12/2017
02/12/2017
03/12/2017
04/12/2017
05/12/2017
06/12/2017
07/12/2017
08/12/2017
Quant. de itens entregues
Pronto
Linear (Pronto)
Gráfico de dispersão
63 63
Gráfico de
dispersão
Características
• Eixo x é a linha do tempo ( calendário)
• Eixo Y representa o cycle time
• Cada ponto no gráfico indica o cycle time a data do item que
terminou.
0
0,5
1
1,5
2
2,5
3
3,5
29/11/2017
30/11/2017
01/12/2017
02/12/2017
03/12/2017
04/12/2017
05/12/2017
06/12/2017
07/12/2017
08/12/2017
Quant. de itens entregues
Pronto
Linear (Pronto)
• Linhas percentis são preferíveis - é a sua robustez em face de
outliers
• Recomenda-se usar os percentis 50º, 70º, 85º, 95º
Quantos % de chance temos de terminar em x dias ou menos?
64 64
Gráfico de
dispersão
Características
• Densidade e dispersão (outliers) indicam algum
tipo de variabilidade
0
0,5
1
1,5
2
2,5
3
3,5
29/11/2017
30/11/2017
01/12/2017
02/12/2017
03/12/2017
04/12/2017
05/12/2017
06/12/2017
07/12/2017
08/12/2017
Quant. de itens entregues
Pronto
Linear (Pronto)
65 65
Exercício 7 -Gráficos de dispersão
Item 9
Imagem: https://www.infoq.com/articles/kanban-siemens-health-services
66 66
Gráfico cumulativo - CFD
67 67
CFD
Para que serve?
1. Para medir e comunicar o progresso
2. Para responder se o time consegue entregar
3. Para visualizar a estabilidade e previsibilidade
da entrega
4. Para melhor distribuição de frequência
5. Não serve para projeção mas para
introspecção.
6. Não é sobre conclusões, mas análise
68 68
CFD
• Gráfico que exibe o progresso de um processo em que há
diversos estágios pelos quais um item deve passar até
estar pronto.
• Quando o sistema demonstra estabilidade as bandas do
diagrama serão suaves e sua altura estável.
• Variações indicam áreas potencialmente incômodas que
requerem atenção.
69 69
CFD – composição
Para que serve?
Para medir e comunicar o progresso
Para responder se o time consegue
entregar
Para visualizar a estabilidade e
previsibilidade da entrega
Para melhor distribuição de frequência
Não serve para projeção mas para
introspecção.
Não desenhe conclusões nele, ele é sobre
resposta certa.
Linha horizontal superior: mudança de escopo
Eixo vertical: numero de tarefas, quantos itens há na fila.
Horizontal: linha do tempo ( dias, horas, semanas, etc).
70 70
CFD – composição
Para que serve?
Para medir e comunicar o progresso
Para responder se o time consegue
entregar
Para visualizar a estabilidade e
previsibilidade da entrega
Para melhor distribuição de frequência
Não serve para projeção mas para
introspecção.
Não desenhe conclusões nele, ele é sobre
resposta certa.
Curvas ( inclinação): número de itens em cada parte ( etapa do
processo) do fluxo de entrega.
Linha superior = chegadas acumuladas
Linha inferior = partidas cumulativas
71 71
CFD – composição
Para que serve?
Para medir e comunicar o progresso
Para responder se o time consegue
entregar
Para visualizar a estabilidade e
previsibilidade da entrega
Para melhor distribuição de frequência
Não serve para projeção mas para
introspecção.
Não desenhe conclusões nele, ele é sobre
resposta certa.A distância vertical entre duas linhas é a quantidade total de
trabalho (WIP) que está em andamento.
Lead time, cycle time: distância horizontal entre duas linhas
(tempo médio de ciclo = data da linha inferior - data da linha
superior + 1)
72 72
Exercício 8 – item 10
Modelando CFDS
73 73
CFDs: algumas análises
• Alterações na estabilidade da entrega
• Aumento de escopo
• Análise das 3 pernas do fluxo de entrega
• Crescimento de etapas
74 74
Por que é importante entender o CFD?
1. Análises contínuas de risco e cenários de "e se".
2. Análise da capacidade de melhora da precisão do rastreamento de
custos através da correlação do tempo do ciclo com as alocações
orçamentárias reais.
3. Melhora a precisão do cálculo dos custos unitários de uma história,
característica e / ou lançamento.
75 75
• Produz stand-ups mais significativos
• Alinha capacidade e demanda
• Prever custos prováveis junto com datas, além de poder
colocar um valor em dinheiro em reduções ou aumentos do
tempo do ciclo.
• Melhoram a comunicação com as principais partes
interessadas para respostas baseadas em tempo e não
pontos de história.
Por que é importante entender o
CFD?
76 76
Ajudam a eliminar a emoção e a recriminação associadas à
estimativa.
Ajudam a melhorar a efetividade operacional, pois produz
uma visão em “tempo real” dos blocos sistêmicos, da
variabilidade e dos estrangulamentos.
Por que é importante entender o
CFD?
77 77
 Ajuda a entender onde estamos enfrentando problemas de
capacidade
 Ajuda a visualizar tempo de entrega, tempo de bloqueio,
tempo esperado
 As métricas obtidas a partir deles pode ser usadas para
produzir retrospectivas mais orientadas.
Por que é importante entender o
CFD?
78 78
Quantas coisas eu preciso medir?
Primeiro... Por que métricas?
79 79
“Para afetar mudanças positivas em seu
processo geral, você não precisa passar por
uma transformação ágil complexa nem precisa
fazer estimativas e planejamento mais intensos.
Na maior parte das vezes, tudo o que você precisa fazer é
controlar o número de coisas em que você está trabalhando em
qualquer momento. Simples, mas é verdade.”
(DANIEL VACANTI, BENNET VALLET, “Actionable Metrics at Siemens Health Services”)
80 80
Não podemos controlar as ondas da incerteza, mas
podemos aprender como surfar
Como modelar e lidar com a
incerteza?
Imagem: https://www.dreamstime.com/royalty-free-stock-photography-surfing-shark-image16396567
81 81
Controle de processo estatístico (SPC)
Teoria da variação
John Seddon
Todo sistema varia, isto significa não podemos esperar que o
trabalho seja concluído como resulto médio.
82 82
Princípio 1- as coisas variam
 Há variação natural em todos os sistemas. Não se surpreenda
se obtiver resultados diferentes de pessoas diferentes ( ou das
mesmas) em dias diferentes.
Pequenas amostras não podem dizer se isso é bom ou ruim e
está dentro ou fora da variação normal.
 Usando um gráfico SPC, você pode ver se a variação é
previsível (dentro dos limites de controle) ou imprevisível (fora
os limites de controle).
 Por exemplo, o desempenho de um trabalhador pode parecer
excelente. Quando você obtém uma mostra maior, no entanto,
vê que era exatamente o que esperar, dada a variação natural.
SPC – Teoria da variação
83 83
Princípio # 2: compreender a variação te dirá o que
esperar.
 Equipes geralmente esperam estar na média todas as vezes.
Mas isso não vai acontecer, porque somos seres humanos
trabalhando com conhecimento, e isso naturalmente tem
variações.
 Isto implica dizer que o time pode estar por vezes acima da
média (vai pra casa triste) e outras abaixo da média ( via pra
casa feliz)
 Definir o alvo em direção abaixo da média, embora pareça
bom, pode produzir ainda mais fracasso, pois há que custo
tentarão alcançar esse objetivo?
SPC – Teoria da variação
84 84
Princípio # 3: Trabalhe sobre as causas das variações,
que sempre são encontradas no sistema.
A maioria da variação de desempenho é encontrada no próprio
sistema, fora do controle dos indivíduos que trabalham nela.
Considere todas as coisas que afetam sua atual situação: políticas,
papéis, estrutura organizacional, procedimentos, requisitos,
financiamento e informações, só para mencionar alguns.
Todos estes são exemplos de coisas que (normalmente) estão fora
do controle da equipe. Coisas como essas também causam
variação natural no sistema.
As coisas que causam a variação natural estão fora do controle
do time. Os gerentes devem buscar minimizar a variação
trabalhando nas coisas que causam variação no sistema.
SPC – Teoria da variação
85 85
Princípio # 4: compreender a variação diz quando algo
aconteceu.
Em um gráfico SPC, você pode ver se um único valor é uma
causa em especial (está fora do controle limites) ou se é uma
causa comum (dentro do controle limites e, portanto, efeito da
variação natural). Esteja ciente da diferença.
Por exemplo: alguem leva entre 20-40 minutos dirigindo até o
trabalho. Um dia ele teve um pneu furado e a viagem levou 1 h.
Deveria esse único incidente mudar a maneira como dirige;
levar uma pequena moto no carro? ou tratar esse incidente
como isolado?
Analise a variação: porquê, o que é importante: nunca se
atrasar? Qual o impacto? Qual a origem?
SPC – Teoria da variação
86 86
Padrões para aumentar a
previsibilidade do lançamento
Essencialmente duas estratégias:
1.Diminuir o WIP
2.Aumentar a taxa de transferência
87 87
First things first
O “start” é tão importante quanto o “done”. Não dá pra medir
tempo sem uma definição clara de ambos
88 88
O valor comercial
Como se mover para frente, para mais perto da visão?
Você pode ter o melhor sistema de fluxo contínuo em toda a cadeia de
valor, mas sem feedback a alinhamento constante pode significar que
está produzindo mais rapidamente itens sem valor.
Fique atento ao que pode comprometer o fluxo, como por exemplo,
aumento da capacidade de utilização.
Lembre sempre que otimizar o fluxo é parte da eliminação de resíduos.
Primeiro... Por que métricas?
89 89
Otimize o fluxo, não a utilização: cadência global é melhor
que velocidade individual
Primeiro... Por que métricas?
90 90
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Como evidenciar analiticamente as restrições?
Se você tenta pressionar o sistema além de sua capacidade o
levará a uma menor qualidade, ritmo insustentável, custos de
manutenção mais altos, entre outras perdas.
Como evidenciar que não há sentido em esgotar colaboradores em
horas extras de longos períodos?
Como evidenciar que as “soluções” podem ser muito caras e
produzem mais deperdícios que ganhos?
Primeiro... Por que métricas?
91 91
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Lidar com evidência para análise de resultados
É... melhor dizer: os itens na fila de espera estão aumentando além
dos desvios aceitáveis em X%”, que dizer “acho que não estamos
entregando conforme o esperado”.
Dados concretos permitem discutir e definir deterministicamente as
ações.
Primeiro... Por que métricas?
92 92
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Que tipo de métricas queremos?
93 93
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
As únicas métricas nas quais os empresários devem investir são
aquelas que os ajudam a tomar decisões
(Eric Ries – “Vanity Metrics vs. Actionable Metrics”)
Se uma métrica não oferece poder preditivo, capturar essa
métrica é um desperdício
(Troy Magennis)
Fonte: “By the power of metrics”, Wolfgang Wiedenroth
Que tipo de métricas queremos?
94 94
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
 Alinhe senpre as métricas com objetivos reais da empresa.
 Antes de medir estabeleça um alvo.
 Sem alvo é o número pelo número sem benefício real
 Medir resultados isolados não nos diz nada sobre os fatores dinâmicos
que os produzem.
 Pense sebre como os números podem ajudar a tomar decisões e
capaciar pessoas a produzirem melhores resultados.
É fácil medir o que
não precisa
Imagem: http://www.oakdenehollins.com/hospitality.php
95 95
Definições essenciais
MÉTRICAS ACIONÁVEIS: conjunto de métricas que sugerem
intervenções específicas para alcancar resultados esperados e
melhorar o desempenho geral de um processo.
Imagem: https://www.getcontrol.co/blog/actionable-vs-vanity-metrics/
96 96
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas acionáveis
Ao invés de um conjunto rígido de métricas, métricas que
promovam benefícios globais, métricas que abram campo para
observação mais profunda de cenários
97 97
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
O que mediremos?
98 98
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Três métricas essenciais de fluxo:
WIP, Throughput e Tempo do Ciclo
(lead, takt, cycle).
Todas intrinsecamente ligadas por
um relacionamento simples e
poderoso conhecido como lei de
Little.
O que mediremos?
A mudança em qualquer uma dessas métricas quase certamente
causará uma mudança nas demais.
99 99
Métricas de fluxo
Também são conhecidas como “métricas acionáveis”, as
métricas de fluxo são diferentes das tradicionais estilo
Scrum. O foco não é nos pontos por história ou velocidade,
é no WIP, Cycle time e Throughput que se presta atenção.
100100
Lei de Little
Aplicada a qualquer sistema
THROUGHPUT = WIP / LEADTIME
OU ( RELAÇÃO DE EQUIVALÊNCIA)
LEAD TIME = WIP / THROUGHPUT
THp = Projeto THt = time de desenvolvimento
LTp = Projeto LTt = time de desenvolvimento
101101
Lei de Little
Fórmula para calcular predicativamente o tempo de ciclo do
número de unidades no sistema, bem como a taxa de
tranferência de WIPs
 Sistema precisa ser estável: visualizar instabilidade gerir
cadência  obter indicador confiável.
 Válido para o sistema Dev.
 Seu poder não está de prever WIP, Thoughput ou Leadtime,
mas de influenciar o comportamento do time com relação às
suas suposições.
102102
 Não garante que a redução dos WIPs tenha um efeito
determinista no tempo do Ciclo.
 Então, por que aprender sobre a Lei de Little? porque entender os
pressupostos dessa lei nos ajuda a criar políticas de processo que
tornarão seu processo previsível.
 A implementação dessas políticas é o que torna as métricas de
fluxo (WIP, Cycle Time e Throughput) verdadeiramente acionáveis.
Lei de Little
103103
Como medimos leadtime? Ou...
Quando isto estará pronto?
104104
Tempo de execução:
Projeto: medimos o intervalo de tempo entre o ponto de
compromisso e a entrega ao cliente.
Para o Dev System, não medimos o tempo entre o ponto de
compromisso e a primeira fila infinita.
Como medimos leadtime? Ou...
Quando isto estará pronto?
105105
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
The Scrumban [R]Evolution: Getting the
Most Out of Agile, Scrum, and Lean
Kanban
; Ajay Reddy
The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban; Ajay Reddy
106106
Medindo quatro grandes áreas
QUALIDADE
(QUÃO BEM)
• Contagem de redução de
defeitos
• % de itens rejeitados, etc.
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
• Tempo de resolução de
defeitos
• Lead time, cycle time
• Eficiência de fluxo
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
• Throughtput
• WIP
• Tamanho do time
• Velocidade
PREVISIBILIDADE
(QUÃO REPETÍVEL)
• Coeficiente de variação,
etc.
107107
MÉTRICAS DE PREVISIBILIDADE
Previsões para itens individuais
108108
Não tente estimar o tamanho dos itens de trabalho.
Existem apenas dois "tamanhos" - “pequeno o
suficiente" e “Muito grande". "Muito grande" deve
ser dividido.
Imagem: http://www.vissinc.com/2012/02/28/t-shirt-sizing-predictability-with-pull-scheduling/
109109
Por que não medir tamanho, por
exemplo, ponto por história?
Sendo a historia A mais complexa que a B ela levará mais tempo
pra ser concluída?
 A pergunta que o cliente faz: quando estará pronto?
 Complexidade relativa x lead time
 Previsão é sobre análise, não estimativa
 A historia sem fim: quão complexo é o complexo?
110110
Por que não medir tamanho, por
exemplo, ponto por história?
Sendo a historia A mais complexa que a B ela levará mais tempo
pra ser concluída?
“Tamanho certo” é um “range de possíveis” resultados dentro de
um intervalo de confiança: você consegue entregar o item em x
dias?
Como redefinir o trabalho para caber no intervalo de confiança?
111111
Por que não medir tamanho, por
exemplo, ponto por história?
Sendo a historia A mais complexa que a B ela levará mais tempo
pra ser concluída?
“Tamanho certo” é um “range de possíveis” resultados dentro de
um intervalo de confiança: você consegue entregar o item em x
dias?
Como redefinir o trabalho para caber no intervalo de confiança?
112112
Previsões para itens individuais
Coisas importantes:
 Proatividade pra completude;
 Monitore o progresso: controle os itens que afetam o
ciclo;
 Plot a idade dos itens;
 Repreveja quando tiver mais informação
Imagem: https://www.123rf.com/stock-photo/proactivity.html?sti=n3v7xti2cf43k7jps0|
113113
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
CYCLE TIME é a única métrica que precisamos
para prever itens individuais.
Daniel S. Vacanti; “when will it be done”
114114
TAXA DE TRANSFERÊNCIA DO PERÍODO PASSADO
THROUGHPUT = WIP / LEADTIME
Concluimos 8 histórias nos ultimos
3 dias. Qual foi a taxa média de
entrega?
WIP é N ( número de itens )
Analisando passadoPRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
115115
CAPACIDADE DE ENTREGA FUTURA
Quantas historias por semana preciso
entregar para entregar 2200 historias em 10
meses com lead time de 0,4 semanas por
história?
22 Histórias
Analisando o futuro
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
116116
RITMO DE ENTREGA PARA A DATA PROMETIDA?
TT = TAKT TIME
Qual o ritmo de entrega diário para entregar
(N)5 historias em (T)10 dias?
Analisando o futuro
TTp = Projeto TTt = time de desenvolvimento
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
117117
DURAÇÃO DO PROJETO NA MÉDIA DO
RITMO DE ENTREGA
Quantos dias (semanas, meses) durará o
projeto (ciclo) para entregar 40 histórias,
entregando 1 história a cada 2 dias?
Futuro: ritmo unitário de entrega
T = N . TT
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
118118
DURAÇÃO DO PROJETO NA MÉDIA DO RITMO DE ENTREGA
Quando (semanas ,dias, meses) entregaremos
400 histórias, sabendo que entregamos 10
historias por ciclo de entrega e temos um lead
time de 0,4 semana por história?
16 semanas
CAPACIDADE DE RESPOSTA
(QUÃO RÁPIDO)
Futuro: Quando vai ser entregue?
119119
QUANTAS PESSOAS SÃO
NECESSÁRIAS
Para entregar 22 historias por ciclo de
entrega, de quantas pessoas eu preciso?
Analisando o futuro
Se um WIP por pessoa, com fila de tamanho 0:
22 pessoas.
Se a fila é de tamanho 2 (duas histórias na fila):
20 pessoas: 20 pessoas * 1 historia por
pessoa+tamanho da fila
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
120120
QUANTAS PESSOAS SÃO
NECESSÁRIAS
Para entregar 22 historias por ciclo de
entrega, de quantas pessoas eu preciso?
Analisando o futuro
Adicionar mais pessoas, ou há mais itens
entregues por pessoa são elementos que
influenciam o fluxo de entrega.
Use a fórmula com cuidado, pois não há correlação
linear entre WIP e LT
121121
TEMPO NÃO TOCADO
Imagem: http://godschildfoundation.org/?tag=queue
122122
Eficiência de fluxo
123123
Velocidade
Tempo tocado - tempo de espera
124124
Eficiência de fluxo
Qual a eficiência de fluxo de um item que teve 2 dias de trabalho
e 8 dias de espera?
Tempo de espera: tempo de setup, bloqueados, etc.
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
125125
Bloqueadores
Quantidade de bloqueadores
Onde ocorrem?
Frequência (horas, dias, etc) com que os itens
bloqueados ocorrem?
Duração média de itens bloqueados?
Itens bloqueados + massa escura
Como capturá-los?
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
126126
Bloqueadores
Taxa % de adição de tarefas: mede mudanças em planos
com relação ao backlog.
Formula = (total de tarefas no final do ciclo – total de
tarefas no começo do ciclo) / numero de dias do ciclo.
Valor é positivo? Tarefas adicionadas
Valor é negativo? Tarefas cortadas
Medindo massa escura
PRODUTIVIDADE
( QUANTO, RITMO DE ENTREGA)
127127
Bloqueadores
Bloqueador Frequência de ocorrência Impacto em horas
Ambiente quebrado 2 3
Esperando feedback 3 8
Férias/ doença 5 6
Impacto dos bloqueadores: frequência de um bloqueador x
duração do bloqueio
128128
Métricas de qualidade
Taxa de defeito.
“Qualidade, eu explico pacientemente, não é a
ausência de algo aos olhos da gerência, isto é,
defeitos, mas a presença de algo aos olhos do
consumidor, isto é, valor.’
Alan Weiss (Million Dollar Consulting (McGraw-Hill, 2009, http://amzn.com/0071622101).
129129
Métricas de qualidade
Taxa de defeito + demanda de falha.
-Não olhar a métrica isoladamente
0%
20%
27%
29%
14%
31%
33%
9%
30%
33%
14%
8%
17%
13%
0%
25%
22%
Unplannedworkrate(inadditiontoplannedwork)
Year-Week Number
Defects Rate Linear (Defects Rate)
Fonte: http://focusedobjective.com/team-metrics-right/
QUALIDADE
(QUÃO BEM)
quantos itens de trabalho o sistema processa devido a má qualidade.
130130
Como lidar com
riscos na previsão?
131131
Riscos começam a assumir controle quando ( entre outras razões):
Não usamos dados para quantifica-los, quando negligenciamos o
efeito de sua ocorrência, quando temos medidas imprecisas ou
insuficientes.
Não conseguimos contabilidazar e entender as incertezas em
nosso planejamento, ou quando falhamos em incorporar um
buffer suficiente para se proteger contra eles.
132132
A que parte do projeto se aplica a
estimativa?
As três pernas do fluxo de entrega
Segunda perna. Percentis 63, 85,90
133133
 Taxas de entrega de trabalho em projetos não são uniformes, tendem
a seguir uma Curva S (com atrasos no início e no final de um projeto).
 Lei de Little pode, portanto, ser aplicado com alta confiança apenas
para a parte média da maioria dos projetos (aproximadamente 60%
da duração total do projeto).
 Para os restantes 40% do projeto, precisamos trabalhar com um
buffer de projeto.
Como lidar com
riscos na previsão?
134134
O T calculado deve ser usado apenas
para a segunda etapa da curva Z
Project planning using Little’s Law, Dimitar Bakardzhiev
135135
Por que não utilizamos a média calculada TH para as três
pernas da curva Z?
 Apenas a segunda perna da curva Z representa a
capacidade do Dev System e mostra a variação de causa
comum e específica para cada um.
 As primeiras e as terceiras pernas da curva Z são específicas
do projeto e mostram variações especiais de causa.
136136
A curva Z/S
Aproximadamente...
Primeira perna: 20% do tempo terá de entrega será lenta.
Segunda perna: 60% do tempo haverá período de “hiperprodutividade"
Terceira perna: 20% até o final será "lento".
Os números podem variar dependendo do contexto, mas o princípio
básico sobre as três seções é correto.
137137
Visualizar a curva S/Z no CFD
138138
A duração do projeto é influenciada pela:
 Expansão do trabalho à medida que aprendemos mais sobre a
necessidade do cliente.
 Demanda em função de falhas (como, por exemplo, garantir alta
qualidade removendo a dívida técnica).
Em função disso precisamos uma forma de lidar com as influências:
40% da curva S, expansão do trabalho e demanda de falhas.
139139
Gerenciando incerteza ao planejar um projeto
Fontes de incerteza
Ao calcular o tempo de execução do projeto, precisamos considerar a
incerteza em termos de:
 Conta para a primeira e terceira pernas da curva Z
 Conta pela Matéria Negra
 Conta para carga de falha
140140
Matéria escura

O número de itens de trabalho crescerá através da expansão
natural à medida que os investigarmos.
 É possível que alguns recursos sejam divididos em 2 ou mais, assim
que você começar.
 É por isso que adicionamos itens de trabalho para compensar o
trabalho desconhecido ou a matéria obscura.
Minha experiência é que eu amortizei pelo menos 20% para isso e com
as equipes novas em um novo produto (especialmente se fosse um
produto novo altamente inovador, onde não tivéssemos conhecimento
prévio ou experiência), então eu poderia chegar a 100%.
Expansão do trabalho
141141
Carga de falha
Adicionamos itens de trabalho para compensar a carga de falha
esperada em termos de defeitos, retrabalho e dívida técnica.
Expansão do trabalho
142142
A data de entrega prometida do projeto é então a soma
da duração inicialmente calculada da segunda etapa da
curva Z (T) + buffer do Projeto.
Buffers
143143
Buffers
144144
Buffers
Para gerenciar a alta incerteza e os riscos nos projetos, usamos um
intervalo de tempo de segurança para proteger a data de vencimento
do projeto prometida ao cliente de variação na taxa de transferência.
Isso melhora a confiabilidade da data de vencimento geral também.
Esse buffer é conhecido como buffer do projeto.
145145
 Protegemos a data de entrega do projeto de uma variação de
causa especial usando um buffer de projeto
 Em função disso precisamos uma forma de incluir as influências:
40% da curva S, expansão do trabalho e demanda de falhas.
 Isso pode ser feito calculando um buffer de projeto.
 Para explicar a variabilidade associada à primeira e terceira
pernas, além da variabilidade criada pela matéria escura e
demanda de falhas, calculamos um buffer
Buffers
146146
Cuidado pra não superstimar o buffer criando objetivos
incapazes de serem competitivos e consequentemente
perda de negócio.
Buffers
147147
Buffers de etapa de processo
Se você sabe que existe um gargalo no seu sistema, é sempre bom
introduzir um buffer apropriado antes do gargalo para observar
com que frequencia é drenado.
Exemplo: quando a etapa “análise” demonstrar que já entregou,
mas os dev não conseguem pegar o item.
Para soluções de curto prazo, adicionar mais recurso pode ser útil.
148148
Como adicionar buffers em
previsões probabilísticas?
É preciso adicionar buffers em
previsões probabilísticas?
149149
Modelagem probabilística
150150
Planejamento probabilístico
Entre outras coisas...
 Particularmente útil quando não tem um monte de dados
reais para trabalhar
 Possibilita reamostrar o padrão específico dos resultados
reais
 Nos permitem executar “e se”
151151
Planejamento probabilístico
Entre outras coisas...
 Permite examinar a forma dos dados e analisá-los para
tirar conclusões sobre o comportamento do sistema em
comparação com outros que geram a mesma forma
 Podemos experimentar e isolar alterações
 Ajudam a determinar estratégias de gerenciamento para o
sucesso
152152
Classificando incertezas
 Aleatoria: não pode ser reduzida ou aumentar o grau de
certeza;
Exemplo: no contexto do desenvolvimento de software
representam variações naturais: esforço de trabalho,
produtividade, questões de qualidade que exigem retrabalho.
Epistêmica: pode ser potencialmente gerida ou reduzida obtendo
através de conhecimento (mais dados ou outros experimentos).
Exemplo: eventos e impactos probabilísticos
153153
Como podemos prever o tempo de entrega do projeto
sem um cronograma detalhado? Isso está avaliando as
dependências entre o trabalho, o custo do trabalho e
a seqüência do trabalho?
Planejamento probabilístico
154154
 Uma previsão requer uma faixa de incerteza e uma
probabilidade
 Previsões são resultantes da distribuição da dados
 O ponto de partida mínimo é coletar dados sobre o tempo
de entrega, taxa de entrega, WiP e custo (geralmente
principalmente o esforço em pessoa-dias consumidos pelo
serviço).
Previsão de múltiplos itens
155155
Por que não se pode confiar na média?
1. Variabilidade, dados discrepantes, outliers
2. Dados nem sempre se agrupam em torno de
uma única média: tendência dist. normal
156156
A falha da média
157157
“Eu já aludi como nossa inclinação natural para aplicar valores médios
em previsão representa uma "falha de médias" a evitar. Afinal, você não
quer sofrer a mesma situação do estatístico que se afogou em um rio
cuja "profundidade média" era 1m.
Por esse motivo, recomendo a previsão de valores que representem pelo
menos do 80º ao 85 percentil dos resultados modelados”
Ajay Reddy [9]
A falha de usar
só médias
Imagem: http://herdingcats.typepad.com/my_weblog/2011/02/there-is-always-an-average-but-is-not-always-meaningful.html
158158
Nunca comunique uma previsão só tem termos de média ou dos
resultados mais prováveis
Cycle time como um único número mascara as incertezas
A falha de usar
só médias
159159
Em ambientes de deenvolvimento de software:
1. Métricas tendem a refletir padrões de distribuição distorcidos à
esquerda ou à direita (cauda muito longa de resultados "outlier“)
2. Em tais padrões, o resultado médio geralmente é um valor
substancialmente menor que a média.
3. Aplicar valores médios na previsão representa estimativas imprecisas
1. Na melhor das hipóteses 50% das amostras serão menores que a
mediana e, portanto, mais de 50% dos resultados serão menores do
que a média
A falha de usar só médias
160160
MEDIDAS DE POSIÇÃO ( tendência central): Moda, Média,
Mediana.
Onde se concentram, qual a tendência das amostras?
MEDIDAS DE DISPERSÃO: Amplitude, Desvio Padrão.
Qual o valor que resume a variabilidade de um conjunto de
dados?
Analisando além
da média
161161
Mediana: valor que divide o conjunto de dados em dois
subconjuntos de mesmo tamanho
{1100, 1200, 1210, 1250, 1300, 1450, 1500, 1600,
1980)
Desvio padrão: indica o grau de variação ( dispersão) de um
conjunto. serve pra dizer o quanto os valores dos quais se
extraiu a média são próximos ou distantes da própria média.
Analisando além
da média
Moda: valor que ocorre com maior
frequência ou o valor mais comum
(5,6,6,7,8)
162162
O planejamento deterministico é usado atualmente pra forçar
a certeza em situações incertas e mascarar a incerteza ao
invés de destacá-la.
Planejamento determinístico
163163
Simulação de Monte Carlo
Métodos que aplicam uma abordagem frequentista para
modelagem aleatória de incerteza por amostragem- embora
qualquer abordagem possa ser usada- na qual cada elemento
da população tem a mesma chance de ser escolhido.
164164
Simulação de
Monte Carlo
1. São úteis quando uma série de condições de entrada podem
afetar significativamente o resultado final produzido por um
processo ou sistema.
2. Quando a simulação é executada, valores aleatórios dentro dos
intervalos definidos em todas as variáveis são gerados,
produzindo resultados diferentes para cada simulação completa.
3. Ajudam a gerir risco em gestão do conhecimento
165165
1. Executam muitas permutações de uma simulação para
encontrar prováveis padrões de saída.
2. Uma amostra grande de dados para a distribuição ajuda a
mostrar padrões de diferentes tipos de dados no contexto.
3. Os valores potenciais para cada variável caem dentro de um
intervalo calculado estatisticamente (idealmente calculado a
partir de dados históricos para cada um): limite alto e limite
baixo.
Simulação de
Monte Carlo
166166
Monte Carlo
Passo 1: Crie um modelo paramétrico, y = f(x1, x2, ..., xq).
Passo 2: Gere um conjunto de inputs randômicos., xi1, xi2, ..., xiq.
Idealmente, pelo menos parcialmente histórico e os compute.
Passo 3: Avalie o modelo e guarde os resultados, como yi.
Passo 4: Repita os passos 2 e 3 para i = 1 até n.
Passo 5: Analise os resultados usando histogramas, sumarização
estatística, intervalos de confiança, etc
Resumindo
167167
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Métricas: algumas palavras
finais ( por agora)
168168
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
Objetivo das métricas
 Melhorar, não punir.
 Ter uma maneira efetiva de avaliar melhor o passado e tomar
melhores decisões no presente
 Diagnosticar um problema ou condição
 Alavancar e influenciar comportamento do time e da empresa
Métricas: algumas palavras finais ( por agora)
Imagem: https://commons.wikimedia.org/wiki/File:Martina_gives_Bob_Bryan_a_hand.jpg
169169
Características de boas métricas
 Objetivamente comparativo (capaz de ser comparado a
outros períodos de tempo e / ou grupos)
 Facilmente compreensível:
- Permite às pessoas internaliza-las e discuti-las
- Colabora para mudança no processo ou cultura.
Métricas: algumas palavras finais
170170
Características de boas métricas
De preferência quantitativo:
-Dados quantitativos são geralmente mais científicos e mais
fáceis de entender
- Qualitativos ajudam a responder "porquê"
Ser relatável:
- Informar sobre o que está acontecendo ou permitir especular
ajudando a descobrir novas idéias.
Métricas: algumas palavras finais
171171
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
 Ajudam a lançar um olhar combinado de métricas na análise
 Ajudar a liderar:
- ver tendências ou preditores de resultados futuros
- ver atrasos iluminando condições reais e resultados
 Permite verificar percepções contra dados que as demonstrem.
 Ajudam a responder perguntas às quais atualmente não temos
resposta
Características de boas métricas
Imagem: ps://pt.slideshare.net/kim_williams/enhancing-scholarly-reputation-using-
metrics-and-name-management-for-good-not-evil-26329454
172172
O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente
 Te ajudam a entender melhor sua demanda e capacidade
 Te ajudam a distinguir entre mudanças boas ou más de um ponto
de vista de um objetivo
 Ajudam a promover transparência e analisar incongruências entre
previsão e realidade.
 Promovem visão ubiqua entre times, organização e stakeholders
sobre a entrega do sistema, criando um programa de gestão com
dados altamente visíveis.
 Ajudam a visualizar como o impacto da utilização de recursos
influencia no fluxo de entrega.
Características de
boas métricas
173173
Referências - Books
174174
Referências - Books
175175
[1] "Moneyball for Software Projects: Agile Metrics for the Metrically Challenged";Troy Magennis
goo.gl/VbAEEZ
[2] "High-Level Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev
goo.gl/KkC74b
[3]"#NoEstimates Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev
goo.gl/SDHJYP
[4]"Little's law and predictability"; Daniel Vacanti
goo.gl/ETDzg9
Referências - Presentations
176176
Referências - Presentations
[5] "Kanban Metrics in practice at Sky Network Services"; Mattia Battiston
goo.gl/tQXqwN
[6] "By the power of metrics";Wolfgang Wiedenroth
goo.gl/ebGU3h
177177
Referências - Vídeos
[1] "Project Planning Using Little's Law"; Dimitar Bakardzhiev
https://www.youtube.com/watch?v=r38a25ak4co
[2] "High-Level Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev
https://www.youtube.com/watch?v=GE9vrJ741WY
[3] "Portfolio Management";Jake Xia
https://www.youtube.com/watch?v=8TJQhQ2GZ0Y
178178
Referências - Papers
[1] "Project planning using Little’s Law"; Dimitar Bakardzhiev
goo.gl/rw1X5T
179179
Referências - Articles
[1] "Actionable Metrics at Siemens Health Services"; Daniel Vacanti
goo.gl/nS34ZP
[2] "#NoEstimates Project Planning Using Monte Carlo Simulation"; Dimitar Bakardzhiev
goo.gl/FMeeXR
[3] "Inside a Lead Time Distribution"; Alexei Zheglov
goo.gl/yHx3eY
[4] "Lead Time Distributions and Antifragility"; Alexei Zheglov
goo.gl/Ytnwya
[5] "Doing Team Metrics Right"; Troy Magennis
goo.gl/Qm6irp
180180
Referências - Articles
[6] "Release planning using a great extension of Little’s Law"; Sebastian Radics
goo.gl/XnH7Qs
[7] "Probabilistic Project Sizing Using Randomized Branch Sampling (RBS)"; Dimitar Bakardzhiev
goo.gl/vFiSPN
[8] "Control Chart – How to create one in Excel 2010"; Håkan Forss
goo.gl/3VyLr8
[9] "How to Match to Weibull Distribution without Excel";Håkan Forss
goo.gl/nFDuuU
[10] "Removing the bubbles: solving bottlenecks in software product development"; Benjamin
Mitchell
goo.gl/swfDzx
181181
Referências - Articles
[11] "How to Match to Weibull Distribution in Excel"; Alexei Zheglov
goo.gl/LVB4Jo
[2] “Project Portfolio Management”
http://johanfrisk.com/queue/

Mais conteúdo relacionado

Mais procurados

Introduction of Kanban metrics
Introduction of Kanban metricsIntroduction of Kanban metrics
Introduction of Kanban metrics
Chuck Durfee
 
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdfCaipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
Andressa Chiara
 
Papeis Ágeis - uma proposta operacional Scrum
Papeis Ágeis - uma proposta operacional ScrumPapeis Ágeis - uma proposta operacional Scrum
Papeis Ágeis - uma proposta operacional Scrum
Kleitor Franklint Correa Araujo
 
Cost of delay - Comunicando o impacto do tempo no valor
Cost of delay - Comunicando o impacto do tempo no valorCost of delay - Comunicando o impacto do tempo no valor
Cost of delay - Comunicando o impacto do tempo no valor
Rodrigo Yoshima
 
Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de Scrum
Luiz Duarte
 
Treinamento Agile Coach
Treinamento Agile CoachTreinamento Agile Coach
Treinamento Agile Coach
Silas Serpa
 
Scaled Agile Framework (SAFe) Roles and Meetings
Scaled Agile Framework (SAFe) Roles and MeetingsScaled Agile Framework (SAFe) Roles and Meetings
Scaled Agile Framework (SAFe) Roles and Meetings
Rob Betcher
 
Métricas no Fluxo Unificado
Métricas no Fluxo UnificadoMétricas no Fluxo Unificado
Métricas no Fluxo Unificado
Taller Negócio Digitais
 
Scrum
ScrumScrum
Kanban values exercise
Kanban values exerciseKanban values exercise
Kanban values exercise
Mike Burrows
 
[Lean kanban brazil 2017] Workshop de métricas
[Lean kanban brazil 2017] Workshop de métricas[Lean kanban brazil 2017] Workshop de métricas
[Lean kanban brazil 2017] Workshop de métricas
Raphael Donaire Albino
 
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
Kanban India 2022 - Keynote - Todd Little |  Turbocharge your Scrum with KanbanKanban India 2022 - Keynote - Todd Little |  Turbocharge your Scrum with Kanban
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
LeanKanbanIndia
 
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
Agile En Seine
 
Agile 101
Agile 101Agile 101
Agile 101
beLithe
 
Agile metrics
Agile metricsAgile metrics
Agile metrics
Ankit Tandon
 
scrum
scrumscrum
scrum
Noman sial
 
Sixsigma
SixsigmaSixsigma
Sixsigma
lcbj
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
Wise Systems
 
Introduction to Acceptance Test Driven Development
Introduction to Acceptance Test Driven DevelopmentIntroduction to Acceptance Test Driven Development
Introduction to Acceptance Test Driven Development
Elisabeth Hendrickson
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
Leinylson Fontinele
 

Mais procurados (20)

Introduction of Kanban metrics
Introduction of Kanban metricsIntroduction of Kanban metrics
Introduction of Kanban metrics
 
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdfCaipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
Caipira Ágil 2023 - Os desafios da liderança_ como transformar dinossauros.pdf
 
Papeis Ágeis - uma proposta operacional Scrum
Papeis Ágeis - uma proposta operacional ScrumPapeis Ágeis - uma proposta operacional Scrum
Papeis Ágeis - uma proposta operacional Scrum
 
Cost of delay - Comunicando o impacto do tempo no valor
Cost of delay - Comunicando o impacto do tempo no valorCost of delay - Comunicando o impacto do tempo no valor
Cost of delay - Comunicando o impacto do tempo no valor
 
Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de Scrum
 
Treinamento Agile Coach
Treinamento Agile CoachTreinamento Agile Coach
Treinamento Agile Coach
 
Scaled Agile Framework (SAFe) Roles and Meetings
Scaled Agile Framework (SAFe) Roles and MeetingsScaled Agile Framework (SAFe) Roles and Meetings
Scaled Agile Framework (SAFe) Roles and Meetings
 
Métricas no Fluxo Unificado
Métricas no Fluxo UnificadoMétricas no Fluxo Unificado
Métricas no Fluxo Unificado
 
Scrum
ScrumScrum
Scrum
 
Kanban values exercise
Kanban values exerciseKanban values exercise
Kanban values exercise
 
[Lean kanban brazil 2017] Workshop de métricas
[Lean kanban brazil 2017] Workshop de métricas[Lean kanban brazil 2017] Workshop de métricas
[Lean kanban brazil 2017] Workshop de métricas
 
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
Kanban India 2022 - Keynote - Todd Little |  Turbocharge your Scrum with KanbanKanban India 2022 - Keynote - Todd Little |  Turbocharge your Scrum with Kanban
Kanban India 2022 - Keynote - Todd Little | Turbocharge your Scrum with Kanban
 
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
De la gestion de portefeuille Lean à la gestion des flux de valeur avec le Fl...
 
Agile 101
Agile 101Agile 101
Agile 101
 
Agile metrics
Agile metricsAgile metrics
Agile metrics
 
scrum
scrumscrum
scrum
 
Sixsigma
SixsigmaSixsigma
Sixsigma
 
Workshop Scrum - 8 horas
Workshop Scrum - 8 horasWorkshop Scrum - 8 horas
Workshop Scrum - 8 horas
 
Introduction to Acceptance Test Driven Development
Introduction to Acceptance Test Driven DevelopmentIntroduction to Acceptance Test Driven Development
Introduction to Acceptance Test Driven Development
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 

Semelhante a Metricas (e previsões) acionáveis de projeto

O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
Cleiton Luis Mafra
 
Metricas parte 1
Metricas parte 1Metricas parte 1
Metricas parte 1
Camila Capellão
 
Metricas forecasting
Metricas forecastingMetricas forecasting
Metricas forecasting
Rodrigo Oliveira, Msc, PMP
 
Gestão ágil: gerar valor partir otimização de fluxo
Gestão ágil: gerar valor partir otimização de fluxoGestão ágil: gerar valor partir otimização de fluxo
Gestão ágil: gerar valor partir otimização de fluxo
Anderson Silveira
 
Aula gestão estratégica do lead time
Aula gestão estratégica do lead timeAula gestão estratégica do lead time
Aula gestão estratégica do lead time
Carlos Campos - MBA,ADM.
 
the-hard-road.PDF
the-hard-road.PDFthe-hard-road.PDF
the-hard-road.PDF
VictorFelix44
 
Workshop Kanban - julho 2016
Workshop  Kanban - julho 2016Workshop  Kanban - julho 2016
Workshop Kanban - julho 2016
Rodrigo Vieira
 
Engenharia de software Lean Kanban
Engenharia de software  Lean KanbanEngenharia de software  Lean Kanban
Engenharia de software Lean Kanban
Kleitor Franklint Correa Araujo
 
Aula Mapeamento de Processos Aula 1 2015.pdf
Aula Mapeamento de Processos Aula 1 2015.pdfAula Mapeamento de Processos Aula 1 2015.pdf
Aula Mapeamento de Processos Aula 1 2015.pdf
Pedro Luis Moraes
 
Ciclo DPCA aplicado dentro da industria.
Ciclo DPCA aplicado dentro da industria.Ciclo DPCA aplicado dentro da industria.
Ciclo DPCA aplicado dentro da industria.
JairGaldino4
 
Métricas Lean que Fazem a Diferença
Métricas Lean que Fazem a DiferençaMétricas Lean que Fazem a Diferença
Métricas Lean que Fazem a Diferença
Teresa Maciel
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
Marcos Garrido
 
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis project lab
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis   project labGerenciamento ágil e o aprendizado a partir de indicadores ágeis   project lab
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis project lab
Raphael Donaire Albino
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
Alessandro Rodrigues, CSM, SFC
 
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
Amanda Varella
 
Requisitos ageis para times sem tempo
Requisitos ageis para times sem tempoRequisitos ageis para times sem tempo
Requisitos ageis para times sem tempo
Kleitor Franklint Correa Araujo
 
Gestão Ágil: Gerar valor a partir da otimização de fluxo
Gestão Ágil: Gerar valor a partir da otimização de fluxoGestão Ágil: Gerar valor a partir da otimização de fluxo
Gestão Ágil: Gerar valor a partir da otimização de fluxo
Anderson Silveira
 
Porque estimar e porque deixar de estimar
Porque estimar e porque deixar de estimarPorque estimar e porque deixar de estimar
Porque estimar e porque deixar de estimar
Rodrigo Yoshima
 
Gestão Ágil com Fluxo Unificado
Gestão Ágil com Fluxo UnificadoGestão Ágil com Fluxo Unificado
Gestão Ágil com Fluxo Unificado
Taller Negócio Digitais
 
Teste de software gestao e kaizen
Teste de software gestao e kaizenTeste de software gestao e kaizen
Teste de software gestao e kaizen
Kleitor Franklint Correa Araujo
 

Semelhante a Metricas (e previsões) acionáveis de projeto (20)

O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
O que não te contaram sobre as métricas e voce precisa saber! [SGRIo 06/2019]
 
Metricas parte 1
Metricas parte 1Metricas parte 1
Metricas parte 1
 
Metricas forecasting
Metricas forecastingMetricas forecasting
Metricas forecasting
 
Gestão ágil: gerar valor partir otimização de fluxo
Gestão ágil: gerar valor partir otimização de fluxoGestão ágil: gerar valor partir otimização de fluxo
Gestão ágil: gerar valor partir otimização de fluxo
 
Aula gestão estratégica do lead time
Aula gestão estratégica do lead timeAula gestão estratégica do lead time
Aula gestão estratégica do lead time
 
the-hard-road.PDF
the-hard-road.PDFthe-hard-road.PDF
the-hard-road.PDF
 
Workshop Kanban - julho 2016
Workshop  Kanban - julho 2016Workshop  Kanban - julho 2016
Workshop Kanban - julho 2016
 
Engenharia de software Lean Kanban
Engenharia de software  Lean KanbanEngenharia de software  Lean Kanban
Engenharia de software Lean Kanban
 
Aula Mapeamento de Processos Aula 1 2015.pdf
Aula Mapeamento de Processos Aula 1 2015.pdfAula Mapeamento de Processos Aula 1 2015.pdf
Aula Mapeamento de Processos Aula 1 2015.pdf
 
Ciclo DPCA aplicado dentro da industria.
Ciclo DPCA aplicado dentro da industria.Ciclo DPCA aplicado dentro da industria.
Ciclo DPCA aplicado dentro da industria.
 
Métricas Lean que Fazem a Diferença
Métricas Lean que Fazem a DiferençaMétricas Lean que Fazem a Diferença
Métricas Lean que Fazem a Diferença
 
Gestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com ScrumGestão Ágil de Projetos com Scrum
Gestão Ágil de Projetos com Scrum
 
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis project lab
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis   project labGerenciamento ágil e o aprendizado a partir de indicadores ágeis   project lab
Gerenciamento ágil e o aprendizado a partir de indicadores ágeis project lab
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
SCRUM RIO 2014 - Resolvendo os problemas certos com Kanban, Métricas e Visual...
 
Requisitos ageis para times sem tempo
Requisitos ageis para times sem tempoRequisitos ageis para times sem tempo
Requisitos ageis para times sem tempo
 
Gestão Ágil: Gerar valor a partir da otimização de fluxo
Gestão Ágil: Gerar valor a partir da otimização de fluxoGestão Ágil: Gerar valor a partir da otimização de fluxo
Gestão Ágil: Gerar valor a partir da otimização de fluxo
 
Porque estimar e porque deixar de estimar
Porque estimar e porque deixar de estimarPorque estimar e porque deixar de estimar
Porque estimar e porque deixar de estimar
 
Gestão Ágil com Fluxo Unificado
Gestão Ágil com Fluxo UnificadoGestão Ágil com Fluxo Unificado
Gestão Ágil com Fluxo Unificado
 
Teste de software gestao e kaizen
Teste de software gestao e kaizenTeste de software gestao e kaizen
Teste de software gestao e kaizen
 

Mais de Kleitor Franklint Correa Araujo

Modelagem com historias bem além dos requisitos
Modelagem com historias bem além dos requisitosModelagem com historias bem além dos requisitos
Modelagem com historias bem além dos requisitos
Kleitor Franklint Correa Araujo
 
Fundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e QualidadeFundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e Qualidade
Kleitor Franklint Correa Araujo
 
MBA em projetos - Gestao Ágil
MBA em projetos - Gestao ÁgilMBA em projetos - Gestao Ágil
MBA em projetos - Gestao Ágil
Kleitor Franklint Correa Araujo
 
Automação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégiasAutomação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégias
Kleitor Franklint Correa Araujo
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
Kleitor Franklint Correa Araujo
 
Gestao de Projeto com gráfico burndown
Gestao de Projeto com gráfico burndownGestao de Projeto com gráfico burndown
Gestao de Projeto com gráfico burndown
Kleitor Franklint Correa Araujo
 
Teste de segurança do lado servidor - Nível 1
Teste de segurança do lado servidor - Nível 1Teste de segurança do lado servidor - Nível 1
Teste de segurança do lado servidor - Nível 1
Kleitor Franklint Correa Araujo
 
Introdução de teste de segurança app web
Introdução de teste de segurança app webIntrodução de teste de segurança app web
Introdução de teste de segurança app web
Kleitor Franklint Correa Araujo
 
Gestão Agil de tudo - Retrospectivas
Gestão Agil de tudo - RetrospectivasGestão Agil de tudo - Retrospectivas
Gestão Agil de tudo - Retrospectivas
Kleitor Franklint Correa Araujo
 
Gestao Ágil do Backlog - Taskboards
Gestao Ágil do Backlog - TaskboardsGestao Ágil do Backlog - Taskboards
Gestao Ágil do Backlog - Taskboards
Kleitor Franklint Correa Araujo
 
Gestão Ágil de tudo: Planejamento backlog
Gestão Ágil de tudo: Planejamento backlogGestão Ágil de tudo: Planejamento backlog
Gestão Ágil de tudo: Planejamento backlog
Kleitor Franklint Correa Araujo
 
Gestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião DiáriaGestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião Diária
Kleitor Franklint Correa Araujo
 
Agil - coisas essenciais de sempre
Agil - coisas essenciais de sempreAgil - coisas essenciais de sempre
Agil - coisas essenciais de sempre
Kleitor Franklint Correa Araujo
 
Gestão de projeto PMBOK 5 com um Toque Agil - praticas de fundamentos
Gestão de projeto PMBOK 5 com um Toque Agil -  praticas de fundamentosGestão de projeto PMBOK 5 com um Toque Agil -  praticas de fundamentos
Gestão de projeto PMBOK 5 com um Toque Agil - praticas de fundamentos
Kleitor Franklint Correa Araujo
 
Gestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciaisGestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciais
Kleitor Franklint Correa Araujo
 
Test First, TDD e outros Bichos
Test First, TDD e outros BichosTest First, TDD e outros Bichos
Test First, TDD e outros Bichos
Kleitor Franklint Correa Araujo
 
Teste Ágeis para todo o time
Teste Ágeis para todo o timeTeste Ágeis para todo o time
Teste Ágeis para todo o time
Kleitor Franklint Correa Araujo
 
Estrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressãoEstrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressão
Kleitor Franklint Correa Araujo
 
Teste de Segurança orientado a valor
Teste de Segurança orientado a valorTeste de Segurança orientado a valor
Teste de Segurança orientado a valor
Kleitor Franklint Correa Araujo
 
Mobile App Security Test
Mobile App Security TestMobile App Security Test
Mobile App Security Test
Kleitor Franklint Correa Araujo
 

Mais de Kleitor Franklint Correa Araujo (20)

Modelagem com historias bem além dos requisitos
Modelagem com historias bem além dos requisitosModelagem com historias bem além dos requisitos
Modelagem com historias bem além dos requisitos
 
Fundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e QualidadeFundamentos Gestão de Escopo e Qualidade
Fundamentos Gestão de Escopo e Qualidade
 
MBA em projetos - Gestao Ágil
MBA em projetos - Gestao ÁgilMBA em projetos - Gestao Ágil
MBA em projetos - Gestao Ágil
 
Automação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégiasAutomação de testes - uma introdução sobre estratégias
Automação de testes - uma introdução sobre estratégias
 
Introdução ao design de teste de software
Introdução ao design de teste de softwareIntrodução ao design de teste de software
Introdução ao design de teste de software
 
Gestao de Projeto com gráfico burndown
Gestao de Projeto com gráfico burndownGestao de Projeto com gráfico burndown
Gestao de Projeto com gráfico burndown
 
Teste de segurança do lado servidor - Nível 1
Teste de segurança do lado servidor - Nível 1Teste de segurança do lado servidor - Nível 1
Teste de segurança do lado servidor - Nível 1
 
Introdução de teste de segurança app web
Introdução de teste de segurança app webIntrodução de teste de segurança app web
Introdução de teste de segurança app web
 
Gestão Agil de tudo - Retrospectivas
Gestão Agil de tudo - RetrospectivasGestão Agil de tudo - Retrospectivas
Gestão Agil de tudo - Retrospectivas
 
Gestao Ágil do Backlog - Taskboards
Gestao Ágil do Backlog - TaskboardsGestao Ágil do Backlog - Taskboards
Gestao Ágil do Backlog - Taskboards
 
Gestão Ágil de tudo: Planejamento backlog
Gestão Ágil de tudo: Planejamento backlogGestão Ágil de tudo: Planejamento backlog
Gestão Ágil de tudo: Planejamento backlog
 
Gestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião DiáriaGestao Ágil de Projeto - Reunião Diária
Gestao Ágil de Projeto - Reunião Diária
 
Agil - coisas essenciais de sempre
Agil - coisas essenciais de sempreAgil - coisas essenciais de sempre
Agil - coisas essenciais de sempre
 
Gestão de projeto PMBOK 5 com um Toque Agil - praticas de fundamentos
Gestão de projeto PMBOK 5 com um Toque Agil -  praticas de fundamentosGestão de projeto PMBOK 5 com um Toque Agil -  praticas de fundamentos
Gestão de projeto PMBOK 5 com um Toque Agil - praticas de fundamentos
 
Gestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciaisGestão de projeto- conceitos essenciais
Gestão de projeto- conceitos essenciais
 
Test First, TDD e outros Bichos
Test First, TDD e outros BichosTest First, TDD e outros Bichos
Test First, TDD e outros Bichos
 
Teste Ágeis para todo o time
Teste Ágeis para todo o timeTeste Ágeis para todo o time
Teste Ágeis para todo o time
 
Estrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressãoEstrategias Ágeis para testes sob pressão
Estrategias Ágeis para testes sob pressão
 
Teste de Segurança orientado a valor
Teste de Segurança orientado a valorTeste de Segurança orientado a valor
Teste de Segurança orientado a valor
 
Mobile App Security Test
Mobile App Security TestMobile App Security Test
Mobile App Security Test
 

Metricas (e previsões) acionáveis de projeto

  • 1. 1 1 Métricas acionáveis de projeto Kleitor Franklint Lean PMO consulting Agile Coach Clipzen.blog
  • 2. 2 2 Esta apresentação faz parte do conjunto de dois cursos: 1. Métricas acionáveis de projeto 2. Práticas avançadas com métricas acionáveis Métricas acionáveis de projeto
  • 3. 3 3 O que veremos?  Gestão probabilística de projetos  Fluxo: influência e impacto  Coleta de métricas acionáveis  Visualização e análise do fluxo de trabalho  Previsão para itens individuais  Previsão para múltiplos itens Métricas acionáveis de projeto
  • 4. 4 4 Como estamos lidando com a incerteza: faturamento e satisfação do cliente? Fonte: https://clipzen.blog/2017/11/28/noestimates-my-way-to-do/ PREVER
  • 5. 5 5 Sua vez agora!! Por que estimar? Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
  • 6. 6 6 Porque clientes pergutam: quanto tempo demorará e quanto custará para nos entregar? Eles precisam de uma data de entrega e uma estimativa orçamentária. Por que estimar? Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
  • 7. 7 7 Quanto tempo demorará e quanto custará para nos entregar? Esta pergunta é melhor respondida com uma estimativa ou com uma previsão? Imagem: http://broadleaf.com.au/resource-material/cost-and-schedule-risk-assessment-risk-factor-modelling/
  • 8. 8 8 Diferença entre estimativa e previsão Imagem: http://blog.crisp.se/tag/estimating
  • 9. 9 9 Definições essenciais PONTO DE DEPARTIDA: Um ponto específico em que uma unidade de trabalho se transforma de uma idéia arbitrária em um item de trabalho que deve ser imediatamente atualizado e completado. PONTO DE CHEGADA: Definido como entrega para um usuário final ou entrega para algum outro time ou processo. TRABALHO: Qualquer unidade discreta ou indireta de trabalho de valor de cliente é um candidato de trabalho - nomeado como item de trabalho (história, épico, característica, requisito, caso de uso, aprimoramento, ...) Imagem: https://www.infoq.com/articles/noestimates-monte-carlo
  • 10. 10 10 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Exercício 1- item 1
  • 11. 11 11 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Entender as fronteiras ajuda a entender o custo do tempo
  • 12. 12 12 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Conceitos essenciais 1. Quanto tempo leva cada um desses itens para passar por nosso processo? 2. Quanto tempo para completar? 3. Quando isso será feito? TEMPO DO CICLO ( CYCLE TIME): A quantidade de tempo decorrido que um item de trabalho gasta como trabalho em andamento. É sobre “quanto tempo”. Também pode ser usado como preditor de custo  A quantidade de tempo que leva para obter feedback dos clientes  Conhecido também como “service time”.
  • 13. 13 13 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Exercício 2- itens 2 e 3
  • 14. 14 14 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Coletando dados De onde se extrai os dados? Pra que coletar dados?
  • 15. 15 15 Coletando quatro grandes áreas QUALIDADE (QUÃO BEM) • Demanda de falha. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Percentis
  • 16. 16 16 Exercício 3: coletando tempo do fluxo Item 4 QUALIDADE (QUÃO BEM) • Demanda de falha. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Percentis
  • 17. 17 17 Definições essenciais TAXA DE TRANSFERÊNCIA (THROUGHPUT): Takt, Cycle, Lead time Quantidade de unidades (WIP) concluídas num determinado período. Taxa na qual o sistema atinge seu objetivo. Por exemplo: 10 histórias por semana, 5 clientes por hora, etc. Ajudam a responder perguntas tais como: Quantos itens completos por unidade de tempo? Quantos recursos eu preciso na próxima versão? Compreender throughput em cada etapa ajudará a identificar as restrições no fluxo de trabalho e a encontrar pontos para melhorias de processo
  • 18. 18 18 Exercício 4: coletando produtividade Item 6 QUALIDADE (QUÃO BEM) • Demanda de falha. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Percentis
  • 19. 19 19 Principal opção para muitos. Equipes trabalhando mais horas incluindo os fins de semana e tentando roubar recursos de outros projetos, além da possibilidade contratar mais pessoal. Tentar impactar o Throughput desta maneira aumenta o WIP mais rápido que a taxa de entrega, e os tempos do ciclo de entrega só aumentarão. Padrões para aumentar a previsibilidade do lançamento Aumentar a taxa de transferência
  • 20. 20 20 Carga de falha ( Demanda de falha) Controla quantos itens de trabalho o sistema processa devido a má qualidade. Isso inclui defeitos de produção (bugs) no software e novos recursos solicitados pelos usuários devido a uma usabilidade fraca ou a uma incapacidade de antecipar adequadamente as necessidades dos usuários. Os defeitos representam o custo de oportunidade e afetam o tempo de entrega e o throughput do sistema Kanban.
  • 21. 21 21 Exercício 5: coletando qualidade da produtividade Item 6 QUALIDADE (QUÃO BEM) • Demanda de falha. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Percentis
  • 22. 22 22 Percentis e intervalo de confiança Faixa de valores possíveis para a magnitude (risco relativo) real do efeito. Temos X% de chance do intervalo conter o verdadeiro valor da média populacional. Em vez de estimar o parâmetro por um único valor, é dado um intervalo de estimativas prováveis.
  • 23. 23 23 Intervalo de confiança Estimar pra quê? Fonte: “By the power of metrics”, Wolfgang Wiedenroth Percentis e intervalo de confiança
  • 24. 24 24 Percentis e intervalo de confiança Estimar pra quê? Previsão é melhor Aproximadamente certo é melhor que exatamente errado Ao invés de "que data está pronto?" pergunte, "Qual é a probabilidade de terminar este pedido dentro de tantos dias?"
  • 25. 25 25 Exercício 6: calcule o possível período de entrega com intervalos de confiança. (ITEM 7) QUALIDADE (QUÃO BEM) • Demanda de falha. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Percentis
  • 26. 26 26 Previsibilidade da entrega Estabilidade e transação X Variabilidade e retenção http://theprocessconsultant.com/classifying-different-process-types/
  • 27. 27 27 Por que é importante estabilizar a entrega? 1. Para criar previsibilidade 2. Ritmo sustentável 3. Identificar capacidade do time
  • 28. 28 28 Por que gestão de fluxo?
  • 29. 29 29 Definições essenciais FLUXO: movimento e a entrega de valor ao cliente através de um processo. Portanto, todo o nosso processo deve ser orientado em torno do fluxo otimizado.
  • 30. 30 30 É sobre ler o seu sistema para tomar as melhores decisões possíveis com a informação disponível na busca do ROI mais alto. Gestão de fluxo
  • 31. 31 31 Ferramenta para o alinhamento, não um critério de sucesso, ele mede seu fluxo para determinar se você ainda está alinhado Planos Imagem: https://thedigitalprojectmanager.com/project-plan-guide/
  • 32. 32 32 Para fins de planejamento, é melhor modelar projetos como um fluxo de itens de trabalho através de um sistema. Planos Mas, por que?
  • 33. 33 33 O que significa para você? Projeto terminado na metade do tempo? Projeto terminado no dobro do tempo? Gestão de fluxo https://www.15five.com/blog/4-scientifically-proven-methods-increase-productivity/
  • 34. 34 34 Fazer na metade do tempo não significa metade do custo nem ser mais produtivo. Pode haver (entre outros) custos de qualidade não levados em conta. Dobro do tempo não é o dobro do custo: muitos dos custos podem ser desperdícios, incluindo custo de retenção. SÓ O TEMPO NÃO DIZ MUITO Por que gestão de fluxo?
  • 35. 35 35 PORQUE AS FILAS INFLUENCIAM? Gestão de fluxo Imagem: http://godschildfoundation.org/?tag=queue
  • 36. 36 36 PORQUE AS FILAS INFLUENCIAM  Sem filas o sistema se move para frente em direção do fluxo e o valor é entregue sem demora  Filas criam delay na entrega Por que gestão de fluxo?
  • 37. 37 37 Dentre as causas estão: 1. variabilidade: 2. sobrecarga de capacidade humana; 3. grandes lotes e descoberta tardia de surpresas Mas em geral só o segundo tipo é visto como fila no desenvolvimento de produto. FILAS Por que gestão de fluxo?
  • 38. 38 38 Em que instante surge o atraso e a sobrecarga? Por que gestão de fluxo? Em que instante o projeto precisa ser melhor monitorado? https://chrisandsusanbeesley.com/how-to-overcome-information-overload/overload/
  • 39. 39 39 A relação de utilização com o tamanho da fila não é linear. O atraso e a sobrecarga podem ocorrer em qualquer período e percentual de utilização. A velocidade diminui bem antes da capacidade ser alcançada. Por que gestão de fluxo?
  • 40. 40 40 Em uma rodovia, por exemplo, a desaceleração torna-se perceptível entre 50 em 100% de utilização e as filas crescem. Por que gestão de fluxo?
  • 41. 41 41 Limpar a fila demora mais que construí-la. Por que gestão de fluxo? A variação e aleatoriedade com probabilidade nos mostra que o modelo não é determinista, mas estocástico.
  • 42. 42 42 O IMPACTO NO CYCLE TIME NÃO É LINEAR Há quem creia que quanto mais trabalho atribuído mais será entregue e que somente quando o recurso chegar a 100% de utilização haverá degradação da velocidade e qualidade.
  • 43. 43 43 O IMPACTO NO CYCLE TIME NÃO É LINEAR Fonte: https://less.works/less/principles/queueing_theory.html
  • 44. 44 44 Multitarefa e desaparecimento artificial das filas  Tempos mais longos no ciclo de entrega  Produz ritmo insustentável  Aumenta a complexidade da gestão  Aumenta aumento do número de defeitos oriundos do impacto humano  Aumento de custos pela mudança de contexto tornando a equipe menos efetiva.
  • 45. 45 45 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente “se você tiver um problema que requer mais de uma semana de horas extras, você tem um problema que não deveria ser corrigido com horas extras de forma alguma". Ken Beck (criador do XP)
  • 46. 46 46 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente 1. Sem cycle time previsível e estável não se pode usar métricas para previsões futuras 2. Ao escolher a cadência de entrega deve-se estar ciente do custo econômico da escolha. • Custo de transação associado ao release • Custo de retenção associado a entrega. Previsibilidade e o custo da retenção
  • 47. 47 47 Estabilize a entrega Cadência e feedback x retenção e inércia Muitas equipes ágeis maduras geram releases com um clique, mas ainda esperam 3 semanas antes de obter feedback de seus clientes ( internos e externos) Imagem: http://www.humanresourcesonline.net/retain-young-talent-pr-world/
  • 48. 48 48 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Por que o custo da retenção é ruim? 1. Mais itens agrupados  menor custo da transação  maior custo de retenção. 2. Cada recurso aguarda mais tempo gerando perda comercial 3. Colabora para feedback desatualizado 4. Decisões desatualizadas 5. Menor envolvimento do cliente
  • 49. 49 49 0 0,5 1 1,5 2 2,5 3 3,5 29/11/2017 30/11/2017 01/12/2017 02/12/2017 03/12/2017 04/12/2017 05/12/2017 06/12/2017 07/12/2017 08/12/2017 Pronto Linear (Pronto) Visualizando o fluxo do sistema. 0,00% 20,00% 40,00% 60,00% 80,00% 100,00% 120,00% 0 0,5 1 1,5 2 2,5 3 3,5 0 0 1 4 8 18 21 24 Mais Freqüência % cumulativo
  • 50. 50 50 Por que visualizar o fluxo?
  • 51. 51 51 QUANDO O QUADRO KANBAN NÃO É SUFICIENTE. Olhar no quadro de kanban em um dia específico não facilita a resposta a perguntas como estas: • Quanto tempo demora para completar itens de trabalho nesta etapa do processo? • Com que frequência vemos filas nesta etapa? Por quanto tempo elas duram? • Essas filas são um evento especial ou acontecem regularmente?
  • 52. 52 52 Visualizando o fluxo do sistema. Rastrear a avançar com precisão
  • 53. 53 53 O termo estatístico implica que você usará análise estatística no gráfico para obter melhor visão e tendências reais. GRÁFICOS SPC (Controle de processo estatístico) Mostram tendências de como o processo está indo ao longo do tempo.
  • 54. 54 54 Quais e quantos dados você precisa para desenhar um? GRÁFICOS SPC
  • 55. 55 55 HISTOGRAMAS DE CYCLE TIME 0,00% 20,00% 40,00% 60,00% 80,00% 100,00% 120,00% 0 0,5 1 1,5 2 2,5 3 3,5 0 0 1 4 8 18 21 24 Mais Freqüência % cumulativo Representação gráfica (um gráfico de barras verticais ou barras horizontais) da distribuição de frequências de um conjunto de dados quantitativos contínuos. http://www.portalaction.com.br/estatistica-basica/16-histograma
  • 56. 56 56 2. Mostram a distribuição do fluxo de trabalho 3. Mostram frequência ( numero de ocorrências) de um cicle time específico 4. Mostra como seria a distribuição excluindo itens bloqueados 5. Mostram medidas de tendência central 6. Mostram a forma dos dados ajudando a melhor compreender os padrões de Cycle Time HISTOGRAMAS DE CYCLE TIME 0,00% 20,00% 40,00% 60,00% 80,00% 100,00% 120,00% 0 0,5 1 1,5 2 2,5 3 3,5 0 0 1 4 8 18 21 24 Mais Freqüência % cumulativo 1. Fornecem uma visão espacial e condensada com base na freqüência de ocorrência dos tempos de um ciclo.
  • 57. 57 57 2. O cycle time é visível no eixo X 3. Conhecer a visão subjacente dos dados não é necessário para previsões 4. Ajudar a visualizar o cycle time como uma forma, nao como um número. HISTOGRAMAS DE CYCLE TIME 0,00% 20,00% 40,00% 60,00% 80,00% 100,00% 120,00% 0 0,5 1 1,5 2 2,5 3 3,5 0 0 1 4 8 18 21 24 Mais Freqüência % cumulativo
  • 58. 58 58 HISTOGRAMAS DE CYCLE TIME 0,00% 20,00% 40,00% 60,00% 80,00% 100,00% 120,00% 0 0,5 1 1,5 2 2,5 3 3,5 0 0 1 4 8 18 21 24 Mais Freqüência % cumulativo Componentes O eixo dos X é o tempo de ciclo ( lead, takt, cycle) O eixo Y são o numero de itens do backlog ( tickets finalizados) Linhas percentis verticais (como no diagrama de dispersão) Etapas Criar classes de distribuição Inserir histograma Usar distribuição ou classes de intervalo. Aplicar Curva S
  • 59. 59 59 Histograma  Fornece informações sobre tendências e comportamentos  Permite análise da variabilidade  Mostra a forma da distribuição: normal, não normal http://www.portalaction.com.br/probabilidades/62-distribuicao-normal https://support.minitab.com/pt-br/minitab/18/help-and-how-to/quality-and-process- improvement/capability-analysis/how-to/capability-analysis/nonnormal-capability- analysis/interpret-the-results/all-statistics-and-graphs/graphs/
  • 60. 60 60 Formato dos dados e variabilidade Distribuição Weibull Seu cycle time não é uma distribuição normal
  • 61. 61 61 Exercício 7 – Histograma do cycle time Item 8
  • 63. 63 63 Gráfico de dispersão Características • Eixo x é a linha do tempo ( calendário) • Eixo Y representa o cycle time • Cada ponto no gráfico indica o cycle time a data do item que terminou. 0 0,5 1 1,5 2 2,5 3 3,5 29/11/2017 30/11/2017 01/12/2017 02/12/2017 03/12/2017 04/12/2017 05/12/2017 06/12/2017 07/12/2017 08/12/2017 Quant. de itens entregues Pronto Linear (Pronto) • Linhas percentis são preferíveis - é a sua robustez em face de outliers • Recomenda-se usar os percentis 50º, 70º, 85º, 95º Quantos % de chance temos de terminar em x dias ou menos?
  • 64. 64 64 Gráfico de dispersão Características • Densidade e dispersão (outliers) indicam algum tipo de variabilidade 0 0,5 1 1,5 2 2,5 3 3,5 29/11/2017 30/11/2017 01/12/2017 02/12/2017 03/12/2017 04/12/2017 05/12/2017 06/12/2017 07/12/2017 08/12/2017 Quant. de itens entregues Pronto Linear (Pronto)
  • 65. 65 65 Exercício 7 -Gráficos de dispersão Item 9 Imagem: https://www.infoq.com/articles/kanban-siemens-health-services
  • 67. 67 67 CFD Para que serve? 1. Para medir e comunicar o progresso 2. Para responder se o time consegue entregar 3. Para visualizar a estabilidade e previsibilidade da entrega 4. Para melhor distribuição de frequência 5. Não serve para projeção mas para introspecção. 6. Não é sobre conclusões, mas análise
  • 68. 68 68 CFD • Gráfico que exibe o progresso de um processo em que há diversos estágios pelos quais um item deve passar até estar pronto. • Quando o sistema demonstra estabilidade as bandas do diagrama serão suaves e sua altura estável. • Variações indicam áreas potencialmente incômodas que requerem atenção.
  • 69. 69 69 CFD – composição Para que serve? Para medir e comunicar o progresso Para responder se o time consegue entregar Para visualizar a estabilidade e previsibilidade da entrega Para melhor distribuição de frequência Não serve para projeção mas para introspecção. Não desenhe conclusões nele, ele é sobre resposta certa. Linha horizontal superior: mudança de escopo Eixo vertical: numero de tarefas, quantos itens há na fila. Horizontal: linha do tempo ( dias, horas, semanas, etc).
  • 70. 70 70 CFD – composição Para que serve? Para medir e comunicar o progresso Para responder se o time consegue entregar Para visualizar a estabilidade e previsibilidade da entrega Para melhor distribuição de frequência Não serve para projeção mas para introspecção. Não desenhe conclusões nele, ele é sobre resposta certa. Curvas ( inclinação): número de itens em cada parte ( etapa do processo) do fluxo de entrega. Linha superior = chegadas acumuladas Linha inferior = partidas cumulativas
  • 71. 71 71 CFD – composição Para que serve? Para medir e comunicar o progresso Para responder se o time consegue entregar Para visualizar a estabilidade e previsibilidade da entrega Para melhor distribuição de frequência Não serve para projeção mas para introspecção. Não desenhe conclusões nele, ele é sobre resposta certa.A distância vertical entre duas linhas é a quantidade total de trabalho (WIP) que está em andamento. Lead time, cycle time: distância horizontal entre duas linhas (tempo médio de ciclo = data da linha inferior - data da linha superior + 1)
  • 72. 72 72 Exercício 8 – item 10 Modelando CFDS
  • 73. 73 73 CFDs: algumas análises • Alterações na estabilidade da entrega • Aumento de escopo • Análise das 3 pernas do fluxo de entrega • Crescimento de etapas
  • 74. 74 74 Por que é importante entender o CFD? 1. Análises contínuas de risco e cenários de "e se". 2. Análise da capacidade de melhora da precisão do rastreamento de custos através da correlação do tempo do ciclo com as alocações orçamentárias reais. 3. Melhora a precisão do cálculo dos custos unitários de uma história, característica e / ou lançamento.
  • 75. 75 75 • Produz stand-ups mais significativos • Alinha capacidade e demanda • Prever custos prováveis junto com datas, além de poder colocar um valor em dinheiro em reduções ou aumentos do tempo do ciclo. • Melhoram a comunicação com as principais partes interessadas para respostas baseadas em tempo e não pontos de história. Por que é importante entender o CFD?
  • 76. 76 76 Ajudam a eliminar a emoção e a recriminação associadas à estimativa. Ajudam a melhorar a efetividade operacional, pois produz uma visão em “tempo real” dos blocos sistêmicos, da variabilidade e dos estrangulamentos. Por que é importante entender o CFD?
  • 77. 77 77  Ajuda a entender onde estamos enfrentando problemas de capacidade  Ajuda a visualizar tempo de entrega, tempo de bloqueio, tempo esperado  As métricas obtidas a partir deles pode ser usadas para produzir retrospectivas mais orientadas. Por que é importante entender o CFD?
  • 78. 78 78 Quantas coisas eu preciso medir? Primeiro... Por que métricas?
  • 79. 79 79 “Para afetar mudanças positivas em seu processo geral, você não precisa passar por uma transformação ágil complexa nem precisa fazer estimativas e planejamento mais intensos. Na maior parte das vezes, tudo o que você precisa fazer é controlar o número de coisas em que você está trabalhando em qualquer momento. Simples, mas é verdade.” (DANIEL VACANTI, BENNET VALLET, “Actionable Metrics at Siemens Health Services”)
  • 80. 80 80 Não podemos controlar as ondas da incerteza, mas podemos aprender como surfar Como modelar e lidar com a incerteza? Imagem: https://www.dreamstime.com/royalty-free-stock-photography-surfing-shark-image16396567
  • 81. 81 81 Controle de processo estatístico (SPC) Teoria da variação John Seddon Todo sistema varia, isto significa não podemos esperar que o trabalho seja concluído como resulto médio.
  • 82. 82 82 Princípio 1- as coisas variam  Há variação natural em todos os sistemas. Não se surpreenda se obtiver resultados diferentes de pessoas diferentes ( ou das mesmas) em dias diferentes. Pequenas amostras não podem dizer se isso é bom ou ruim e está dentro ou fora da variação normal.  Usando um gráfico SPC, você pode ver se a variação é previsível (dentro dos limites de controle) ou imprevisível (fora os limites de controle).  Por exemplo, o desempenho de um trabalhador pode parecer excelente. Quando você obtém uma mostra maior, no entanto, vê que era exatamente o que esperar, dada a variação natural. SPC – Teoria da variação
  • 83. 83 83 Princípio # 2: compreender a variação te dirá o que esperar.  Equipes geralmente esperam estar na média todas as vezes. Mas isso não vai acontecer, porque somos seres humanos trabalhando com conhecimento, e isso naturalmente tem variações.  Isto implica dizer que o time pode estar por vezes acima da média (vai pra casa triste) e outras abaixo da média ( via pra casa feliz)  Definir o alvo em direção abaixo da média, embora pareça bom, pode produzir ainda mais fracasso, pois há que custo tentarão alcançar esse objetivo? SPC – Teoria da variação
  • 84. 84 84 Princípio # 3: Trabalhe sobre as causas das variações, que sempre são encontradas no sistema. A maioria da variação de desempenho é encontrada no próprio sistema, fora do controle dos indivíduos que trabalham nela. Considere todas as coisas que afetam sua atual situação: políticas, papéis, estrutura organizacional, procedimentos, requisitos, financiamento e informações, só para mencionar alguns. Todos estes são exemplos de coisas que (normalmente) estão fora do controle da equipe. Coisas como essas também causam variação natural no sistema. As coisas que causam a variação natural estão fora do controle do time. Os gerentes devem buscar minimizar a variação trabalhando nas coisas que causam variação no sistema. SPC – Teoria da variação
  • 85. 85 85 Princípio # 4: compreender a variação diz quando algo aconteceu. Em um gráfico SPC, você pode ver se um único valor é uma causa em especial (está fora do controle limites) ou se é uma causa comum (dentro do controle limites e, portanto, efeito da variação natural). Esteja ciente da diferença. Por exemplo: alguem leva entre 20-40 minutos dirigindo até o trabalho. Um dia ele teve um pneu furado e a viagem levou 1 h. Deveria esse único incidente mudar a maneira como dirige; levar uma pequena moto no carro? ou tratar esse incidente como isolado? Analise a variação: porquê, o que é importante: nunca se atrasar? Qual o impacto? Qual a origem? SPC – Teoria da variação
  • 86. 86 86 Padrões para aumentar a previsibilidade do lançamento Essencialmente duas estratégias: 1.Diminuir o WIP 2.Aumentar a taxa de transferência
  • 87. 87 87 First things first O “start” é tão importante quanto o “done”. Não dá pra medir tempo sem uma definição clara de ambos
  • 88. 88 88 O valor comercial Como se mover para frente, para mais perto da visão? Você pode ter o melhor sistema de fluxo contínuo em toda a cadeia de valor, mas sem feedback a alinhamento constante pode significar que está produzindo mais rapidamente itens sem valor. Fique atento ao que pode comprometer o fluxo, como por exemplo, aumento da capacidade de utilização. Lembre sempre que otimizar o fluxo é parte da eliminação de resíduos. Primeiro... Por que métricas?
  • 89. 89 89 Otimize o fluxo, não a utilização: cadência global é melhor que velocidade individual Primeiro... Por que métricas?
  • 90. 90 90 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Como evidenciar analiticamente as restrições? Se você tenta pressionar o sistema além de sua capacidade o levará a uma menor qualidade, ritmo insustentável, custos de manutenção mais altos, entre outras perdas. Como evidenciar que não há sentido em esgotar colaboradores em horas extras de longos períodos? Como evidenciar que as “soluções” podem ser muito caras e produzem mais deperdícios que ganhos? Primeiro... Por que métricas?
  • 91. 91 91 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Lidar com evidência para análise de resultados É... melhor dizer: os itens na fila de espera estão aumentando além dos desvios aceitáveis em X%”, que dizer “acho que não estamos entregando conforme o esperado”. Dados concretos permitem discutir e definir deterministicamente as ações. Primeiro... Por que métricas?
  • 92. 92 92 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Que tipo de métricas queremos?
  • 93. 93 93 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente As únicas métricas nas quais os empresários devem investir são aquelas que os ajudam a tomar decisões (Eric Ries – “Vanity Metrics vs. Actionable Metrics”) Se uma métrica não oferece poder preditivo, capturar essa métrica é um desperdício (Troy Magennis) Fonte: “By the power of metrics”, Wolfgang Wiedenroth Que tipo de métricas queremos?
  • 94. 94 94 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente  Alinhe senpre as métricas com objetivos reais da empresa.  Antes de medir estabeleça um alvo.  Sem alvo é o número pelo número sem benefício real  Medir resultados isolados não nos diz nada sobre os fatores dinâmicos que os produzem.  Pense sebre como os números podem ajudar a tomar decisões e capaciar pessoas a produzirem melhores resultados. É fácil medir o que não precisa Imagem: http://www.oakdenehollins.com/hospitality.php
  • 95. 95 95 Definições essenciais MÉTRICAS ACIONÁVEIS: conjunto de métricas que sugerem intervenções específicas para alcancar resultados esperados e melhorar o desempenho geral de um processo. Imagem: https://www.getcontrol.co/blog/actionable-vs-vanity-metrics/
  • 96. 96 96 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Métricas acionáveis Ao invés de um conjunto rígido de métricas, métricas que promovam benefícios globais, métricas que abram campo para observação mais profunda de cenários
  • 97. 97 97 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente O que mediremos?
  • 98. 98 98 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Três métricas essenciais de fluxo: WIP, Throughput e Tempo do Ciclo (lead, takt, cycle). Todas intrinsecamente ligadas por um relacionamento simples e poderoso conhecido como lei de Little. O que mediremos? A mudança em qualquer uma dessas métricas quase certamente causará uma mudança nas demais.
  • 99. 99 99 Métricas de fluxo Também são conhecidas como “métricas acionáveis”, as métricas de fluxo são diferentes das tradicionais estilo Scrum. O foco não é nos pontos por história ou velocidade, é no WIP, Cycle time e Throughput que se presta atenção.
  • 100. 100100 Lei de Little Aplicada a qualquer sistema THROUGHPUT = WIP / LEADTIME OU ( RELAÇÃO DE EQUIVALÊNCIA) LEAD TIME = WIP / THROUGHPUT THp = Projeto THt = time de desenvolvimento LTp = Projeto LTt = time de desenvolvimento
  • 101. 101101 Lei de Little Fórmula para calcular predicativamente o tempo de ciclo do número de unidades no sistema, bem como a taxa de tranferência de WIPs  Sistema precisa ser estável: visualizar instabilidade gerir cadência  obter indicador confiável.  Válido para o sistema Dev.  Seu poder não está de prever WIP, Thoughput ou Leadtime, mas de influenciar o comportamento do time com relação às suas suposições.
  • 102. 102102  Não garante que a redução dos WIPs tenha um efeito determinista no tempo do Ciclo.  Então, por que aprender sobre a Lei de Little? porque entender os pressupostos dessa lei nos ajuda a criar políticas de processo que tornarão seu processo previsível.  A implementação dessas políticas é o que torna as métricas de fluxo (WIP, Cycle Time e Throughput) verdadeiramente acionáveis. Lei de Little
  • 103. 103103 Como medimos leadtime? Ou... Quando isto estará pronto?
  • 104. 104104 Tempo de execução: Projeto: medimos o intervalo de tempo entre o ponto de compromisso e a entrega ao cliente. Para o Dev System, não medimos o tempo entre o ponto de compromisso e a primeira fila infinita. Como medimos leadtime? Ou... Quando isto estará pronto?
  • 105. 105105 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban ; Ajay Reddy The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban; Ajay Reddy
  • 106. 106106 Medindo quatro grandes áreas QUALIDADE (QUÃO BEM) • Contagem de redução de defeitos • % de itens rejeitados, etc. CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) • Tempo de resolução de defeitos • Lead time, cycle time • Eficiência de fluxo PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA) • Throughtput • WIP • Tamanho do time • Velocidade PREVISIBILIDADE (QUÃO REPETÍVEL) • Coeficiente de variação, etc.
  • 108. 108108 Não tente estimar o tamanho dos itens de trabalho. Existem apenas dois "tamanhos" - “pequeno o suficiente" e “Muito grande". "Muito grande" deve ser dividido. Imagem: http://www.vissinc.com/2012/02/28/t-shirt-sizing-predictability-with-pull-scheduling/
  • 109. 109109 Por que não medir tamanho, por exemplo, ponto por história? Sendo a historia A mais complexa que a B ela levará mais tempo pra ser concluída?  A pergunta que o cliente faz: quando estará pronto?  Complexidade relativa x lead time  Previsão é sobre análise, não estimativa  A historia sem fim: quão complexo é o complexo?
  • 110. 110110 Por que não medir tamanho, por exemplo, ponto por história? Sendo a historia A mais complexa que a B ela levará mais tempo pra ser concluída? “Tamanho certo” é um “range de possíveis” resultados dentro de um intervalo de confiança: você consegue entregar o item em x dias? Como redefinir o trabalho para caber no intervalo de confiança?
  • 111. 111111 Por que não medir tamanho, por exemplo, ponto por história? Sendo a historia A mais complexa que a B ela levará mais tempo pra ser concluída? “Tamanho certo” é um “range de possíveis” resultados dentro de um intervalo de confiança: você consegue entregar o item em x dias? Como redefinir o trabalho para caber no intervalo de confiança?
  • 112. 112112 Previsões para itens individuais Coisas importantes:  Proatividade pra completude;  Monitore o progresso: controle os itens que afetam o ciclo;  Plot a idade dos itens;  Repreveja quando tiver mais informação Imagem: https://www.123rf.com/stock-photo/proactivity.html?sti=n3v7xti2cf43k7jps0|
  • 113. 113113 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente CYCLE TIME é a única métrica que precisamos para prever itens individuais. Daniel S. Vacanti; “when will it be done”
  • 114. 114114 TAXA DE TRANSFERÊNCIA DO PERÍODO PASSADO THROUGHPUT = WIP / LEADTIME Concluimos 8 histórias nos ultimos 3 dias. Qual foi a taxa média de entrega? WIP é N ( número de itens ) Analisando passadoPRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 115. 115115 CAPACIDADE DE ENTREGA FUTURA Quantas historias por semana preciso entregar para entregar 2200 historias em 10 meses com lead time de 0,4 semanas por história? 22 Histórias Analisando o futuro PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 116. 116116 RITMO DE ENTREGA PARA A DATA PROMETIDA? TT = TAKT TIME Qual o ritmo de entrega diário para entregar (N)5 historias em (T)10 dias? Analisando o futuro TTp = Projeto TTt = time de desenvolvimento CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO)
  • 117. 117117 DURAÇÃO DO PROJETO NA MÉDIA DO RITMO DE ENTREGA Quantos dias (semanas, meses) durará o projeto (ciclo) para entregar 40 histórias, entregando 1 história a cada 2 dias? Futuro: ritmo unitário de entrega T = N . TT CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO)
  • 118. 118118 DURAÇÃO DO PROJETO NA MÉDIA DO RITMO DE ENTREGA Quando (semanas ,dias, meses) entregaremos 400 histórias, sabendo que entregamos 10 historias por ciclo de entrega e temos um lead time de 0,4 semana por história? 16 semanas CAPACIDADE DE RESPOSTA (QUÃO RÁPIDO) Futuro: Quando vai ser entregue?
  • 119. 119119 QUANTAS PESSOAS SÃO NECESSÁRIAS Para entregar 22 historias por ciclo de entrega, de quantas pessoas eu preciso? Analisando o futuro Se um WIP por pessoa, com fila de tamanho 0: 22 pessoas. Se a fila é de tamanho 2 (duas histórias na fila): 20 pessoas: 20 pessoas * 1 historia por pessoa+tamanho da fila PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 120. 120120 QUANTAS PESSOAS SÃO NECESSÁRIAS Para entregar 22 historias por ciclo de entrega, de quantas pessoas eu preciso? Analisando o futuro Adicionar mais pessoas, ou há mais itens entregues por pessoa são elementos que influenciam o fluxo de entrega. Use a fórmula com cuidado, pois não há correlação linear entre WIP e LT
  • 121. 121121 TEMPO NÃO TOCADO Imagem: http://godschildfoundation.org/?tag=queue
  • 124. 124124 Eficiência de fluxo Qual a eficiência de fluxo de um item que teve 2 dias de trabalho e 8 dias de espera? Tempo de espera: tempo de setup, bloqueados, etc. PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 125. 125125 Bloqueadores Quantidade de bloqueadores Onde ocorrem? Frequência (horas, dias, etc) com que os itens bloqueados ocorrem? Duração média de itens bloqueados? Itens bloqueados + massa escura Como capturá-los? PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 126. 126126 Bloqueadores Taxa % de adição de tarefas: mede mudanças em planos com relação ao backlog. Formula = (total de tarefas no final do ciclo – total de tarefas no começo do ciclo) / numero de dias do ciclo. Valor é positivo? Tarefas adicionadas Valor é negativo? Tarefas cortadas Medindo massa escura PRODUTIVIDADE ( QUANTO, RITMO DE ENTREGA)
  • 127. 127127 Bloqueadores Bloqueador Frequência de ocorrência Impacto em horas Ambiente quebrado 2 3 Esperando feedback 3 8 Férias/ doença 5 6 Impacto dos bloqueadores: frequência de um bloqueador x duração do bloqueio
  • 128. 128128 Métricas de qualidade Taxa de defeito. “Qualidade, eu explico pacientemente, não é a ausência de algo aos olhos da gerência, isto é, defeitos, mas a presença de algo aos olhos do consumidor, isto é, valor.’ Alan Weiss (Million Dollar Consulting (McGraw-Hill, 2009, http://amzn.com/0071622101).
  • 129. 129129 Métricas de qualidade Taxa de defeito + demanda de falha. -Não olhar a métrica isoladamente 0% 20% 27% 29% 14% 31% 33% 9% 30% 33% 14% 8% 17% 13% 0% 25% 22% Unplannedworkrate(inadditiontoplannedwork) Year-Week Number Defects Rate Linear (Defects Rate) Fonte: http://focusedobjective.com/team-metrics-right/ QUALIDADE (QUÃO BEM) quantos itens de trabalho o sistema processa devido a má qualidade.
  • 131. 131131 Riscos começam a assumir controle quando ( entre outras razões): Não usamos dados para quantifica-los, quando negligenciamos o efeito de sua ocorrência, quando temos medidas imprecisas ou insuficientes. Não conseguimos contabilidazar e entender as incertezas em nosso planejamento, ou quando falhamos em incorporar um buffer suficiente para se proteger contra eles.
  • 132. 132132 A que parte do projeto se aplica a estimativa? As três pernas do fluxo de entrega Segunda perna. Percentis 63, 85,90
  • 133. 133133  Taxas de entrega de trabalho em projetos não são uniformes, tendem a seguir uma Curva S (com atrasos no início e no final de um projeto).  Lei de Little pode, portanto, ser aplicado com alta confiança apenas para a parte média da maioria dos projetos (aproximadamente 60% da duração total do projeto).  Para os restantes 40% do projeto, precisamos trabalhar com um buffer de projeto. Como lidar com riscos na previsão?
  • 134. 134134 O T calculado deve ser usado apenas para a segunda etapa da curva Z Project planning using Little’s Law, Dimitar Bakardzhiev
  • 135. 135135 Por que não utilizamos a média calculada TH para as três pernas da curva Z?  Apenas a segunda perna da curva Z representa a capacidade do Dev System e mostra a variação de causa comum e específica para cada um.  As primeiras e as terceiras pernas da curva Z são específicas do projeto e mostram variações especiais de causa.
  • 136. 136136 A curva Z/S Aproximadamente... Primeira perna: 20% do tempo terá de entrega será lenta. Segunda perna: 60% do tempo haverá período de “hiperprodutividade" Terceira perna: 20% até o final será "lento". Os números podem variar dependendo do contexto, mas o princípio básico sobre as três seções é correto.
  • 138. 138138 A duração do projeto é influenciada pela:  Expansão do trabalho à medida que aprendemos mais sobre a necessidade do cliente.  Demanda em função de falhas (como, por exemplo, garantir alta qualidade removendo a dívida técnica). Em função disso precisamos uma forma de lidar com as influências: 40% da curva S, expansão do trabalho e demanda de falhas.
  • 139. 139139 Gerenciando incerteza ao planejar um projeto Fontes de incerteza Ao calcular o tempo de execução do projeto, precisamos considerar a incerteza em termos de:  Conta para a primeira e terceira pernas da curva Z  Conta pela Matéria Negra  Conta para carga de falha
  • 140. 140140 Matéria escura  O número de itens de trabalho crescerá através da expansão natural à medida que os investigarmos.  É possível que alguns recursos sejam divididos em 2 ou mais, assim que você começar.  É por isso que adicionamos itens de trabalho para compensar o trabalho desconhecido ou a matéria obscura. Minha experiência é que eu amortizei pelo menos 20% para isso e com as equipes novas em um novo produto (especialmente se fosse um produto novo altamente inovador, onde não tivéssemos conhecimento prévio ou experiência), então eu poderia chegar a 100%. Expansão do trabalho
  • 141. 141141 Carga de falha Adicionamos itens de trabalho para compensar a carga de falha esperada em termos de defeitos, retrabalho e dívida técnica. Expansão do trabalho
  • 142. 142142 A data de entrega prometida do projeto é então a soma da duração inicialmente calculada da segunda etapa da curva Z (T) + buffer do Projeto. Buffers
  • 144. 144144 Buffers Para gerenciar a alta incerteza e os riscos nos projetos, usamos um intervalo de tempo de segurança para proteger a data de vencimento do projeto prometida ao cliente de variação na taxa de transferência. Isso melhora a confiabilidade da data de vencimento geral também. Esse buffer é conhecido como buffer do projeto.
  • 145. 145145  Protegemos a data de entrega do projeto de uma variação de causa especial usando um buffer de projeto  Em função disso precisamos uma forma de incluir as influências: 40% da curva S, expansão do trabalho e demanda de falhas.  Isso pode ser feito calculando um buffer de projeto.  Para explicar a variabilidade associada à primeira e terceira pernas, além da variabilidade criada pela matéria escura e demanda de falhas, calculamos um buffer Buffers
  • 146. 146146 Cuidado pra não superstimar o buffer criando objetivos incapazes de serem competitivos e consequentemente perda de negócio. Buffers
  • 147. 147147 Buffers de etapa de processo Se você sabe que existe um gargalo no seu sistema, é sempre bom introduzir um buffer apropriado antes do gargalo para observar com que frequencia é drenado. Exemplo: quando a etapa “análise” demonstrar que já entregou, mas os dev não conseguem pegar o item. Para soluções de curto prazo, adicionar mais recurso pode ser útil.
  • 148. 148148 Como adicionar buffers em previsões probabilísticas? É preciso adicionar buffers em previsões probabilísticas?
  • 150. 150150 Planejamento probabilístico Entre outras coisas...  Particularmente útil quando não tem um monte de dados reais para trabalhar  Possibilita reamostrar o padrão específico dos resultados reais  Nos permitem executar “e se”
  • 151. 151151 Planejamento probabilístico Entre outras coisas...  Permite examinar a forma dos dados e analisá-los para tirar conclusões sobre o comportamento do sistema em comparação com outros que geram a mesma forma  Podemos experimentar e isolar alterações  Ajudam a determinar estratégias de gerenciamento para o sucesso
  • 152. 152152 Classificando incertezas  Aleatoria: não pode ser reduzida ou aumentar o grau de certeza; Exemplo: no contexto do desenvolvimento de software representam variações naturais: esforço de trabalho, produtividade, questões de qualidade que exigem retrabalho. Epistêmica: pode ser potencialmente gerida ou reduzida obtendo através de conhecimento (mais dados ou outros experimentos). Exemplo: eventos e impactos probabilísticos
  • 153. 153153 Como podemos prever o tempo de entrega do projeto sem um cronograma detalhado? Isso está avaliando as dependências entre o trabalho, o custo do trabalho e a seqüência do trabalho? Planejamento probabilístico
  • 154. 154154  Uma previsão requer uma faixa de incerteza e uma probabilidade  Previsões são resultantes da distribuição da dados  O ponto de partida mínimo é coletar dados sobre o tempo de entrega, taxa de entrega, WiP e custo (geralmente principalmente o esforço em pessoa-dias consumidos pelo serviço). Previsão de múltiplos itens
  • 155. 155155 Por que não se pode confiar na média? 1. Variabilidade, dados discrepantes, outliers 2. Dados nem sempre se agrupam em torno de uma única média: tendência dist. normal
  • 156. 156156 A falha da média
  • 157. 157157 “Eu já aludi como nossa inclinação natural para aplicar valores médios em previsão representa uma "falha de médias" a evitar. Afinal, você não quer sofrer a mesma situação do estatístico que se afogou em um rio cuja "profundidade média" era 1m. Por esse motivo, recomendo a previsão de valores que representem pelo menos do 80º ao 85 percentil dos resultados modelados” Ajay Reddy [9] A falha de usar só médias Imagem: http://herdingcats.typepad.com/my_weblog/2011/02/there-is-always-an-average-but-is-not-always-meaningful.html
  • 158. 158158 Nunca comunique uma previsão só tem termos de média ou dos resultados mais prováveis Cycle time como um único número mascara as incertezas A falha de usar só médias
  • 159. 159159 Em ambientes de deenvolvimento de software: 1. Métricas tendem a refletir padrões de distribuição distorcidos à esquerda ou à direita (cauda muito longa de resultados "outlier“) 2. Em tais padrões, o resultado médio geralmente é um valor substancialmente menor que a média. 3. Aplicar valores médios na previsão representa estimativas imprecisas 1. Na melhor das hipóteses 50% das amostras serão menores que a mediana e, portanto, mais de 50% dos resultados serão menores do que a média A falha de usar só médias
  • 160. 160160 MEDIDAS DE POSIÇÃO ( tendência central): Moda, Média, Mediana. Onde se concentram, qual a tendência das amostras? MEDIDAS DE DISPERSÃO: Amplitude, Desvio Padrão. Qual o valor que resume a variabilidade de um conjunto de dados? Analisando além da média
  • 161. 161161 Mediana: valor que divide o conjunto de dados em dois subconjuntos de mesmo tamanho {1100, 1200, 1210, 1250, 1300, 1450, 1500, 1600, 1980) Desvio padrão: indica o grau de variação ( dispersão) de um conjunto. serve pra dizer o quanto os valores dos quais se extraiu a média são próximos ou distantes da própria média. Analisando além da média Moda: valor que ocorre com maior frequência ou o valor mais comum (5,6,6,7,8)
  • 162. 162162 O planejamento deterministico é usado atualmente pra forçar a certeza em situações incertas e mascarar a incerteza ao invés de destacá-la. Planejamento determinístico
  • 163. 163163 Simulação de Monte Carlo Métodos que aplicam uma abordagem frequentista para modelagem aleatória de incerteza por amostragem- embora qualquer abordagem possa ser usada- na qual cada elemento da população tem a mesma chance de ser escolhido.
  • 164. 164164 Simulação de Monte Carlo 1. São úteis quando uma série de condições de entrada podem afetar significativamente o resultado final produzido por um processo ou sistema. 2. Quando a simulação é executada, valores aleatórios dentro dos intervalos definidos em todas as variáveis são gerados, produzindo resultados diferentes para cada simulação completa. 3. Ajudam a gerir risco em gestão do conhecimento
  • 165. 165165 1. Executam muitas permutações de uma simulação para encontrar prováveis padrões de saída. 2. Uma amostra grande de dados para a distribuição ajuda a mostrar padrões de diferentes tipos de dados no contexto. 3. Os valores potenciais para cada variável caem dentro de um intervalo calculado estatisticamente (idealmente calculado a partir de dados históricos para cada um): limite alto e limite baixo. Simulação de Monte Carlo
  • 166. 166166 Monte Carlo Passo 1: Crie um modelo paramétrico, y = f(x1, x2, ..., xq). Passo 2: Gere um conjunto de inputs randômicos., xi1, xi2, ..., xiq. Idealmente, pelo menos parcialmente histórico e os compute. Passo 3: Avalie o modelo e guarde os resultados, como yi. Passo 4: Repita os passos 2 e 3 para i = 1 até n. Passo 5: Analise os resultados usando histogramas, sumarização estatística, intervalos de confiança, etc Resumindo
  • 167. 167167 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Métricas: algumas palavras finais ( por agora)
  • 168. 168168 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente Objetivo das métricas  Melhorar, não punir.  Ter uma maneira efetiva de avaliar melhor o passado e tomar melhores decisões no presente  Diagnosticar um problema ou condição  Alavancar e influenciar comportamento do time e da empresa Métricas: algumas palavras finais ( por agora) Imagem: https://commons.wikimedia.org/wiki/File:Martina_gives_Bob_Bryan_a_hand.jpg
  • 169. 169169 Características de boas métricas  Objetivamente comparativo (capaz de ser comparado a outros períodos de tempo e / ou grupos)  Facilmente compreensível: - Permite às pessoas internaliza-las e discuti-las - Colabora para mudança no processo ou cultura. Métricas: algumas palavras finais
  • 170. 170170 Características de boas métricas De preferência quantitativo: -Dados quantitativos são geralmente mais científicos e mais fáceis de entender - Qualitativos ajudam a responder "porquê" Ser relatável: - Informar sobre o que está acontecendo ou permitir especular ajudando a descobrir novas idéias. Métricas: algumas palavras finais
  • 171. 171171 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente  Ajudam a lançar um olhar combinado de métricas na análise  Ajudar a liderar: - ver tendências ou preditores de resultados futuros - ver atrasos iluminando condições reais e resultados  Permite verificar percepções contra dados que as demonstrem.  Ajudam a responder perguntas às quais atualmente não temos resposta Características de boas métricas Imagem: ps://pt.slideshare.net/kim_williams/enhancing-scholarly-reputation-using- metrics-and-name-management-for-good-not-evil-26329454
  • 172. 172172 O problema mais comum não é que não chegamos à causa raiz; O problema mais comum é que nós Nem tente  Te ajudam a entender melhor sua demanda e capacidade  Te ajudam a distinguir entre mudanças boas ou más de um ponto de vista de um objetivo  Ajudam a promover transparência e analisar incongruências entre previsão e realidade.  Promovem visão ubiqua entre times, organização e stakeholders sobre a entrega do sistema, criando um programa de gestão com dados altamente visíveis.  Ajudam a visualizar como o impacto da utilização de recursos influencia no fluxo de entrega. Características de boas métricas
  • 175. 175175 [1] "Moneyball for Software Projects: Agile Metrics for the Metrically Challenged";Troy Magennis goo.gl/VbAEEZ [2] "High-Level Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev goo.gl/KkC74b [3]"#NoEstimates Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev goo.gl/SDHJYP [4]"Little's law and predictability"; Daniel Vacanti goo.gl/ETDzg9 Referências - Presentations
  • 176. 176176 Referências - Presentations [5] "Kanban Metrics in practice at Sky Network Services"; Mattia Battiston goo.gl/tQXqwN [6] "By the power of metrics";Wolfgang Wiedenroth goo.gl/ebGU3h
  • 177. 177177 Referências - Vídeos [1] "Project Planning Using Little's Law"; Dimitar Bakardzhiev https://www.youtube.com/watch?v=r38a25ak4co [2] "High-Level Project Planning using Monte Carlo simulation"; Dimitar Bakardzhiev https://www.youtube.com/watch?v=GE9vrJ741WY [3] "Portfolio Management";Jake Xia https://www.youtube.com/watch?v=8TJQhQ2GZ0Y
  • 178. 178178 Referências - Papers [1] "Project planning using Little’s Law"; Dimitar Bakardzhiev goo.gl/rw1X5T
  • 179. 179179 Referências - Articles [1] "Actionable Metrics at Siemens Health Services"; Daniel Vacanti goo.gl/nS34ZP [2] "#NoEstimates Project Planning Using Monte Carlo Simulation"; Dimitar Bakardzhiev goo.gl/FMeeXR [3] "Inside a Lead Time Distribution"; Alexei Zheglov goo.gl/yHx3eY [4] "Lead Time Distributions and Antifragility"; Alexei Zheglov goo.gl/Ytnwya [5] "Doing Team Metrics Right"; Troy Magennis goo.gl/Qm6irp
  • 180. 180180 Referências - Articles [6] "Release planning using a great extension of Little’s Law"; Sebastian Radics goo.gl/XnH7Qs [7] "Probabilistic Project Sizing Using Randomized Branch Sampling (RBS)"; Dimitar Bakardzhiev goo.gl/vFiSPN [8] "Control Chart – How to create one in Excel 2010"; Håkan Forss goo.gl/3VyLr8 [9] "How to Match to Weibull Distribution without Excel";Håkan Forss goo.gl/nFDuuU [10] "Removing the bubbles: solving bottlenecks in software product development"; Benjamin Mitchell goo.gl/swfDzx
  • 181. 181181 Referências - Articles [11] "How to Match to Weibull Distribution in Excel"; Alexei Zheglov goo.gl/LVB4Jo [2] “Project Portfolio Management” http://johanfrisk.com/queue/