1. Módulo 2 - As estratégias
1.1. M2A03 Gestão de WIP Como fazer
1.1.1. Feedback visual
1.1.1.1. Tangibilizar o resultado
1.1.1.1.1. Jogar o WAR sem o board, não tem jogo
1.1.1.2. Mais fácil de manipular
1.1.1.2.1. Post its
1.1.1.2.2. cartões
1.1.1.3. Cada equipe tem um mapa diferente
1.1.2. Quadro na parede é a melhor solução
1.1.3. Mapear ao trabalho em progresso
1.1.3.1. os itens em trabalho devem ser colocados no quadro
1.1.3.1.1. mapear as etapas
1.1.3.1.2. pode colocar em uma planilha todos os itens
1.1.3.2. Pode ter itens esperando alguma coisa
1.1.3.2.1. Fila
1.1.3.2.2. Buffer
1.1.3.3. as demandas agora começam a ser tangíveis
1.1.4. Administrar a capacidade
1.1.4.1. Modelo tático para vencer as demandas
1.1.4.2. organizar o time para saber a jogada certa
1.1.4.3. O jogador pode estar em pontos diferentes do quadro
1.1.4.4. Política de limitar o WIP
1.1.4.4.1. Seja eficaz
1.1.4.4.2. Gerar folga sistemica
2. Módulo 3 - As armas
2.1. M3A01
2.1.1. Uma Imagem vale por mil palavras Processar imagens (mapas) melhor que formato texto
2.1.2. O exemplo da bicicleta uma conectada a outra Não faz sentido, não entendo
2.1.3. Mapas permite simulação visualização futura Modelo mental
2.1.3.1. Enxerga gargalo
2.1.3.2. Enxerga limites
2.1.4. Quadro Kanban
2.1.4.1. Quadro Kanbam é uma foto do momento
2.1.4.1.1. Server para fazer coordenação tática
2.1.4.1.2. Saber o que precisa ser feito
2.1.4.1.3. O que está acontecendo hoje
2.1.4.1.4. Tem um ciclo de evolução
2.1.4.2. Está sujeito a ficar desatualizada
2.1.4.3. O sincronismo deve existir entre o quadro atual e o mundo real
2.1.4.4. Refactoring
2.1.4.4.1. Fazer refactoring do quadro
2.1.4.4.2. Fazer o ciclo de refactoring para evolução/melhoria do quadro
2.1.4.4.3. Melhora aspectos internos do processo
2.1.4.5. As pessoas querem mapear o processo em torno do Kanban
2.1.4.6. Ciclo de feedback
2.1.4.6.1. Participa do ciclo de feedback de visualização do trabalho
2.1.4.6.2. - Ele mostra se algo está fora do normal - Reduz o ciclo de feedback de consciência da situação do seu trabalho
2.1.4.6.3. Valida o estado das hipoteses
2.1.4.7. Nosso cérebro
2.1.4.7.1. Recebe a imagem e sofre filtros de modelos mentais
2.1.4.7.2. Cria significado para a imagem e se torna util
2.1.4.7.3. Filtros interessantes
2.1.4.7.4. Vídeo sobre o processamento das imagens no nosso cérebro
2.1.4.8. Kanban físcico
2.1.4.8.1. Maior engajamento da equipe
2.1.4.8.2. Iteração maior
2.1.4.8.3. exemplo de um jogo de tabuleiro
2.1.4.8.4. cria significado
2.1.4.8.5. Equipe vai querer usar porque de fato ajuda no trabalho
2.2. M3A02
2.2.1. Físico x Eletrönico
2.2.1.1. Físico é melhor
2.2.1.1.1. razóes
2.2.1.1.2. cada vez mais rico e customizado
2.2.1.1.3. Problemas
2.2.1.1.4. No inicio do process não vá para o físico
2.2.1.2. eletronico
2.2.1.2.1. posso errar na digitação
2.2.1.2.2. nem sempre é possível customizar
2.2.1.2.3. nào há ferramenta que permite customizar tudo no quadro
2.2.1.2.4. times tem adaptação rápida
2.2.1.3. Dicas
2.2.1.3.1. post its
2.2.1.3.2. cartão de índice
2.2.1.3.3. bolinhas adesivas varias cores
2.2.1.3.4. A montagem do quadro
2.2.1.3.5. avatar
2.2.1.3.6. Labels das colunas
2.2.1.3.7. post it Rosa
2.2.1.4. Ferramentas
2.2.1.4.1. Trello
2.2.1.4.2. Kanbanize
2.2.1.4.3. LeanKit
2.2.1.4.4. Site
2.3. M3A03
2.3.1. Padrões para design de mapas
2.3.1.1. Modelo mental (Framework)
2.3.1.1.1. input
2.3.1.1.2. in progress
2.3.1.1.3. output
2.3.1.2. Modelo tradicional de quadro
2.3.1.2.1. raias verticais (handoffs)
2.3.1.2.2. raias horizontais
2.3.1.2.3. Team view
2.3.1.2.4. Priority filter
2.3.1.2.5. initiative box (by Alisson)
2.3.1.2.6. Perpetual multi-vote
2.3.1.3. documentando do processo
2.3.1.3.1. explicação de cada coluna
2.3.1.3.2. ou critério para a atividade ir de um lugar a outro
2.4. M3A04
2.4.1. Exemplos de mapas
2.4.1.1. quadro quando temos demanda por projetos
2.4.1.1.1. vários projetos rodando ao mesmo tempo
2.4.1.1.2. prioriza-se os projetos
2.4.1.1.3. Equipe puxa atividade e vai até o fim
2.4.1.2. Modelo do Jeff Patton
2.4.1.2.1. usa fita dupla face
2.4.1.2.2. buffer fica na própria coluna a parte de baixo
2.4.1.2.3. fila de espera também na mesma coluna
2.4.1.2.4. fluxo anda de cima para baixo e a avança para próxima etapa
2.4.1.3. Development Team por Release
2.4.1.3.1. Não tem Business Value
2.4.1.3.2. são apenas varias features agrupadas
2.4.1.4. Business Analysis Team
2.4.1.4.1. Está associado ao mapa de Development
2.4.1.4.2. É outro time
2.4.1.4.3. responsável pelos testes do mapa Development Team por Release
2.4.1.5. Carteira de projetos de um gerente
2.4.1.5.1. Com base nas expectativas do cliente
2.4.1.5.2. antecipava os problemas com cliente e contornava a situação
2.4.1.6. Petrobrás
2.4.1.6.1. Quadro voltado para a maturidade de práticas dos projetos
2.4.1.6.2. cada raia horizontal é um projeto
2.4.1.6.3. raia vertical é uma boa prática
2.4.1.6.4. para cada prática alcançada pelo projeto era dada um cor
2.4.1.6.5. práticas não adotadas ganha outra cor
2.4.1.6.6. visibilidade da maturidade
2.5. M3A05
2.5.1. O combate às filas individuais
2.5.1.1. Sair do modelo de fluxo individual
2.5.1.1.1. O maior esforço é sair desse modelo
2.5.1.1.2. Variabilidade do tamanho dos itens é muito alta
2.5.1.1.3. Falta de colaboração
2.5.1.1.4. alta especialização
2.5.1.2. 10 passos para sair deste modelo
2.5.1.2.1. Definir o que está na fila e classificar
2.5.1.2.2. Desenhar uma visualização sistemica
2.5.1.2.3. Transferir os itens das filas individuais para o novo quadro
2.5.1.2.4. Limitar o WIP com base no que você tem agora
2.5.1.2.5. Projetos/Itens grandes devem ser reavaliados
2.5.1.2.6. Instalar coordenação tática
2.5.1.2.7. Marcar leadtime toda vez em que os tickets se moverem dentro do quadro
2.5.1.2.8. Comece a explicar o novo sistema aos seus clientes e outros envolvidos
2.5.1.2.9. Comece a exercitar a arte de fazer a coisa certa
2.5.1.2.10. Continuar observando e aprimorando o processo dia após dia
2.6. M3A06
2.6.1. Parte 01
2.6.2. Parte 02
2.6.3. Parte 03
2.7. M3A07
2.7.1. Parte 01
2.7.2. Parte 02
2.7.3. Parte 03
2.8. M3A08
2.8.1. Parte 01
2.8.2. Parte 02
2.8.3. Parte 03
2.9. M3A09
2.9.1. XX
3. Módulo 4 - A Batalha Zen
3.1. M4A01 Vendendo o processo de mudança
3.1.1. Convencer as pessoas
3.1.1.1. A sair da zona de conforto
3.1.1.2. A aprender coisas novas
3.1.2. Pessoas não gostam de ser manipuladas
3.1.2.1. Não deixar passar a ideia de convencimento
3.1.3. Modelo sugerido by Alisson
3.1.3.1. Entender o problema
3.1.3.1.1. Saber explicar o problema melhor que elas mesma sabem
3.1.3.1.2. Detalhar o problema e porque elas tem esse problema
3.1.3.1.3. Conversar com o cliente e partes interessadas
3.1.3.1.4. Você é a pessoa mais indicada porque está vendo o problema de fora
3.1.3.2. Fazer o encaixe da solução do problema
3.1.3.2.1. Cliente achava que não estava nada pronto
3.1.3.2.2. Reduzir o ciclo de feedback
3.1.3.2.3. Receber releases estáveis frequentemente
3.1.3.2.4. Equipe dizia que tinha muita coisa pra fazer
3.1.3.2.5. O tamanho dos entregáveis estão grandes
3.1.3.2.6. Aplicar as estratégias
3.1.3.3. Remover as objeções
3.1.3.3.1. "Aqui não funciona"
3.1.3.3.2. "Isso é para Startup"
3.1.3.3.3. "Muito dificil gerar release"
3.1.3.3.4. Estudar os problemas
3.1.3.4. Estruturar a apresentação
3.1.3.4.1. Pode ser no batepapo com as pessoas
3.1.3.4.2. Ou reunião formal, com powerpoint
3.2. M4A02 Como começar
3.2.1. Existem várias formas
3.2.1.1. Quando o projeto é novo, uma abordadem
3.2.1.2. Ou quando as pessoas já estão no caos, é outra abordagem
3.2.1.2.1. Quanto mais mudanças bruscas mais complicado de administrar
3.2.1.2.2. Introduzir uma mudança por vez
3.2.1.2.3. Introduzir a Daily Meeting
3.3. M4A03 A coordenação diária
3.3.1. Minimizar as distrações
3.3.1.1. Fazer perguntas individuais pode gerar distração
3.3.1.2. Foque no problema
3.3.2. Visualizar o quadro
3.3.2.1. Começando da direita para esquerda
3.3.2.2. Falar rapidamente sobre o item
3.3.2.3. Solcitar o Status update
3.3.2.3.1. Problemas serão tratados depois da Daily
3.3.2.3.2. Fazer a movimentação dos itens
3.3.3. Problemas de comportamento
3.3.3.1. Pessoas com distração
3.3.3.2. Não cumprem horário
3.3.3.3. Saem durante a reunião
3.3.4. Fazer reunião de retrospectiva
3.3.4.1. Workshop
3.3.4.1.1. acertar o alinhamento social
3.3.4.1.2. O que queremos das pessoas
3.3.4.1.3. Comportamentos aceitáveis
3.4. M4A04 Os primeiros dados
3.4.1. Semana #1
3.4.1.1. Zoe escolheu Business Value
3.4.1.1.1. Quebrou o BV em historias
3.4.1.1.2. Reunião de planejamento
3.4.1.2. O framework
3.4.1.2.1. Dá suporte ao sistema
3.4.1.2.2. Mudado o nome da coluna para "Outros"
3.4.1.3. 3 Desenvolvedores codificando
3.4.1.3.1. As coisas iam terminando e os Devs já puxavam outras
3.4.1.3.2. Itens bloqueados e um precisa ajudar o outro
3.4.1.3.3. Necessidade de fazer PAR para não haver acúmulo
3.4.2. Semana #2
3.4.2.1. Senior e Design não estão trabalhando nos entregáveis
3.4.2.1.1. Não há Value Stream
3.4.2.1.2. Agregar esta atividade associada a uma feature
3.4.2.1.3. Papel do Design não é deixar a tela bonita. Usabilidade é o papel correto
3.4.2.2. Coleta de dados
3.4.2.2.1. Aba de alocação
3.4.2.2.2. Diário das atividades
3.4.2.2.3. CPF
3.4.2.3. Devs continuam a trabalhar em novas atividades
3.4.2.3.1. Nenhum item é entregue
3.4.2.3.2. Coisas ficam paradas
3.4.2.4. Sinalização de interrupção é importante
3.4.2.4.1. Sub-dividir os impedimentos por tipo
3.4.2.5. Reunião Diária
3.4.2.5.1. Não acontece da forma esperada
3.4.2.6. Workshop de retrospectiva
3.4.2.6.1. Fala-se sobre o Daily Meeting
3.4.2.7. Fim da semana #2
3.4.2.7.1. Nada entregue
3.4.2.7.2. Muitas coisas acumuladas em TESTE
3.5. M4A05 A luta contra o gargalo
3.5.1. Semana #4
3.5.1.1. Zoe com preocupação com o gargalo
3.5.1.2. Equipe ainda no mindset da eficiência
3.5.1.3. A foto do quadro revela o caos
3.5.1.3.1. Muitas coisas inacabadas
3.5.1.4. A equipe foi rearranjada a fim de remover os impedimentos
3.5.1.4.1. Formação de pares é importante
3.5.1.5. Inicia-se a limitação das etapas
3.5.1.5.1. Cadenciamento do fluxo
3.5.1.5.2. Evita-se o gargalo
3.5.1.5.3. Os Devs precisam se movimentar antes de puxar coisas novas
3.5.2. Semana #5
3.5.2.1. Não existe mais gargalos
3.5.2.2. Marca com o cliente a Review
3.5.2.2.1. As entregas se atrasam em uma semana
3.5.2.3. Novo comportamento da equipe
3.5.2.3.1. Devs olham primeiro o quadro antes de puxar qualquer coisa
3.5.2.3.2. Fazer o trabalho fluir
3.5.2.4. Os limites do quadro é reajustado para um valor menor
3.5.2.5. Features pequenas não são importantes
3.5.2.5.1. Melhor uma feature entregue no tempo certo do que tentar entregar tudo e não entregar nada
3.5.2.5.2. Entregar escopo reduzido de forma consistente do que cumprir a promessa
3.5.2.6. O paradigma da eficâcia enfim é posto em prática
3.6. M4A06 Hora de apresentar para o cliente
3.6.1. Considerações
3.6.1.1. Review constante
3.6.1.1.1. 1 a 2 semanas
3.6.1.1.2. Estreitar conversação com cliente
3.6.1.2. Estoque alto
3.6.1.2.1. Dificil de validar
3.6.1.2.2. Surge retrabalho
3.6.1.3. Buffer de Homolog
3.6.1.4. Receber software funcionando
3.6.1.4.1. Propósito não é cumprir o cronograma
3.6.1.4.2. Entregar valor é o que interessa
3.6.1.4.3. Demonstre engajamento
3.6.1.5. Remoção da raia do Design/Framework
3.6.1.6. Focar um Business Value por vêz
3.6.1.6.1. Itens pequenos
3.6.1.6.2. Entrega rápida
3.6.1.7. Planejamento
3.6.1.7.1. Preparação para homolog
3.6.1.7.2. Implantação progressiva
3.6.1.7.3. Workshop restrospectiva
3.6.1.7.4. Celebrar a entrega
3.6.1.8. Métricas
3.6.1.8.1. Análise dos indicadores
3.7. Revisão
3.7.1. A venda
3.7.1.1. Alinhar o que é necessário em termos de solução da solução
3.7.1.1.1. Sistema complexo
3.7.1.2. Proposta
3.7.1.2.1. Mobilizar as pessoas para seguir um caminho
3.7.1.2.2. Entender qual é a situação
3.7.1.2.3. Criar empatia
3.7.1.2.4. Ouvir as perspectivas de todas as pessoas
3.7.1.2.5. Descrever o problema delas melhor que elas mesmas
3.7.1.2.6. Estratégia
3.7.2. Como começar
3.7.2.1. Livro
3.7.2.1.1. Toyota Kata
3.7.2.2. Coordenação Tática
3.7.2.3. Uma mudança por vez
3.7.2.4. Assistir o estudo de caso Dojo - diagnostico manutenção
3.7.2.5. Observar sem introduzir mudanças
3.7.2.6. Visualizar o trabalho corrente
3.7.2.6.1. Estabilizar o mapa x terreno
3.7.2.6.2. Impedimentos são apontados
3.7.3. Coordenação diária
3.7.3.1. Persistir para alcançar a colaboração
3.7.3.2. Cuidado com Distração
3.7.3.2.1. Cada um faz o seu
3.7.3.2.2. Pessoas atrasadas
3.7.3.2.3. Não dão valor
3.7.3.3. Boas práticas
3.7.3.3.1. Começar da direita pra esquerda
3.7.3.3.2. Olhar os bloqueios
3.7.3.3.3. As pessoas envolvidas com história devem falar sobre o trabalho
3.7.3.3.4. Com o tempo, as pessoas começam a analisar os movimentos
3.7.3.3.5. Workshop restrospectiva
3.7.4. Os primeiros dados
3.7.4.1. xx