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)
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Pesquisa em Métodos Ágeis Para o Desenvolvimento de Software
Adolfo NetoDepartamento Acadêmico de Informática (DAINF)
Universidade Tecnológica Federal do Paraná (UTFPR)
OBJETIVOS
MÉTODOSÁGEIS
DESCREVER
COMPARAR
LITERATURACIENTÍFICA
LITERATURANÃO-CIENTÍFICA
PROBLEMASEM ABERTO
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)
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.
EXEMPLO DE MÉTODO ÁGIL:
PROGRAMAÇÃO EXTREMA
PROGRAMAR:ATIVIDADE-CHAVE
DISCIPLINA
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!”
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.”
Extreme Programming
“XP takes commonsense principles and practices to extreme levels.”
– Pair programming– Unit testing– Functional testing– Refactoring– Continuous integration
Um Episódio de Desenvolvimento
Engenharia de Software
Nã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!!!
Engenharia de SoftwareTradicional
• 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
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]
Manifesto para oDesenvolvimento Ágil de
Software
http://agilemanifesto.org/iso/ptbr/
http://agilemanifesto.org/iso/ptbr/
Manifesto ÁgilIndiví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
10 anos!
10 anos do Manifesto Ágil
Impacto crescente:– Livros– Conferências (AgileBrazil)– Casos (SalesForce)– Publicações (IEEE Software)– Software (Testes unitários)
Métodose
Práticas Ágeis
Métodos e Práticas Ágeis
TDD Programação
Pareada Refatoração Integração Contínua Dojos de
Programação
Extreme Programming
Scrum Kanban Lean
SCRUM
Scrum
Provavelmente o método mais utilizadoGerência de projetos (de software)Desenvolvimento iterativo: ciclos (sprints)CertificaçãoPapéis:
– ScrumMaster– ProductOwner– Team
Burndown Chart
KANBAN
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.
TDD
TDD: Desenvolvimento Dirigido por Testes
TDD = Test-Driven DevelopmentNão é uma técnica de Testes, mas de Projeto
TDD: Desenvolvimento Dirigido por Testes
Prá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
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
PROGRAMAÇÃO
PAREADA
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.
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.
INTEGRAÇÃO
CONTÍNUA
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.
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
REFATORAÇÃO
Refatoração
Reescrever código que já está funcionando!
Com o apoio de ferramentas.
DOJOS DE
PROGRAMAÇÃO
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.
Comparação entre Métodos Ágeis
Comparação entre Práticas Ágeis
Panorama da Pesquisa em Métodos Ágeis
Alguns Artigos
Exemplos de Artigos
Empirical studies of agile software development: A
systematic review[ScienceDirect link]
Exemplos de Artigos
What Do We Know about Agile Software Development?
[IEEE Xplore link]
Exemplos de Artigos
What Do We Know about Test-Driven Development?
[IEEE Xplore link]
Exemplos de Artigos
Are Two Heads Better than One? On the Effectiveness of Pair
Programming[IEEE Xplore link]
Exemplos de Artigos
Most Common Mistakes in Test-Driven Development Practice: Results from an Online Survey
with Developers[IEEE Xplore link]
Outros tipos de artigos
Estudos 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
Como métodos e práticas ágeis podem ser avaliados
cientificamente?
Avaliação
Pesquisa Quantitativa e Qualitativa– Estudos de caso– Entrevistas– Questionários– Métricas
Colaboração com outras áreas (por exemplo, Psicologia)
LITERATURA
NÃO-CIENTÍFICA
LIVROS
BLOGS
SITES
CONFERÊNCIAS
Há impacto da pesquisa científica sobre métodos
ágeis na prática da indústria?
Exemplo de Produto Desenvolvido com XP
Exemplo de Produto Desenvolvido com XP
Quais são as oportunidades de pesquisa
em métodos ágeis?
TDD é efetivo?
TDD melhora
o design?
TDDaumenta
a produtividade?
Quem diz que está fazendo TDD
está MESMO fazendo TDD?
Programação Pareada aumenta ou diminui a
produtividade?
Programação Pareada aumenta ou diminui a
qualidade?
Como aplicar métodos ágeis no Setor Público?
Dojos de programação são uma boa técnica para o
ensino de técnicas ágeis?
Dojos de programação são uma boa técnica para o
ensino de técnicas ágeis?
Dojos de programação são apenas um placebo?
CONSIDERAÇÕES FINAIS
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
Pesquisa em Métodos Ágeis Para o Desenvolvimento de Software
Adolfo NetoDepartamento Acadêmico de Informática (DAINF)
Universidade Tecnológica Federal do Paraná (UTFPR)
Related Documents
