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.
5. Mas tudo faz sentido...
Será que vale a pena
estudar melhor?
6. Homens de nível educacional mais alto apresentaram
maior quantidade de sintomas pseudoneuróticos do
que aqueles que haviam recebido menos instrução;
Homens do meio rural mantiveram-se mais bem-
humorados durante a guerra do que os soldados
recrutados nas cidades;
A capacidade dos homens do Sul (dos EUA) para
suportar o calor era maior do que as dos soldados do
Norte.
Lazarsfeld, P. "The American Soldier - An Expository Review", 1949.
10. • 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.
12. Mas tem um monte
de trabalhos sobre
métodos ágeis!
Diversos questionários
da VersionOne, Scott Ambler, e outras
evidências anedotais!
13. De 1996 trabalhos,
só 36 possuem
rigor científico
(Dyba,T., Dingsoyr,T. Empirical studies of agile software
development: A systematic review)
14. • 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)
15. 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.
21. Efeitos no projeto
de classes?
- Pouco conclusivos
- Projetos mal escolhidos
- Focados em métricas de código
22. 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
24. 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
25. 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
26. 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.
27. Eu não uso TDD quando...
• Já tenho bem claro o projeto da classe que
estou trabalhando;
• É código que lida com infraestrutura.
28. Mas testo o tempo todo!
• Mesmo quando não faço TDD, escrevo
testes frequentemente.
32. Por quê?
• Código de maior qualidade
• Maior produtividade
• Distribuição de conhecimento
33. 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
34. Talvez uma das áreas
com a maior quantidade
de estudos feitos
[Begel and Nagappan 2008], [Dyba et al. 2007], [Jensen 2003], [Luck 2004],
[Vanhanen and Korpi 2007], ...
36. 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.
37. 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.
38. 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ídos
Laurie Williams em “Making Software:What Really Works, and Why We Believe it” -- Oram,Wilson
42. 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:1
Barry Boehm em “Making Software:What Really Works, and Why We Believe it” -- Oram,Wilson
43. Mas sabemos que é
impossível levantar
todos os requisitos
antes!
45. Podemos então
usar única e
exclusivamente
documentação oral?
“Do as much or as little requirements
documentation as you feel is necessary, but
personally we do as little as we can”
46. Como documentar?
• Levante requisitos e os valide
constantemente
• Maximize comunicação: papel, bate-papo,
feedback constante.
49. Por quê?
• Complexidade desnecessária
• Desperdício de tempo, pois na
prática, sabemos que as coisas
mudam
50. UML é um veneno!
Será mesmo?
2007, Mario Cherubini, Gina Venolia, Rob DeLine and Andrew Ko
51. 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
56. Muitos estudos diziam que mulheres que faziam terapia de
substituição de hormônios tinham menos chance de ter
uma doença do coração;
Mas alguns estudos controlados mostraram que a terapia
AUMENTAVA a chance;
A re-análise dos primeiros estudos mostrou que as
mulheres que passavam pelo tratamento pertenciam a
classes mais altas, que tinham uma alimentação melhor e
praticavam exercícios, e por isso o resultado.
http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation
59. O que eu faço
com isso?
"We identified a number of reported benefits and limitations of
agile development within each of these themes. However, the
strength of evidence is very low, which makes it difficult to offer
specific advice to industry. Consequently, we advise readers from
industry to use this article as a map of findings according to
topic, which they can use to investigate relevant studies further
and compare the settings in the studies to their own situation."
(Dyba,T., Dingsoyr,T. Empirical studies of agile software
development: A systematic review)
62. 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.
63. 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.
64. Como unir o quê a
ciência faz de melhor
com o quê a indústria
faz de melhor?