O documento discute a relação entre pessoas e processos no desenvolvimento de software, utilizando o sistema Toyota de produção como referência para eliminar desperdícios e focar nas necessidades do cliente. Aborda também a importância das metodologias ágeis e do aprendizado contínuo, enfatizando a relevância de decisões tardias e entregas rápidas com funções prioritárias. O texto conclui que a aplicação de práticas de gestão industrial pode melhorar significativamente o 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 LinharesBOT da lista de discussão do PBJUGDesenvolvedor da CodeVaderInstrutor da LinuxFiModerador 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ícioQualquer coisa que não gere valor para o cliente, é desperdício

12. Exemplos de desperdício segundo OhnoEstoque;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 – LeanDevelopmentA 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 extrasSabe 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ássicoPeopleware, 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 valorOu, 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ísticasTempo 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 aprendizadoPorque desenvolver software ainda é explicar ao computador como o mundo funciona

36. Feedback é tudoEquipes á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ínuoO 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ívelPor que tomar a decisão agora se ela só precisa ser tomada amanhã?

39. Decidir ou não decidir, eis a questãoQuanto 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íveisAs 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ívelSoftware com a metade das funcionalidades hoje é melhor do que software com metade das funcionalidades erradas amanhã

43. Pull systemsKanban e os estoques infinitos sem estoque

44. Pull systems e desenvolvimento de softwareO 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 atrasoQuando 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 ágilIndividuals and interactions over processes and toolsWorking 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ênciasDeMarco, Tom; Lister, Tim. Peopleware: ProductiveProjectsandTeams. DorsetHousePublishing.Poppendieck, Tom & Mary. Lean Software Development: AnAgile Toolkit.Addison-Wesley.DeMarco, Tom. Slack: GettingPastBurnout, BusyworkandtheMythof Total Efficiency. Broadway.