Implementing lean software development

3,170 views

Published on

Palestra realizada em 17/02/2010 baseada no livro "Implementing Lean Software Development: From Concept to Cash" de Mary e Tom Poppendieck.

Esta apresentação faz parte do Bluesoft Labs.

Published in: Technology, Business
3 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
3,170
On SlideShare
0
From Embeds
0
Number of Embeds
731
Actions
Shares
0
Downloads
0
Comments
3
Likes
6
Embeds 0
No embeds

No notes for slide

  • Prefácio de Jeff Sutherland

    Criador do Scrum

    CTO da PatientKeeper


  • Vendas cresceram muito, então montaram uma fábrica de automóveis
  • Período pós-guerra
  • Levaram anos fazendo experimentos para criar o Toyota Production System

    Um sistema que visa a eliminação total do desperdício
  • 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.
  • Totalmente contrário à sabedoria da época

    Enorme resistência

    Único modelo industrial que efetivamente gerencia complexidade
  • 1990 - The machine that changed the world

    Novo nome para JIT ou TPS: “Lean Production”
  • Eles compram jogos, editores de texto ou algo que gerencie o processo de seu negócio


  • Porém quando entendemos os princípios, é interessante copiar as práticas de outras empresas e modificá-las para atender suas necessidades.
  • 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


  • 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.
  • Para que uma empresa faça isto muita disciplina é exigida.


  • Caso da Sears (3 semanas) x L.L. Bean (24 horas)

    Fedex: overnight

    Dell: assemble-to-order
  • 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.


  • The Kano Model
  • 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.

  • Scott Cook: “Marketing Malpractice: the cause and the cure”

    Harward Business Review, 2005



  • O custo da complexidade não é linear. É exponencial!



  • O objetivo é manter um fluxo rápido.

    A única forma de se atingir isto é trabalhar em pequenos lotes ou iterações.

  • Você pode tentar documentar todas as decisões mas geralmente ninguém olha para aquela documentação novamente
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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.
  • Este percentual é chamado de eficiência do ciclo.
  • 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.


  • 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.
  • 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.
  • 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.
  • 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.
  • Se algo é difícil faça com mais frequência, e você vai se sair muito melhor naquilo.

  • 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.

  • 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.

  • Um princípio básico da Toyota é que o trabalho em equipe é essencial mas sempre deve haver alguém responsável.
  • 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.
  • 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:

  • São apresentadas algumas lições desta empresa.

    Ryan Martens, CTO da Rally
  • 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.
  • A melhor maneira de se criar conhecimento é resolver os problemas e impedir que aconteçam novamente.
  • É o DNA do Toyota Production System.

    Cada trabalhador é instruído com algumas ferramentas para resolução de problemas.


  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Como reduzir equívocos no desenvolvimento: automatização

    Automatize principalmente tarefas de rotina. Tarefas esporádicas também são candidatas à automatização.




  • 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?
  • 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?



  • Implementing lean software development

    1. 1. Implementing Lean Software Development From Concept to Cash
    2. 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.
    3. 3. História
    4. 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. 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. 6. História • 1945 - Não era possível aplicar economia em escala (produção em massa) • Materiais escassos • Poucos pedidos • Muita Variedade
    7. 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
    8. 8. Just-in-Time
    9. 9. Just-in-Time
    10. 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. 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
    12. 12. Princípios
    13. 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. 14. Princípios • Copiar práticas sem entender seus princípios traz resultados medíocres.
    15. 15. Desenvolvimento • É o processo de transformar ideias em produtos. • Existem duas escolas de pensamento: • Determinística • Empírica
    16. 16. Desenvolvimento • Acreditamos que todo processo de desenvolvimento deve ser empírico pois este provê a melhor maneira de se adaptar à mudanças.
    17. 17. Os 7 princípios do desenvolvimento Lean
    18. 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. 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. 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. 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. 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. 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. 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. 25. Valor
    26. 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?
    27. 27. Modelo de Kano
    28. 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. 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. 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.
    31. 31. Desperdício
    32. 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. 33. Complexidade • Empresas inteligentes têm como prioridade manter o código simples, limpo e pequeno.
    34. 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. 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. 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. 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. 38. #2 - Funcionalidades Extras • Adicionar algo que o cliente não solicitou é o pior dos 7 desperdícios.
    39. 39. #3 - Reaprendizagem • Redescobrir algo que já se sabia e foi esquecido é talvez a melhor definição de "retrabalho" no desenvolvimento
    40. 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. 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. 42. #5 - Troca de tarefas (Switching)
    43. 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. 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.
    45. 45. Mapeando cadeias de valor
    46. 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?
    47. 47. Mapeando cadeias de valor
    48. 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.
    49. 49. Velocidade
    50. 50. Velocidade • É a ausência de desperdícios.
    51. 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.
    52. 52. Variação e Utilização
    53. 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. 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.
    55. 55. Pessoas
    56. 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. 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. 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. 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. 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. 61. Incentivos • Existem dois tipos de companhias (de Geus): • Econômica • “Rio”
    62. 62. Encontre os motivadores corretos • Realizações • Crescimento • Controle sobre seu trabalho • Reconhecimento • Ambiente de trabalho agradável
    63. 63. Conhecimento
    64. 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. 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. 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
    67. 67. Qualidade
    68. 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. 69. Disciplina • Não é possível mover-se com velocidade sem construir um produto com qualidade, e isto requer muita disciplina.
    70. 70. Os 5 S’s • Seiri (Selecione) • Seiton (Sistematize) • Seiso (Lustre) • Seiketsu (Padronize) • Shitsuke (Sustente)
    71. 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. 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. 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. 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. 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. 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.
    77. 77. A jornada
    78. 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. 79. Em que você realmente acredita sobre as pessoas?
    80. 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. 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. 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. 83. Referência Título: Implementing Lean Software Development Subtítulo: From Concept to Cash Autores: Tom e Mary Poppendieck ISBN: 9780321437389

    ×