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.

1. Métodos Ágeis:
O que é folclore
e o que é real?
Mauricio Aniche
mauricio.aniche@caelum.com.br
@mauricioaniche

3. Nós amamos
métodos ágeis!

4. No mestrado...

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.

7. Nossa intuição
pode estar errada!

8. Mas nós conhecemos
bem de software, não
tem como errarmos!

9. Programador 10x!

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.

11. Pode ser
verdade,
mas a ciência
não mostrou!

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.

16. Vamos analisar
alguns desses
mitos...

17. Sem TDD, meu código
não terá qualidade!

18. Por quê?
• TDD faz o programador criar melhores
projetos de classes.

20. A maioria dos
estudos foram
feitos com estudantes!

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

23. A pergunta é:
usar ou não
usar TDD?

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.

29. Testes automatizados
é um dos grandes
trunfos dos métodos ágeis

30. MITO!

31. Programação pareada é
obrigatório!

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], ...

35. Programação
pareada
100% do
tempo?

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

39. MITO!

40. Documentação não
serve pra nada!

41. Por quê?
• Documentações raramente
representam a realidade.

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!

44. “XPers are not afraid of
oral documentation”
Uncle Bob

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.

47. MITO!

48. Big Design Up Front?
Seu cascateiro!

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

52. MITO!

53. Correlação x Causa

54. Meu irmão passou em
todas universidades!

55. A ciência não erra?

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

57. Precisamos ser
pragmáticos e analisar
a situação
corretamente

58. Ainda bem que
a medicina não
faz assim!

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)

60. Separe fatos
de folclore!

61. Não posso mais
blogar então?

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?

65. Obrigado!
mauricio.aniche@caelum.com.br
@mauricioaniche