Carregado porLuiz Faias Junior
Implementing lean software development
O documento aborda a implementação do desenvolvimento de software enxuto, enfatizando a eliminação de desperdícios e a entrega rápida de valor ao cliente. Apresenta sete princípios fundamentais, como construir com qualidade embutida e respeitar as pessoas, além de discutir a importância da colaboração em equipe. O texto conclui que a adaptação contínua e o aprendizado são essenciais para o sucesso de uma organização.
Mais conteúdo relacionado
Semelhante a Implementing lean software development
Implementing lean software development
- 1. Implementing Lean Software Development From Concept to Cash
- 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.
- 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
- 8.
- 9.
- 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
- 12.
- 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ípiosdo desenvolvimento Lean
- 18. #1 - Eliminedesperdí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 - Construacom 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 - Crieconhecimento • 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 - Adiecompromissos • 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 - Entreguerapidamente • 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 - Respeiteas 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 - Otimizeo 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.
- 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.
- 28. Entendendo profundamente oconsumidor • “Ó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.
- 31.
- 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 acomplexidade • 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íciosem 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 - Trabalhoparcialmente 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 - FuncionalidadesExtras • 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 - Trocade 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 - Trocade 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.
- 45. Mapeando cadeias devalor
- 46. Mapeando cadeias devalor • 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. Mapeando cadeias devalor
- 48. Mapeando cadeias devalor • 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.
- 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.
- 52.
- 53. Como reduzir otempo 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 otempo 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.
- 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 programasfalham? • 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 motivadorescorretos • Realizações • Crescimento • Controle sobre seu trabalho • Reconhecimento • Ambiente de trabalho agradável
- 63.
- 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 é oseu 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íficade 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.
- 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’sem 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 provade 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.
- 77.
- 78. Aonde você querchegar? • 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 acreditarque 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 asmedidas? • 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 LeanSoftware Development Subtítulo: From Concept to Cash Autores: Tom e Mary Poppendieck ISBN: 9780321437389
Notas do Editor
- #3 Prefácio de Jeff Sutherland Criador do Scrum CTO da PatientKeeper
- #6 Vendas cresceram muito, então montaram uma fábrica de automóveis
- #7 Período pós-guerra
- #8 Levaram anos fazendo experimentos para criar o Toyota Production System Um sistema que visa a eliminação total do desperdício
- #9 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.
- #10 Totalmente contrário à sabedoria da época Enorme resistência Único modelo industrial que efetivamente gerencia complexidade
- #11 1990 - The machine that changed the world Novo nome para JIT ou TPS: “Lean Production”
- #12 Eles compram jogos, editores de texto ou algo que gerencie o processo de seu negócio
- #15 Porém quando entendemos os princípios, é interessante copiar as práticas de outras empresas e modificá-las para atender suas necessidades.
- #16 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
- #19 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.
- #20 Para que uma empresa faça isto muita disciplina é exigida.
- #23 Caso da Sears (3 semanas) x L.L. Bean (24 horas) Fedex: overnight Dell: assemble-to-order
- #24 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.
- #27 The Kano Model
- #28 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.
- #30 Scott Cook: “Marketing Malpractice: the cause and the cure” Harward Business Review, 2005
- #34 O custo da complexidade não é linear. É exponencial!
- #38 O objetivo é manter um fluxo rápido. A única forma de se atingir isto é trabalhar em pequenos lotes ou iterações.
- #40 Você pode tentar documentar todas as decisões mas geralmente ninguém olha para aquela documentação novamente
- #41 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
- #42 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
- #43 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
- #44 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
- #45 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.
- #46 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.
- #47 Este percentual é chamado de eficiência do ciclo.
- #48 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.
- #51 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.
- #52 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.
- #53 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.
- #54 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.
- #55 Se algo é difícil faça com mais frequência, e você vai se sair muito melhor naquilo.
- #57 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.
- #59 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.
- #61 Um princípio básico da Toyota é que o trabalho em equipe é essencial mas sempre deve haver alguém responsável.
- #62 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.
- #63 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:
- #65 São apresentadas algumas lições desta empresa. Ryan Martens, CTO da Rally
- #66 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.
- #67 A melhor maneira de se criar conhecimento é resolver os problemas e impedir que aconteçam novamente.
- #68 É o DNA do Toyota Production System. Cada trabalhador é instruído com algumas ferramentas para resolução de problemas.
- #71 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.
- #72 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.
- #73 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.
- #74 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.
- #75 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.
- #76 Como reduzir equívocos no desenvolvimento: automatização Automatize principalmente tarefas de rotina. Tarefas esporádicas também são candidatas à automatização.
- #81 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?
- #82 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?