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.

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. História

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. Just-in-Time

9. Just-in-Time

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. Princípios

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?

27. Modelo de Kano

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.

31. Desperdício

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.

45. Mapeando cadeias de valor

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. Mapeando cadeias de 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.

49. Velocidade

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. Variação e Utilização

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.

55. Pessoas

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

63. Conhecimento

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

67. Qualidade

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.

77. A jornada

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