Métodos Ágeis:O que é folclore e o que é real?         Mauricio Aniche mauricio.aniche@caelum.com.br        @mauricioaniche
Nós amamosmétodos ágeis!
No mestrado...
Mas tudo faz sentido...Será que vale a pena  estudar melhor?
Homens de nível educacional mais alto apresentarammaior quantidade de sintomas pseudoneuróticos doque aqueles que haviam r...
Nossa intuiçãopode estar errada!
Mas nós conhecemosbem de software, nãotem como errarmos!
Programador 10x!
• Sackman, Erikson, Grant (1968): experimento  controlado com programadores depurando;• Curtis (1981) também depurando;• M...
Pode ser  verdade,mas a ciêncianão mostrou!
Mas tem um monte de trabalhos sobre   métodos ágeis!        Diversos questionáriosda VersionOne, Scott Ambler, e outras   ...
De 1996 trabalhos, só 36 possuem rigor científico   (Dyba,T., Dingsoyr,T. Empirical studies of agile software              ...
• Grande parte dos estudos feitos com XP  (76%);• Single-Case (39%) e Multiple-Case (33%)• 73% dos estudos com iniciantes ...
Vocês sabem, aliás,        como nasceu a XP?“The best software development team      on the face of the earth”.           ...
Vamos analisar alguns desses    mitos...
Sem TDD, meu código não terá qualidade!
Por quê?• TDD faz o programador criar melhores  projetos de classes.
A maioria dos     estudos foramfeitos com estudantes!
Efeitos no projeto    de classes?       - Pouco conclusivos    - Projetos mal escolhidos- Focados em métricas de código
Outras pessoas           já perceberam que           os efeitos de TDD          não são tão naturais                  assi...
A pergunta é: usar ou não usar TDD?
a prática de TDD não guia o    desenvolvedor para um bom   projeto de classes de forma           automática!Aniche, Gerosa...
TDD dá retorno   constante sobre os possíveis    problemas existentes no atual     projeto de classes. É tarefa        do ...
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.
Eu não uso TDD quando... • Já tenho bem claro o projeto da classe que   estou trabalhando; • É código que lida com infraes...
Mas testo o tempo todo! • Mesmo quando não faço TDD, escrevo   testes frequentemente.
Testes automatizados     é um dos grandestrunfos dos métodos ágeis
MITO!
Programação pareada é     obrigatório!
Por quê?• Código de maior qualidade• Maior produtividade• Distribuição de conhecimento
Veio antes da XP...• “Fellow graduate student Bill Wright and I first  tried pair programming when I was a grad  student (1...
Talvez uma das áreascom a maior quantidade   de estudos feitos [Begel and Nagappan 2008], [Dyba et al. 2007], [Jensen 2003...
Programação  pareada  100% do   tempo?
Quando usar PP?       • Quando a tarefa é complexa;       • Quando há conhecimento para ser            compartilhado.Anich...
Quando não usar PP?       • Quando a tarefa é simples e não há            conhecimento a ser compartilhado;       • Tarefa...
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 ...
MITO!
Documentação não serve pra nada!
Por quê?• Documentações raramente  representam a realidade.
Na ciência...    • Corrigir um problema durante o         levantamento de requisitos custa 100x         menos do que corri...
Mas sabemos que éimpossível levantartodos os requisitos      antes!
“XPers are not afraid of oral documentation”      Uncle Bob
Podemos então   usar única e  exclusivamentedocumentação oral?  “Do as much or as little requirementsdocumentation as you ...
Como documentar?• Levante requisitos e os valide  constantemente• Maximize comunicação: papel, bate-papo,  feedback consta...
MITO!
Big Design Up Front?   Seu cascateiro!
Por quê?• Complexidade desnecessária• Desperdício de tempo, pois na  prática, sabemos que as coisas  mudam
UML é um veneno!                         Será mesmo?2007, Mario Cherubini, Gina Venolia, Rob DeLine and Andrew Ko
Pense em         arquitetura sim!• O problema é “TENTAR PENSAR EM  TODOS OS DETALHES DE  PRIMEIRA”, e não “TENTAR  PENSAR”...
MITO!
Correlação x Causa
Meu irmão passou emtodas universidades!
A ciência não erra?
Muitos estudos diziam que mulheres que faziam terapia desubstituição de hormônios tinham menos chance de teruma doença do ...
Precisamos serpragmáticos e analisar      a situação    corretamente
Ainda bem quea medicina não   faz assim!
O que eu faço                com isso?"We identified a number of reported benefits and limitations ofagile development withi...
Separe fatosde folclore!
Não posso mais blogar então?
Compartilhe                    experiências e                      “transfira”                    conhecimento!Aniche, Silv...
Desirability bias           41% dos brasileiros já tiveram uma             interação virtual que pode ser                 ...
Como unir o quê aciência faz de melhorcom o quê a indústria   faz de melhor?
Obrigado!mauricio.aniche@caelum.com.br       @mauricioaniche
Métodos Ágeis: O que é folclore e o que é real? (QCON SP 2012)
Métodos Ágeis: O que é folclore e o que é real? (QCON SP 2012)
Upcoming SlideShare
Loading in …5
×

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

4,244 views

Published on

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.

Published in: Technology
2 Comments
14 Likes
Statistics
Notes
  • Oi Adolfo, obrigado! Vou ler a referência sim!
       Reply 
    Are you sure you want to  Yes  No
    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
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,244
On SlideShare
0
From Embeds
0
Number of Embeds
29
Actions
Shares
0
Downloads
97
Comments
2
Likes
14
Embeds 0
No embeds

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
  • Métodos Ágeis: O que é folclore e o que é real? (QCON SP 2012)

    1. 1. Métodos Ágeis:O que é folclore e o que é real? Mauricio Aniche mauricio.aniche@caelum.com.br @mauricioaniche
    2. 2. Nós amamosmétodos ágeis!
    3. 3. No mestrado...
    4. 4. Mas tudo faz sentido...Será que vale a pena estudar melhor?
    5. 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. 6. Nossa intuiçãopode estar errada!
    7. 7. Mas nós conhecemosbem de software, nãotem como errarmos!
    8. 8. Programador 10x!
    9. 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. 10. Pode ser verdade,mas a ciêncianão mostrou!
    11. 11. Mas tem um monte de trabalhos sobre métodos ágeis! Diversos questionáriosda VersionOne, Scott Ambler, e outras evidências anedotais!
    12. 12. De 1996 trabalhos, só 36 possuem rigor científico (Dyba,T., Dingsoyr,T. Empirical studies of agile software development: A systematic review)
    13. 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. 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. 15. Vamos analisar alguns desses mitos...
    16. 16. Sem TDD, meu código não terá qualidade!
    17. 17. Por quê?• TDD faz o programador criar melhores projetos de classes.
    18. 18. A maioria dos estudos foramfeitos com estudantes!
    19. 19. Efeitos no projeto de classes? - Pouco conclusivos - Projetos mal escolhidos- Focados em métricas de código
    20. 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. 21. A pergunta é: usar ou não usar TDD?
    22. 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. 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. 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. 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. 26. Mas testo o tempo todo! • Mesmo quando não faço TDD, escrevo testes frequentemente.
    27. 27. Testes automatizados é um dos grandestrunfos dos métodos ágeis
    28. 28. MITO!
    29. 29. Programação pareada é obrigatório!
    30. 30. Por quê?• Código de maior qualidade• Maior produtividade• Distribuição de conhecimento
    31. 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. 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. 33. Programação pareada 100% do tempo?
    34. 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. 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. 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. 37. MITO!
    38. 38. Documentação não serve pra nada!
    39. 39. Por quê?• Documentações raramente representam a realidade.
    40. 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. 41. Mas sabemos que éimpossível levantartodos os requisitos antes!
    42. 42. “XPers are not afraid of oral documentation” Uncle Bob
    43. 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. 44. Como documentar?• Levante requisitos e os valide constantemente• Maximize comunicação: papel, bate-papo, feedback constante.
    45. 45. MITO!
    46. 46. Big Design Up Front? Seu cascateiro!
    47. 47. Por quê?• Complexidade desnecessária• Desperdício de tempo, pois na prática, sabemos que as coisas mudam
    48. 48. UML é um veneno! Será mesmo?2007, Mario Cherubini, Gina Venolia, Rob DeLine and Andrew Ko
    49. 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. 50. MITO!
    51. 51. Correlação x Causa
    52. 52. Meu irmão passou emtodas universidades!
    53. 53. A ciência não erra?
    54. 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. 55. Precisamos serpragmáticos e analisar a situação corretamente
    56. 56. Ainda bem quea medicina não faz assim!
    57. 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. 58. Separe fatosde folclore!
    59. 59. Não posso mais blogar então?
    60. 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. 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. 62. Como unir o quê aciência faz de melhorcom o quê a indústria faz de melhor?
    63. 63. Obrigado!mauricio.aniche@caelum.com.br @mauricioaniche

    ×