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
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?
9.
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
11. Chaos Report Desafiado: atrasou, custou mais, ou entregou menos Fracasso: cancelado, ou entregue e nunca usado Fonte: Standish Group
12. Uso de Funcionalidades 64% Nunca ou Raramente Utilizadas 20% do Software é Realmente Útil Fonte: Standish Group, 2002
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
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
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