Pesquisa em Métodos Ágeis para o Desenvolvimento de Software

2.495 visualizações

Publicada em

Slides do mini-curso apresentado em 10.06.2011 no X Simpósio Brasileiro em Qualidade de Software (Curitiba-PR).

Mais informações em http://bit.ly/eyYo8Y

Publicada em: Educação, Tecnologia
2 comentários
4 gostaram
Estatísticas
Notas
  • Obrigado pelo comentário! Os slides são para um mini-curso. Não tem a pretensão de ser um texto técnico. São apenas um auxílio informal.

    Mas essa questão depende de quem estiver na banca e do contexto do uso do termo. Um dos artigos mais citados na área, este aqui, http://www.sintef.no/home/Publications/Publication/?page=27334, usa
    'agile methods' duas vezes só no abstract.

    Não conheço artigos que usam 'modelos ágeis de desenvolvimento de software'.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • O slide ficou bom.
    Mas gostaria de fazer uma observação:
    Não existem 'Métodos Ágeis'. Isto é um termo errado que é utilizado muito na internet.
    Também é errado dizer 'Metodologias Ágeis' e 'Processos Ágeis' o correto é 'Modelos Ágeis de Desenvolvimento de Software'.

    Pode parecer besteira, mas se vc chegar em uma banca para defender uma tese e utilizar o termo 'Métodos Ágeis' poderá ser reprovado na hora(se tiver sendo avaliado por bons professores, que com certeza pregam pelo uso correto dos termos e definições).

    Abraço e sucesso!
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
2.495
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
58
Comentários
2
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Pesquisa em Métodos Ágeis para o Desenvolvimento de Software

  1. 1. Pesquisa em Métodos Ágeis Parao Desenvolvimento de Software Adolfo Neto Departamento Acadêmico de Informática (DAINF) Universidade Tecnológica Federal do Paraná (UTFPR)
  2. 2. OBJETIVOS
  3. 3. MÉTODOS ÁGEIS
  4. 4. DESCREVER
  5. 5. COMPARAR
  6. 6. LITERATURA CIENTÍFICA
  7. 7. LITERATURANÃO-CIENTÍFICA
  8. 8. PROBLEMASEM ABERTO
  9. 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. 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. 11. EXEMPLO DE MÉTODO ÁGIL:PROGRAMAÇÃO EXTREMA
  12. 12. PROGRAMAR:ATIVIDADE-CHAVE
  13. 13. DISCIPLINA
  14. 14. Extreme ProgrammingO primeiro livro (BECK, 1999).Trechos - Foreword, Erich Gamma:“Extreme Programming (XP) nominates coding as the key activity throughout a software project. This cant possibly work!”
  15. 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. 16. Extreme Programming“XP takes commonsense principles and practices to extreme levels.” – Pair programming – Unit testing – Functional testing – Refactoring – Continuous integration
  17. 17. Um Episódio de Desenvolvimento
  18. 18. Engenharia de SoftwareNão é parecida com Engenharia Civil!– Após construir uma casa não é fácil mudaruma parede de lugar!!!– Mas em software, “mudar uma parede delugar” é sim relativamente fácil...• Tampouco é muito parecida com outrasengenharias!!!• Software é flexível!!!
  19. 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. 20. Engenharia de Software Tradicional: Analogia ErradaProgramadores 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. 21. Manifesto para oDesenvolvimento Ágil de Software
  22. 22. http://agilemanifesto.org/iso/ptbr/
  23. 23. http://agilemanifesto.org/iso/ptbr/
  24. 24. Manifesto ÁgilIndivíduos e interações processos e ferramentasSoftware em funcionamento documentação abrangenteColaboração com o cliente negociação de contratosResponder a mudançasseguir um plano
  25. 25. 10 anos!
  26. 26. 10 anos do Manifesto ÁgilImpacto crescente: – Livros – Conferências (AgileBrazil) – Casos (SalesForce) – Publicações (IEEE Software) – Software (Testes unitários)
  27. 27. Métodos ePráticas Ágeis
  28. 28. 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
  29. 29. SCRUM
  30. 30. ScrumProvavelmente o método mais utilizadoGerência de projetos (de software)Desenvolvimento iterativo: ciclos (sprints)CertificaçãoPapéis: – ScrumMaster – ProductOwner – Team
  31. 31. Burndown Chart
  32. 32. Burndown Chart
  33. 33. KANBAN
  34. 34. KanbanO método com menor quantidade de regras. – Menos prescritivoProvavelmente 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 itemSem papéis obrigatórios.
  35. 35. TDD
  36. 36. TDD: Desenvolvimento Dirigido por TestesTDD = Test-Driven DevelopmentNão é uma técnica de Testes, mas de Projeto
  37. 37. TDD: Desenvolvimento Dirigido por TestesPrática ágil relacionada à programaçãoConsiste em escrever os testes antes de escrever o código da funcionalidadeNão é uma técnica de Testes, mas de ProjetoTestes automatizados - FerramentasDisciplinaCobertura de código
  38. 38. 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
  39. 39. PROGRAMAÇÃO PAREADA
  40. 40. Programação PareadaProgramaçã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.
  41. 41. Programação PareadaO 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.
  42. 42. INTEGRAÇÃO CONTÍNUA
  43. 43. 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.
  44. 44. Integração ContínuaCada 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
  45. 45. REFATORAÇÃO
  46. 46. RefatoraçãoReescrever código que já está funcionando!Com o apoio de ferramentas.
  47. 47. DOJOS DEPROGRAMAÇÃO
  48. 48. Dojos de ProgramaçãoAtividade 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.
  49. 49. Comparação entre Métodos Ágeis
  50. 50. Comparação entre Práticas Ágeis
  51. 51. Panorama da Pesquisa em Métodos Ágeis
  52. 52. Alguns Artigos
  53. 53. Exemplos de ArtigosEmpirical studies of agilesoftware development: A systematic review [ScienceDirect link]
  54. 54. Exemplos de ArtigosWhat Do We Know about Agile Software Development? [IEEE Xplore link]
  55. 55. Exemplos de ArtigosWhat Do We Know about Test- Driven Development? [IEEE Xplore link]
  56. 56. Exemplos de ArtigosAre Two Heads Better than One? On the Effectiveness of Pair Programming [IEEE Xplore link]
  57. 57. Exemplos de ArtigosMost Common Mistakes in Test- Driven Development Practice: Results from an Online Survey with Developers [IEEE Xplore link]
  58. 58. Outros tipos de artigosEstudos de casoNovas “metodologias”Softwares que auxiliam na adoção de técnicas e/ou práticasSoftware que verificam a utilização correta de práticas
  59. 59. Como métodos e práticaságeis podem ser avaliados cientificamente?
  60. 60. AvaliaçãoPesquisa Quantitativa e Qualitativa – Estudos de caso – Entrevistas – Questionários – MétricasColaboração com outras áreas (por exemplo, Psicologia)
  61. 61. LITERATURANÃO-CIENTÍFICA
  62. 62. LIVROS
  63. 63. BLOGS
  64. 64. SITES
  65. 65. CONFERÊNCIAS
  66. 66. Há impacto da pesquisacientífica sobre métodos ágeis na prática da indústria?
  67. 67. Exemplo de ProdutoDesenvolvido com XP
  68. 68. Exemplo de ProdutoDesenvolvido com XP
  69. 69. Quais são asoportunidades de pesquisa em métodos ágeis?
  70. 70. TDD é efetivo?
  71. 71. TDD melhorao design?
  72. 72. TDD aumentaa produtividade?
  73. 73. Quem dizque está fazendo TDD está MESMO fazendo TDD?
  74. 74. Programação Pareadaaumenta ou diminui a produtividade?
  75. 75. Programação Pareadaaumenta ou diminui a qualidade?
  76. 76. Como aplicar métodoságeis no Setor Público?
  77. 77. Dojos de programação são uma boa técnica para oensino de técnicas ágeis?
  78. 78. Dojos de programação são uma boa técnica para oensino de técnicas ágeis?
  79. 79. Dojos de programação são apenas um placebo?
  80. 80. CONSIDERAÇÕES FINAIS
  81. 81. ReferênciasBECK, 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
  82. 82. Pesquisa em Métodos Ágeis Parao Desenvolvimento de Software Adolfo Neto Departamento Acadêmico de Informática (DAINF) Universidade Tecnológica Federal do Paraná (UTFPR)

×