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...
Upcoming SlideShare
Loading in …5
×

Práticas De Um Engenheiro De Software Eficiente

2,281 views
2,223 views

Published on

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

Published in: Technology, Business
1 Comment
7 Likes
Statistics
Notes
  • 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.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,281
On SlideShare
0
From Embeds
0
Number of Embeds
612
Actions
Shares
0
Downloads
0
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide
  • De 1 hora e meia a 2 horas de palestra
  • Tudo funciona Nenhum erro Isso é impossível mas é um objetivo a ser perseguido
  • Buscar entender o que aconteceu pra evitar que aconteça novamente.
  • Testes
  • O tanto que você testar
  • Não necessariamente, mas mais de 90% no mínimo
  • Porque não? E você trabalhasse em uma cia. aérea? Ou na Nasa?
  • Quando tentamos ir rápido nos vemos dessa forma
  • Mas a figura mais real é parecida com isso
  • Geralmente custa muito, o código não foi feito pra mudar Porque? Se os requisitos mudam toda hora...
  • O que esperamos
  • Os requisitos mudam
  • O código estava errado
  • Interpretamos o cliente errado
  • Mentira
  • Vai quebrar meu brinquedo!
  • Só se resolve isso com testes
  • E em vários níveis
  • Programe em pares
  • TDD vai te permitir não usar o debugger Os ciclos curtos vão permitir isso
  • Testes demonstram como usar uma API
  • Não Não fica tão testável Fica muito acoplado Fica menos fácil de usar
  • Quem tem um conceito de pronto?
  • Testes definem quando a aplicação está pronta
  • Não do seu chefe Não do seu professor
  • Médico sim Atores sim Desenvolvedores não
  • Entenda o negócio em que você está atuando Você não precisa ser um expert Não importa o seu papel no projeto, aprenda o domínio Quando o software não funciona, sempre é culpa sua -se os requerimentos estavam errados é sua responsabilidade saber disso Entenda porque o expert de domínio quer o que quer, entenda-o
  • 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>

    ×