1. Orientações e Apresentações
1.1. Marcar no Zoom para todos os participantes e palestrantes
1.2. De onde vocês são?
1.3. Que empresa vocês trabalham?
1.4. Que função vocês exercem?
2. Sprint #1: Análise do problema
2.1. O Começo - S1A01
2.1.1. Ao longo dos anos
2.1.1.1. 1968
2.1.1.1.1. Conferência da OTAN, 1968
2.1.1.1.2. IBM CICS (Customer Information Control System)
2.1.1.1.3. Douglas Engelbart - Apresentou o mouse
2.1.1.2. 1984
2.1.1.2.1. Livro Software Engineering Economics
2.1.1.3. 1994
2.1.1.3.1. The CHAOS Report
2.1.2. Sistema
2.1.2.1. Caos Sistêmico
2.1.2.1.1. Sintomas
2.1.2.1.2. A Era da Engenharia de Software
2.1.2.2. Ignorância Sistêmica
2.1.2.2.1. Pessoas não conseguem olhar para os efeitos ou para as ações que executam, ignorando tudo que está acontecendo
2.1.2.2.2. Decisões começam a conflitar uma com as outras
2.1.2.2.3. Ocorrem no âmbito da iteração e não no Sistema como um todo
2.1.2.2.4. "Ninguém quer produzir os resultados sistêmicos que nós consistentemente produzimos. E essa é a definição arquetípica do que eu chamo de Inteligência Sistêmica ou, vamos dizer, Ignorância Sistêmica" Peter Senge
2.1.3. Caso WTPL
2.1.3.1. Parte 1: O começo
2.1.3.1.1. Primeira versão nasce depois de 2 anos de trabalho
2.1.3.1.2. Atraso de mais de 6 meses
2.1.3.1.3. Custou 40% a mais do que foi estimado
2.1.3.1.4. Mesma época da Crise do Software
2.1.3.2. Parte 2: O outro capítulo
2.1.3.2.1. Perda de contrato para empresas consolidadas no mercado
2.1.3.2.2. Novos desafios
2.1.3.2.3. Criação de processos
2.1.3.3. Parte 3: O Caos Ordenado - Só um tipo diferente de caos
2.1.3.3.1. Desenvolvedores
2.1.3.3.2. Analistas
2.1.3.3.3. Testadores
2.1.3.3.4. Os problemas
2.1.3.4. Parte 4 - O lançamento
2.1.3.4.1. Caos no lançamento
2.1.3.4.2. Apresentação de vários inconsistência
2.1.3.4.3. Uso de especificação assinada para justificar não ter feito o que estava sendo pedido
2.1.3.4.4. De quem é a culpa de tantos erros?
2.1.3.4.5. Pessoas deixando a empresa por insatisfação
2.1.3.5. Parte 5 - Reviravolta
2.1.3.5.1. Enxugaram o produto
2.1.3.5.2. Cobrança por licença de acesso
2.1.3.5.3. Produto difícil de manter e evoluir de forma sustentável
2.1.3.6. Parte 6 - A oportunidade bate a porta
2.1.3.6.1. Reconstrução do Sistema
2.1.3.6.2. Tentativa de implantação do Scrum
2.1.3.6.3. Contratação da Zoe
2.1.4. Produto
2.1.4.1. Desenvolver o produto de ponta a ponta resolvendo os problemas do cliente
2.2. O Problema - S1A02
2.2.1. Gestão: O maior desafio
2.2.1.1. Melhorar socialmente e economicamente
2.2.1.2. Barry Boehm
2.2.1.2.1. Livro Software Engineering Economics, 1984
2.2.1.3. Desafio complexo
2.2.1.3.1. Organização do trabalho
2.2.1.3.2. Alinhamento das pessoas
2.2.1.3.3. Ambiente estruturado para poder produzir
2.2.1.3.4. Coordenar pessoas para produzir resultados satisfatórios
2.2.1.3.5. Definição de regras e políticas
2.2.1.4. Gerald Weinberg
2.2.1.4.1. Quality Software Management
2.2.2. Organização do fluxo de trabalho
2.2.2.1. Mais eficiente possível
2.2.2.2. Mais eficaz possível
2.2.3. Software na Década de 90
2.2.3.1. Foco em tentar se criar um processo definido
2.2.3.1.1. Encadeado
2.2.3.1.2. Executar um processo e fazer a mágica acontecer
2.2.3.2. Mercado de certificações
2.2.3.2.1. Consultorias de certificações começaram a surgir
2.2.3.3. História
2.2.3.3.1. Gastos absurdos para escrever um processo de desenvolvimento de software
2.2.3.4. Ampliação do uso de UML
2.2.3.5. Empresas pequenas começaram a ficar sem nada
2.2.3.5.1. Não podiam explorar o que as grandes estavam utilizando
2.2.3.5.2. E não possuíam uma solução alternativa
2.2.3.5.3. Sem âncora metodológica
2.2.3.5.4. Passaram muito tempo tentando e não conseguiam
2.2.4. Essência do nosso trabalho
2.2.4.1. Incertezas
2.2.4.2. Instabilidade
2.2.4.3. Foco nas pessoas
2.2.4.4. Ambiente bem diverso do ambiente da indústria
2.2.5. Virada dos anos 90
2.2.5.1. Surgimento do Movimento ágil
2.2.5.1.1. Forma de organizar o trabalho
2.2.5.1.2. Problemas não resolvidos
2.2.6. Foco no problema
2.2.6.1. Virar o foco e parar de tentar achar que um método é a solução para todos os problemas
2.2.6.2. Transformar os métodos em ferramentas
2.2.6.3. Focar em como resolver o problema que possuímos
2.2.6.4. Buscar entender a causa raiz do problema
2.2.6.4.1. Usar caixa de ferramentas para resolver
2.2.7. Conclusão
2.2.7.1. Problema
2.2.7.2. Como chegamos até esse ponto
2.3. O ciclo de vida das demandas - S1A03
2.3.1. Visão Sistêmica
2.3.1.1. Nosso problema é complexo. Amanhã será ainda mais complexo
2.3.1.2. A medida que o tempo passa a complexidade aumenta
2.3.1.2.1. Motivo: Trajetória de crescimento
2.3.1.3. Sistemas
2.3.1.3.1. Malha de interações
2.3.1.3.2. Aumento de complexidade do Sistema de Gestão conforme o tempo evolui
2.3.1.3.3. Número de interações entre os vários elementos
2.3.1.3.4. Visão do todo
2.4. Teoria das Filas - S1A04
2.4.1. A maior alavanca está no que NÃO estamos fazendo, não NO QUE estamos fazendo
2.4.2. Demanda de Trabalho
2.4.2.1. Expectativas
2.4.2.1.1. Cliente > Investidor ou Gerente = Projetos
2.4.2.1.2. Investidor > Gerente = Melhorias no Produto
2.4.2.1.3. Usuários > Gerente = Melhorias das features
2.4.2.1.4. Usuários > Desenvolvedores = Resolução de bugs
2.4.2.1.5. Usuários > Clientes = Melhorias
2.4.2.1.6. Gerentes > Desenvolvedores = Features e Melhorias para reduzir suporte
2.4.2.2. Grande parte do nosso trabalho está em filas, uma pequena parte está em execução
2.4.2.3. Ciclo de vida
2.4.2.3.1. Nasce
2.4.2.3.2. Aceitação
2.4.2.3.3. Wait Time
2.4.2.3.4. Touch Time
2.4.2.4. Lead Time
2.4.2.4.1. Compromisso até a Entrega
2.4.2.4.2. O tempo mais relevante para o cliente
2.4.3. Little's Law
2.4.3.1. Tempo médio que as coisas levam dentro de um Sistema é proporcional ( Tamanho das filas / Taxa de entrega )
2.4.3.2. Diminuir o tamanho das filas ou aumentar a taxa de entrega
2.4.4. Variabilidade e utilização: A chave para a estabilização
2.4.4.1. Sistema estável
2.4.4.1.1. Variabilidade
2.4.4.1.2. Utilização
2.5. Gestão como Design - S1A05
2.5.1. A natureza do trabalho
2.5.1.1. Diferença entre:
2.5.1.1.1. Entender a diferença evita que cair em armadilhas de aplicar práticas de gestão que são ineficientes para a nossa realidade
2.5.1.1.2. Era industrial
2.5.1.1.3. Era da informação
2.5.2. Sistemas produtivos
2.5.2.1. Era Industrial
2.5.2.1.1. Replicação
2.5.2.1.2. Variabilidade Nula
2.5.2.1.3. Prescritivo
2.5.2.2. Era da informação
2.5.2.2.1. Criação
2.5.2.2.2. Variabilidade natural e necessária
2.5.2.2.3. Empírico
2.5.2.2.4. Ciclos de Feedback
2.5.2.2.5. Usar o resultado para melhorar o processo
2.5.2.3. Vídeo do Martin Fowler
2.5.2.3.1. Analogia do Bolo de Frutas
2.5.2.3.2. Analogia do Chuveiro
2.5.3. Conclusão
2.5.3.1. Diferença do processo criativo para o processo industrial
2.5.3.2. Na era da informação tentar fazer o mesmo trabalho é desperdício
2.5.3.3. Próximos temas
2.5.3.3.1. Análises Sistêmicas
2.5.3.3.2. Ciclos de Feedback
2.5.3.4. Planejamento prescritivo a longo prazo é completamente ineficiente no desenvolvimento de software
2.6. O Impacto da Tolerência ao Erro - S1A06
2.6.1. Caminhos do Projeto
2.6.1.1. Deterioração do projeto
2.6.1.2. Otimização progressiva
2.6.2. Desafio
2.6.2.1. Facilitar a mudança
2.6.2.2. Procurar sempre melhorar
2.6.3. Russel Ackoff
2.6.3.1. PhD System Thinking
2.6.3.2. Tipos de erros
2.6.3.2.1. Algo que você não deveria fazer
2.6.3.2.2. Quando você não faz algo que você deveria ter feito
2.6.3.3. "Você aprende apenas com os erros"
2.6.4. Cultura
2.6.4.1. Aprendemos que errar é uma coisa ruim
2.6.4.1.1. Notas baseadas em erros
2.6.4.1.2. Criar um ambiente desfavorável ao seu ambiente de trabalho, porque reforça essa cultura
2.6.4.2. Quando acertamos, não há aprendizado real, apenas confirmando algo que sabíamos
2.6.5. Melhorias
2.6.5.1. Oportunidade de melhoria
2.6.5.1.1. Caminhos
2.6.5.2. Incentivo a melhoria
2.6.5.2.1. Condição que depende da cultura
2.7. Sprint Review - S1A07
2.7.1. Sprint 0
2.7.1.1. Assistir o vídeo "Como vai ser?" - S0A01
2.7.1.2. Fazer o setup inicial
2.7.2. Sprint 1
2.7.2.1. Assistir a aula de abertura
2.7.2.2. 6 aulas adicionais para assistir
2.7.2.3. O que irá ter?
2.7.2.3.1. S1A01 - Preparando-se para sprint
2.7.2.4. Seção de Q&A
2.7.2.4.1. Ouvir os áudios em tempo livro
2.7.2.5. S1A02
2.7.2.5.1. Foco no problema
2.7.2.6. S1A03
2.7.2.6.1. Ciclo de vida das demandas
2.7.2.7. S1A04
2.7.2.7.1. Teoria das filas
2.7.2.8. S1A05
2.7.2.8.1. Gestão como design
2.7.2.9. S1A06
2.7.2.9.1. Impacto de tolerância ao erro
2.7.3. O que mais rolou?
2.7.3.1. Discussões no fórum
2.7.3.1.1. Perguntas específicas ao Alisson marcar ele
2.7.3.1.2. Não fazer perguntas genéricas
2.7.3.1.3. Mapa Mental
2.7.3.2. Prefácio e Capítulo 1
2.7.3.2.1. Narrativa paralela ao conteúdo do curso
2.7.3.2.2. Capítulo 2 - Entrará um novo personage, a Sophia
2.7.3.3. Problema da Zoe
2.7.3.3.1. Fase 1 - Teve bastante discussão no grupo
2.7.3.4. Ranking
2.7.3.4.1. Acompanhar
2.7.3.5. Trófeu
2.7.3.5.1. As que chamaram mais atenção e que endereçaram a questão, receberam o prêmio de comentário valioso
2.7.3.5.2. Capriche nas respostas
2.7.3.6. Twitter bombando
2.7.3.6.1. Pessoal postando todos os dias
2.7.3.6.2. Acompanhem
2.7.3.7. Slack
2.7.3.7.1. Boas discussões no Slack
2.7.3.8. Inscrições para o MasterClass
2.7.3.8.1. Encerrada as incrições
2.7.3.9. Continua em aberto para as pessoas que ainda não conseguiram fazer
3. A Batalha Zen: Respostas
3.1. Fase 1: Porque iniciativas ágeis falham?
3.1.1. As 10 razões mais comuns
3.1.1.1. 1. A empresa não tem uma cultura que permita aplicar a agilidade 2. As pessoas não tem o mindset adequado 3. As práticas não estão sendo bem aplicadas 4. As práticas técnicas, que envolvem código, testes automatizados e design estão sendo desconsideradas 5. Falta liderança 6. Não há condições mínimas 7. O time não é bom 8. A empresa ou o time confunde Ágil com eXtreme Go Horse 9. O time ou a empresa não tem interesse em melhorar 10. Não há o apoio de um especialista
3.1.2. No caso da empresa da Zoe
3.1.2.1. Informações adicionais
3.1.2.1.1. Conflito do entendimento do que deveria ser feito
3.1.2.1.2. Problemas na aplicação do Scrum por questões internas da empresa
3.1.2.2. O Problema
3.1.2.2.1. Preocupados com os traumas do passado
3.1.2.2.2. Mudanças no mundo da gestão e desenvolvimento de produtos
3.1.2.2.3. Contrato fechado
3.1.2.3. Onde está o erro?
3.1.2.3.1. Para que a gente possa simplificar o mundo, nós simplificamos o objetivo
3.1.3. The invisible Gorila
3.1.3.1. Apesar de seus olhos verem a imagem quem irá processar será seu cérebro
3.1.3.2. Semelhante com a empresa
3.1.3.2.1. Enquanto você persegue uma meta, elas estão pulando na sua frente e você não percebe
3.1.3.2.2. Tentando fazer o Scrum funcionar como se fosse a sua meta
3.1.4. Gurus
3.1.4.1. Donella Meadows
3.1.4.1.1. "Nada tem maior poder de alavancagem do que se mexer no propósito de um sistema"
3.1.4.2. Kent Beck
3.1.4.2.1. Spotify didn't implement the Spotify model by copying Spotify. Why do folks at another companies think they can implement the Spotify model copying Spotify?
3.1.5. Spotify
3.1.5.1. Surgiu bottom-up
3.1.5.1.1. Agilistas, Especialistas Kanban e Lean
3.1.6. Em resumo...
3.1.6.1. Iniciativas ágeis podem falhar pelas mais diversas razões associadas com a ideia de a empresa ou a equipe não estar "fazendo do jeito certo". Mas o erro fatal começa a acontecer quando você transforma a sua iniciativa Ágil em um fim, no objetivo do seu esforço; esquecendo a razão pela qual você precisa do Ágil em primeiro lugar. Nesse caso, o erro é fatal, porque você não está "fazendo a coisa certa".
3.1.7. Reflexão
3.1.7.1. Você usa Ágil para resolver problemas da sua empresa, ou você usa sua empresa para adotar ideias Ágeis?
3.1.8. Disclaimer final
3.1.8.1. Existem cenários em que o método será o alvo, não invalide isso
4. Sprint #0: O Início
4.1. S0A1: Como vai ser?
4.1.1. Sprints dos programas
4.1.2. Setup inicial
4.1.3. O Mapa da Jornada - Perspectiva diferente das Sprints
4.1.4. Conheça o seu instrutor - Vídeo no formato documentário sobre o Alisson Vale
4.1.5. O conteúdo preparatório
4.1.5.1. Linha de conteúdo do programa
4.1.6. Como iremos interagir
4.1.6.1. Fórum
4.1.6.1.1. Tópicos específicos
4.1.6.1.2. Lugar adequado para facilitação de debates
4.1.6.2. WhatsApp
4.1.6.2.1. Não usar o grupo para obter suporte individual
4.1.6.3. e-mail
4.1.6.3.1. Para tirar dúvidas e suporte diretamente com o Alisson
4.1.6.4. Slack
4.1.6.4.1. softwarezen.slack.com
4.1.6.5. Twitter
4.1.6.5.1. #softwarezen
4.1.7. Como assistir?
4.1.8. Sprints
4.1.8.1. 7 Sprints
4.1.8.2. Para cada uma delas haverá aula de abertura
4.1.8.3. Masterclass
4.1.8.3.1. Sábado, 07/12 de 09 às 18hs
4.1.8.3.2. Em São Paulo
4.1.8.3.3. 50 vagas
4.1.8.3.4. Quinta-feira 17/10 à partir das 08:00 abrirá as inscrições
4.1.8.3.5. Multa de R$ 300 para quem faltar e se não pagar perderá o direito de participar gratuitamente das futuras edições do Software Zen
4.1.8.4. Semana de recuperação entre a Sprint #3 e #4
4.1.8.5. Anatomia de uma Sprint
4.1.8.5.1. 19:30 - Review
4.1.8.5.2. 20:00 - Aula oficial
4.1.8.5.3. 22:00 - Q&A (Perguntas e respostas)
4.1.8.5.4. 07:00 (Dia seguinte) - Envio da gravação
4.1.8.5.5. Durante a semana
4.1.8.5.6. Níveis
4.1.9. Níveis de Experiência
4.1.9.1. Essential
4.1.9.1.1. Assistir às aulas ao vivo
4.1.9.2. Plena
4.1.9.2.1. Assistir às aulas ao vivo e fazer os exercícios
4.1.9.3. Expert
4.1.9.3.1. Plena + Fazer mapas mentais ou resumos e interagira no fórum e nas redes sociais
4.1.10. Anotações
4.1.10.1. Resumos
4.1.10.1.1. Poe tirar foto e compartilhar as anotações
4.1.10.2. Mapas Mentais
4.1.10.2.1. http://mindmeister.com
4.1.10.2.2. http://xmind.net
4.1.11. Batalha Zen
4.1.11.1. Ranking
4.1.11.1.1. Bot - Sistema de apuração
4.1.11.2. Quadro de pontuação
4.1.11.2.1. Como marcar pontos
4.1.11.3. Níveis e prêmios
4.1.11.3.1. Zen Essential
4.1.11.3.2. Zen Pleno
4.1.11.3.3. Zen Expert
4.1.11.3.4. Zen Master
4.2. Ementa
4.2.1. Módulos
4.2.1.1. Mindset
4.2.1.1.1. Design do processo de trabalho na era da informação
4.2.1.1.2. Aprendizagem do porque das coisas
4.2.1.1.3. Atualmente o mindset predominante nas empresas é o da eficiência
4.2.1.1.4. Aprender a se relacionar com o cliente de igual para igual
4.2.1.1.5. Construção uma solução aderente ao problema em conjunto com o cliente
4.2.1.2. A Estratégia
4.2.1.2.1. Considere que o mundo está girando
4.2.1.2.2. 5 estratégias
4.2.1.3. As armas
4.2.1.3.1. Mapas para visualizar o trabalho
4.2.1.3.2. Métricas para medir o que está acontecendo
4.2.1.3.3. Técnicas para otimizar o fluxo e trabalho
4.2.1.3.4. Técnicas para reduzir os desperdícios
4.2.1.3.5. Técnicas para conduzir os projetos
4.2.1.4. A batalha
4.2.1.4.1. 6 fases de jogo
4.2.1.4.2. Exercicío do aprendizado em um jogo
4.2.1.5. A transformação
4.2.1.5.1. Utilizar novas habilidades para transformação
4.2.1.5.2. Construir a visão de futuro
4.3. S0A2: Conheça o seu instrutor
4.3.1. Alisson Vale
4.3.1.1. Desenvolvedor de Software a mais de 20 anos
4.3.1.2. Gosto profundo por desenvolver software
4.3.1.3. Caiu a ficha
4.3.1.3.1. Após a leitura do livro Adapative Software Development - Jim Highsmith
4.3.1.4. Desafios encontrados após dominar o ágil para criação de produtos
4.3.1.4.1. Manutenção de Sistemas
4.3.1.4.2. Suporte técnico
4.3.1.4.3. Projetos de implantação
4.3.1.4.4. Marketing
4.3.1.4.5. Vendas
4.3.1.5. Descoberta do Paradigma do Fluxo / Lean
4.3.1.5.1. Mary Poppendieck
4.3.1.6. Kanban
4.3.1.6.1. Até o início dos anos 80 as empresas não se preocupavam com o estoque
4.3.1.6.2. Taichi Onno
4.3.1.6.3. David Anderson
4.3.1.7. Nova jornada
4.3.1.7.1. Lead Time
4.3.1.7.2. Cultura da melhoria contínua
4.3.1.8. Trabalhou com times em:
4.3.1.8.1. Microsoft
4.3.1.8.2. Petrobrás
4.3.1.8.3. Globo
4.3.1.8.4. Embraer
4.3.1.9. Associado ao Lean Kanban University
4.3.2. Fevereiro de 2001: Manifesto Ágil
4.3.2.1. 17 Desenvolvedores
4.3.2.2. Resort Snowbird - Utah
4.3.2.3. Como era e como é?
4.3.2.3.1. Antes: Tentava adivinhar as datas que as atividades seriam concluídas e a sequência pré-definida que elas seriam executadas
4.3.2.3.2. Depois: Modelo que tenta antecipar o valor para o mais cedo possível
4.4. S0A3: A verdadeira gestão
4.4.1. Barry Boehm - Software Engineering Economics
4.4.1.1. “Uma gestão ruim pode aumentar os custos do desenvolvimento de software mais do que qualquer outro fator”
4.4.1.2. Estudos mostram que 64% dos nos problemas estão relacionados a gestão
4.4.2. David Anderson
4.4.2.1. Lessons in Agile Management
4.4.2.1.1. "A lição aqui, é que o maior fator de alavancagem para melhorar a efetividade de um projeto de software está em educar gerentes para gerenciarem melhor"
4.4.3. Alisson Vale
4.4.3.1. Realizou o primeiro estudo de caso da America Latina sobre o Kanban
4.4.3.1.1. Método Kanban ainda estava em formação
4.4.3.2. Escreveu um capítulo do livro “Métodos ágeis de desenvolvimento de Software”, sendo co-autor
4.4.3.3. Se especializou no modelo Lean utilizado pela Toyota
4.4.4. Um novo mindset
4.4.4.1. The Lean Midset: Ask the right questions
4.4.4.1.1. Mary Poppendieck & Tom Poppendieck
4.4.4.1.2. Se o nosso modelo mental não se encaixa com o que fazemos todo dia, sentimos dor e frustração, se por outro lado se as duas coisas se encaixam temos energia e motivação.
4.4.4.2. Economia de fluxo
4.4.4.2.1. Eficácia e tempo são mais importantes que eficiência e volume
4.4.4.3. Economia criativa e Problemas complexos surgiram e os métodos de gestão não acompanharam
4.4.5. Visão sistêmica
4.4.5.1. Sua empresa, seu projeto, seu departamento são sistemas
4.4.5.2. Um Sistema possui uma função ou propósito, ele tem elementos e interações entre os elementos e essas interações faz com que a função ou propósito seja atingido
4.4.5.3. Para muda o comportamento de um sistema é preciso entender o porque, a razão, a causa raiz
4.4.5.3.1. Exemplo:
4.4.5.4. Primeiro passo da verdadeira gestão
4.4.5.4.1. Parar de culpar as pessoas pelos problemas e olhar para como os sistemas estão estruturados
4.4.5.5. A estrutura de um sistema de trabalho
4.4.5.5.1. Elementos
4.4.5.5.2. Demandas de trabalho
4.4.5.5.3. Validando demandas de trabalho
4.4.5.5.4. Entre o Input e o Output está a Capacidade para cumprir o seu propósito
4.4.5.5.5. Forças que agem para sobrecarregar a capacidade do sistema
4.4.5.5.6. As pessoas não enxergam o sistema como um todo e tomam decisões apenas se comunicando com seus nós adjacentes
4.4.5.5.7. Como reverter essa situação
4.5. S0A4: As estratégias
4.5.1. Parte 1: A gestão do trabalho em progresso
4.5.1.1. Aplicando a visão sistêmica
4.5.1.1.1. Componentes do Sistema de Trabalho
4.5.1.2. Não adianta andar mais rápido se você está na estrada errada, estar na estrada errada pode ser a razão pela qual você conviva com os problemas ao invés de resolve-los - Alisson Vale
4.5.2. Parte 2: Gerindo passado e futuro
4.5.2.1. Revisão da aula S0A4
4.5.2.1.1. Relembrado o que é Input, WIP, Output
4.5.2.1.2. Relembrado as estratégias
4.5.2.1.3. Explicado que iremos passar a fundo em cada termo
4.5.2.2. Gatekeeper
4.5.2.2.1. Selecionar entre todas as opções disponíveis, aquela que irá levar o sistema a coisa certa na hora certa ao cliente
4.5.2.2.2. Não é necessário processar todos os itens. Lembre-se
4.5.2.2.3. A sua meta não é entregar tudo ou vencer o cronograma.
4.5.2.2.4. Estratégias
4.5.2.3. A arte de fazer a coisa certa
4.5.2.3.1. O que flui bem
4.5.2.3.2. Minimizar o trabalho em entregáveis
4.5.2.3.3. Peter Druker
4.5.2.3.4. Fazer nos níveis
4.5.2.4. Output
4.5.2.4.1. Estratégias
4.5.2.5. Tangibilizando os resultados
4.5.2.5.1. Aprendizado
4.5.2.5.2. Maior entendimento do produto / problema sendo resolvido
4.5.2.5.3. Conhecimento sobre a capacidade de entrega
4.5.2.6. Resultados da implementação das estratégias
4.5.2.6.1. Sistema equilibrado
4.5.2.6.2. Pessoas engajadas
4.5.2.6.3. Evita retardos
4.5.2.7. Próximos vídeos
4.5.2.7.1. Métodos da moda ou pesados processos de certificação que não foram feitos para a realidade que você vive
4.5.2.7.2. Entender o que está por trás dos métodos
4.6. S0A6: A Transformação
4.6.1. O caminho da transformação
4.6.1.1. Pirâmide
4.6.1.1.1. Sabedoria
4.6.1.1.2. Entendimento
4.6.1.1.3. Conhecimento
4.6.1.1.4. Informação
4.6.2. Conheça o seu guia
4.6.2.1. Alisson relatou a sua trajetória, apresentado no S0A02 - Conheça o seu instrutor
4.6.2.2. Incluiu os relatos sobre as palestras no Brasil e Exterior
4.6.2.3. David Anderson visitou a sua empresa em Vitória - ES
4.6.2.3.1. David Anderson relata sobre a Phidelis e o tempo excepcional em receber e responder uma demanda
4.6.2.4. Trabalhou na Petrobras, Embraer, Microsoft e InfoGlobo
4.6.3. Cases de Kanban no Mundo
4.6.3.1. Microsoft reduziu em 90% o tempo de entrega e aumentou em 200% a produtividade
4.6.3.2. HP reduziu em 80% o tempo de entrega e aumentou em 400% a produtividade
4.6.4. Lições aprendidas
4.6.4.1. Toda mudança positiva ocorre fora da zona de conforto
4.6.4.2. Diga sim para as oportunidades
4.6.5. Módulos
4.6.5.1. Mindset
4.6.5.2. Estratégias
4.6.5.3. As armas
4.6.5.4. A batalha
4.6.5.5. A transformação
4.6.5.6. Material adicional
4.6.6. Depoimentos dos alunos
4.6.6.1. Alexandre Nodari
4.6.6.2. Allan Lima
4.6.6.3. André Bertoletti
4.6.6.4. Leandro Garcia
4.6.6.5. Michel Amaral
4.6.6.6. Nitai Fernandes
4.6.6.7. Paulo Mariano
4.6.6.8. Paulo Roberto Araújo
4.6.6.9. Tiago Sciencia
4.6.6.10. Tony Lampada
4.6.6.11. Wagner Pancini
5. Sprint #2 - O caminho para a solução
5.1. S2A01 - Preparando-se para a Sprint
5.1.1. Sprint anterior
5.1.1.1. Crise do software
5.1.1.2. Caos gerado pela ignorância sistêmica
5.1.1.3. A era da engenhria como resposta
5.1.1.4. As premissas da era da engenharia
5.1.1.5. O problema do controle como objetivo da gestão
5.1.1.6. Pêndulo
5.1.1.6.1. Zero Controle > Controle Total
5.1.1.7. Aula S1A06 - Impacto da tolerância ao erro
5.1.1.7.1. Duas dimensões
5.1.1.7.2. Cultura de tolerância ao erro ou cultura de experimentação
5.1.1.7.3. Um sistema é deteriorado não porque as pessoas fazem o que deveriam fazer do jeito errado, mas porque se omitem da responsabilidade de fazer a coisa certa
5.1.1.7.4. Erro de omissão
5.1.1.8. Iniciativas ágeis podem falhar pelas mais diversas razões associadas com a ideia de a empresa ou a equipe não estar "fazendo do jeito certo". Mas o erro fatal começa a acontecer quando você transforma a sua iniciativa ágil em um fim, no objetivo em primeiro lugar. Nesse caso, o erro é fatal poque você não está "fazendo a coisa certa". - Alisson Vale
5.1.2. Vamos estabelecer o caminho para a solução
5.1.2.1. Pêndulo da Crise
5.1.2.1.1. Zero Controle
5.1.2.1.2. O Encaixe Problema-Solução
5.1.2.1.3. Controle Total
5.1.3. Métodos Ágeis
5.1.3.1. Kent Beck
5.1.3.1.1. XP
5.1.4. Fazer do Jeito Certo VS Fazer a coisa Certa
5.1.4.1. Fazer do Jeito certo
5.1.4.1.1. Implica na Conformidade
5.1.4.1.2. O Correto
5.1.4.1.3. Eficiência
5.1.4.2. Fazer a coisa certa
5.1.4.2.1. Implica em Boas escolhas
5.1.4.2.2. O Bom
5.1.4.2.3. Eficácia
5.1.4.3. Nilton Bonder
5.1.4.3.1. A Alma Imoral
5.1.5. Pirâmide de Ackoff
5.1.5.1. Russel Ackoff
5.1.5.1.1. Re-creating corporation
5.1.5.1.2. Pegar a Ferrari para ir a São Paulo, usando a estrada para ir a BH. Não adianta ter a Ferrari indo para o lugar errado
5.1.5.2. Pirâmide
5.1.5.2.1. Fazer a coisa certa
5.1.5.2.2. Fazer do jeito certo
5.1.5.3. Pirâmide de "Lado"
5.1.5.3.1. Passado
5.1.5.3.2. Futuro
5.1.5.4. Tensão da relação
5.1.5.4.1. Passado
5.1.5.4.2. Futuro
5.1.6. A fórmula da eficácia
5.1.6.1. Dado que entendemos que as hipóteses irão emergir, precisamos validar essas hipóteses o mais rápido possível
5.1.6.2. Aula na Sprint 2 explicando em detalhes
5.1.6.3. "O futuro se manifesta por meio de uma série de apostas que você faz enquanto tenta fazer a coisa certa. Quando você acerta nas suas apostas, incorpora as informações, o conhecimento e o entendimento trazido por esse acerto ao seu "jeito certo de fazer". Quando você erra, você aprende "o que não fazer", evitando assim, a deterioração do seu modo deagir enquanto segue na direção do seu obetivo" - Alisson Vale
5.1.7. Conceptual Tool
5.1.7.1. Problema A
5.1.7.2. Solução B
5.1.7.3. No caminho entre o ponto A e ponto B existem pontos de decisão, opções, escolhas e decisões até chegar ao ponto B
5.1.8. Busca pela eficiência
5.1.8.1. Eliminar opções
5.1.8.2. Forma de agir: Busca pela eficiência
5.1.8.3. Jeito certo é definido a priori
5.1.8.4. Quando a meta é eficiência
5.1.8.4.1. Vídeo: TW Job Intructions
5.1.8.4.2. Lean Enterprise Insitute - Lean.org
5.1.8.4.3. Máquina de dobrar camisetas - Busca pela eficiência remove a necessidade de pessoas no processo.
5.1.9. Exemplo
5.1.9.1. Relatório Executivo
5.1.9.1.1. Empresa A
5.1.9.1.2. Empresa B
5.1.9.2. O que o seu cliente quer não é o seu produto, mas os problemas que ele deixa de ter por causa dele
5.1.10. Na próxima Sprint vamos migrar da eficiência de recurso para eficiência de fluxo
5.2. S2A02 - A Pirâmide de Ackoff
5.2.1. O porque do nome Zen
5.2.1.1. Mais analogia do que referência literal
5.2.1.1.1. Curso segue um caminho de iluminação e isso define o nome ZEN
5.2.1.1.2. Surgiu para nos ajudar a pensar e transformar nossos ambientes de trabalho iniciando dentro de nós, para entendermos a essência do que fazemos e que tipo de abordagem precisamos usar para endereçar esses desafios
5.2.1.2. Desbalanceamento crônico
5.2.1.2.1. Desapegar dos desafios sociais e econômicos
5.2.1.2.2. Estrutura de gestão não está ancorado a nossa realidade de trabalho
5.2.1.2.3. Apego a uma mentalidade de gestão que não foi desenhada para a nossa realidade
5.2.1.2.4. Modelo de gestão que usamos hoje está estruturado em base teórica do século passado baseado em manufatura, de serviços, de administração e trabalho repetitivo
5.2.1.3. Empresas com dificuldades de se organizar e tornar os processos de desenvolvimento de software sustentáveis socialmente, onde as pessoas estarão motivadas e suportadas economicamente
5.2.1.3.1. Viciados no modelo de gestão que foi construído para otimizar trabalho repetitivo
5.2.1.3.2. Software não é repetitivo
5.2.2. Zen e a pirâmide de Ackoff
5.2.2.1. 5 formas que nosso cérebro organizam conteúdo ao longo da vida
5.2.2.1.1. Dados
5.2.2.1.2. Informação
5.2.2.1.3. Conhecimento
5.2.2.1.4. Entendimento
5.2.2.1.5. Sabedoria
5.2.2.2. Eficiência
5.2.2.2.1. Dados a Entendimento
5.2.2.3. Eficácia
5.2.2.3.1. Sabedoria
5.2.2.4. Analogia da estrada
5.2.2.4.1. Estar na estrada errada com um carro rápido, você só irá chegar mais rápido no lugar errado
5.2.2.4.2. Você dever consciência do caminho que você está seguindo
5.2.3. Conclusão
5.2.3.1. "Um resultado gerado por um ganho de eficácia é pelo menos uma ordem de grandeza a mais do que um ganho relacionado a eficiência" - Alisson Vale
5.2.3.1.1. Você perguntando porque uma feature precisa ser feita, descobrindo que não preciso fazer por possuir uma solução alternativa, é ser eficaz
5.2.3.1.2. Muito mais significativo do que sair desenvolvendo sem necessidade
5.2.3.1.3. Eficácia lida muito bem se estamos fazendo a coisa certa
5.2.3.1.4. Não adianta saber tudo sobre XP, Lean, Kanban em um contexto errado é um desastre muito maior do que fazer errado em um contexto certo
5.3. S2A03 - Pensamento Sistêmico
5.3.1. Colocar em foco principal a razão e experimentação
5.3.2. Renaissence
5.3.2.1. Começou uma mudança muito grande
5.3.2.1.1. Humanismo
5.4. S2A04: Do mecanismo para o organismo
5.4.1. 1999, Jim Highsmith
5.4.1.1. Adaptive Software Development
5.4.1.1.1. Uma abordagem colaborativa para gerenciar sistemas complexos
5.4.1.1.2. W. Brian Arthur
5.4.2. Mundos diferentes, gestão diferente
5.4.2.1. Dois mundos com demanda por culturas de gestão completamente diferente
5.4.2.2. O mundo não esperou que essa cultura de gestão fosse dissecada e digerida. O mundo continuou em uma velocidade bem maior
5.4.2.3. Operamos um mercado de natureza e demanda cultural diferente com instrumentos do outro mercado
5.4.2.4. As diferenças entre os mundos
5.4.2.4.1. Tradicional
5.4.2.4.2. Segundo mundo
5.4.2.5. Ordens
5.4.2.5.1. Ordem imposta
5.4.2.5.2. Ordem emergente
5.4.2.6. Conclusão
5.4.2.6.1. Eficácia é a meta e eficiência é o pressuposto
5.4.2.6.2. Mecanismo funciona melhor com controles e Organismo funciona melhor com restrições, influência e alavancagem sistêmica
5.4.2.6.3. Admirável mundo novo
5.5. S2A05: Performance e satisfação para profissionais do conhecimento
5.5.1. Problemas que vivemos na gestão
5.5.1.1. Sem tempo para melhorar o processo
5.5.1.2. Sem tempo para fazer as tarefas realmente importantes
5.5.1.3. Somos interrompidos para executar coisas urgentes
5.5.1.4. Projetos perdendo valor ao longo do tempo
5.5.1.5. Demandas urgentes batendo a porta
5.5.1.6. Especializando a equipe em módulos do sistema
5.5.1.7. Rotatividade aumenta
5.5.1.8. Manter talentos
5.5.1.9. Features que não são usadas
5.5.1.10. Problemas entre a equipe e a gestão da empresa
5.5.1.11. Sem colaboração e compromisso nas metas compartilhadas
5.5.2. 1981 - Barry Boehm
5.5.2.1. Software Engineering Economics
5.5.2.1.1. "Uma gestão ruim pode aumentar os custos de desenvolvimento de software mais do que qualquer outro fator"
5.5.2.1.2. Estudos posteriores mostraram que 64% estão relacionados a gestão
5.5.3. David Anderson
5.5.3.1. Lessons in Agile Management - On the Road to Kanban
5.5.3.1.1. Citou o Barry Boehm
5.5.4. "Você não é avaliado pelo o que você faz, você é avaliado pelo resultado do que você faz" - Alisson Vale
5.5.5. Jeff Atwood
5.5.5.1. “Desenvolvedores de software acham que seu trabalho é escrever código, mas não é. Seu trabalho é solucionar os problemas dos seus clientes. Claro que o meio preferido para resolvermos os problemas é o software, e isso envolve escrever código. Mas sejamos diretos, escrever código é algo que você tem que fazer para entregar uma solução, não é o fim em si mesmo”
5.5.6. O Segredo da sua performance e satifação
5.5.6.1. Eficiência x Eficácia
5.5.6.1.1. Eficiência
5.5.6.1.2. Eficácia
5.5.6.2. Projetos de software
5.5.6.2.1. Uma boa gestão é a arte de fazer a coisa certa - Eficácia
5.5.6.3. Peter Drucker
5.5.6.3.1. "Eficiência é fazer do jeito certo e Eficácia é fazer a coisa certa" - Peter Drucker
5.5.6.3.2. ”Aumentar a eficácia pode bem ser a única área onde podemos esperar um significante aumento no nível de performance, realização e satisfação de um trabalhador do conhecimento”
5.5.7. "O processo"
5.5.7.1. Especializava e isolava as pessoas em determinadas posições
5.5.7.1.1. Resultado sempre o mesmo
5.5.7.1.2. Mundo da eficiência
5.5.7.1.3. Fábrica de Software
5.5.8. Decisões
5.5.8.1. Onde eu coloco esse método?
5.5.8.2. Qual o nome que eu dou para essa classe?
5.5.8.3. Que tarefa eu faço agora?
5.5.8.4. Qual a próxima feature?
5.5.9. Conclusão
5.5.9.1. Problemas que vivemos
5.5.9.2. Importância da gestão para melhorar esses problemas
5.5.9.3. Eficácia como ponto de partida
5.6. S2A06: A fórmula da eficácia
5.6.1. Diferença entre eficiência e eficácia
5.6.1.1. Eficiência
5.6.1.1.1. Trabalho manual
5.6.1.1.2. Tem como objetivo a forma mais barata
5.6.1.1.3. Sem tomada de decisões
5.6.1.1.4. Variação no processo
5.6.1.2. Eficácia
5.6.1.2.1. Software
5.6.1.2.2. Demanda surge por problemas não resolvidos
5.6.1.2.3. Requer tomada de decisão
5.6.1.2.4. Value-Full
5.6.1.2.5. Resolver a coisa certa na hora certa
5.6.2. A fórmula
5.6.2.1. Tomamos decisões o tempo todo
5.6.2.2. Ao tomar uma decisão você tem muito menos informação quando você descobre se foi a decisão certa
5.6.2.3. ? min(t) !
5.6.2.3.1. ? - Hipótese
5.6.2.3.2. min(t) - Minimizar o tempo entre o surgimento da hipótese e sua validação
5.6.2.3.3. ! - Validação
5.6.3. Modo estruturado para se tornar mais eficaz
5.6.4. Exemplos:
5.6.4.1. Codificação
5.6.4.1.1. Cada linha escrita é uma hipótese
5.6.4.1.2. Compilado é validado a hipótese
5.6.4.2. Cartões perfurados
5.6.4.2.1. Todos os cartões furados corretamente eram hipóteses
5.6.4.2.2. Cartões processados no service desk central validavam a hipótese
5.6.4.3. Testes
5.6.4.3.1. Feature implementada está executando aquilo que deveria executar
5.6.4.3.2. Testes naquela feature
5.6.5. Boa prática
5.6.5.1. Programação em Par
5.6.6. Lean
5.6.6.1. Administração do estoque de suposições não validadas
5.6.7. XP
5.6.7.1. Prática do cliente presente
5.6.7.2. Fazer a coisa certa no nível de produto
5.6.8. Coordenação Tática
5.6.8.1. Garante que estão fazendo a coisa certa
5.6.8.2. Garante que saibam quais as próximas coisas a serem feitas
5.6.8.3. Estou sendo bloqueado por algo?
5.7. S2A07: Review da Sprint
5.7.1. O mundo requer uma postura diferente
5.7.2. Contraste entre Empresa A e Empresa B
5.7.3. A eficácia como alternativa
5.7.4. Pirâmide de Ackoff
5.7.4.1. Processo de absorção e reflete a forma como agimos
5.7.5. Pensamento analítico para o Sistêmico
5.7.5.1. Sem o pensamento sistêmico não conseguimos dar conta dos problemas que surgem
5.7.6. Mecanismo para o organismo
5.7.6.1. Como fazemos os designes de nossos produtos e processos
5.7.6.2. Eficiência - Pensamento Análitico
5.7.6.3. Eficácia - Pensamento Sistêmico
5.7.6.4. Criar novas capacidades
5.7.6.5. Lado A e Lado B de um disco
5.7.6.5.1. Coerência dos dois lados, o problema existe quando os misturamos
5.7.7. Performance e Satisfação para profissionais do conhecimento
5.7.8. A fórmula da eficácica
5.7.8.1. Apresentado exemplos aplicado em vários cenários
5.7.9. Conceito mais discutido
5.7.9.1. Gestão como controle
5.7.10. Controle e Restrições
5.7.10.1. Controle é um cronograma detalhado, pedindo para as pessoas estimarem individualmente e você controlar se está sendo feito
5.7.10.2. Restrições é deixar que o time se auto-organize para cumprir o trabalho. Ex.: Reunião diária as 16:00
5.7.11. Livro - Capítulo 2
5.7.11.1. Postura de eficiência e postura de eficácia
5.7.11.2. Impacto da diferença entre as abordagens
5.7.12. Fase 2 do Jogo da Zoe
5.7.12.1. Como vender esse caminho novo?
5.7.12.2. Buscar diagnostico mais claro
5.7.12.3. É uma estratégia do que será feito
5.7.12.4. Remover as objeções