Giovanni Bassi Arquiteto de software independente www.giovannibassi.com unplugged.giggio.net Realização: Ciência da Comput...
Giovanni Bassi <ul><li>Arquiteto de software </li></ul><ul><li>Microsoft MVP </li></ul><ul><li>Consultoria, gestão, mentor...
Certificações/Títulos
Online @ <ul><li>Email: giggio@giggio.net  </li></ul><ul><li>Blog técnico:  http://unplugged.giggio.net   </li></ul><ul><l...
Tudo que vocês acham que sabem está errado
 
 
 
Bugs Escopo fechado “ Nada muda” Comando e controle Estimativa  assinada com sangue Prazo fechado Múltiplas linguagens Pre...
Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Stan...
Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
Cone da incerteza Fonte: NASA (Cone of uncertainty)
Falsa percepção de progresso
Os primeiros 90% da aplicação levam 90% do tempo para ficarem prontos Os 10% finais levam mais 90% do tempo para terminar
 
Seu time se parece com isso?
O método de pagamento por hora premia a ineficiência Não somos medidos por entrega
 
 
Visão de futuro
Sua produtividade se parece com isso?
Ou com isso?
Software tem que funcionar
O que deve ser acontecer na homologação?
E o que fazer quando um bug aparece em homologação ou produção?
Como  isso?
Quanto da sua aplicação você quer que funcione?
de cobertura de código?
Você confiaria sua vida ao seu código?
 
 
Quanto custa mudar o seu código?
Escrevemos código que não deve mudar
Requisito Código
Requisito Código
Requisito Código
Requisito Código
“ Não se mexe em time que está ganhando”
Refatore seu código o tempo todo
 
 
Com testes não há medo
“ Sempre deixe as coisas mais limpas do que estavam quando você chegou” Regra dos escoteiros
Trabalhe iterativamente
 
 
Programação em par melhora o foco na entrega
Não critique programação em par sem tentar
 
Test Driven Development
 
 
 
 
 
 
 
Quantas pessoas você conhece que executaram o próprio código cinco minutos atrás?
 
 
 
 
 
“ Não posso escrever o teste depois do código?”
 
pronto “ pronto   pronto” pronto concluído
Daily Meeting
 
 
 
Quantas empresas você conhece que compilaram e executaram todo seu código ontem? E a cada check-in?
 
 
 
 
 
 
 
 
Conheça... Padrões arquiteturais Padrões de projeto Princípios de OO Algoritmos Processos
 
Aprender é sua responsabilidade Assim como transmitir seu conhecimento
 
 
 
 
 
Saia do cubículo!
Desligue o fone de ouvido!
Utilize o quadro branco
Desenvolvedores Arquitetos Analistas de negócio Analistas de sistemas Designers Testadores
 
Conheça o negócio em que você atua
Saiba que você não é seu usuário
Concluindo...
Como fazíamos software?
Manifesto Ágil Indivíduos e interações  mais que processos e ferramentas  Produto em funcionamento  mais que documentação ...
 
 
 
 
 
Online @ <ul><li>Email: giggio@giggio.net  </li></ul><ul><li>Blog técnico:  http://unplugged.giggio.net   </li></ul><ul><l...
Próximos SlideShares
Carregando em…5
×

Práticas De Um Engenheiro De Software Eficiente

2.462 visualizações

Publicada em

Keynote da semana da informação da Univem, 2009.

Publicada em: Tecnologia, Negócios
  • Apenas vendo os slides deu pra ver que realmente foi uma grande palestra. Acho que alguns gerentes de projetos devem mesmo ver umas palestras como essa.

    Obrigado pelo compartilhamento de boas ideias

    Abs.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

Práticas De Um Engenheiro De Software Eficiente

  1. 1. Giovanni Bassi Arquiteto de software independente www.giovannibassi.com unplugged.giggio.net Realização: Ciência da Computação Sistemas de Informação
  2. 2. Giovanni Bassi <ul><li>Arquiteto de software </li></ul><ul><li>Microsoft MVP </li></ul><ul><li>Consultoria, gestão, mentoring </li></ul><ul><li>Treinamento </li></ul><ul><li>Palestrante </li></ul><ul><li>Professor universitário </li></ul><ul><li>Dezenas de artigos na .Net Magazine </li></ul><ul><li>Parte do corpo editorial da .Net Magazine </li></ul><ul><li>C#, VB, J#, F#, IronRuby, etc... (beta a beta) </li></ul><ul><li>Líder e fundador do .Net Architects (1º grupo de arquitetura de software com .Net do Brasil) </li></ul><ul><li>Ineta Board Member </li></ul>
  3. 3. Certificações/Títulos
  4. 4. Online @ <ul><li>Email: giggio@giggio.net </li></ul><ul><li>Blog técnico: http://unplugged.giggio.net </li></ul><ul><li>Site: http://giovannibassi.com </li></ul><ul><li>Twitter: @giovannibassi </li></ul><ul><li>.Net Architects: </li></ul><ul><li>Grupo: http://dotnetarchitects.net </li></ul><ul><li>Podcast: http://podcast.dotnetarchitects.net </li></ul><ul><li>Online: http://tinyurl.com/DotNetArch </li></ul><ul><li>Twitter: #DotNetArchitects </li></ul>
  5. 5. Tudo que vocês acham que sabem está errado
  6. 9. Bugs Escopo fechado “ Nada muda” Comando e controle Estimativa assinada com sangue Prazo fechado Múltiplas linguagens Preço fechado Foco nas ferramentas Processos complexos Documentação extensa Silos Atrasos constantes Inexistência de testes Qualidade sofrível
  7. 10. Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Standish Group
  8. 11. Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
  9. 12. Cone da incerteza Fonte: NASA (Cone of uncertainty)
  10. 13. Falsa percepção de progresso
  11. 14. Os primeiros 90% da aplicação levam 90% do tempo para ficarem prontos Os 10% finais levam mais 90% do tempo para terminar
  12. 16. Seu time se parece com isso?
  13. 17. O método de pagamento por hora premia a ineficiência Não somos medidos por entrega
  14. 20. Visão de futuro
  15. 21. Sua produtividade se parece com isso?
  16. 22. Ou com isso?
  17. 23. Software tem que funcionar
  18. 24. O que deve ser acontecer na homologação?
  19. 25. E o que fazer quando um bug aparece em homologação ou produção?
  20. 26. Como isso?
  21. 27. Quanto da sua aplicação você quer que funcione?
  22. 28. de cobertura de código?
  23. 29. Você confiaria sua vida ao seu código?
  24. 32. Quanto custa mudar o seu código?
  25. 33. Escrevemos código que não deve mudar
  26. 34. Requisito Código
  27. 35. Requisito Código
  28. 36. Requisito Código
  29. 37. Requisito Código
  30. 38. “ Não se mexe em time que está ganhando”
  31. 39. Refatore seu código o tempo todo
  32. 42. Com testes não há medo
  33. 43. “ Sempre deixe as coisas mais limpas do que estavam quando você chegou” Regra dos escoteiros
  34. 44. Trabalhe iterativamente
  35. 47. Programação em par melhora o foco na entrega
  36. 48. Não critique programação em par sem tentar
  37. 50. Test Driven Development
  38. 58. Quantas pessoas você conhece que executaram o próprio código cinco minutos atrás?
  39. 64. “ Não posso escrever o teste depois do código?”
  40. 66. pronto “ pronto pronto” pronto concluído
  41. 67. Daily Meeting
  42. 71. Quantas empresas você conhece que compilaram e executaram todo seu código ontem? E a cada check-in?
  43. 80. Conheça... Padrões arquiteturais Padrões de projeto Princípios de OO Algoritmos Processos
  44. 82. Aprender é sua responsabilidade Assim como transmitir seu conhecimento
  45. 88. Saia do cubículo!
  46. 89. Desligue o fone de ouvido!
  47. 90. Utilize o quadro branco
  48. 91. Desenvolvedores Arquitetos Analistas de negócio Analistas de sistemas Designers Testadores
  49. 93. Conheça o negócio em que você atua
  50. 94. Saiba que você não é seu usuário
  51. 95. Concluindo...
  52. 96. Como fazíamos software?
  53. 97. Manifesto Ágil Indivíduos e interações mais que processos e ferramentas Produto em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano http://agilemanifesto.org Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
  54. 103. Online @ <ul><li>Email: giggio@giggio.net </li></ul><ul><li>Blog técnico: http://unplugged.giggio.net </li></ul><ul><li>Site: http://giovannibassi.com </li></ul><ul><li>Twitter: @giovannibassi </li></ul><ul><li>.Net Architects: </li></ul><ul><li>Grupo: http://dotnetarchitects.net </li></ul><ul><li>Podcast: http://podcast.dotnetarchitects.net </li></ul><ul><li>Online: http://tinyurl.com/DotNetArch </li></ul><ul><li>Twitter: #DotNetArchitects </li></ul>

×