Upload
rafael-mora
View
215
Download
1
Embed Size (px)
Citation preview
Processos Ágeis de Desenvolvimento de Software
PADSPADS
Márcio [email protected]
Milton [email protected]
Recife-PE, 2009
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ítulo9.5 Processo X9.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çãoA 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 ÁgilManifesto 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
Em meados de 1990, Kent BeckKent 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 BeckKent 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
CIN/UFPE Márcio Amorim / Milton Campos 12
Coach
Desenvolvedor
Analista de Teste
Redator Técnico
Gerente de Projeto
Cliente
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Ênfase dada ao gerenciamento do projeto.Atividades de monitoramento e feedbackNã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
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
Product Backlog
Main Flow
Sprint Planning 1BLI 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 Tasks To Do Work In Progress Done
[IBL001]
[IBL003]
[IBL002]
Require
ments
Analysis and
DesignCoding
Test Code Review
Deploy
ment
Requirements
Analysis and Design
Coding
TestCode
Review
Deployment
Requirements
Analysi
s and
DesignCoding
TestCode Review
Deployment
Main Flow
Reunião diária de 15 minutosMesmo local e hora todo os diasCada 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?
Daily Scrums
Sprint – The Task BoardIBLs Tasks To Do Work In Progress Done
[IBL001]
[IBL003]
[IBL002]
Require
ments
Analysis and
DesignCoding
Test Code Review
Deploy
ment
Requirements
Analysis and Design
Coding
Test
Code Review Deploy
ment
Requirements
Analysi
s and
DesignCoding
TestCode Review
Deployment
dev 0
dev 1
imp
Burndown Chart
Main Flow
Participa todos os stakeholdersApresentação do que foi “feito” durante a Sprint
Sprint Review Meeting
Participa o time e o POMelhoria do ProcessoSoluções para os problemas críticos
Sprint Retrospective
Referências BibliográficasSchwaber, 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
... 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
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
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
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
CIN/UFPE Márcio Amorim / Milton Campos
Gestor de projeto
Gestor de desenvolvimento
Chefe de design
Programador chefe
Dono de classe Especialista
Gestor de atividade
Guru de linguagem
Eng. de builds
Adm. de sistemas
CLIENTE
TestadorSuporte Documentador
PrimárioSecundárioAdicionais
Papéis:
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:
CIN/UFPE Márcio Amorim / Milton Campos 51
Estrutura
Possui cinco processos bem definidos e integrados:
CIN/UFPE Márcio Amorim / Milton Campos
Desenvolver um Modelo Abrangente: Análise Orientada por Objetos
Construir a Lista de Funcionalidades: DecomposiçãoFuncional
Planejar por Funcionalidade: PlanejamentoIncremental
Detalhar por Funcionalidade: Desenho (Projeto) Orientado por Objetos
Construir por Funcionalidade: Programação e Teste Orientados por Objetos
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.
CIN/UFPE Márcio Amorim / Milton Campos
Especialista Programador-chefe Arquiteto-chefeCLIENTE
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.
CIN/UFPE Márcio Amorim / Milton Campos
Especialista Programador-chefe Arquiteto-chefe
CLIENTE
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;
CIN/UFPE Márcio Amorim / Milton Campos
Gestor de Projeto Gestor de Desenvolvimento Programador-chefe
CLIENTE
58
Estrutura
CIN/UFPE Márcio Amorim / Milton Campos 59
CLIENTE
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.
CIN/UFPE Márcio Amorim / Milton Campos
Planejamento completo Dono da classe Programador-chefe
Planejamento..................................................................................
.........................................
.........................................
.........................................
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).
CIN/UFPE Márcio Amorim / Milton Campos
Eng. de build Dono da classe Programador-chefeDono da classe
CLIENTE
62
Estrutura
CIN/UFPE Márcio Amorim / Milton Campos 63
Estrutura - medição
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
Estudo dirigido sobre o domínio
1%
Desenho do projeto
40%
Inspeção do
desenho3%
Codificação
45%
Inspeção de código
10%
Promoção ao build
1%
4 - DPF 5 - CPF
64
Estrutura - progresso
CIN/UFPE Márcio Amorim / Milton Campos
Feature Status disponíveis: NÃO INICIADA
ANDAMENTO
CONCLUÍDO
ABORTADA
BLI 7 - informar qual o caso de teste do bug
Atualizar doc. requisitos
Atualizar VO CONCLUÍDO Ana 24-May 24-May
Atualizar model CONCLUÍDO Ana 24-May 24-May
Atualizar Magic Search para levar em consideração a nova coluna
CONCLUÍDO Milton 25-May 25-May
Atualizar datagrid para listar os test cases CONCLUÍDO Ana 25-May 25-May
Listar os possíveis test cases na tela de criação/edição do bug
CONCLUÍDO Ana 24-May 26-May
Persistir o test case do bug no banco de dados CONCLUÍDO Ana 25-May 25-May
Atualizar Choose Column para visualizar / ocultar testcase
CONCLUÍDO Ana 25-May 25-May
Atualizar o histório pra salvar as alterações dos Testes CONCLUÍDO Milton 28-May 28-May
Atualizar planilha de testes ANDAMENTO Milton 26-May 26-May
Executar testes sistêmicos NÃO INICIADA Camila 29-May 31-May
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
CIN/UFPE Márcio Amorim / Milton Campos
Referências BibliográficasANDERSON, D.J.. Agile Management for Software Engineering: Using the Theory of Constraints for Business Results. 2003COAD, 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.
70
DSDMDynamic Systems Development MethodOriginalmente baseada no RADProgenitor do XPParticipação ativa dos usuáriosFixa tempo e recursos ajustando a quantia de funcionalidades
Pequenas equipesSuporta mudanças nos requisitos durante o ciclo de vida
Ciclo de Vida DSDM
Técnicas do DSDMTimeboxing: 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 DSDMPrototipagem: 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
Processos Ágeis de Desenvolvimento de Software
PADSPADS
Obrigado!
Márcio [email protected]
Milton [email protected]