Apresentação sobre como é possível aprender com o modelo Toyota de desenvolvimento de produtos e aplicar as suas idéias no desenvolvimento de Software.

1. Pessoas ou processos? Entenda o que a Toyota, os processos e as pessoas tem haver com o desenvolvimento de software

2. Quem sou eu? Maurício Linhares BOT da lista de discussão do PBJUG Desenvolvedor da CodeVader Instrutor da LinuxFi Moderador do GUJ

3. Eu não posso ter pessoas E processos? Se você valoriza as pessoas, os processos tornam-se menos importantes, eles tornam-se mais maleáveis, eles não pertencem aos chefes, mas as pessoas;

4. Eu não posso ter pessoas E processos? Se você valoriza os processos, eles tornam-se mais importantes do que as pessoas que os executam (afinal, o processo já diz como as coisas devem ser), o trabalho das pessoas é apenas executar;

5. O que nós vemos no dia-a-dia? Processos normalmente são mais importantes do que as pessoas

6. Mas em alguns lugares, as pessoas são mais importantes do que os processos

7. Onde?

8. Como tudo começou? Japão, 1940; Povo pobre, mercado pequeno; Produção em massa era impossível, o mercado não seria capaz de absorver os produtos;

9. Como produzir carros em pequenas quantidades com o custo de carros produzidos em massa?

10. Elimine o desperdício! Essa foi a solução encontrada por TaiichiOhno, pai do Toyota Production System, simples, não?

11. Simples, até ele dizer pra você o que é desperdício Qualquer coisa que não gere valor para o cliente, é desperdício

12. Exemplos de desperdício segundo Ohno Estoque; Transporte; Movimento; Espera; Produzir algo antes da hora que ele é necessário; Serviços extras; Defeitos;

13. Como funciona uma indústria de carros da velha guarda? Vários departamentos diferentes produzem pilhas de produtos intermediários; Estes produtos ficam estocados nas fábricas até que a linha de produção precise deles;

14. Como funciona uma indústria de carros da velha guarda? Quando a linha de produção precisa de alguma coisa, vai ao estoque e pega os produtos que são necessários; Após reunir as partes, eles começam a produção, se houver alguma falha em alguma das partes e ela só for descoberta agora, tudo o que está no estoque vai pro lixo;

15. E como a Toyota faz? Só é produzido o que é necessário; Não existem diversas equipes para se produzir um carro, apenas uma “célula” cuida de fazer todo o trabalho; Se um defeito é encontrado, toda a linha de produção pára até que o defeito seja corrigido;

16. Onde entram as pessoas? Agora não é mais responsabilidade do processo garantir que as coisas funcionem, é das pessoas, pois agora todos controlam a linha de produção e tem o dever de mandar parar tudo se houver algum problema;

17. Mas o que é que isso tem haver com sofware? Você já teve que escrever “componentes” para uso futuro? Já escreveu documentos que ninguém leu? Já encontrou defeitos que impediam o uso de aplicações em produção?

18. Mas o que é que isso tem haver com software? Já adicionou uma funcionalidade que ninguém havia pedido? Já deixou o cliente esperando por uma ferramenta que nunca chega?

19. Toyota Production System – LeanDevelopment A prática do Lean Software development (e das metodologias ágeis no geral) tem como base os avanços da gestão industrial capitaneada pela Toyota e outras montadoras do Oriente;

20. Os 7 tipos de desperdício

21. Trabalho feito “pela metade” Sabe aquele seu framework “caseiro”, ele mesmo; Qualquer coisa que você faça que não vai ser utilizado imediatamente; No dia que você realmente precisar, será que ele atende as necessidades?

22. Processos extras Sabe aquele diagrama UML que ninguém olhou? Pois é, ficou obsoleto; Já pensou em quem está lendo esses documentos que você anda fazendo? Traças letradas essas viu. Cada folha de papel que você usa, é uma árvore a menos no mundo 

23. Funcionalidades extras “Olha, agora o menu aparece e desaparece!” Cada linha de código a mais é uma linha de código que precisa ser testada, compilada e documentada; Usuário + Opções = Problema

24. Troca de tarefas “Olha, você tem 8 horas hoje, então são 16 bugs para corrigir, um a cada 30 minutos, agora começa que os primeiros 30 minutos já tão contando”; Desenvolvimento de software é uma tarefa que se faz com o cérebro, quem trabalha com os dedos é digitador;

25. Uma pequena pausa para um clássico Peopleware, DeMarco e Lister; Desenvolvedores só produzem de verdade quando eles entram no estado de “flow”; Você só entra em “flow” após algum tempo de trabalho concentrado e initerrupto;

26. Espera “Seguinte, já tá quase pronto, mas eu só posso colocar em produção depois que o financeiro liberar a nota e o gerente terminar a planilha de horas”; Quanto o seu cliente perde de dinheiro a cada segundo sem utilizar a aplicação?

27. Movimento “Ei, você sabe se os testes passaram?” “Náo, vai ali e pergunta pra equipe de testes” “O analista já tá com o documento de requisitos?” “Não, o arquiteto ainda tá validando ele”

28. Movimento “Como assim eu vou ter que ir pro Amazonas pra poder fazer uma visita ao cliente?” “Será que essa p&%%# só atende pelo callcenter?”

29. Defeitos “Errrrrr... Cê sabe aquela piada do gato que subiu no telhado?” “Sei.” “Sabe o banco de dados?” “Fala.” “Ele subiu no telhado.”

30. Mapeando o fluxo de valor Ou, como descobrir o quanto de dinheiro você está jogando no lixo antes de ir a falência.

31. A vida de uma latinha de refrigerante

32. Estatísticas Tempo total: 319 dias; Tempo executando alguma coisa de valor: 3 horas

33. Fluxo de valor em uma fábrica de software comum

34. Fluxo de valor no desenvolvimento ágil

35. Amplificando o aprendizado Porque desenvolver software ainda é explicar ao computador como o mundo funciona

36. Feedback é tudo Equipes ágeis trabalham em iterações curtas, recebendo feedback dos clientes o tempo todo e aprendendo com os especialistas do problema; Quanto menos tempo você perder fazendo a coisa do jeito errado, melhor;

37. Iterações e o aprendizado contínuo O desenvolvimento, assim como o aprendizado, funciona melhor em pequenas doses; É bem mais fácil aprender um pouco, aplicar e aprender mais um pouco do que “aprender tudo” e só depois aplicar; Se você dá passos curtos, a chance de cair é menor;

38. Decida o mais tarde possível Por que tomar a decisão agora se ela só precisa ser tomada amanhã?

39. Decidir ou não decidir, eis a questão Quanto mais cedo você decide, menos informações você tem; Maiores são os problemas causados por um erro nos seus cálculos; Mais engessada fica a estrutura da aplicação;

40. Minimizando ações irreversíveis As fontes de alimentação das impressoras da HP são específicas para cada país; As impressoras são todas iguais; Então impressoras não precisam ter uma fonte nelas;

41. Ao deixar a decisão para mais tarde... Você pode pensar e aplicar diversas opções; Pode aprender mais sobre o problema em questão; Você tem mais tempo para mudar o caminho a ser seguido;

42. Entregue o mais rápido possível Software com a metade das funcionalidades hoje é melhor do que software com metade das funcionalidades erradas amanhã

43. Pull systems Kanban e os estoques infinitos sem estoque

44. Pull systems e desenvolvimento de software O cliente define as funcionalidades e as prioridades para o ciclo atual; A equipe se reúne, diariamente, comenta o que já foi feito, o que está por fazer e os problemas encontrados; Ao fim da iteração, avalia-se se tudo foi realmente feito;

45. Gerencia pela visibilidade

46. O preço do atraso Quando o cliente receber o sistema, quanto ele vai deixar de gastar? Ele poderia ter recebido antes? Quanto seria a economia de ter começado a usar antes? Aprenda a fazer escolhas, ou lança, ou implementa todas as funcionalidades ou aumenta o preço, não dá pra ter tudo ao mesmo tempo;

47. O manifesto ágil Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

48. Qual a importância de tudo isso? Nós somos novos demais, temos que aprender com quem já administra a anos e já desenvolveu práticas melhores do que as nossas; Não somos tão diferentes ao ponto de não podermos nos aproveitar do que eles já descobriram;

49. Questões?

50. Referências DeMarco, Tom; Lister, Tim. Peopleware: ProductiveProjectsandTeams. DorsetHousePublishing. Poppendieck, Tom & Mary. Lean Software Development: AnAgile Toolkit.Addison-Wesley. DeMarco, Tom. Slack: GettingPastBurnout, BusyworkandtheMythof Total Efficiency. Broadway.