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

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)

description

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

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

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 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

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

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)