Processos Ágeis de
Desenvolvimento de Software
Márcio Amorim
[email protected]
Milton Campos
[email protected]
Recife-PE, 2009
PADS
Estrutura do Capítulo
 9.1 Introdução
 9.2 Origem Ágil
 9.3 Extreme Programming – XP
 9.4 Scrum
 9.5 Feature Driven Development – FDD
 9.6 Dynamic Systems Development Method - DSDM
 9.7 Considerações Finais
 9.8 Exercício
 9.9 Referências Bibliográficas
CIN/UFPE
Márcio Amorim / Milton Campos
2
Estrutura do Processo no
Capítulo
9.5 Processo X
9.5.1 A Aplicabilidade do X.
9.5.2 Características do X.
9.5.3 Ciclo de Vida do X.
9.5.4 Papéis do X.
9.5.5 Práticas do X.
CIN/UFPE
Márcio Amorim / Milton Campos
3
Contextualização
A Engenharia de software vêm
recorrentemente enfrentando o cenário onde
...
as aplicações são cada vez mais complexas...
 o tempo de desenvolvimento é cada vez
menor...
 há necessidade de diminuição de custos ...
 busca constante pelo aumento da qualidade.
Contextualização
Processos tradicionais tornaram-se “pesados”
para a engenharia de software
 Muita burocracia
 Muita documentação
 Pouca flexibilidade a mudanças no projeto
 Não contemplam o cenário atual
 Conflito de interesses
Origem Ágil
 Reunião entre 17 gurus da comunidade de
desenvolvimento:
- Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn,
Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e
Dave Thomas.
Realizada entre os dias 11 e 13 de fevereiro de
2001 em uma estação de esqui nas montanhas
de Utah, Estados Unidos,
CIN/UFPE
Márcio Amorim / Milton Campos
6
Origem Ágil
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
CIN/UFPE
Márcio Amorim / Milton Campos
7
eXtreme Programming
Márcio Amorim
[email protected]
Milton Campos
[email protected]
XP
eXtreme Programming
 Em meados de 1990, Kent Beck procurou
formas mais simples e eficientes de desenvolver
software
- Identificou o que tornava simples e o que dificultava o
desenvolvimento de software
Em Março de 1996, ele iniciou um projeto com
novos conceitos que resultaram no processo
XP - eXtreme Programming
CIN/UFPE
Márcio Amorim / Milton Campos
9
eXtreme Programming
“Trata-se de uma metodologia ágil para
equipes
pequenas
e
médias
desenvolvendo software com requisitos
vagos e em constante mudança”
Kent Beck
CIN/UFPE
Márcio Amorim / Milton Campos
10
Características do XP
 Equipes pequenas e médias;
 Requisitos vagos;
 Valores, Princípios e Práticas;
 Foco na programação.
CIN/UFPE
Márcio Amorim / Milton Campos
11
Papéis do XP
Gerente de Projeto
Analista de Teste
Coach
Desenvolvedor
Cliente
Redator Técnico
CIN/UFPE
Márcio Amorim / Milton Campos
12
Valores do XP
 Comunicação;
 Simplicidade;
 Feedback; e
 Coragem.
CIN/UFPE
Márcio Amorim / Milton Campos
13
Princípios do XP
 Feedback rápido;
 Assumir simplicidade;
 Mudanças incrementais; e
 Trabalho de qualidade.
CIN/UFPE
Márcio Amorim / Milton Campos
14
Práticas do XP
 Cliente Presente;
 Jogo de Planejamento;
 Stand Up Meeting;
 Programação Pareada;
 Desenvolvimento guiado pelos testes;
 Refatoração;
CIN/UFPE
Márcio Amorim / Milton Campos
15
Práticas do XP
 Código Coletivo;
 Código Padronizado;
 Projeto Simples;
 Metáfora;
 Ritmo Sustentável;
 Integração Continua; e
 Pequenas Versões.
CIN/UFPE
Márcio Amorim / Milton Campos
16
Ciclo de Vida do XP
 A fase de exploração
- É anterior à construção do sistema;
- Investigações de possíveis soluções são feitas e
verifica-se a viabilidade de tais soluções;
- Os programadores elaboram possíveis arquiteturas
e fazem considerações sobre o ambiente
tecnológico
(hardware,
rede,
software,
performance, tráfego) onde o sistema irá rodar.
CIN/UFPE
Márcio Amorim / Milton Campos
17
Ciclo de Vida do XP
 A fase de planejamento inicial
- Definição das estórias pelo cliente;
- Os programadores assinalam dificuldades;
- Escolhas das estórias por valor de negócio.
CIN/UFPE
Márcio Amorim / Milton Campos
18
Ciclo de Vida do XP
 Iterações do release
- São escritos os casos de teste funcionais e de
unidade. Os programadores vão seguindo mais ou
menos o seguinte fluxo de atividades na seguinte
ordem (em cada iteração): escrita dos casos de
testes; projeto e refatoramento; codificação;
realização dos testes; e integração.
CIN/UFPE
Márcio Amorim / Milton Campos
19
Ciclo de Vida do XP
 A fase de manutenção
- pode ser considerada como uma característica
inerente a um projeto XP;
- Em XP você está simultaneamente produzindo
novas funcionalidades, mantendo o sistema
existente rodando, incorporando novas pessoas na
equipe e melhorando o código.
CIN/UFPE
Márcio Amorim / Milton Campos
20
Ciclo de Vida do XP
 A fase de morte
- Atendendo o que foi solicitado pelo cliente;
- Economicamente inviável, devido a dificuldades de
adicionar funcionalidades a um custo baixo e
devido a uma alta taxa de erros.
CIN/UFPE
Márcio Amorim / Milton Campos
21
Referências Bibliográficas
 MANHÃES Teles, Vinícius. Extreme Programming. 1. ed. Novatec
Editora, 2004.
 BECK, Kent. Programação Extrema Explicada: acolha as mudanças.
1. ed. Bookman, 2004.
 MANHÃES Teles, Vinícius. Um Estudo de Caso da Adoção das
Práticas e Valores do Extreme Programming. Dissertação (mestrado
em informática) – Universidade Federal do Rio de Janeiro - UFRJ, IM
/ DCC, 2005.
CIN/UFPE
Márcio Amorim / Milton Campos
22
Scrum
Márcio Amorim
[email protected]
Milton Campos
[email protected]
SCRUM
Ênfase dada ao gerenciamento do projeto.
Atividades de monitoramento e feedback
Não estabelece técnicas para o
desenvolvimento
Equipes pequenas (máximo 7 pessoas)
Requisitos que são pouco estáveis ou
desconhecidos
Ciclos curtos (Sprint máx. 30 dias)
Envolvimento do “cliente”
Papéis no Scrum
Product Owner (PO): representa os
interesses de todos no projeto, define as
funcionalidades e as priorizam.
Scrum Master (SM): facilitador, apóia a
equipe no uso adequado do processo,
promove reuniões, remove os
impedimentos
Time: desenvolve as funcionalidades
Main Flow
Product Backlog
Backlog item (BLI)
Business Value
(BV)
[BLI001] As a standard user, search for a movie
1000
[BLI002] As a standard user, search for movie reviews
1000
[BLI003] As a standard user, view the top movies
1000
[BLI004] As a standard user, search for theaters
700
[BLI005] As a standard user, search for movie trailers
700
[BLI006] As a standard user, create the user profile
500
[BLI007] As a standard user, edit the user profile
300
[BLI008] Integration with LDAP
100
Main Flow
Sprint Planning 1
BLI
BV
Size
[Story Points (SP)]
BV/SP
[IBL003] As a standard user, view the top
movies
1000
2
500
[IBL002] As a standard user, search for movie
reviews
1000
3
333
[IBL001] As a standard user, search for a movie
1000
5
200
[IBL004] As a standard user, search for theaters
700
13
53
[IBL005] As a standard user, search for movie
trailers
700
13
53
[IBL006] As a standard user, create the user
profile
500
21
23
Main Flow
Sprint Backlog
IBLs
[IBL001
]
[IBL003
]
[IBL002
]
Tasks To Do
Work In Progress
Done
Main Flow
Daily Scrums
Reunião diária de 15 minutos
Mesmo local e hora todo os dias
Cada integrante do time, responde:
- O que você terminou desde a última reunião?
- O que vai terminar antes da próxima reunião?
- Quais os impedimentos?
Sprint – The Task Board
IBLs
[IBL001
]
[IBL003
]
[IBL002
]
Tasks To Do
Work In Progress
Done
Burndown Chart
Main Flow
Sprint Review Meeting
Participa todos os stakeholders
Apresentação do que foi “feito” durante a
Sprint
Sprint Retrospective
Participa o time e o PO
Melhoria do Processo
Soluções para os problemas críticos
Referências Bibliográficas
Schwaber, K., Agile Project Management With Scrum, Microsoft, 2004.
Schwaber, K. and Beedle, M., Agile Software Development With Scrum. NJ:
Prentence Hall, 2002.
CIN/UFPE
Márcio Amorim / Milton Campos
39
Feature Driven Development
Márcio Amorim
[email protected]
Milton Campos
[email protected]
FDD
Feature Driven Development
 ... após 2 anos de consultoria, 3.500 páginas de
casos de uso e um modelo de objetos com
centenas de classes, foi avaliado como
impossível.
CIN/UFPE
Márcio Amorim / Milton Campos
41
Feature Driven Development
 Criada em 1997 em um grande projeto em
Java para o United Overseas Bank, em
Singapura;
 Nasceu a partir da experiência de análise
e modelagem orientadas por objetos de
Peter Coad, e de gerenciamento de
projetos de Jeff De Luca;
CIN/UFPE
Márcio Amorim / Milton Campos
42
Feature Driven Development
 Primeira publicação em 1999, no do livro
Java Modeling in Color with UML, de Peter
Coad, Eric Lefebvre e Jeff De Luca;
 Em 2002, Stephen Palmer e John Mac
Felsing publicaram o livro A Pratical Guide
to Feature Driven Development, com a
versão completa;
CIN/UFPE
Márcio Amorim / Milton Campos
43
Feature Driven Development
 Em 2003, David Anderson, o livro Agile
Management for Software Engineering:
Using the Theory of Constraints for
Business Results, considerado por muitos
como um marco na literatura ágil.
CIN/UFPE
Márcio Amorim / Milton Campos
44
Feature Driven Development
 Metodologia ágil para o processo de
engenharia de software, com foco na
entrega frequente do sistema funcionando
e na utilização de boas práticas durante o
ciclo de desenvolvimento.
CIN/UFPE
Márcio Amorim / Milton Campos
45
Características do FDD
 Situa-se numa posição intermediária entre
as abordagens mais tradicionais e as
ágeis;
 Envolvimento do cliente nos processos
de planejamento e desenvolvimento de
software;
CIN/UFPE
Márcio Amorim / Milton Campos
46
Características do FDD
 Não é extremamente focada apenas na
programação ou no modelo, mas sim
utiliza o bom senso para abstrair o melhor
dos dois mundos;
 Tamanho dos times de 16 – 20 membros,
suportando composições bem maiores;
CIN/UFPE
Márcio Amorim / Milton Campos
47
Características do FDD
 Entrega resultados funcionais e tangíveis
a cada 2 semanas ou menos;
Pequenos blocos de funcionalidades
(features) valorizados pelo cliente;
 Planejamento detalhado e guiado para
medição;
 Produção de software com qualidade.
CIN/UFPE
Márcio Amorim / Milton Campos
48
Papéis do FDD
Suporte Documentador
Testador
Gestor de projeto
Adm. de sistemas
Eng. de builds
Gestor de
desenvolvimento
Chefe de design
CLIENTE
Programador
chefe
Dono de classe
CIN/UFPE
Guru de
linguagem
Gestor de
atividade
Especialista
Márcio Amorim / Milton Campos
Papéis:
Primário
Secundário
Adicionais
49
Práticas
 Modelagem de objetos de domínio;
 Desenvolvimento por feature;
 Posse individual do código/classe;
 Equipes de features;
 Inspeções e builds reguladores;
 Gerenciamento de configuração;
 Relatório/visibilidade de resultados.
CIN/UFPE
Márcio Amorim / Milton Campos
50
Estrutura
 A FDD é uma metodologia muito objetiva.
Possui apenas duas fases:
Concepção & Planejamento: Pensar um pouco
antes de fazer (tipicamente de 1 a 2 semanas);
Construção: Fazer de forma iterativa
(tipicamente em iterações de 2 semanas).
CIN/UFPE
Márcio Amorim / Milton Campos
51
Estrutura
 Possui cinco processos bem definidos e
integrados:
Desenvolver um
Modelo Abrangente:
Análise Orientada
por Objetos
Construir a Lista de
Funcionalidades:
Decomposição
Funcional
Detalhar por
Funcionalidade:
Desenho (Projeto)
Orientado por Objetos
CIN/UFPE
Planejar por
Funcionalidade:
Planejamento
Incremental
Construir por
Funcionalidade:
Programação e Teste
Orientados por Objetos
Márcio Amorim / Milton Campos
52
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
53
Os 5 processos
DMA
 É uma atividade inicial que abrange todo o
projeto, na qual realiza-se um estudo dirigido
sobre o escopo do sistema e seu contexto, bem
como outros mais detalhados sobre o domínio
do negócio para cada área a ser modelada.
CLIENTE
Programador-chefe
Especialista
CIN/UFPE
Márcio Amorim / Milton Campos
Arquiteto-chefe
54
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
55
Os 5 processos
CLF
 É uma atividade inicial que abrange todo o
projeto, para identificar todas as funcionalidades
que satisfaçam aos requisitos, formando assim a
lista categorizada de funcionalidades.
- Decompor funcionalmente o domínio em áreas de negócio;
- Atividades de negócio dentro delas; e
- Passos dentro de cada atividade de negócio.
CLIENTE
Especialista
CIN/UFPE
Programador-chefe
Márcio Amorim / Milton Campos
Arquiteto-chefe
56
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
57
Os 5 processos
PPF
 É uma atividade inicial que abrange todo o
projeto,
para
produzir
o
plano
de
desenvolvimento.
- Planejam a ordem a partir das dependências, carga de
trabalho do time e complexidade da funcionalidade;
CLIENTE
Gestor de Projeto
CIN/UFPE
Gestor de Desenvolvimento
Márcio Amorim / Milton Campos
Programador-chefe
58
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
59
Os 5 processos
DPF
 É uma atividade executada para cada
funcionalidade, para produzir o pacote de
projeto (design) para ela.
- Seleciona as funcionalidades e identificam os donos da
classe;
- Produz o(s) diagrama(s) de seqüência para a(s)
funcionalidade(s) atribuída(s) e refina o modelo de objetos.
Planejamento
.........................................
.........................................
.........................................
.........................................
CLIENTE
.........................................
Planejamento completo
CIN/UFPE
Dono da classe
Márcio Amorim / Milton Campos
Programador-chefe
60
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
61
Os 5 processos
CPF
 É uma atividade executada para cada
funcionalidade, para produzir uma função com
valor para o cliente (funcionalidade).
- Os donos das classes implementam;
- O código passa por testes e inspeção;
- O código é promovido à versão atual (build).
CLIENTE
Eng. de build
CIN/UFPE
Dono da classe
Dono da classe
Márcio Amorim / Milton Campos
Programador-chefe
62
Estrutura
CIN/UFPE
Márcio Amorim / Milton Campos
63
Estrutura - medição
4 - DPF
Estudo
dirigido
sobre o
domínio
1%
Desenho
do projeto
40%
5 - CPF
Inspeção
do
desenho
3%
Codificaçã
o
45%
Inspeção
de código
10%
Promoção
ao build
1%
 No ciclo iterativo (processos 4 e 5), o progresso é
medido com base em 6 marcos ( milestones) bem
definidos;
 A cada etapa cumprida, o percentual respectivo é
agregado ao total de progresso da feature.
CIN/UFPE
Márcio Amorim / Milton Campos
64
Estrutura - progresso
Feature
Status disponíveis:
NÃO
INICIADA
ANDAMEN CONCLUÍ ABORTA
TO
DO
DA
Atualizar doc. requisitos
Atualizar VO
Atualizar model
Atualizar Magic Search para levar em consideração a
nova coluna
Atualizar datagrid para listar os test cases
BLI 7 - informar qual o Listar os possíveis test cases na tela de criação/edição
caso de teste do bug do bug
Persistir o test case do bug no banco de dados
Atualizar Choose Column para visualizar / ocultar
testcase
Atualizar o histório pra salvar as alterações dos Testes
Atualizar planilha de testes
Executar testes sistêmicos
CIN/UFPE
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
CONCLUÍD
O
Ana
24-May
24-May
Ana
24-May
24-May
Milton
25-May
25-May
Ana
25-May
25-May
Ana
24-May
26-May
Ana
25-May
25-May
Ana
25-May
25-May
Milton
28-May
28-May
26-May
26-May
29-May
31-May
ANDAMEN
TO
Milton
NÃO
INICIADA Camila
Márcio Amorim / Milton Campos
65
...,... implantação das metodologias de OOAD de
Peter Coad e de gerência de projetos de Jeff De
Luca.
...,...,... 15 meses após a contratação da dupla,
2.000 features entregues por uma equipe de 50
pessoas.
CIN/UFPE
Márcio Amorim / Milton Campos
66
Links e Materiais
 Portal FDD, mantido por Jeff De Luca, gerente do projeto original e criador
da FDD
 FDD na Nebulon, empresa de Jeff De Luca
 Stephen Palmer, co-autor do Guia Prático da FDD, consultor sênior da
Borland UK
 FDD Channel no Agile Management, site de David Anderson, autor do livro
de mesmo nome, e participante do projeto que deu origem à FDD
 FDD na Agile Alliance Process Exchange, empresa de John Mac Felsing,
co-autor do Guia Prático da FDD
 Grupo de Usuários da FDD (em Português Brasileiro)
 FDD na Heptagon
 FDD na InfoQ
CIN/UFPE
Márcio Amorim / Milton Campos
67
Links e Materiais
 Mini-curso de FDD, ministrado pelo Heptaman na BorCon 2005
 Entrevista (mp3) com Jeff De Luca, para a Software Engineering Radio, da
Alemanha
 Entrevista (pdf) com Jeff De Luca, para a IT Agile, da Alemanha
 Descrição original dos processos da FDD, no capítulo 6 do livro "Java
Modeling in Color with UML" (1999)
 Video com David Anderson apresentando FDD, juntamente com Alistair
Cockburn apresentando Crystal
 FDD em uma Casca de Banana, por Alexandre Magno
 Algumas implementações da FDD, por Jeff De Luca
 FDD: An Agile Alternative to XP, por Brad Appleton (CM Crossroads)
CIN/UFPE
Márcio Amorim / Milton Campos
68
Links e Materiais
 FDD em CM Crossroads, diversos artigos e muitos links sobre FDD, UML em
Cores e outros recursos (por Brad Appleton)
 Understanding XP Through FDD FDD and XP: A Comparison, por Stephen
Palmer
 Agile Modeling and Feature-Driven Development, por Scott Ambler
 Cognizant FDD Implementation, uma grande empresa indiana que ampliou a
FDD
 CMMI or Agile: Why Not Embrace Both! Nota técnica oficial do SEI sobre a
combinação entre o CMMI e Agile (com menções sobre a FDD)
CIN/UFPE
Márcio Amorim / Milton Campos
69
Referências Bibliográficas
ANDERSON, D.J.. Agile Management for Software Engineering: Using the
Theory of Constraints for Business Results. 2003
COAD, P.; et al. Java modeling in color with UML: enterprise components
and process. Upper Saddle River, NJ: Prentice Hall, 1999.
PALMER, Stephen. A practical Guide to Feature Driven Development. 2002.
CIN/UFPE
Márcio Amorim / Milton Campos
70
Dynamic Systems Development
Method
Márcio Amorim
[email protected]
Milton Campos
[email protected]
DSDM
DSDM
Dynamic Systems Development Method
Originalmente baseada no RAD
Progenitor do XP
Participação ativa dos usuários
Fixa tempo e recursos ajustando a quantia de
funcionalidades
Pequenas equipes
Suporta mudanças nos requisitos durante o
ciclo de vida
Ciclo de Vida DSDM
Técnicas do DSDM
Timeboxing: Encapsulamento de tempo.
Requisitos são escalonados com o
princípio de Moscow.
TEM de ter isto.
DEVE ter isto se for possível ter todo.
PODE ter isto se não afetar o resto.
NÃO VAI ter isto agora mas SERIA bom ter no
futuro.
Técnicas do DSDM
Prototipagem: descoberta antecipada de
possíveis problemas e testes pelos usuários.
Workshops: stakeholders reúnem-se e discutem o
projecto.
Testes: obrigado em todas as iterações = boa
qualidade
Referências Bibliográficas
DSDM Consortium. Delivering Aginle Business Solution on Time.
[Online]. Disponível em http://www.dsdm.org. Acesso em 18.09.2009.
[Flowler, 2003] Fowler, Martin. The New Methodology. [Online]. Disponível em
http://www.martinfowler.com/articles/newMethodology.html.
Acesso
em
07.09/2009
CIN/UFPE
Márcio Amorim / Milton Campos
76
Tradicionais x Ágeis
Considerações Finais
Processos Ágeis ...
... “Resultados frequentes,
tangíveis e funcionais”.
CIN/UFPE
Márcio Amorim / Milton Campos
78
Obrigado!
Márcio Amorim
[email protected]
Milton Campos
[email protected]
PADS
Processos Ágeis de
Desenvolvimento de Software