Pessoas Ou Processos

930 views
820 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
930
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pessoas Ou Processos

  1. 1. Pessoas ou processos?<br />Entenda o que a Toyota, os processos e as pessoas tem haver com o desenvolvimento de software<br />
  2. 2. Quem sou eu?<br />Maurício Linhares<br />BOT da lista de discussão do PBJUG<br />Desenvolvedor da CodeVader<br />Instrutor da LinuxFi<br />Moderador do GUJ<br />
  3. 3. Eu não posso ter pessoas E processos?<br />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;<br />
  4. 4. Eu não posso ter pessoas E processos?<br />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;<br />
  5. 5. O que nós vemos no dia-a-dia?<br />Processos normalmente são mais importantes do que as pessoas<br />
  6. 6. Mas em alguns lugares, as pessoas são mais importantes do que os processos<br />
  7. 7. Onde?<br />
  8. 8. Como tudo começou?<br />Japão, 1940;<br />Povo pobre, mercado pequeno;<br />Produção em massa era impossível, o mercado não seria capaz de absorver os produtos;<br />
  9. 9. Como produzir carros em pequenas quantidades com o custo de carros produzidos em massa?<br />
  10. 10. Elimine o desperdício!<br />Essa foi a solução encontrada por TaiichiOhno, pai do Toyota Production System, simples, não?<br />
  11. 11. Simples, até ele dizer pra você o que é desperdício<br />Qualquer coisa que não gere valor para o cliente, é desperdício<br />
  12. 12. Exemplos de desperdício segundo Ohno<br />Estoque;<br />Transporte;<br />Movimento;<br />Espera;<br />Produzir algo antes da hora que ele é necessário;<br />Serviços extras;<br />Defeitos;<br />
  13. 13. Como funciona uma indústria de carros da velha guarda?<br />Vários departamentos diferentes produzem pilhas de produtos intermediários;<br />Estes produtos ficam estocados nas fábricas até que a linha de produção precise deles;<br />
  14. 14. Como funciona uma indústria de carros da velha guarda?<br />Quando a linha de produção precisa de alguma coisa, vai ao estoque e pega os produtos que são necessários;<br />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;<br />
  15. 15. E como a Toyota faz?<br />Só é produzido o que é necessário;<br />Não existem diversas equipes para se produzir um carro, apenas uma “célula” cuida de fazer todo o trabalho;<br />Se um defeito é encontrado, toda a linha de produção pára até que o defeito seja corrigido;<br />
  16. 16. Onde entram as pessoas?<br />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;<br />
  17. 17. Mas o que é que isso tem haver com sofware?<br />Você já teve que escrever “componentes” para uso futuro?<br />Já escreveu documentos que ninguém leu?<br />Já encontrou defeitos que impediam o uso de aplicações em produção?<br />
  18. 18. Mas o que é que isso tem haver com software?<br />Já adicionou uma funcionalidade que ninguém havia pedido?<br />Já deixou o cliente esperando por uma ferramenta que nunca chega?<br />
  19. 19. Toyota Production System – LeanDevelopment<br />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;<br />
  20. 20. Os 7 tipos de desperdício<br />
  21. 21. Trabalho feito “pela metade”<br />Sabe aquele seu framework “caseiro”, ele mesmo;<br />Qualquer coisa que você faça que não vai ser utilizado imediatamente;<br />No dia que você realmente precisar, será que ele atende as necessidades?<br />
  22. 22. Processos extras<br />Sabe aquele diagrama UML que ninguém olhou? Pois é, ficou obsoleto;<br />Já pensou em quem está lendo esses documentos que você anda fazendo? Traças letradas essas viu.<br />Cada folha de papel que você usa, é uma árvore a menos no mundo <br />
  23. 23. Funcionalidades extras<br />“Olha, agora o menu aparece e desaparece!”<br />Cada linha de código a mais é uma linha de código que precisa ser testada, compilada e documentada;<br />Usuário + Opções = Problema<br />
  24. 24. Troca de tarefas<br />“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”;<br />Desenvolvimento de software é uma tarefa que se faz com o cérebro, quem trabalha com os dedos é digitador;<br />
  25. 25. Uma pequena pausa para um clássico<br />Peopleware, DeMarco e Lister;<br />Desenvolvedores só produzem de verdade quando eles entram no estado de “flow”;<br />Você só entra em “flow” após algum tempo de trabalho concentrado e initerrupto;<br />
  26. 26. Espera<br />“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”;<br />Quanto o seu cliente perde de dinheiro a cada segundo sem utilizar a aplicação?<br />
  27. 27. Movimento<br />“Ei, você sabe se os testes passaram?”<br />“Náo, vai ali e pergunta pra equipe de testes”<br />“O analista já tá com o documento de requisitos?”<br />“Não, o arquiteto ainda tá validando ele”<br />
  28. 28. Movimento<br />“Como assim eu vou ter que ir pro Amazonas pra poder fazer uma visita ao cliente?”<br />“Será que essa p&%%# só atende pelo callcenter?”<br />
  29. 29. Defeitos<br />“Errrrrr... Cê sabe aquela piada do gato que subiu no telhado?”<br />“Sei.”<br />“Sabe o banco de dados?”<br />“Fala.”<br />“Ele subiu no telhado.”<br />
  30. 30. Mapeando o fluxo de valor<br />Ou, como descobrir o quanto de dinheiro você está jogando no lixo antes de ir a falência.<br />
  31. 31. A vida de uma latinha de refrigerante<br />
  32. 32. Estatísticas<br />Tempo total: 319 dias;<br />Tempo executando alguma coisa de valor: 3 horas<br />
  33. 33. Fluxo de valor em uma fábrica de software comum<br />
  34. 34. Fluxo de valor no desenvolvimento ágil<br />
  35. 35. Amplificando o aprendizado<br />Porque desenvolver software ainda é explicar ao computador como o mundo funciona<br />
  36. 36. Feedback é tudo<br />Equipes ágeis trabalham em iterações curtas, recebendo feedback dos clientes o tempo todo e aprendendo com os especialistas do problema;<br />Quanto menos tempo você perder fazendo a coisa do jeito errado, melhor;<br />
  37. 37. Iterações e o aprendizado contínuo<br />O desenvolvimento, assim como o aprendizado, funciona melhor em pequenas doses;<br />É bem mais fácil aprender um pouco, aplicar e aprender mais um pouco do que “aprender tudo” e só depois aplicar;<br />Se você dá passos curtos, a chance de cair é menor;<br />
  38. 38. Decida o mais tarde possível<br />Por que tomar a decisão agora se ela só precisa ser tomada amanhã?<br />
  39. 39. Decidir ou não decidir, eis a questão<br />Quanto mais cedo você decide, menos informações você tem;<br />Maiores são os problemas causados por um erro nos seus cálculos;<br />Mais engessada fica a estrutura da aplicação;<br />
  40. 40. Minimizando ações irreversíveis<br />As fontes de alimentação das impressoras da HP são específicas para cada país;<br />As impressoras são todas iguais;<br />Então impressoras não precisam ter uma fonte nelas;<br />
  41. 41. Ao deixar a decisão para mais tarde...<br />Você pode pensar e aplicar diversas opções;<br />Pode aprender mais sobre o problema em questão;<br />Você tem mais tempo para mudar o caminho a ser seguido;<br />
  42. 42. Entregue o mais rápido possível<br />Software com a metade das funcionalidades hoje é melhor do que software com metade das funcionalidades erradas amanhã<br />
  43. 43. Pull systems<br />Kanban e os estoques infinitos sem estoque<br />
  44. 44. Pull systems e desenvolvimento de software<br />O cliente define as funcionalidades e as prioridades para o ciclo atual;<br />A equipe se reúne, diariamente, comenta o que já foi feito, o que está por fazer e os problemas encontrados;<br />Ao fim da iteração, avalia-se se tudo foi realmente feito;<br />
  45. 45. Gerencia pela visibilidade<br />
  46. 46. O preço do atraso<br />Quando o cliente receber o sistema, quanto ele vai deixar de gastar?<br />Ele poderia ter recebido antes? Quanto seria a economia de ter começado a usar antes?<br />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;<br />
  47. 47. O manifesto ágil<br />Individuals and interactions over processes and tools<br />Working software over comprehensive documentation <br />Customer collaboration over contract negotiation <br />Responding to change over following a plan  <br />
  48. 48. Qual a importância de tudo isso?<br />Nós somos novos demais, temos que aprender com quem já administra a anos e já desenvolveu práticas melhores do que as nossas;<br />Não somos tão diferentes ao ponto de não podermos nos aproveitar do que eles já descobriram;<br />
  49. 49. Questões?<br />
  50. 50. Referências<br />DeMarco, Tom; Lister, Tim. Peopleware: ProductiveProjectsandTeams. DorsetHousePublishing.<br />Poppendieck, Tom & Mary. Lean Software Development: AnAgile Toolkit.Addison-Wesley.<br />DeMarco, Tom. Slack: GettingPastBurnout, BusyworkandtheMythof Total Efficiency. Broadway.<br />

×