• Save
Práticas De Um Engenheiro De Software Eficiente
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Práticas De Um Engenheiro De Software Eficiente

on

  • 3,586 views

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

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

Statistics

Views

Total Views
3,586
Views on SlideShare
3,010
Embed Views
576

Actions

Likes
6
Downloads
0
Comments
1

9 Embeds 576

http://unplugged.giggio.net 355
http://elvisfusco.com.br 109
http://elvisfusco.wordpress.com 78
http://blog.lambda3.com.br 21
http://www.slideshare.net 9
http://64.233.163.132 1
http://campodedistorcaodarealidade.blogspot.com 1
http://twitter.com 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • 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.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Presentation Transcript

  • 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. Giovanni Bassi
    • Arquiteto de software
    • Microsoft MVP
    • Consultoria, gestão, mentoring
    • Treinamento
    • Palestrante
    • Professor universitário
    • Dezenas de artigos na .Net Magazine
    • Parte do corpo editorial da .Net Magazine
    • C#, VB, J#, F#, IronRuby, etc... (beta a beta)
    • Líder e fundador do .Net Architects (1º grupo de arquitetura de software com .Net do Brasil)
    • Ineta Board Member
  • 3. Certificações/Títulos
  • 4. Online @
    • Email: giggio@giggio.net
    • Blog técnico: http://unplugged.giggio.net
    • Site: http://giovannibassi.com
    • Twitter: @giovannibassi
    • .Net Architects:
    • Grupo: http://dotnetarchitects.net
    • Podcast: http://podcast.dotnetarchitects.net
    • Online: http://tinyurl.com/DotNetArch
    • Twitter: #DotNetArchitects
  • 5. Tudo que vocês acham que sabem está errado
  • 6.  
  • 7.  
  • 8.  
  • 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
  • 10. Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Standish Group
  • 11. Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
  • 12. Cone da incerteza Fonte: NASA (Cone of uncertainty)
  • 13. Falsa percepção de progresso
  • 14. Os primeiros 90% da aplicação levam 90% do tempo para ficarem prontos Os 10% finais levam mais 90% do tempo para terminar
  • 15.  
  • 16. Seu time se parece com isso?
  • 17. O método de pagamento por hora premia a ineficiência Não somos medidos por entrega
  • 18.  
  • 19.  
  • 20. Visão de futuro
  • 21. Sua produtividade se parece com isso?
  • 22. Ou com isso?
  • 23. Software tem que funcionar
  • 24. O que deve ser acontecer na homologação?
  • 25. E o que fazer quando um bug aparece em homologação ou produção?
  • 26. Como isso?
  • 27. Quanto da sua aplicação você quer que funcione?
  • 28. de cobertura de código?
  • 29. Você confiaria sua vida ao seu código?
  • 30.  
  • 31.  
  • 32. Quanto custa mudar o seu código?
  • 33. Escrevemos código que não deve mudar
  • 34. Requisito Código
  • 35. Requisito Código
  • 36. Requisito Código
  • 37. Requisito Código
  • 38. “ Não se mexe em time que está ganhando”
  • 39. Refatore seu código o tempo todo
  • 40.  
  • 41.  
  • 42. Com testes não há medo
  • 43. “ Sempre deixe as coisas mais limpas do que estavam quando você chegou” Regra dos escoteiros
  • 44. Trabalhe iterativamente
  • 45.  
  • 46.  
  • 47. Programação em par melhora o foco na entrega
  • 48. Não critique programação em par sem tentar
  • 49.  
  • 50. Test Driven Development
  • 51.  
  • 52.  
  • 53.  
  • 54.  
  • 55.  
  • 56.  
  • 57.  
  • 58. Quantas pessoas você conhece que executaram o próprio código cinco minutos atrás?
  • 59.  
  • 60.  
  • 61.  
  • 62.  
  • 63.  
  • 64. “ Não posso escrever o teste depois do código?”
  • 65.  
  • 66. pronto “ pronto pronto” pronto concluído
  • 67. Daily Meeting
  • 68.  
  • 69.  
  • 70.  
  • 71. Quantas empresas você conhece que compilaram e executaram todo seu código ontem? E a cada check-in?
  • 72.  
  • 73.  
  • 74.  
  • 75.  
  • 76.  
  • 77.  
  • 78.  
  • 79.  
  • 80. Conheça... Padrões arquiteturais Padrões de projeto Princípios de OO Algoritmos Processos
  • 81.  
  • 82. Aprender é sua responsabilidade Assim como transmitir seu conhecimento
  • 83.  
  • 84.  
  • 85.  
  • 86.  
  • 87.  
  • 88. Saia do cubículo!
  • 89. Desligue o fone de ouvido!
  • 90. Utilize o quadro branco
  • 91. Desenvolvedores Arquitetos Analistas de negócio Analistas de sistemas Designers Testadores
  • 92.  
  • 93. Conheça o negócio em que você atua
  • 94. Saiba que você não é seu usuário
  • 95. Concluindo...
  • 96. Como fazíamos software?
  • 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
  • 98.  
  • 99.  
  • 100.  
  • 101.  
  • 102.  
  • 103. Online @
    • Email: giggio@giggio.net
    • Blog técnico: http://unplugged.giggio.net
    • Site: http://giovannibassi.com
    • Twitter: @giovannibassi
    • .Net Architects:
    • Grupo: http://dotnetarchitects.net
    • Podcast: http://podcast.dotnetarchitects.net
    • Online: http://tinyurl.com/DotNetArch
    • Twitter: #DotNetArchitects