Caminho Do Desenvolvedor Amador Para o Profissional

2.263 visualizações

Publicada em

Palestra realizada no MS Tech Days. Veja o vídeo aqui:
http://unplugged.giggio.net/post/Palestra-do-caminho-desenvolvedor-amador-para-o-profissional-ao-vivo!.aspx

Publicada em: Tecnologia
0 comentários
7 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.263
No SlideShare
0
A partir de incorporações
0
Número de incorporações
387
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • De 1 hora e meia a 2 horas de palestra
  • Pra pensar até o final...
  • Tudo funciona Nenhum erro Isso é impossível mas é um objetivo a ser perseguido
  • Testes
  • O tanto que você testar
  • 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...
  • 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 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
  • Caminho Do Desenvolvedor Amador Para o Profissional

    1. 1. Giovanni Bassi Arquiteto de software independente www.giovannibassi.com unplugged.giggio.net
    2. 3. 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. 4. Certificações/Títulos
    4. 5. <ul><li>Giovanni Bassi: </li></ul><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>Online @
    5. 6. Tudo que vocês acham que sabem está errado
    6. 7. Profissionalismo é algo muito diferente do que vocês imaginam
    7. 8. Quais são as práticas de um engenheiro mecânico profissional? Quais são as práticas de um médico profissional? Quais são as práticas de um engenheiro de software profissional?
    8. 10. 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
    9. 11. Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Standish Group
    10. 12. Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
    11. 13. Cone da incerteza Fonte: NASA (Cone of uncertainty)
    12. 14. Falsa percepção de progresso
    13. 15. Os primeiros 90% da aplicação levam 90% do tempo para ficarem prontos Os 10% finais levam mais 90% do tempo para terminar
    14. 17. Seu time se parece com isso?
    15. 20. Visão de futuro
    16. 21. Sua produtividade se parece com isso?
    17. 22. Ou com isso?
    18. 23. Software tem que funcionar
    19. 24. Quantos erros QA deve encontrar na homologação?
    20. 25. Você deve isso
    21. 26. Quanto da sua aplicação você quer que funcione?
    22. 27. Confie sua vida ao seu código
    23. 30. Quanto custa mudar o seu código?
    24. 31. Escrevemos código que não é feito para mudar Requisito Código
    25. 32. “ Não se mexe em time que está ganhando”
    26. 33. Refatore seu código o tempo todo
    27. 36. Com testes não há medo
    28. 37. “ Sempre deixe as coisas mais limpas do que estavam quando você chegou” Regra dos escoteiros
    29. 38. Trabalhe iterativamente
    30. 41. Use Test Driven Development
    31. 42. TDD
    32. 46. Quantas pessoas você conhece que executaram o próprio código cinco minutos atrás?
    33. 51. Stress Aceitação Funcional (Regressão vem de graça) Faça outros tipos de testes
    34. 54. Qual dos dois tem qualidade superior?
    35. 55. Estimativa = cálculo aproximado Dicionário Aulete http://aulete.uol.com.br/site.php?mdl=aulete_digital&op=loadVerbete&palavra=estimativa
    36. 56. “ A distinção entre estimativas, metas e compromissos é crítica para entender o que uma estimativa é, o que uma estimativa não é, e como tornar suas estimativas melhores.” Steve McConnell No livro “Software Estimation: Demystifying the Black Art” http://tinyurl.com/estimativa
    37. 63. Conheça... Padrões arquiteturais Padrões de projeto Princípios de OO Algoritmos Processos
    38. 65. Aprender é sua responsabilidade Assim como transmitir seu conhecimento
    39. 68. Saia do cubículo!
    40. 69. Desligue o fone de ouvido!
    41. 70. Utilize o quadro branco
    42. 72. Conheça o negócio em que você atua
    43. 73. Saiba que você não é seu usuário
    44. 75. Como fazíamos software?
    45. 76. 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
    46. 77. Portanto...
    47. 83. <ul><li>Giovanni Bassi: </li></ul><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>Online @

    ×