Métodos Ágeis: O que é folclore e o que é real? (QCON SP 2012)

  • 2,978 views
Uploaded on

Minha palestra sobre fatos e folclores comuns entre praticantes de metodologias ágeis e o que a ciência pensa disso. …

Minha palestra sobre fatos e folclores comuns entre praticantes de metodologias ágeis e o que a ciência pensa disso.

Apresentei no dia 4 de agosto de 2012, na QCON SP, organizado pela Caelum.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Oi Adolfo, obrigado! Vou ler a referência sim!
    Are you sure you want to
    Your message goes here
  • Muito bom! É isto mesmo. Vivo falando estas coisas para meus alunos de Métodos Ágeis no Mestrado da UTFPR.

    Por um lado é muito bom. Tem espaço para muita pesquisa.
    Por outro lado, é difícil fazer boa pesquisa experimental. É muito mais fácil emitir opiniões.

    Com relação à Medicina, eles têm vários problemas ainda. Um exemplo é este livro:

    http://www.amazon.com/gp/product/B0036S4EGE/ref=kinw_myk_ro_title

    Anatomy of an Epidemic: Magic Bullets, Psychiatric Drugs, and the Astonishing Rise of Mental Illness in America
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,978
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
87
Comments
2
Likes
14

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Transcript

  • 1. Métodos Ágeis:O que é folclore e o que é real? Mauricio Aniche mauricio.aniche@caelum.com.br @mauricioaniche
  • 2. Nós amamosmétodos ágeis!
  • 3. No mestrado...
  • 4. Mas tudo faz sentido...Será que vale a pena estudar melhor?
  • 5. Homens de nível educacional mais alto apresentarammaior quantidade de sintomas pseudoneuróticos doque aqueles que haviam recebido menos instrução;Homens do meio rural mantiveram-se mais bem-humorados durante a guerra do que os soldadosrecrutados nas cidades;A capacidade dos homens do Sul (dos EUA) parasuportar o calor era maior do que as dos soldados doNorte. Lazarsfeld, P. "The American Soldier - An Expository Review", 1949.
  • 6. Nossa intuiçãopode estar errada!
  • 7. Mas nós conhecemosbem de software, nãotem como errarmos!
  • 8. Programador 10x!
  • 9. • Sackman, Erikson, Grant (1968): experimento controlado com programadores depurando;• Curtis (1981) também depurando;• Mills (1983) apenas um relato de opiniões;Só um relacionado:• Valett (1989) achou razões de 1 pra 8 em projetos pequenos e 1 pra 20 em projetos grandes (mas mediu em produtividade com número de linhas escritas) Bossavit.The Leprechauns of Software Engineering, 2011.
  • 10. Pode ser verdade,mas a ciêncianão mostrou!
  • 11. Mas tem um monte de trabalhos sobre métodos ágeis! Diversos questionáriosda VersionOne, Scott Ambler, e outras evidências anedotais!
  • 12. De 1996 trabalhos, só 36 possuem rigor científico (Dyba,T., Dingsoyr,T. Empirical studies of agile software development: A systematic review)
  • 13. • Grande parte dos estudos feitos com XP (76%);• Single-Case (39%) e Multiple-Case (33%)• 73% dos estudos com iniciantes em agile; só 12% com times maduros;• 73% dos estudos com profissionais; (Dyba,T., Dingsoyr,T. Empirical studies of agile software development: A systematic review)
  • 14. Vocês sabem, aliás, como nasceu a XP?“The best software development team on the face of the earth”. “As of the first of February, 2000, the C3 project has been terminated without a successful launch of the next phase”. Stephens, Roseberg. Extremme Programming Refactored: A Case Against XP, 2003.
  • 15. Vamos analisar alguns desses mitos...
  • 16. Sem TDD, meu código não terá qualidade!
  • 17. Por quê?• TDD faz o programador criar melhores projetos de classes.
  • 18. A maioria dos estudos foramfeitos com estudantes!
  • 19. Efeitos no projeto de classes? - Pouco conclusivos - Projetos mal escolhidos- Focados em métricas de código
  • 20. Outras pessoas já perceberam que os efeitos de TDD não são tão naturais assim!M. Siniaalto and P. Abrahamsson, “Does test-driven development improve the program code?Alarming results from a comparative case study,” Balancing Agility and Formalism in Software Engineering, vol. 5082, pp. 143–156, 2008. [Online]. Available: http://dx.doi.org/10. 1007/978- 3- 540- 85279- 7_12
  • 21. A pergunta é: usar ou não usar TDD?
  • 22. a prática de TDD não guia o desenvolvedor para um bom projeto de classes de forma automática!Aniche, Gerosa. Como a Prática de TDD Influencia o Projeto de Classes em Sistemas Orientados a Objetos: Padrões de Feedback para o Desenvolvedor. 2012
  • 23. TDD dá retorno constante sobre os possíveis problemas existentes no atual projeto de classes. É tarefa do desenvolvedor perceber esses problemas e melhorar o projeto de acordo.Aniche, Gerosa. Como a Prática de TDD Influencia o Projeto de Classes em Sistemas Orientados a Objetos: Padrões de Feedback para o Desenvolvedor. 2012
  • 24. Eu uso TDD quando...• Não sei bem como projetar minhas classes;• Sei bem o quê quero fazer, mas não sei bem como fazer.
  • 25. Eu não uso TDD quando... • Já tenho bem claro o projeto da classe que estou trabalhando; • É código que lida com infraestrutura.
  • 26. Mas testo o tempo todo! • Mesmo quando não faço TDD, escrevo testes frequentemente.
  • 27. Testes automatizados é um dos grandestrunfos dos métodos ágeis
  • 28. MITO!
  • 29. Programação pareada é obrigatório!
  • 30. Por quê?• Código de maior qualidade• Maior produtividade• Distribuição de conhecimento
  • 31. Veio antes da XP...• “Fellow graduate student Bill Wright and I first tried pair programming when I was a grad student (1953-1956).We produced 1500 lines of defect-free code; it ran correctly first try” Fred Brooks
  • 32. Talvez uma das áreascom a maior quantidade de estudos feitos [Begel and Nagappan 2008], [Dyba et al. 2007], [Jensen 2003], [Luck 2004], [Vanhanen and Korpi 2007], ...
  • 33. Programação pareada 100% do tempo?
  • 34. Quando usar PP? • Quando a tarefa é complexa; • Quando há conhecimento para ser compartilhado.Aniche, Silveira. Increasing Learning in an Agile Environment: Lessons Learned in an Agile Team, 2011.
  • 35. Quando não usar PP? • Quando a tarefa é simples e não há conhecimento a ser compartilhado; • Tarefas de estudo.Aniche, Silveira. Increasing Learning in an Agile Environment: Lessons Learned in an Agile Team, 2011.
  • 36. Desafios da PP • Não é fácil parear • Luta contra o hábito • Ponto de vista financeiro • “If I have a choice, I can employ one star programmer instead of two programmers who need to code in a pair” [Begel and Nagappan, 2008] • Coordenação e times distribuídosLaurie Williams em “Making Software:What Really Works, and Why We Believe it” -- Oram,Wilson
  • 37. MITO!
  • 38. Documentação não serve pra nada!
  • 39. Por quê?• Documentações raramente representam a realidade.
  • 40. Na ciência... • Corrigir um problema durante o levantamento de requisitos custa 100x menos do que corrigir o mesmo problema quando o software já está em produção. • Em projetos pequenos, a escala é de 5:1Barry Boehm em “Making Software:What Really Works, and Why We Believe it” -- Oram,Wilson
  • 41. Mas sabemos que éimpossível levantartodos os requisitos antes!
  • 42. “XPers are not afraid of oral documentation” Uncle Bob
  • 43. Podemos então usar única e exclusivamentedocumentação oral? “Do as much or as little requirementsdocumentation as you feel is necessary, but personally we do as little as we can”
  • 44. Como documentar?• Levante requisitos e os valide constantemente• Maximize comunicação: papel, bate-papo, feedback constante.
  • 45. MITO!
  • 46. Big Design Up Front? Seu cascateiro!
  • 47. Por quê?• Complexidade desnecessária• Desperdício de tempo, pois na prática, sabemos que as coisas mudam
  • 48. UML é um veneno! Será mesmo?2007, Mario Cherubini, Gina Venolia, Rob DeLine and Andrew Ko
  • 49. Pense em arquitetura sim!• O problema é “TENTAR PENSAR EM TODOS OS DETALHES DE PRIMEIRA”, e não “TENTAR PENSAR” Veja os dados encontrados por Barry Boehm em “Making Software:What Really Works, and Why We Believe it” -- Oram,Wilson
  • 50. MITO!
  • 51. Correlação x Causa
  • 52. Meu irmão passou emtodas universidades!
  • 53. A ciência não erra?
  • 54. Muitos estudos diziam que mulheres que faziam terapia desubstituição de hormônios tinham menos chance de teruma doença do coração;Mas alguns estudos controlados mostraram que a terapiaAUMENTAVA a chance;A re-análise dos primeiros estudos mostrou que asmulheres que passavam pelo tratamento pertenciam aclasses mais altas, que tinham uma alimentação melhor epraticavam exercícios, e por isso o resultado. http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation
  • 55. Precisamos serpragmáticos e analisar a situação corretamente
  • 56. Ainda bem quea medicina não faz assim!
  • 57. O que eu faço com isso?"We identified a number of reported benefits and limitations ofagile development within each of these themes. However, thestrength of evidence is very low, which makes it difficult to offerspecific advice to industry. Consequently, we advise readers fromindustry to use this article as a map of findings according totopic, which they can use to investigate relevant studies furtherand compare the settings in the studies to their own situation." (Dyba,T., Dingsoyr,T. Empirical studies of agile software development: A systematic review)
  • 58. Separe fatosde folclore!
  • 59. Não posso mais blogar então?
  • 60. Compartilhe experiências e “transfira” conhecimento!Aniche, Silveira. Increasing Learning in an Agile Environment: Lessons Learned in an Agile Team, 2011. Fernandes.There and Back Again, 2012.
  • 61. Desirability bias 41% dos brasileiros já tiveram uma interação virtual que pode ser considerada traição. [Fonte: Instituto Qualibest]Aniche, Ferreira, Gerosa..What Concerns Beginner Test-Driven Development Practitioners: A Qualitative Analysis of Opinions in an Agile Conference, 2011.
  • 62. Como unir o quê aciência faz de melhorcom o quê a indústria faz de melhor?
  • 63. Obrigado!mauricio.aniche@caelum.com.br @mauricioaniche