SlideShare uma empresa Scribd logo
Implementing Lean
Software Development
     From Concept to Cash
Jeff Sutherland


        Lean vê todos os métodos ágeis como
          válidos, aplicações comprovadas do
                            pensamento lean.
                  Vai além disto, permitindo a
                prosperidade destes métodos.
História
História

•   1914 - Ford aplica os conceitos de Taylor na linha de produção

    •   Treinamento de pessoas em poucos minutos

    •   Rapidamente substituíveis

•   GM: múltiplos modelos para diversos segmentos de mercado
História

•   Toyoda produzia teares no Japão

    •   Contratam os melhores engenheiros das universidades japonesas
        e os mantém na equipe de pesquisas

    •   Criaram métodos para detectar problemas e parar as máquinas,
        assim poderiam rodar à noite desacompanhadas
História

•   1945 - Não era possível aplicar economia em escala (produção em massa)

    •   Materiais escassos

    •   Poucos pedidos

    •   Muita Variedade
História

•   Kiichiro teve a visão de que as peças deveriam chegar à linha de produção
    “Just-in-Time”

•   Não poderia haver estoque das peças

•   Deveriam ser feitas pouco antes de quando fossem necessárias
Just-in-Time
Just-in-Time
Toyota Production System

•   Design por um líder empreendedor

    •   Engenheiro muito experiente. Também entende do mercado para criar
        um veículo que encante os consumidores

•   Supervisores são mestres no que fazem

•   Decisões são tomadas somente quando são absolutamente necessárias
Lean Software Development


•   Clientes não compram o software que desenvolvemos

•   Muitos softwares estão incluídos em algo maior que seu código
Princípios
Princípios


•   Princípios são conceitos atemporais. Práticas são as aplicações dos
    princípios em uma determinada situação.
Princípios



•   Copiar práticas sem entender seus princípios traz resultados medíocres.
Desenvolvimento

•   É o processo de transformar ideias em produtos.

•   Existem duas escolas de pensamento:

     •   Determinística

     •   Empírica
Desenvolvimento


•   Acreditamos que todo processo de desenvolvimento deve ser empírico
    pois este provê a melhor maneira de se adaptar à mudanças.
Os 7 princípios do
desenvolvimento Lean
#1 - Elimine desperdícios


•   Para eliminá-los, primeiro você deve reconhecê-los

•   Tudo o que fazemos que não adiciona valor para o cliente é desperdício

•   Todo atraso em permitir que o cliente receba valor também é desperdício
#2 - Construa com qualidade (embutida)

•   Crie código com qualidade desde o início, não teste depois.

•   Seu foco não deve ser em registrar defeitos em um sistema, mas evitá-los
    em primeiro lugar.

•   Quando um defeito é encontrado, “pare a linha”, encontre a causa e corrija
    imediatamente.

•   O trabalho dos testadores é prevenir que aconteçam defeitos e não
    encontrá-los.
#3 - Crie conhecimento

•   Um design prematuro não consegue antecipar a complexidade encontrada
    durante a implementação.

•   Um processo de desenvolvimento focado em conhecimento espera que o
    design evolua durante a codificação.

•   É responsabilidade do time de desenvolvimento a melhoria do processo.
    Todo time deve ter um tempo para trabalhar nestas melhorias.
#4 - Adie compromissos


•   Agende decisões irreversíveis para o último momento possível.

•   Um sistema não precisa ser completamente flexível, mas deve permitir
    mudanças onde elas provavelmente ocorrerão.
#5 - Entregue rapidamente
•   Temos que entregar software tão rápido que os clientes não tenham tempo
    de mudar de ideia.

•   Empresas que competem em tempo geralmente têm uma redução
    significativa nos custos pois eliminaram muito desperdício.

     •   Possuem baixo nível de defeitos

     •   Entendem profundamente o cliente

•   O trabalho é estruturado para que todos saibam o que fazer sem
    precisarem perguntar e resolvem problemas sem pedir permissão
#6 - Respeite as pessoas
•   Líder empreendedor: uma empresa que respeita as pessoas desenvolve
    ótimos líderes que promovem engajamento para criar ótimos produtos.

•   A empresa deve “nutrir” a excelência técnica em sua área.

    •   Empresas que compram a expertise verão que seus concorrentes
        também podem comprar

•   Ao invés de dizer às pessoas o que fazer e como fazer, crie uma
    organização onde todos reflitam e resolvam problemas sozinhos
#7 - Otimize o todo


•   Uma empresa Lean otimiza toda a cadeia de valor, desde o pedido de um
    cliente até o software em produção

•   Se você quebra esta cadeia em silos e otimiza-os individualmente, o
    sistema completo será certamente subotimizado.
Valor
Entregando Valor


•   Conceitos são bem aceitos, mas nada se compara a verificar as coisas no
    mundo real

•   Como criar produtos que encantem o consumidor?
Modelo de Kano
Entendendo profundamente o consumidor



•   “Ótimos softwares nascem da sinergia entre uma pessoa que realmente
    entende do negócio e uma pessoa que realmente entende a tecnologia.”
Focando no trabalho


•   “Valor é criado quando nos concentramos no trabalho que precisa ser
    realizado melhorando o produto para que seja melhor que qualquer outra
    alternativa.”
Trabalho em times


•   Software é melhor suportado por times que se mantém pois o
    conhecimento do cliente, do código e do domínio são difíceis de se
    transferir.
Desperdício
Desperdício


•   Se fossemos procurar pela causa raiz de todo o desperdício em
    desenvolvimento de software, um ótimo candidato seria a complexidade.
Complexidade


      •   Empresas inteligentes têm como
          prioridade manter o código
          simples, limpo e pequeno.
Justifique cada estória


•   Lançar um produto com as funcionalidades certas, nem mais nem menos,
    mostra que você realmente entende o que o cliente deseja
Não automatize a complexidade


•   Não estaremos ajudando o cliente se simplesmente automatizarmos um
    processo complexo ou bagunçado.

    •   Qualquer processo que é candidato a ser automatizado deve antes ser
        esclarecido e simplificado
Os 7 desperdícios em software
         Manufatura                    Software

     Estoque em processo   Trabalho parcialmente concluído

       Sobre-produção           Funcionalidades extras

     Processamento extra            Reaprendizado

         Transporte        Transferência de tarefa (Handoffs)

        Movimentação          Troca de tarefa (Switching)

           Espera                       Atrasos

          Defeitos                     Defeitos
#1 - Trabalho parcialmente concluído

•   Exemplos:

     •   Documentação sem código

     •   Código não sincronizado (branches)

     •   Código não testado

     •   Código não instalado (undeployed)
#2 - Funcionalidades Extras



•   Adicionar algo que o cliente não solicitou é o pior dos 7 desperdícios.
#3 - Reaprendizagem


•   Redescobrir algo que já se sabia e foi esquecido é talvez a melhor
    definição de "retrabalho" no desenvolvimento
#4 - Transferências (Handoffs)
•   É muito difícil transferir conhecimento tácito através de documentos.

•   Quando o trabalho é transferido uma grande quantidade de conhecimento
    tácito é deixado pra trás por quem o originou.

•   Como reduzir o desperdício?

      •   Reduza o número de handoffs

      •   Tenha discussões face-a-face
#5 - Troca de tarefas (Switching)

•   Quando trabalhadores do conhecimento tem 3 ou 4 tarefas para fazer,
    passarão mais tempo “limpando” sua mente do que realmente trabalhando
    nelas. Isto é desperdício.

•   Além do tempo necessário para completar as tarefas, o valor em potencial
    de não tê-las entregue antes para o cliente também é desperdício
#5 - Troca de tarefas (Switching)
#6 - Atrasos

•   Uma decisão pode ser tomada rapidamente se um desenvolvedor entende
    bem o que deve ser realizado, e se houver alguém na mesma sala que pode
    responder à dúvidas que surjam.

•   Conhecimento deve estar disponível exatamente quando necessário - não
    muito cedo, pois poderá ser mudado, nem tão tarde, pois será ignorado.
#7 - Defeitos

•   Quando um defeito é encontrado, um teste deve ser criado para que
    nunca mais volte a acontecer.

•   Se o software frequentemente entra na fase de verificações finais com
    defeitos, está sendo produzido por um processo defeituoso.

•   Um bom time ágil possui uma taxa muito baixa de defeitos pois o objetivo
    primário é desenvolver código a prova de erros.
Mapeando cadeias de valor
Mapeando cadeias de valor


•   Depois de fazer o mapa, pergunte-se:

     •   Quanto tempo demora para atender a solicitação de um cliente?

     •   Qual é o percentual de tempo gasto adicionando valor?
Mapeando cadeias de valor
Mapeando cadeias de valor

•   Mapas futuros:

    •   Escolha os maiores atrasos ou as maiores filas e ataque-os primeiro.

    •   Desenhe um novo mapa de como pretende estar em 3 a 6 meses que
        contenha de 1 a 3 alterações chave.

    •   Quando estas mudanças tiverem sido implementadas desenhe outro
        mapa procurando novamente os maiores problemas.
Velocidade
Velocidade



•   É a ausência de desperdícios.
Tempo de ciclo


•   É a medida em Lean que alerta quando algo está indo mal.

•   Um processo ótimo é aquele que transforma necessidades do cliente em
    valor em uma cadência confiável e frequente.
Variação e Utilização
Como reduzir o tempo de ciclo?

•   Grandes filas de tarefas geralmente são irrealistas e desnecessárias.

    •   Pergunte-se: Quantas coisas nesta fila não serão nunca desenvolvidas?
        Seja honesto. Corte-as.

    •   Quantas sobraram? Metade? Faça então uma análise de Pareto e
        elimine os 80% menos importantes.
Como reduzir o tempo de ciclo?

•   Minimize o tamanho:

    •   Tenha ciclos de releases curtos e pequenos pacotes de trabalho.

    •   É uma tarefa difícil e requer disciplina.

    •   A cadência deve ser curta o bastante para que os clientes possam
        esperar até o fim da iteração para solicitar mudanças e grande o
        bastante para que o sistema permaneça estável.
Pessoas
Pessoas


•   Lean é um sistema de gerenciamento que cria pessoas engajadas em
    qualquer nível de uma organização e particularmente na linha de frente.
W. Edwards Deming


•   A proposta de uma empresa não é ganhar dinheiro, é deixar os clientes tão
    satisfeitos que queiram continuar a comprar seus produtos.
Porque bons programas falham?


•   Iniciativas Lean de sucesso devem ser baseadas em um profundo respeito
    por cada pessoa da empresa, especialmente os mais “comuns” que
    realmente fazem o produto acontecer.
Times


•   Colocar um grupo de pessoas juntas e chamá-los de time não os faz um
    verdadeiro time.

•   O que torna um grupo em um time é o comprometimento dos membros
    em direcionar suas diversas habilidades para atingir um propósito comum.
Liderança

   •   Um grande time sem um líder
       não é suficiente.

   •   O time pode até ir rápido e na
       direção correta, mas não terá
       sincronismo e não fará as correções
       de curso que o fazem vencedor.
Incentivos


•   Existem dois tipos de companhias (de Geus):

     •   Econômica

     •   “Rio”
Encontre os motivadores corretos

  •   Realizações

  •   Crescimento

  •   Controle sobre seu trabalho

  •   Reconhecimento

  •   Ambiente de trabalho agradável
Conhecimento
Conhecimento

•   Empresas do ocidente pensam que o conhecimento é algo escrito.

•   Empresa japonesas pensam que conhecimento escrito é apenas a ponta do
    iceberg.

•   Conhecimento tácito não vem do estudo, mas da experiência.
Qual é o seu maior problema?


•   Encontre o maior problema que esteja em seu caminho para o sucesso, e
    mantenha todos focados em como resolvê-lo.

•   A primeira regra do processo de melhoria é não tentar fazer tudo de uma
    vez.
Uma maneira científica de pensamento
                   Toytota                      Deming

            1. Defina o problema.

           2. Procure a causa raiz.

       3. Proponha uma contramedida.

    4. Especifique os resultados esperados.   1. Planejamento

       5. Implemente a contramedida.          2. Execução

          6.Verifique os resultados.           3.Verificação

        7. Dê seguimento. Padronize.             4. Ação
Qualidade
Arquitetura


•   O objetivo de uma boa arquitetura de software é manter o mínimo
    possível de decisões irreversíveis e prover uma forma de trabalho que
    suporte desenvolvimento iterativo.
Disciplina


•   Não é possível mover-se com velocidade sem construir um produto com
    qualidade, e isto requer muita disciplina.
Os 5 S’s

•   Seiri (Selecione)

•   Seiton (Sistematize)

•   Seiso (Lustre)

•   Seiketsu (Padronize)

•   Shitsuke (Sustente)
Os 5 S’s em Java
•   Seiri: reduza o tamanho da base de código.

    •   Remova código inutilizado (imports, variáveis, métodos, classes)

•   Seiton: organize os projetos e pacotes. Tenha um lugar para tudo.

•   Seiso: faça a limpeza.

    •   Resolva testes unitários quebrados e warnings do checkstyle e PMD

•   Seiketsu: já que está tudo limpo, mantenha desta forma. Reduza a complexidade para facilitar a
    manutenção.

•   Shitsuke: use e siga procedimentos padronizados.
Padrões


•   Tornam possível operar reflexivamente e mover informações sem o
    desperdício de fazer conversões.

•   Uma infraestrutura padronizada com uma arquitetura comum reduz a
    complexidade e consequentemente o custo.
Revisões de código

•   Usá-las para reforçar padrões ou encontrar defeitos é um desperdício.

•   O código de um desenvolvedor menos experiente pode ser revisado para
    se conseguir simplicidade, encontrar repetições e práticas de orientação à
    objetos.

•   Trabalho em par: cria sinergia
Sistemas a prova de erros


•   Equívocos não são culpa daquele que os cometeu, mas do sistema que
    permitiu que fossem cometidos.

•   Em software, tudo o que puder dar errado, eventualmente dará errado.
Test-Driven Development


•   A meta do desenvolvimento de software Lean é prevenir que defeitos
    entrem no código e a forma para que isto aconteça é utilizar TDD.
Test-Driven Development
•   Testes unitários: escrever testes antes geralmente simplifica o design pois
    gera código que é desacoplado.

•   Testes de aceitação: identificam a intenção do negócio. Ajudam a pensar no
    que envolve o trabalho do cliente e como isto será suportado por software.

•   Testes exploratórios: especialistas testam quais são as barreiras do software
    além de procurar resultados inesperados.

•   Testes de propriedade: incluem requisitos não-funcionais como tempo de
    resposta, robustez, escalabilidade, etc.
A jornada
Aonde você quer chegar?


•   Organizações que desenvolveram a capacidade de aprender e se adaptar são
    aquelas que sobreviverão.

•   Devem ser centradas em pessoas. Removê-las significa que o processo não
    será mais capaz de se modificar ou se adaptar.
Em que você realmente acredita
      sobre as pessoas?
Você deve acreditar que não há melhor forma
  para atacar os problemas do que treinar as
 pessoas e fornecer ferramentas para que elas
mesmas os resolvam e melhorem seu processo.
Questione


•   Todo trabalhador, a qualquer momento, deve questionar como é seu
    processo de trabalho e deve ser encorajado a usar técnicas para testar
    novas ideias e implementar aquelas que funcionarem.
Quais são as medidas?

•   Tempo de ciclo: quão rápido você atende o cliente de forma repetida e
    confiável?

•   Retorno financeiro: seu software está trazendo retorno sobre o
    investimento do cliente?

•   Satisfação: seu cliente recomendaria seu produto?
Referência
Título: Implementing Lean Software Development

Subtítulo: From Concept to Cash

Autores: Tom e Mary Poppendieck

ISBN: 9780321437389

Mais conteúdo relacionado

Mais procurados

Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Rafael Salerno de Oliveira
 
Kanban: Aplicando TDD à melhoria contínua do seu processo
Kanban: Aplicando TDD à melhoria contínua do seu processoKanban: Aplicando TDD à melhoria contínua do seu processo
Kanban: Aplicando TDD à melhoria contínua do seu processo
Rodrigo Yoshima
 
Visões sobre Lean & Agile - Victor Hugo & Manoel Pimentel
Visões sobre Lean & Agile -  Victor Hugo & Manoel PimentelVisões sobre Lean & Agile -  Victor Hugo & Manoel Pimentel
Visões sobre Lean & Agile - Victor Hugo & Manoel Pimentel
Manoel Pimentel Medeiros
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
Rodrigo Branas
 
Liderança Lean
Liderança LeanLiderança Lean
Liderança Lean
Carlos Frederico Pinto
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
João Carlos Ottobboni
 
Novidades ALM Summit 2013
Novidades ALM Summit 2013Novidades ALM Summit 2013
Novidades ALM Summit 2013
Lambda 3
 
Marketing de Produtos Digitais
Marketing de Produtos DigitaisMarketing de Produtos Digitais
Marketing de Produtos Digitais
Lambda 3
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
Claudia Melo
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
Renato Pina
 
Scrum em 1h.
Scrum em 1h.Scrum em 1h.
Scrum em 1h.
Márcio Oya
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
Joaquim Lopes Júnior
 
Kanban
KanbanKanban
Kanban pragmático
Kanban pragmáticoKanban pragmático
Kanban pragmático
Paulo Rebelo, MSc, PMP, CSP
 
O programador lean
O programador leanO programador lean
O programador lean
Rodrigo Yoshima
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
Igor Abade
 
Modelo ágil
Modelo ágilModelo ágil
Modelo ágil
Ariovaldo Carmona
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Neubio Ferreira
 
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
 
Kanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e LimitesKanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e Limites
Rodrigo Yoshima
 

Mais procurados (20)

Como automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOpsComo automatizar Sistemas Legados utilizando ferramentas de DevOps
Como automatizar Sistemas Legados utilizando ferramentas de DevOps
 
Kanban: Aplicando TDD à melhoria contínua do seu processo
Kanban: Aplicando TDD à melhoria contínua do seu processoKanban: Aplicando TDD à melhoria contínua do seu processo
Kanban: Aplicando TDD à melhoria contínua do seu processo
 
Visões sobre Lean & Agile - Victor Hugo & Manoel Pimentel
Visões sobre Lean & Agile -  Victor Hugo & Manoel PimentelVisões sobre Lean & Agile -  Victor Hugo & Manoel Pimentel
Visões sobre Lean & Agile - Victor Hugo & Manoel Pimentel
 
XP - Extreme Programming
XP - Extreme ProgrammingXP - Extreme Programming
XP - Extreme Programming
 
Liderança Lean
Liderança LeanLiderança Lean
Liderança Lean
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
Novidades ALM Summit 2013
Novidades ALM Summit 2013Novidades ALM Summit 2013
Novidades ALM Summit 2013
 
Marketing de Produtos Digitais
Marketing de Produtos DigitaisMarketing de Produtos Digitais
Marketing de Produtos Digitais
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
 
Scrum em 1h.
Scrum em 1h.Scrum em 1h.
Scrum em 1h.
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
 
Kanban
KanbanKanban
Kanban
 
Kanban pragmático
Kanban pragmáticoKanban pragmático
Kanban pragmático
 
O programador lean
O programador leanO programador lean
O programador lean
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
 
Modelo ágil
Modelo ágilModelo ágil
Modelo ágil
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
Test First, TDD e outros Bichos
Test First, TDD e outros BichosTest First, TDD e outros Bichos
Test First, TDD e outros Bichos
 
Kanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e LimitesKanban Avançado - Além de Visualizações e Limites
Kanban Avançado - Além de Visualizações e Limites
 

Destaque

User Stories Applied
User Stories AppliedUser Stories Applied
User Stories Applied
IIBA UK Chapter
 
Intro to Agile and Lean Software Development
Intro to Agile and Lean Software DevelopmentIntro to Agile and Lean Software Development
Intro to Agile and Lean Software Development
Aleksejs Truhans
 
Lean Software Development & Kanban
Lean Software Development & KanbanLean Software Development & Kanban
Lean Software Development & Kanban
Rishi Chaddha
 
Agile and Lean Software Development
Agile and Lean Software DevelopmentAgile and Lean Software Development
Agile and Lean Software Development
Tathagat Varma
 
Agile Software Development Scrum Vs Lean
Agile Software Development Scrum Vs LeanAgile Software Development Scrum Vs Lean
Agile Software Development Scrum Vs Lean
Abdul Wahid
 
Agile User Stories
Agile User StoriesAgile User Stories
Agile User Stories
kahgeh75
 
How to write good user stories
How to write good user storiesHow to write good user stories
How to write good user stories
Jose E. Rodriguez Huerta
 
Agile Project Management for PMP's
Agile Project Management for PMP'sAgile Project Management for PMP's
Agile Project Management for PMP's
VersionOne
 
Lean and Kanban-based Software Development
Lean and Kanban-based Software DevelopmentLean and Kanban-based Software Development
Lean and Kanban-based Software Development
Tathagat Varma
 

Destaque (9)

User Stories Applied
User Stories AppliedUser Stories Applied
User Stories Applied
 
Intro to Agile and Lean Software Development
Intro to Agile and Lean Software DevelopmentIntro to Agile and Lean Software Development
Intro to Agile and Lean Software Development
 
Lean Software Development & Kanban
Lean Software Development & KanbanLean Software Development & Kanban
Lean Software Development & Kanban
 
Agile and Lean Software Development
Agile and Lean Software DevelopmentAgile and Lean Software Development
Agile and Lean Software Development
 
Agile Software Development Scrum Vs Lean
Agile Software Development Scrum Vs LeanAgile Software Development Scrum Vs Lean
Agile Software Development Scrum Vs Lean
 
Agile User Stories
Agile User StoriesAgile User Stories
Agile User Stories
 
How to write good user stories
How to write good user storiesHow to write good user stories
How to write good user stories
 
Agile Project Management for PMP's
Agile Project Management for PMP'sAgile Project Management for PMP's
Agile Project Management for PMP's
 
Lean and Kanban-based Software Development
Lean and Kanban-based Software DevelopmentLean and Kanban-based Software Development
Lean and Kanban-based Software Development
 

Semelhante a Implementing lean software development

Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software LeanMinicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
Claudia Melo
 
Slides da Aula de Gestão de Projetos Digitais
Slides da Aula de Gestão de Projetos DigitaisSlides da Aula de Gestão de Projetos Digitais
Slides da Aula de Gestão de Projetos Digitais
Márcio Oya
 
O que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBMO que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBM
Felipe Freire
 
SCRUM - Aula1
SCRUM - Aula1SCRUM - Aula1
SCRUM - Aula1
Saulo Arruda
 
Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.
Rafael de Oliveira
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
Alessandro Rodrigues, CSM, SFC
 
Velozes e furiosos com extreme programming.
Velozes e furiosos com extreme programming. Velozes e furiosos com extreme programming.
Velozes e furiosos com extreme programming.
Alessandro Binhara
 
SCRUM.pptx
SCRUM.pptxSCRUM.pptx
SCRUM.pptx
Ricardo Santos
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
Achiles Camilo
 
Seu código fede e você nem sabia
Seu código fede e você nem sabiaSeu código fede e você nem sabia
Seu código fede e você nem sabia
Wagner Mendes Voltz Fusca
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
Rudson Kiyoshi Souza Carvalho
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Elaine Cecília Gatto
 
Apresentação Executiva
Apresentação ExecutivaApresentação Executiva
Apresentação Executiva
Powerlogic Consultoria e Sistemas
 
Projetos Empresariais , Computação em Nuvem e Inovação !
Projetos Empresariais  , Computação em Nuvem e Inovação !Projetos Empresariais  , Computação em Nuvem e Inovação !
Projetos Empresariais , Computação em Nuvem e Inovação !
Manoel Veras, Dr.Eng.
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
Elaine Cecília Gatto
 
Os 7 Princípios do desenvolvimento Lean de Software
Os 7 Princípios do desenvolvimento Lean de SoftwareOs 7 Princípios do desenvolvimento Lean de Software
Os 7 Princípios do desenvolvimento Lean de Software
Lucas Oliveira
 
Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?
Cristiano Schwening
 
Manifesto Ágil.pdf
Manifesto Ágil.pdfManifesto Ágil.pdf
Manifesto Ágil.pdf
LeonardoCristianoQui
 
Treinamento Scrum - Módulo
Treinamento Scrum - MóduloTreinamento Scrum - Módulo
Treinamento Scrum - Módulo
Alberto Caeiro, CSPO, CSM, PMP
 
Startups e DevOps
Startups e DevOpsStartups e DevOps
Startups e DevOps
José Bringel Filho
 

Semelhante a Implementing lean software development (20)

Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software LeanMinicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
 
Slides da Aula de Gestão de Projetos Digitais
Slides da Aula de Gestão de Projetos DigitaisSlides da Aula de Gestão de Projetos Digitais
Slides da Aula de Gestão de Projetos Digitais
 
O que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBMO que é DevOps? Introdução à abordagem pela IBM
O que é DevOps? Introdução à abordagem pela IBM
 
SCRUM - Aula1
SCRUM - Aula1SCRUM - Aula1
SCRUM - Aula1
 
Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.Palestra sobre Fundamentos do Scrum e Kanban.
Palestra sobre Fundamentos do Scrum e Kanban.
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Velozes e furiosos com extreme programming.
Velozes e furiosos com extreme programming. Velozes e furiosos com extreme programming.
Velozes e furiosos com extreme programming.
 
SCRUM.pptx
SCRUM.pptxSCRUM.pptx
SCRUM.pptx
 
Metodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introduçãoMetodologias Ágeis: Uma breve introdução
Metodologias Ágeis: Uma breve introdução
 
Seu código fede e você nem sabia
Seu código fede e você nem sabiaSeu código fede e você nem sabia
Seu código fede e você nem sabia
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Apresentação Executiva
Apresentação ExecutivaApresentação Executiva
Apresentação Executiva
 
Projetos Empresariais , Computação em Nuvem e Inovação !
Projetos Empresariais  , Computação em Nuvem e Inovação !Projetos Empresariais  , Computação em Nuvem e Inovação !
Projetos Empresariais , Computação em Nuvem e Inovação !
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Os 7 Princípios do desenvolvimento Lean de Software
Os 7 Princípios do desenvolvimento Lean de SoftwareOs 7 Princípios do desenvolvimento Lean de Software
Os 7 Princípios do desenvolvimento Lean de Software
 
Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?Muita gestão e pouca engenharia, por onde anda o XP?
Muita gestão e pouca engenharia, por onde anda o XP?
 
Manifesto Ágil.pdf
Manifesto Ágil.pdfManifesto Ágil.pdf
Manifesto Ágil.pdf
 
Treinamento Scrum - Módulo
Treinamento Scrum - MóduloTreinamento Scrum - Módulo
Treinamento Scrum - Módulo
 
Startups e DevOps
Startups e DevOpsStartups e DevOps
Startups e DevOps
 

Mais de Luiz Faias Junior

Apresentação da monografia - PRONTO
Apresentação da monografia - PRONTOApresentação da monografia - PRONTO
Apresentação da monografia - PRONTO
Luiz Faias Junior
 
Apresentação do Ghost.org
Apresentação do Ghost.orgApresentação do Ghost.org
Apresentação do Ghost.org
Luiz Faias Junior
 
Cosmogênese e antropogênese
Cosmogênese e antropogêneseCosmogênese e antropogênese
Cosmogênese e antropogênese
Luiz Faias Junior
 
Palestra APAS 2005
Palestra APAS 2005Palestra APAS 2005
Palestra APAS 2005
Luiz Faias Junior
 
Enchantment
EnchantmentEnchantment
Enchantment
Luiz Faias Junior
 
Blueprint CSS
Blueprint CSSBlueprint CSS
Blueprint CSS
Luiz Faias Junior
 
Os 10 mandamentos do insucesso
Os 10 mandamentos do insucessoOs 10 mandamentos do insucesso
Os 10 mandamentos do insucesso
Luiz Faias Junior
 
Reggae do node
Reggae do nodeReggae do node
Reggae do node
Luiz Faias Junior
 
Pensando Lean
Pensando LeanPensando Lean
Pensando Lean
Luiz Faias Junior
 
Remember the milk
Remember the milkRemember the milk
Remember the milk
Luiz Faias Junior
 
Certified Scrum Product Owner
Certified Scrum Product OwnerCertified Scrum Product Owner
Certified Scrum Product Owner
Luiz Faias Junior
 
Lean software and systems conference 2010
Lean software and systems conference 2010Lean software and systems conference 2010
Lean software and systems conference 2010
Luiz Faias Junior
 
Scrum feito com soluções simples e de baixo custo
Scrum feito com soluções simples e de baixo custoScrum feito com soluções simples e de baixo custo
Scrum feito com soluções simples e de baixo custo
Luiz Faias Junior
 
Restrospectiva Bluesoft 2008
Restrospectiva Bluesoft 2008Restrospectiva Bluesoft 2008
Restrospectiva Bluesoft 2008
Luiz Faias Junior
 

Mais de Luiz Faias Junior (14)

Apresentação da monografia - PRONTO
Apresentação da monografia - PRONTOApresentação da monografia - PRONTO
Apresentação da monografia - PRONTO
 
Apresentação do Ghost.org
Apresentação do Ghost.orgApresentação do Ghost.org
Apresentação do Ghost.org
 
Cosmogênese e antropogênese
Cosmogênese e antropogêneseCosmogênese e antropogênese
Cosmogênese e antropogênese
 
Palestra APAS 2005
Palestra APAS 2005Palestra APAS 2005
Palestra APAS 2005
 
Enchantment
EnchantmentEnchantment
Enchantment
 
Blueprint CSS
Blueprint CSSBlueprint CSS
Blueprint CSS
 
Os 10 mandamentos do insucesso
Os 10 mandamentos do insucessoOs 10 mandamentos do insucesso
Os 10 mandamentos do insucesso
 
Reggae do node
Reggae do nodeReggae do node
Reggae do node
 
Pensando Lean
Pensando LeanPensando Lean
Pensando Lean
 
Remember the milk
Remember the milkRemember the milk
Remember the milk
 
Certified Scrum Product Owner
Certified Scrum Product OwnerCertified Scrum Product Owner
Certified Scrum Product Owner
 
Lean software and systems conference 2010
Lean software and systems conference 2010Lean software and systems conference 2010
Lean software and systems conference 2010
 
Scrum feito com soluções simples e de baixo custo
Scrum feito com soluções simples e de baixo custoScrum feito com soluções simples e de baixo custo
Scrum feito com soluções simples e de baixo custo
 
Restrospectiva Bluesoft 2008
Restrospectiva Bluesoft 2008Restrospectiva Bluesoft 2008
Restrospectiva Bluesoft 2008
 

Implementing lean software development

  • 2. Jeff Sutherland Lean vê todos os métodos ágeis como válidos, aplicações comprovadas do pensamento lean. Vai além disto, permitindo a prosperidade destes métodos.
  • 4. História • 1914 - Ford aplica os conceitos de Taylor na linha de produção • Treinamento de pessoas em poucos minutos • Rapidamente substituíveis • GM: múltiplos modelos para diversos segmentos de mercado
  • 5. História • Toyoda produzia teares no Japão • Contratam os melhores engenheiros das universidades japonesas e os mantém na equipe de pesquisas • Criaram métodos para detectar problemas e parar as máquinas, assim poderiam rodar à noite desacompanhadas
  • 6. História • 1945 - Não era possível aplicar economia em escala (produção em massa) • Materiais escassos • Poucos pedidos • Muita Variedade
  • 7. História • Kiichiro teve a visão de que as peças deveriam chegar à linha de produção “Just-in-Time” • Não poderia haver estoque das peças • Deveriam ser feitas pouco antes de quando fossem necessárias
  • 10. Toyota Production System • Design por um líder empreendedor • Engenheiro muito experiente. Também entende do mercado para criar um veículo que encante os consumidores • Supervisores são mestres no que fazem • Decisões são tomadas somente quando são absolutamente necessárias
  • 11. Lean Software Development • Clientes não compram o software que desenvolvemos • Muitos softwares estão incluídos em algo maior que seu código
  • 13. Princípios • Princípios são conceitos atemporais. Práticas são as aplicações dos princípios em uma determinada situação.
  • 14. Princípios • Copiar práticas sem entender seus princípios traz resultados medíocres.
  • 15. Desenvolvimento • É o processo de transformar ideias em produtos. • Existem duas escolas de pensamento: • Determinística • Empírica
  • 16. Desenvolvimento • Acreditamos que todo processo de desenvolvimento deve ser empírico pois este provê a melhor maneira de se adaptar à mudanças.
  • 17. Os 7 princípios do desenvolvimento Lean
  • 18. #1 - Elimine desperdícios • Para eliminá-los, primeiro você deve reconhecê-los • Tudo o que fazemos que não adiciona valor para o cliente é desperdício • Todo atraso em permitir que o cliente receba valor também é desperdício
  • 19. #2 - Construa com qualidade (embutida) • Crie código com qualidade desde o início, não teste depois. • Seu foco não deve ser em registrar defeitos em um sistema, mas evitá-los em primeiro lugar. • Quando um defeito é encontrado, “pare a linha”, encontre a causa e corrija imediatamente. • O trabalho dos testadores é prevenir que aconteçam defeitos e não encontrá-los.
  • 20. #3 - Crie conhecimento • Um design prematuro não consegue antecipar a complexidade encontrada durante a implementação. • Um processo de desenvolvimento focado em conhecimento espera que o design evolua durante a codificação. • É responsabilidade do time de desenvolvimento a melhoria do processo. Todo time deve ter um tempo para trabalhar nestas melhorias.
  • 21. #4 - Adie compromissos • Agende decisões irreversíveis para o último momento possível. • Um sistema não precisa ser completamente flexível, mas deve permitir mudanças onde elas provavelmente ocorrerão.
  • 22. #5 - Entregue rapidamente • Temos que entregar software tão rápido que os clientes não tenham tempo de mudar de ideia. • Empresas que competem em tempo geralmente têm uma redução significativa nos custos pois eliminaram muito desperdício. • Possuem baixo nível de defeitos • Entendem profundamente o cliente • O trabalho é estruturado para que todos saibam o que fazer sem precisarem perguntar e resolvem problemas sem pedir permissão
  • 23. #6 - Respeite as pessoas • Líder empreendedor: uma empresa que respeita as pessoas desenvolve ótimos líderes que promovem engajamento para criar ótimos produtos. • A empresa deve “nutrir” a excelência técnica em sua área. • Empresas que compram a expertise verão que seus concorrentes também podem comprar • Ao invés de dizer às pessoas o que fazer e como fazer, crie uma organização onde todos reflitam e resolvam problemas sozinhos
  • 24. #7 - Otimize o todo • Uma empresa Lean otimiza toda a cadeia de valor, desde o pedido de um cliente até o software em produção • Se você quebra esta cadeia em silos e otimiza-os individualmente, o sistema completo será certamente subotimizado.
  • 25. Valor
  • 26. Entregando Valor • Conceitos são bem aceitos, mas nada se compara a verificar as coisas no mundo real • Como criar produtos que encantem o consumidor?
  • 28. Entendendo profundamente o consumidor • “Ótimos softwares nascem da sinergia entre uma pessoa que realmente entende do negócio e uma pessoa que realmente entende a tecnologia.”
  • 29. Focando no trabalho • “Valor é criado quando nos concentramos no trabalho que precisa ser realizado melhorando o produto para que seja melhor que qualquer outra alternativa.”
  • 30. Trabalho em times • Software é melhor suportado por times que se mantém pois o conhecimento do cliente, do código e do domínio são difíceis de se transferir.
  • 32. Desperdício • Se fossemos procurar pela causa raiz de todo o desperdício em desenvolvimento de software, um ótimo candidato seria a complexidade.
  • 33. Complexidade • Empresas inteligentes têm como prioridade manter o código simples, limpo e pequeno.
  • 34. Justifique cada estória • Lançar um produto com as funcionalidades certas, nem mais nem menos, mostra que você realmente entende o que o cliente deseja
  • 35. Não automatize a complexidade • Não estaremos ajudando o cliente se simplesmente automatizarmos um processo complexo ou bagunçado. • Qualquer processo que é candidato a ser automatizado deve antes ser esclarecido e simplificado
  • 36. Os 7 desperdícios em software Manufatura Software Estoque em processo Trabalho parcialmente concluído Sobre-produção Funcionalidades extras Processamento extra Reaprendizado Transporte Transferência de tarefa (Handoffs) Movimentação Troca de tarefa (Switching) Espera Atrasos Defeitos Defeitos
  • 37. #1 - Trabalho parcialmente concluído • Exemplos: • Documentação sem código • Código não sincronizado (branches) • Código não testado • Código não instalado (undeployed)
  • 38. #2 - Funcionalidades Extras • Adicionar algo que o cliente não solicitou é o pior dos 7 desperdícios.
  • 39. #3 - Reaprendizagem • Redescobrir algo que já se sabia e foi esquecido é talvez a melhor definição de "retrabalho" no desenvolvimento
  • 40. #4 - Transferências (Handoffs) • É muito difícil transferir conhecimento tácito através de documentos. • Quando o trabalho é transferido uma grande quantidade de conhecimento tácito é deixado pra trás por quem o originou. • Como reduzir o desperdício? • Reduza o número de handoffs • Tenha discussões face-a-face
  • 41. #5 - Troca de tarefas (Switching) • Quando trabalhadores do conhecimento tem 3 ou 4 tarefas para fazer, passarão mais tempo “limpando” sua mente do que realmente trabalhando nelas. Isto é desperdício. • Além do tempo necessário para completar as tarefas, o valor em potencial de não tê-las entregue antes para o cliente também é desperdício
  • 42. #5 - Troca de tarefas (Switching)
  • 43. #6 - Atrasos • Uma decisão pode ser tomada rapidamente se um desenvolvedor entende bem o que deve ser realizado, e se houver alguém na mesma sala que pode responder à dúvidas que surjam. • Conhecimento deve estar disponível exatamente quando necessário - não muito cedo, pois poderá ser mudado, nem tão tarde, pois será ignorado.
  • 44. #7 - Defeitos • Quando um defeito é encontrado, um teste deve ser criado para que nunca mais volte a acontecer. • Se o software frequentemente entra na fase de verificações finais com defeitos, está sendo produzido por um processo defeituoso. • Um bom time ágil possui uma taxa muito baixa de defeitos pois o objetivo primário é desenvolver código a prova de erros.
  • 46. Mapeando cadeias de valor • Depois de fazer o mapa, pergunte-se: • Quanto tempo demora para atender a solicitação de um cliente? • Qual é o percentual de tempo gasto adicionando valor?
  • 48. Mapeando cadeias de valor • Mapas futuros: • Escolha os maiores atrasos ou as maiores filas e ataque-os primeiro. • Desenhe um novo mapa de como pretende estar em 3 a 6 meses que contenha de 1 a 3 alterações chave. • Quando estas mudanças tiverem sido implementadas desenhe outro mapa procurando novamente os maiores problemas.
  • 50. Velocidade • É a ausência de desperdícios.
  • 51. Tempo de ciclo • É a medida em Lean que alerta quando algo está indo mal. • Um processo ótimo é aquele que transforma necessidades do cliente em valor em uma cadência confiável e frequente.
  • 53. Como reduzir o tempo de ciclo? • Grandes filas de tarefas geralmente são irrealistas e desnecessárias. • Pergunte-se: Quantas coisas nesta fila não serão nunca desenvolvidas? Seja honesto. Corte-as. • Quantas sobraram? Metade? Faça então uma análise de Pareto e elimine os 80% menos importantes.
  • 54. Como reduzir o tempo de ciclo? • Minimize o tamanho: • Tenha ciclos de releases curtos e pequenos pacotes de trabalho. • É uma tarefa difícil e requer disciplina. • A cadência deve ser curta o bastante para que os clientes possam esperar até o fim da iteração para solicitar mudanças e grande o bastante para que o sistema permaneça estável.
  • 56. Pessoas • Lean é um sistema de gerenciamento que cria pessoas engajadas em qualquer nível de uma organização e particularmente na linha de frente.
  • 57. W. Edwards Deming • A proposta de uma empresa não é ganhar dinheiro, é deixar os clientes tão satisfeitos que queiram continuar a comprar seus produtos.
  • 58. Porque bons programas falham? • Iniciativas Lean de sucesso devem ser baseadas em um profundo respeito por cada pessoa da empresa, especialmente os mais “comuns” que realmente fazem o produto acontecer.
  • 59. Times • Colocar um grupo de pessoas juntas e chamá-los de time não os faz um verdadeiro time. • O que torna um grupo em um time é o comprometimento dos membros em direcionar suas diversas habilidades para atingir um propósito comum.
  • 60. Liderança • Um grande time sem um líder não é suficiente. • O time pode até ir rápido e na direção correta, mas não terá sincronismo e não fará as correções de curso que o fazem vencedor.
  • 61. Incentivos • Existem dois tipos de companhias (de Geus): • Econômica • “Rio”
  • 62. Encontre os motivadores corretos • Realizações • Crescimento • Controle sobre seu trabalho • Reconhecimento • Ambiente de trabalho agradável
  • 64. Conhecimento • Empresas do ocidente pensam que o conhecimento é algo escrito. • Empresa japonesas pensam que conhecimento escrito é apenas a ponta do iceberg. • Conhecimento tácito não vem do estudo, mas da experiência.
  • 65. Qual é o seu maior problema? • Encontre o maior problema que esteja em seu caminho para o sucesso, e mantenha todos focados em como resolvê-lo. • A primeira regra do processo de melhoria é não tentar fazer tudo de uma vez.
  • 66. Uma maneira científica de pensamento Toytota Deming 1. Defina o problema. 2. Procure a causa raiz. 3. Proponha uma contramedida. 4. Especifique os resultados esperados. 1. Planejamento 5. Implemente a contramedida. 2. Execução 6.Verifique os resultados. 3.Verificação 7. Dê seguimento. Padronize. 4. Ação
  • 68. Arquitetura • O objetivo de uma boa arquitetura de software é manter o mínimo possível de decisões irreversíveis e prover uma forma de trabalho que suporte desenvolvimento iterativo.
  • 69. Disciplina • Não é possível mover-se com velocidade sem construir um produto com qualidade, e isto requer muita disciplina.
  • 70. Os 5 S’s • Seiri (Selecione) • Seiton (Sistematize) • Seiso (Lustre) • Seiketsu (Padronize) • Shitsuke (Sustente)
  • 71. Os 5 S’s em Java • Seiri: reduza o tamanho da base de código. • Remova código inutilizado (imports, variáveis, métodos, classes) • Seiton: organize os projetos e pacotes. Tenha um lugar para tudo. • Seiso: faça a limpeza. • Resolva testes unitários quebrados e warnings do checkstyle e PMD • Seiketsu: já que está tudo limpo, mantenha desta forma. Reduza a complexidade para facilitar a manutenção. • Shitsuke: use e siga procedimentos padronizados.
  • 72. Padrões • Tornam possível operar reflexivamente e mover informações sem o desperdício de fazer conversões. • Uma infraestrutura padronizada com uma arquitetura comum reduz a complexidade e consequentemente o custo.
  • 73. Revisões de código • Usá-las para reforçar padrões ou encontrar defeitos é um desperdício. • O código de um desenvolvedor menos experiente pode ser revisado para se conseguir simplicidade, encontrar repetições e práticas de orientação à objetos. • Trabalho em par: cria sinergia
  • 74. Sistemas a prova de erros • Equívocos não são culpa daquele que os cometeu, mas do sistema que permitiu que fossem cometidos. • Em software, tudo o que puder dar errado, eventualmente dará errado.
  • 75. Test-Driven Development • A meta do desenvolvimento de software Lean é prevenir que defeitos entrem no código e a forma para que isto aconteça é utilizar TDD.
  • 76. Test-Driven Development • Testes unitários: escrever testes antes geralmente simplifica o design pois gera código que é desacoplado. • Testes de aceitação: identificam a intenção do negócio. Ajudam a pensar no que envolve o trabalho do cliente e como isto será suportado por software. • Testes exploratórios: especialistas testam quais são as barreiras do software além de procurar resultados inesperados. • Testes de propriedade: incluem requisitos não-funcionais como tempo de resposta, robustez, escalabilidade, etc.
  • 78. Aonde você quer chegar? • Organizações que desenvolveram a capacidade de aprender e se adaptar são aquelas que sobreviverão. • Devem ser centradas em pessoas. Removê-las significa que o processo não será mais capaz de se modificar ou se adaptar.
  • 79. Em que você realmente acredita sobre as pessoas?
  • 80. Você deve acreditar que não há melhor forma para atacar os problemas do que treinar as pessoas e fornecer ferramentas para que elas mesmas os resolvam e melhorem seu processo.
  • 81. Questione • Todo trabalhador, a qualquer momento, deve questionar como é seu processo de trabalho e deve ser encorajado a usar técnicas para testar novas ideias e implementar aquelas que funcionarem.
  • 82. Quais são as medidas? • Tempo de ciclo: quão rápido você atende o cliente de forma repetida e confiável? • Retorno financeiro: seu software está trazendo retorno sobre o investimento do cliente? • Satisfação: seu cliente recomendaria seu produto?
  • 83. Referência Título: Implementing Lean Software Development Subtítulo: From Concept to Cash Autores: Tom e Mary Poppendieck ISBN: 9780321437389

Notas do Editor

  1. Prefácio de Jeff Sutherland Criador do Scrum CTO da PatientKeeper
  2. Vendas cresceram muito, então montaram uma fábrica de automóveis
  3. Período pós-guerra
  4. Levaram anos fazendo experimentos para criar o Toyota Production System Um sistema que visa a eliminação total do desperdício
  5. As pedras são defeitos que surgem no produto sem serem detectados. São desperdício escondido que custa muito dinheiro. Você só fica sabendo quando abaixa o nível de inventário.
  6. Totalmente contrário à sabedoria da época Enorme resistência Único modelo industrial que efetivamente gerencia complexidade
  7. 1990 - The machine that changed the world Novo nome para JIT ou TPS: “Lean Production”
  8. Eles compram jogos, editores de texto ou algo que gerencie o processo de seu negócio
  9. Porém quando entendemos os princípios, é interessante copiar as práticas de outras empresas e modificá-las para atender suas necessidades.
  10. Determinística: cria a definição do produto, e depois realiza aquela definição Empírica: cria um conceito de produto e depois trabalha com feedback interpretando o conceito
  11. Nada substitui o valor que o cliente recebe ao começar a utilizar o software. Clientes não sabem o que querem. Quando vêem o software em ação sua ideia irá mudar.
  12. Para que uma empresa faça isto muita disciplina é exigida.
  13. Caso da Sears (3 semanas) x L.L. Bean (24 horas) Fedex: overnight Dell: assemble-to-order
  14. Não existe processo que não pode ser melhorado. Acompanhe uma pessoa fazendo seu trabalho e ideias de melhoria surgirão. Este processo infinito de melhoria contínua deve existir em toda organização que desenvolve software.
  15. The Kano Model
  16. De cara é necessário satisfazer as necessidades básicas do cliente Aumentar a performance traz resultados lineares Para satisfazer de forma exponencial devemos atender necessidades não solicitadas, surpreendendo e encantando os clientes.
  17. Scott Cook: “Marketing Malpractice: the cause and the cure” Harward Business Review, 2005
  18. O custo da complexidade não é linear. É exponencial!
  19. O objetivo é manter um fluxo rápido. A única forma de se atingir isto é trabalhar em pequenos lotes ou iterações.
  20. Você pode tentar documentar todas as decisões mas geralmente ninguém olha para aquela documentação novamente
  21. Se perde-se 50% a cada transferência, então: Sobraria 25% após 2 handoffs 12% após 3 handoffs 6% após 4 handoffs 3% após 5 handoffs
  22. Se perde-se 50% a cada transferência, então: Sobraria 25% após 2 handoffs 12% após 3 handoffs 6% após 4 handoffs 3% após 5 handoffs
  23. Soluções: - Deixe alguém responsável pelas manutenções durante a iteração (Batman) - Trabalhe 2 horas pela manhã nos problemas encontrados no que fizeram no dia anterior e depois comece a trabalhar nas tarefas do dia - Faça uma triagem nas requisições do suporte para saber o que é urgente
  24. Esperar alguém que está trabalhando em outras áreas é uma grande causa de desperdício * Por isto as reuniões de planejamento não devem ir tão além do que se pode atingir naquela iteração
  25. Solução: testes unitários São o design do código. Escrevê-los antes do código leva a um código mais simples, fácil de entender e mais testável.
  26. Cadeias de valor expõe desperdícios através de atrasos no fluxo Clientes não se importam sobre outras solicitações ou o quão ocupado você está. Eles querem saber quanto tempo vai demorar para você atender seu pedido.
  27. Este percentual é chamado de eficiência do ciclo.
  28. Quando todos estão trabalhando em sua capacidade total as tarefas precisam ficar presas em filas. Existe um mito de que todos devem estar 100% ocupados, mas isto acaba diminuindo a eficiência.
  29. Se você trabalha assiduamente para eliminar desperdício, vai aumentar o percentual de tempo adicionando valor durante o processo. Então vai entregar mais rápido, provavelmente muito mais rápido.
  30. A melhor forma de se medir a qualidade de um processo de software é medir a média do tempo de ciclo de ponta a ponta do processo.
  31. Se você trabalha com pequenos lotes e se concentra no fluxo, atingirá boa utilização. Porém a utilização nunca deve ser seu objetivo primário.
  32. Pareto: dê uma nota de 1 a 5 (sendo 1 - menos importante ... 5 - crítico) livre-se de todas que não são 4 nem 5 não se preocupe, se forem importantes voltarão para a lista.
  33. Se algo é difícil faça com mais frequência, e você vai se sair muito melhor naquilo.
  34. Se você implementar todos os princípios exceto um - respeito pelas pessoas - você vai colher apenas uma parte do que Lean pode oferecer. Se implementar apenas este princípio - respeito pelas pessoas - você permitirá que elas descubram e apliquem os princípios restantes.
  35. O ponto central de uma gestão inovadora é invisível para muitos times tentando copiar as ideias inovadoras. Muitas empresas tentam copiar as ideias, mas geralmente esquecem o ponto central que são as pessoas.
  36. Um princípio básico da Toyota é que o trabalho em equipe é essencial mas sempre deve haver alguém responsável.
  37. Econômica: o máximo de resultados com o mínimo de recursos Rio: manter o fluxo, ou seja, manter-se no negócio e prover empregos a longo prazo. O indivíduo se compromete esperando que a empresa desenvolva o potencial de cada um ao máximo. Comprometimento é uma via de duas mãos: as pessoas se comprometem com uma empresa se sentirem que a empresa se compromete com elas.
  38. Recompensas em dinheiro podem motivar por um período, mas não são sustentáveis. Quando uma pessoa recebe um salário adequado, a motivação vem de coisas como:
  39. São apresentadas algumas lições desta empresa. Ryan Martens, CTO da Rally
  40. A grossura da documentação é inversamente proporcional à sua utilidade em transmitir conhecimento. Não devemos pensar no processo de escrita, mas nas pessoas que usarão aquilo que escrevemos.
  41. A melhor maneira de se criar conhecimento é resolver os problemas e impedir que aconteçam novamente.
  42. É o DNA do Toyota Production System. Cada trabalhador é instruído com algumas ferramentas para resolução de problemas.
  43. Só de entrar na sala de desenvolvimento já se percebe o quanto disciplinada é a equipe. Se a sala é bagunçada, o time provavelmente não se preocupa muito com isto, e com certeza o código também será bagunçado. Se uma organização é rápida, as pessoas sabem onde encontrar o que precisam imediatamente porque existe um lugar pra tudo e tudo está em seu lugar.
  44. Aplique o conceito dos 5 S’s na sala de desenvolvimento. Já que software é o reflexo da empresa que o desenvolveu, aplique os conceitos no código também.
  45. Aplique o conceito dos 5 S’s na sala de desenvolvimento. Já que software é o reflexo da empresa que o desenvolveu, aplique os conceitos no código também.
  46. Em Lean padrões são vistos como a melhor maneira de se fazer um trabalho, porém, como sempre há uma forma melhor de se fazer as coisas, todos são encorajados a desafiá-los.
  47. Trabalho em par: duas pessoas frequentemente entregarão mais código testado e livre de defeitos do que cada um produziria separadamente. Open Source: diz-se que se você realmente quer aprender a programar tente contribuir com um projeto open source pois terá muito feedback.
  48. Como reduzir equívocos no desenvolvimento: automatização Automatize principalmente tarefas de rotina. Tarefas esporádicas também são candidatas à automatização.
  49. A questão que deve se responder antes de embarcar em uma iniciativa Lean é: * Você acha que documentação que todos seguem é o caminho para a excelência? * Você acha que as pessoas devem decidir o que fazer ou os gerentes devem sem os responsáveis?
  50. A questão que deve se responder antes de embarcar em uma iniciativa Lean é: * Você acha que documentação que todos seguem é o caminho para a excelência? * Você acha que as pessoas devem decidir o que fazer ou os gerentes devem sem os responsáveis?