Your SlideShare is downloading. ×
0
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Pessoas Ou Processos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Pessoas Ou Processos

765

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.

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
765
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Pessoas ou processos?<br />Entenda o que a Toyota, os processos e as pessoas tem haver com o desenvolvimento de software<br />
  • 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. 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. 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. O que nós vemos no dia-a-dia?<br />Processos normalmente são mais importantes do que as pessoas<br />
  • 6. Mas em alguns lugares, as pessoas são mais importantes do que os processos<br />
  • 7. Onde?<br />
  • 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. Como produzir carros em pequenas quantidades com o custo de carros produzidos em massa?<br />
  • 10. Elimine o desperdício!<br />Essa foi a solução encontrada por TaiichiOhno, pai do Toyota Production System, simples, não?<br />
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Os 7 tipos de desperdício<br />
  • 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. 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. 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. 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. 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. 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. 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. Movimento<br />“Como assim eu vou ter que ir pro Amazonas pra poder fazer uma visita ao cliente?”<br />“Será que essa p&amp;%%# só atende pelo callcenter?”<br />
  • 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. 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. A vida de uma latinha de refrigerante<br />
  • 32. Estatísticas<br />Tempo total: 319 dias;<br />Tempo executando alguma coisa de valor: 3 horas<br />
  • 33. Fluxo de valor em uma fábrica de software comum<br />
  • 34. Fluxo de valor no desenvolvimento ágil<br />
  • 35. Amplificando o aprendizado<br />Porque desenvolver software ainda é explicar ao computador como o mundo funciona<br />
  • 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. 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. Decida o mais tarde possível<br />Por que tomar a decisão agora se ela só precisa ser tomada amanhã?<br />
  • 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. 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. 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. 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. Pull systems<br />Kanban e os estoques infinitos sem estoque<br />
  • 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. Gerencia pela visibilidade<br />
  • 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. 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. 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. Questões?<br />
  • 50. Referências<br />DeMarco, Tom; Lister, Tim. Peopleware: ProductiveProjectsandTeams. DorsetHousePublishing.<br />Poppendieck, Tom &amp; Mary. Lean Software Development: AnAgile Toolkit.Addison-Wesley.<br />DeMarco, Tom. Slack: GettingPastBurnout, BusyworkandtheMythof Total Efficiency. Broadway.<br />

×