Imersão Ágil - Lean & Conceitos_V9 34

Prévia do material em texto

uma das iniciativas
I M E R S Ã O
Á G I L
W O R k S H O P
áudio: pt-br
legendas: off
1ª Temporada
2018
As Origens do Lean
Lean Mindset
Gestão Visual e 
Uso do Kanban Um pouco do Scrum
Um pouco de 
Engenharia de Valor
Por trás das 
Métricas ÁgeisGames
1ª Temporada
EPISÓDIO 1
Kiichiro Toyoda
▪ “Antes de dizer que não pode ser feito, tente.” -- Kiichiro Toyoda
1894 - 1952
Sakichi Toyoda
O REI DOS INVENTORES
Jidoka, 5Why, ...
a crise da Toyota nos anos 50
▪ um recomeço após um quase-fim em 1950
ANO 1950
SITUAÇÃO Intervenção pelos credores / Pedido de Falência
FUNCIONÁRIOS Disputas trabalhistas em massa
EXECUTIVOS Renúncia da maioria dos executivos, inclusive do 
fundador Kiichiro Toyoda
CAIXA Sem dinheiro para comprar máquinas, linhas, peças e 
contratar pessoal
RESULTADO Negativo
POR ÁREA Negativo p/ Maioria -> que área é aquela?
a jornada de Taiichi Ohno
▪ gemba walking
gemba...
Meio 
Inovador 
Interno
“Quanto da nossa agenda está
ocupada por semana com atividades
de melhoria?”
Comparação dos modelos de gestão de ideias
melhores momentos da 
entrevista de Taiichi Ohno
“O desperdício acontece quando 
as pessoas pensam que estão 
trabalhando bem.” Taiichi Ohno
“Precisamos repetir a rotina de 
trabalho, mas sem repetir o 
desperdício.” Taiichi Ohno
“ Sinais de que não estamos vendo o desperdício:
- Sempre fizemos as coisas dessa maneira.
- Mas essa parte não é minha! ”
Taiichi Ohno
“A falta de dinheiro foi a restrição 
que forçou a concepção da 
produção de estoque mínimo. ” 
Taiichi Ohno
▪ Kanban era um cartão que agia como 
moeda e comunicava o que era consumido
▪ A redução do LEADTIME permitiu que a 
Toyota se recuperasse em todas as áreas
definição de LEAN
▪ é eficaz para qualquer processo 
Valor
Desperdício
Foco no que é mais importante
PessoasKaizen
Princípios
Lean
Valor 
Percebido
Desperdício 
Zero
Fluxo 
ContínuoEstoque Zero
Qualidade 
Extrema
SISTEMA EMPURRADO ( “Pensamento Tradicional” )
Expectativa
de Demanda
Produção 
em Massa
Economia 
de Escala
▪ Comportamento
▪ Estatística
▪ Consumo esperado
▪ Foco na Máquina
▪ Estoque
▪ Controle do Plano
▪ Distribuição
▪ Marketing
▪ Vendas
Empurrando
para o 
consumo
SISTEMA PUXADO ( “ÁGIL” )
Necessidades 
do Cliente
Produção sob 
Demanda
▪ Qualidade!
▪ Comunicação
▪ Melhoria Contínua
▪ Foco nas Pessoas
▪ Estoque Zero
▪ Flexibilidade
Puxado 
pelo 
Cliente
Adaptação
▪ Visão e Valor
▪ Priorização
▪ Resultado de 
Negócio
Sistema Puxado + Evolução Contínua
PRODUCTION FLOW
DoR
Definition
of
ready DoD
Definition Of Done
O que não é valor é desperdício.
Software só está pronto quando ativa valor em produção.
TI LEAN
Os 7 Desperdícios
Superprodução
Tempo de Espera
Fluxo Desnecessário
Superprocessamento
Excesso de Movimentos
Defeitos
Estoque
Manufatura
Homologação Tardia
Bloqueios, Sequencia Não Planejada
Falta de Foco, Compartilhamento
Gold Plating , Burocracia
Falta de Automação
Bugs, Criatividade Subestimada
Trabalho Parcialmente Completo 
TI
KAIZEN
Um exemplo de quadro
Cause Ideas
PARKING LOT
WIP CELEBRATE
BENEFITS
#partiu 
Kaizen para
criar melhorias 
contra causas de desperdícios?
a popularização do termo LEAN
▪ o jeito Toyota precisava de um nome (LEAN) e alguém para contar (JOHN SHOOK)
THE LEAN HOUSE
▪ medir, conhecer, analisar, melhorar e voltar a medir
JIDOKA
▪ “autonomação” ou automação com foco no ser humano (Kiichiro Toyoda)
LEAN é aplicado em várias áreas
▪ a cada dia surgem novas aplicações para Lean
thanks
keep the faith
1ª Temporada
EPISÓDIO 02
E em nosso dia-a-dia de 
produção de software, 
quais informações 
podemos/devemos dar 
visibilidade?
Extraia métricas do seu 
quadro KANBAN
thanks
show the situation
1ª Temporada
EPISÓDIO 03
frameworks ágeis
▪ jeitos de fazer diferente do “tradicional”
A G I L E
Kanban
FDD
ASD
XP
SCRUM
Crystal
A G I L E
os idealizadores do SCRUM
O MANIFESTO ÁGIL
▪ agilemanifesto.org OOPSLA 2001
Em 2018, o manifesto completa 17 anos de idade!
▪ Os indivíduos e a interação entre eles mais do que o processos e ferramental
▪ Software funcionando mais do que uma documentação extensa e detalhada
▪ A colaboração com o cliente mais do que a negociação de contratos
▪ Responder a mudanças mais do que seguir um plano pré-estabelecido
http://agilemanifesto.org/
Lean gera agilidade !
Lean / Ágil
vs
modelos 
baseados em 
ESTOQUE
PAPÉIS NO TIME SCRUM
▪ comunicação
Questões chaves para P.O. e P.O. Team
comunicação e interdependência
• Poder de Decisão
• Disponibilidade
• Processo Enxuto e Flexível
“O” Produto
VISÃO DO PRODUTO:
Qual o público alvo ?
Qual a motivação para atender o público alvo ?
Qual o nome do produto? As features são versionadas?
Quais são os principais benefícios?
Competitivo em relação aos concorrentes ?
Qual o diferencial ? 
Exemplo:
Para atender a diretoria executiva que necessita verificar 
mensalmente o andamento dos projetos da companhia, o 
Cockpit de Projetos é um sistema que consolida todas as 
informações dos projetos e gera uma apresentação 
executiva. Ao contrário do trabalho manual que existia para 
gerar essa visão, o nosso produto faz isso de forma 
automática.
BACKLOG INCEPTION
Criação de estórias e seus 
critérios de aceitação
SPRINT #0
- Time preparando o ambiente
P.O + SM e o Time
Estória 
Critério de 
aceitação
INVEST
▪ Lembra que os KANBANs eram usados como moeda? Então...
MOSCOW
▪ Uma forma de priorizar usando Conhecimento de Negócio
estória e critério de aceitação
▪ um exemplo
Eu como Colaborador
necessito visualizar uma lista de 
notícias na Home Page da intranet
pois assim posso me atualizar das 
últimas novidades.
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Estimativa: ___
Valor de 
negócio:___
Critérios de aceitação:
- <critério 1>
- <critério 2>
- <critério N>
Critérios de aceitação:
- A lista deve exibir as 5 últimas 
notícias ordenada por data.
- Ao clicar em “ver mais” uma página 
com todas as notícias deve ser exibida.
- Seguir o layout visualizado em: 
http://www.projetox.com/homepage_mockup.jpg
Valor de 
negócio: 12
Estimativa: 3
Técnica para definição do Valor de negócio:
Qual o benefício de se ter esta funcionalidade (0 -10)?
Qual a penalidade de se não ter esta funcionalidade (0 - 10)?
Benefício + penalidade = Valor de Negócio
PB = PRODUCT BACKLOG
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Eu como <usuário>
necessito de <funcionalidade>
pois assim <retorno>
Precisamos colocar em uma 
ordem de prioridade.
como priorizar a PB
Como colaborador necessito visualizar uma lista de notícias...
Como colaborador necessito de um mecanismo de busca....
Como administrador necessito monitorar o log de acesso...
.
.
.
Valor de
Negócio
14
9
17
.
.
.
Estimativa
(complexidade)5
3
5
.
.
.
VN / Est
2,8
3
3,4
.
.
.
Menos
Prioritário
Mais 
prioritário
Prevendo mudanças, evitando desperdícios...
Criar os Critérios de Aceitação (detalhamento) somente para as estórias mais prioritárias.
DoR
▪ definition of ready
❑ Product Backlog está priorizada?
❑ Estórias mais prioritárias tem critérios de aceitação?
❑ Todos os impedimentos das estórias mais prioritárias estão resolvidos?
ritos ou cerimônias
-Planning – Parte 1
- Entendimento do escopo
- Estimativa de complexidade
- A equipe seleciona itens do Product Backlog com os quais se compromete a 
concluir no próximo sprint, criando o SPRINT BACKLOG
-Planning – Parte 2
- O time divide as estórias do Sprint Backlog em tarefas
- Cada tarefa é estimada pelo time em consenso (pontos e esforço)
❑ SPRINT PLANNING
iteração = SPRINT:
Períodos de 2 – 4 semanas onde o produto é 
projetado, construído e testado.
ritos ou cerimônias
❑ DAILY -> Quanto nós acreditamos como um time que o 
Sprint vai dar certo?
- O que você fez desde a última 
daily para o sucesso do sprint?
- O que você planeja fazer até a 
próxima daily para o sucesso 
do sprint?
- Há algum BLOCK 
para o sucesso do sprint ?
ritos ou cerimônias
- P.O. (com a ajuda do time) 
apresenta para convidados o 
que foi produzido no sprint
- Duração máxima de 2h
- Informal
❑ DEMO MEETING
ritos ou cerimônias
- O que foi bom?
- O que foi ruim?
- O que melhoramos?
- O que vamos melhorar?
KAIZEN
melhoria contínua
pensamento LEAN
❑ RETRO MEETING
artefatos
❑ BURNDOWN CHART
artefatos
❑ registre a leitura e ações do BURNDOWN diariamente
Priorização de 
Funcionalidades 
Importantes
Construções 
curtas a taxas 
constantes
Alinhamento 
Diário
Comunicação 
direta e fluída
Colaboração 
real-time
Entrega de 
funcionalidades 
com qualidade de 
produção
SCRUM FRAMEWORK
• Ciclos curtos
• Colaboração disciplinada promove 
maior grau de compromisso
• Priorização vs Despriorização
• Menos burocracia
• Entregas Rápidas vs 
Pré-detalhamento extensivo
• Constante: como entregar melhor e 
mais rápido?
thanks
show me the code
1ª Temporada
EPISÓDIO 04
engenharia de valor
valor
▪ fórmula básica
▪ A missão do projeto > A visão estratégica de negócio > Compartilhar propósitos > Direcionar valor
aplicando Value Eng na Product Backlog
Fórmula do Elevator Pitch
▪ CLARIFICANDO O BUSINESS VALUE
Fórmula do Elevator Pitch
▪ EXEMPLO
BUSINESS DRIVERS
▪ VISÃO ESTRATÉGICA DE NEGÓCIO
O que nossos entregáveis estão ativando no negócio?
Quais indicadores de negócio estamos afetando? Como?
Qual a visão comum que resume nossa entrega?
BUSINESS DRIVERS
▪ Quais características ou canais que levam o software à atingir a visão estratégica?
BUSINESS DRIVERS
▪ Quais características ou canais que levam o software à atingir a visão estratégica?
Grau de Influência
BUSINESS DRIVERS
▪ Quais características ou canais que levam o software à atingir a visão estratégica?
Grau de Influência
Partes ou Características 
Significantes do Software Transação
Conjunto de Funcionalidades
Tipos de Funções
...
( não técnico )
Deve ser claro do ponto de vista do 
usuário / do negócio
Definido em consenso com a área 
de negócio
COMPONENTES DE VALOR
▪ Grupo de Funcionalidades ou as próprias Funcionalidades (Épicos e/ou Estórias) 
COMPONENTES DE VALOR
▪ Grupo de Funcionalidades ou as próprias Funcionalidades (Épicos e/ou Estórias) 
CURVA DE VALOR
▪ Ordenando os componentes e/ou funcionalidades e colocando em um gráfico
Priorização com a Visão de Valor para o Negócio
▪ Em uso durante todo o processo a partir da PRODUCT BACKLOG
Visão atualizada da Curva de Valor:
Engenharia de Valor
▪ Ferramental !!!
Engenharia de Valor no Suporte (AMS)
▪ Ferramental?
Causa-Raiz
▪ Com ferramental de apoio + engenharia de valor vai reduzir os custos de suporte
thanks
business first
1ª Temporada
EPISÓDIO 05
mesclando os modelos de decisão
▪ como analisar melhor para tomar melhores decisões
RACIONAL
Pensar
CONSTRUTIVO
Fazer
INTUITIVO
Perceber
ADAPTAR
tomando decisões em grupo
▪ vantagens do consenso
Maior precisão
se duas cabeças pensam melhor que uma, várias cabeças pensam ainda melhor
Transmissão e compartilhamento de informações
envolve diversidade e quantidade de informação
Maior motivação
envolvimento de várias pessoas na decisão = consenso
Maior coordenação e controle
ações subsequentes = próximos passos
Vamos medir pensando nas 
mudanças e com base no 
modelo de sucesso do cliente
1º uma escala básica
comparações matemáticas relativas
▪ imaginando funcionalidades de um software
Complexidade Número % Etiqueta Pontos %
Extra Small 1 3%
Simples / Baixa 10 17% Small 3 11%
Média 20 33% Medium 5 17%
Complexa/Alta 30 50% Large 8 27%
Extra Large 13 42%
Total 60 100% 30 100%
Degrau Escala
2º rastrear o tempo
de “BURN”
LEAD TIME
Entrada Saída
Lead Time
Visão do Cliente
CYCLE TIME
burn / queima
Ticket 
Created
Ticket 
Resolved & 
ACTIVATED
Lead Time
Cycle Time
BURN / Queima
cycle time & lead time
▪ a vida real
BURN / Queima
cycle time + lead time no fluxo
? ?
E antes?
E depois?
SCRUM : lead time & cycle time
Business Vision Prioritized 
Product 
Backlog
Release Plan
Control
SPRINT
Sprint 
Backlog
Accepted 
Deliverables
Lead Time
Cycle Time
conceito de throughput
▪ conceito de burn / queima
▪ Qual é a saída?
▪ O que está sendo produzido?
▪ Quantos itens foram produzidos?
▪ Qual a velocidade de produção?
• THROUGHPUT
= quantidade média por ciclo
• VELOCITY
= total de pontos por ciclo
Temos a visão clara das necessidades?
Visão
Temos a visão da solução?
Temos visão dos indicadores de negócio?
- Medir os indicadores de negócio ! [ base de dados ]
Formatos e/ou templates de 
documentos de Visão?
Vision Board ( sample )
Vision Board Detail / Focus ( sample )
O que precisamos? Quais os desafios?Passos
Tendências 
Negativas
Dores
Medos
Tendências 
Positivas
Oportunidades
Expectativas
Desejos
Necessidades
Nome
Papel
Ok... Tudo entendido, carregando a PB.... 
Agora temos as ESTÓRIAS!
gerindo estórias
▪ ferramental?
Key-Users
+
Documentação + 
Conversas
PO
Product Owner
o que o cliente precisa em termos de estimativa?
▪ unidades
Tema
Épico
Estória Estória
Tarefa Tarefa
Ballpark
Estimate
Mesurement
Ordem de Grandeza: XS, S, M, L, XL
base histórica + opinião especializada
Estórias tabuladas + etiqueta
+ base histórica + análise do esforço
Medição do realizado
base de conhecimento de estimativas
▪ PDCA de estimativas > base de conhecimento
Orçado / Vendido
Estimado / Planejado
Executado / Medido
Story Map:
> RASTREABILIDADE
Definição de Escopo e Governança
▪ o mínimo é a excelência
▪ Escopo melhor entendido
▪ Premissas mais claras
▪ Estimativas mais precisas
▪ Planos mais flexíveis
▪ Acordos mais claros e justos
▪ Resultados melhores
Restrições na produção de software
▪ E os riscos?
value
(intrinsic)
quality
(intrinsic)
constraints 
(Scope, Time, 
Cost)
Iron Triangle 
Agile Triangle
Controle otimizado do Budget
▪ Controle orçamentário arrojado
★estimado
★planejado
★aprovado
★monitorado
★otimizado
★reportado
E as INCERTEZAS ??
O Cone da Incerteza
▪ O que entendemos com isso?
Okay.... como as equipes ágeis 
lidaram com isso ao longo do 
tempo?
A história da medição de software em projetos ágeis
▪ Medição de software para medir produtividade e outras métricas
2008 2012 2013 20152006 . . .2014
Medição em Horas e em Story Points
▪ Como medir em horas ou Story Points
Tema
Épico
Estória Estória
Tarefa Tarefa
Story Points
A = DIAS LINEARES
B = PESSOAS ALOCADAS
SP = A / B
Exemplo: SP = 20 /5 = 4
Tarefa ATÔMICA
sempre em HORAS Lineares
T-SHIRT-SIZING
▪ Colocando etiquetas com tamanho que valem pontos
Planning Poker
▪ O processo de estimativas usando consenso
Planning Poker
▪Estimando usando pontos ou horas
Hmmm.... E as medidas são 
relativas???
Complexity Points + T-Shirt Sizing
▪ ooops
Oooops....escalas diferentes?
T-Sizing
▪ Escala Referencial ou Medição Relativa
XS S M L XL
XS S M L XL
Uma nova referência... E agora?
T-Sizing
▪ Escala Referencial ou Medição Relativa
T-Shirt sizing
depende de
referências que são
desnormalizadas
em diferentes 
contextos
comparações de estimativas
▪ A base de conhecimentos precisa ser útil
Team, Project, Client, 
Whatever …
A
Team, Project, Client, 
Whatever ….
B
Normalizando a Complexidade
▪ Analisando RISCOS vs ESFORO vs EXPERIÊNCIA (conhecimentos)
Que tal uma régua de complexidade normalizada?
complexity rule
● Um modelo para determinar complexidade funcional
● único, objetivo e fácil de aplicar
● para qualquer negócio e plataforma de software
● desacoplado de aspectos técnicos
● padrão e estável o suficiente para não mudar ao longo do tempo e nos times
● permitir estimar pontos normalizados considerando esforço, riscos e a experiência do time
● que defina uma linguagem comum entre os vários times
1ª Temporada
EPISÓDIO 06
One Piece Flow
O mito da multitarefa
Medindo o desempenho
2 rodadas
de 3 a 6 por equipe
GAME de
simulação de execução
v1.02
LEAN Production
sistemas de produção
empurrado vs puxado
3 sprints 
de 3 a 6 por equipe
simulação de sistemas 
de produção 
v7.03
As Origens do Lean
Lean Mindset
Gestão Visual e 
Uso do Kanban Um pouco do Scrum
Um pouco de 
Engenharia de Valor
Por trás das 
Métricas ÁgeisGames
Brilhem !!!
Almir Segatti
19 98204-3225 - almir.segatti@gmail.com