Este documento apresenta uma introdução aos métodos ágeis para desenvolvimento de software, descrevendo alguns métodos como Scrum, Kanban e Extreme Programming, além de práticas como TDD, programação pareada e refatoração. O documento também discute objetivos de aprendizagem, exemplos, literatura científica e não-científica sobre o tema e oportunidades para pesquisa futura em métodos ágeis.

1. Pesquisa em Métodos Ágeis Para
o Desenvolvimento de Software
Adolfo Neto
Departamento Acadêmico de Informática (DAINF)
Universidade Tecnológica Federal do Paraná (UTFPR)

2. OBJETIVOS

3. MÉTODOS
ÁGEIS

4. DESCREVER

5. COMPARAR

6. LITERATURA
CIENTÍFICA

7. LITERATURA
NÃO-CIENTÍFICA

8. PROBLEMAS
EM ABERTO

9. Objetivos de Aprendizagem

Ao final deste mini-curso você deverá
ser capaz de:

Descrever e comparar alguns dos
principais métodos ágeis (como XP e
Scrum) e práticas ágeis
(Desenvolvimento Dirigido por Testes,
Programação Pareada, Refatoração,
entre outras)

10. Objetivos de Aprendizagem

Ao final deste mini-curso você deverá
ser capaz de:

Encontrar literatura científica e não-
científica sobre métodos ágeis

Listar alguns dos principais problemas
científicos em aberto na área de
métodos ágeis.

11. EXEMPLO DE MÉTODO ÁGIL:
PROGRAMAÇÃO EXTREMA

12. PROGRAMAR:
ATIVIDADE-CHAVE

13. DISCIPLINA

14. Extreme Programming
O primeiro livro (BECK, 1999).
Trechos - Foreword, Erich Gamma:
“Extreme Programming (XP) nominates
coding as the key activity throughout
a software project. This can't possibly
work!”

15. Extreme Programming
“It would be wrong to conclude that all that is
needed to deliver software is daredevil
programming. Delivering software is hard,
and delivering quality software in time is
even harder. To make it work requires the
disciplined use of additional best
practices. This is where Kent starts in his
though-provoking book on XP.”

16. Extreme Programming
“XP takes commonsense principles and practices
to extreme levels.”
– Pair programming
– Unit testing
– Functional testing
– Refactoring
– Continuous integration

17. Um Episódio de Desenvolvimento

18. Engenharia de Software
Não é parecida com Engenharia Civil!
– Após construir uma casa não é fácil mudar
uma parede de lugar!!!
– Mas em software, “mudar uma parede de
lugar” é sim relativamente fácil...
• Tampouco é muito parecida com outras
engenharias!!!
• Software é flexível!!!

19. Engenharia de Software
Tradicional
• Desenvolvimento ad-hoc de software em geral
produz resultados muito ruins
– Especialmente em sistemas grandes
• Desejo de criar uma engenharia para que se
tenha controle sobre desenvolvimento de
software
• Engenharias tradicionais colocam grande ênfase
em projetar antes de construir
Copyleft Walfredo Cirne

20. Engenharia de Software Tradicional:
Analogia Errada
Programadores não são pedreiros.
Programadores são os verdadeiros engenheiros.
– Quem escreve numa linguagem formal?
– O código-fonte é o documento de projeto.
Compiladores são os pedreiros.
– Quem simplesmente segue as instruções de uma
descrição formal?
Mais sobre isso no vídeo “Real Software
Engineering” de Glenn Vanderburg [link] [post]

21. Manifesto para o
Desenvolvimento Ágil de
Software

22. http://agilemanifesto.org/iso/ptbr/

23. http://agilemanifesto.org/iso/ptbr/

24. Manifesto Ágil
Indivíduos e interações
processos e ferramentas
Software em funcionamento
documentação abrangente
Colaboração com o cliente
negociação de contratos
Responder a mudanças
seguir um plano

26. 10 anos!

27. 10 anos do Manifesto Ágil
Impacto crescente:
– Livros
– Conferências (AgileBrazil)
– Casos (SalesForce)
– Publicações (IEEE Software)
– Software (Testes unitários)

28. Métodos
e
Práticas Ágeis

29. Métodos e Práticas Ágeis

Extreme 
TDD
Programming 
Programação

Scrum Pareada

Kanban 
Refatoração

Lean 
Integração Contínua

Dojos de
Programação

30. SCRUM

31. Scrum
Provavelmente o método mais utilizado
Gerência de projetos (de software)
Desenvolvimento iterativo: ciclos (sprints)
Certificação
Papéis:
– ScrumMaster
– ProductOwner
– Team

32. Burndown Chart

33. Burndown Chart

34. KANBAN

37. Kanban
O método com menor quantidade de regras.
– Menos prescritivo
Provavelmente o mais fácil de introduzir numa empresa
resistente a mudanças.
Regras:
– Visualizar o fluxo de trabalho (quadro Kanban)
– Limitar do trabalho em andamento (por coluna, em
no mínimo uma coluna)
– Medir o tempo médio para completar cada item
Sem papéis obrigatórios.

38. TDD

39. TDD: Desenvolvimento Dirigido
por Testes
TDD = Test-Driven Development
Não é uma técnica de Testes, mas de Projeto

40. TDD: Desenvolvimento Dirigido
por Testes
Prática ágil relacionada à programação
Consiste em escrever os testes antes de escrever
o código da funcionalidade
Não é uma técnica de Testes, mas de Projeto
Testes automatizados - Ferramentas
Disciplina
Cobertura de código

41. Refatoração
• Refatorar é melhorar o código sem alterar sua
funcionalidade
• Antes de fazer uma mudança, você refatora o
código para que a mudança seja simples de
fazer
• Refatoração contínua possibilita manter um
design legal, mesmo com mudanças frequentes
Copyleft Walfredo Cirne

42. PROGRAMAÇÃO
PAREADA

43. Programação Pareada
Programação pareada é a prática onde um ou
mais programadores trabalham lado a lado em
um computador colaborando no mesmo projeto,
algoritmo, código ou teste.

44. Programação Pareada
O par é composto de:
– um motorista: que digita no computador ou
registra o projeto
– um navegador: que observa o trabalho do
motorista e identifica problemas, clarifica
questões e faz sugestões.
• Os parceiros devem trocar de papéis de tempos
em tempos para compartilhar o trabalho
igualmente e obter o máximo da sua
experiência com a programação pareada.

45. INTEGRAÇÃO
CONTÍNUA

46. Integração Contínua
“Integração Contínua é uma prática de
desenvolvimento de software onde os
membros de um time integram seu
trabalho frequentemente.
Geralmente cada pessoa integra pelo
menos diariamente – podendo haver
múltiplas integrações por dia.

47. Integração Contínua
Cada integração é verificada por um build automatizado
(incluindo testes) para detectar erros de integração o mais
rápido possível.
Muitos times acham que essa abordagem leva a uma
significante redução nos problemas de integração e
permite que um time desenvolva software coeso mais
rapidamente.”
Martin Fowler

48. REFATORAÇÃO

49. Refatoração
Reescrever código que já está
funcionando!
Com o apoio de ferramentas.

50. DOJOS DE
PROGRAMAÇÃO

52. Dojos de Programação
Atividade para aprender práticas ágeis na prática.
Ênfase na diversão e na socialização em paralelo
com o aprendizado.
Dojos de programação tem se espalhado pelo
mundo, em empresas, universidades, grupos de
programadores, etc.

53. Comparação entre Métodos Ágeis

54. Comparação entre Práticas Ágeis

56. Panorama da Pesquisa
em Métodos Ágeis

57. Alguns Artigos

58. Exemplos de Artigos
Empirical studies of agile
software development: A
systematic review
[ScienceDirect link]

59. Exemplos de Artigos
What Do We Know about Agile
Software Development?
[IEEE Xplore link]

60. Exemplos de Artigos
What Do We Know about Test-
Driven Development?
[IEEE Xplore link]

61. Exemplos de Artigos
Are Two Heads Better than One?
On the Effectiveness of Pair
Programming
[IEEE Xplore link]

62. Exemplos de Artigos
Most Common Mistakes in Test-
Driven Development Practice:
Results from an Online Survey
with Developers
[IEEE Xplore link]

63. Outros tipos de artigos
Estudos de caso
Novas “metodologias”
Softwares que auxiliam na adoção de técnicas
e/ou práticas
Software que verificam a utilização correta de
práticas

64. Como métodos e práticas
ágeis podem ser avaliados
cientificamente?

65. Avaliação
Pesquisa Quantitativa e Qualitativa
– Estudos de caso
– Entrevistas
– Questionários
– Métricas
Colaboração com outras áreas (por exemplo,
Psicologia)

66. LITERATURA
NÃO-CIENTÍFICA

67. LIVROS

69. BLOGS

71. SITES

73. CONFERÊNCIAS

76. Há impacto da pesquisa
científica sobre métodos
ágeis na prática da
indústria?

78. Exemplo de Produto
Desenvolvido com XP

79. Exemplo de Produto
Desenvolvido com XP

80. Quais são as
oportunidades de pesquisa
em métodos ágeis?

81. TDD é efetivo?

82. TDD
melhora
o design?

83. TDD
aumenta
a produtividade?

84. Quem diz
que está fazendo TDD
está MESMO
fazendo TDD?

85. Programação Pareada
aumenta ou diminui a
produtividade?

86. Programação Pareada
aumenta ou diminui a
qualidade?

87. Como aplicar métodos
ágeis no Setor Público?

88. Dojos de programação são
uma boa técnica para o
ensino de técnicas ágeis?

89. Dojos de programação são
uma boa técnica para o
ensino de técnicas ágeis?

90. Dojos de programação são
apenas um placebo?

91. CONSIDERAÇÕES FINAIS

92. Referências
BECK, K. Extreme Programming Explained: embrace change. Addison-Wesley, 1999.
KNIBERG, H. SKARIN, M. Kanban and Scrum - making the most of both. InfoQ, 2010.
Disponível em: http://www.infoq.com/minibooks/kanban-scrum-minibook. Acesso em: 17 de maio de
2011.
Links ao longo da apresentação.
Mais referências em:
http://www2.dainf.ct.utfpr.edu.br/Members/adolfo/pesquisa/agile-methods/references

93. Pesquisa em Métodos Ágeis Para
o Desenvolvimento de Software
Adolfo Neto
Departamento Acadêmico de Informática (DAINF)
Universidade Tecnológica Federal do Paraná (UTFPR)