1 eXtreming Programming - XP Évisson Lucena [email protected] Mestrado – CIN – UFPE.
-
Upload
walter-da-fonseca-azenha -
Category
Documents
-
view
219 -
download
0
Transcript of 1 eXtreming Programming - XP Évisson Lucena [email protected] Mestrado – CIN – UFPE.
2
Agenda Metodologias Ágeis Extreme Programing – XP XP x RUP XP e Software Livre XP e JAVA Conclusão Referências
3
Metodologias Ágeis Em fevereiro de 2001 um grupo de dezessete
pessoas se reuniu no estado de Utah, Estados Unidos
“Manifesto para o Desenvolvimento Ágil de Software”
Este grupo se intitulou “Aliança Ágil de Desenvolvimento”
Alegação: Produção muito complexa e perda de controle sobre vários documentos e modelos
4
Metodologias Ágeis Valores:
Indivíduos e iterações sobre processos e ferramentas.
Software funcionando sobre documentação compreensiva.
Colaboração do cliente sobre negociação de contrato.
Resposta à mudança sobre seguir um plano.
5
Metodologias Ágeis Princípios:
Satisfazer o cliente através de entrega contínua e rápida de software de valor
Mudanças em requisitos devem ser bem vindas, mesmo que em momentos tardios do desenvolvimento
Cliente e desenvolvedores devem trabalhar juntos, diariamente no projeto
6
Metodologias Ágeis Princípios:
comunicação face-a-face Medida de progresso = o software
funcionando SIMPLICIDADE em todos os aspectos
7
Metodologias Ágeis Extreme Programming (XP) Adaptive Software Development (ASD) Crystal Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Scrum
8
Extreme Programming Metodologia leve de desenvolvimento de
software XP surgiu a partir de idéias de Kent Beck e
Ward Cunningham Projeto piloto em março de 1996 Em 2000, Beck publicou o primeiro livro sobre
XP, o “Exteme Programming Explained: Embrace Change”
9
Extreme Programming
“XP é uma Metodologia Ágil, para equipes pequenas e médias, desenvolvendo software com
requisitos vagos e em constante mudança”
Kent Beck
10
Extreme Programming Às vezes, K. Beck refere-se a XP como
"DISCIPLINA" e não "METODOLOGIA" XP não se baseia em um procedimento atrás do
outro, e sim em regras que devem funcionar o tempo todo, sempre sendo aplicadas e observadas
Não há realmente uma "sequência de passos" a ser seguida, e sim uma maneira de se fazer todas as coisas
11
XP - Introdução “Extreme” empregar ao extremo boas
práticas da engenharia de software Exemplos de extremos:
Se testar é bom, vamos testar toda hora!! Se projetar é bom, vamos fazer disso parte
do trabalho diário de cada pessoa! Se integrar é bom, vamos integrar a maior
quantidade de vezes possível! Se iterações curtas é bom, vamos deixar as
iterações realmente curtas!
12
XP - Introdução XP normalmente é aplicado em projetos que
tenham equipes entre 2 e 10 pessoas Então o XP não pode ser utilizado em grandes
projetos??!! Sim!! Desde que grandes projetos sejam
divididos em subprojetos independentes
13
XP - Introdução
Segundo Beck e Fowler, “XP endereça projetos longos quebrando-os em
uma seqüência de mini projetos auto contidos, com duração de uma a três
semanas”
14
XP - Introdução Restrições:
Cultura da documentação Cultura de horas de trabalho para
comprovar comprometimento Dificuldade para mudanças Ambiente onde é necessário muito tempo
para obtenção de feedback Ambiente em que não é possível realizar
testes automáticos Ambiente não propício a um projeto XP
15
XP - Introdução Extreme Programming é de domínio público, o
que facilita bastante a sua disseminação Livros Web Sites Artigos Podem ser utilizados como fonte
16
XP - Introdução Extreme Programming é definida através de valores,
princípios e práticas Os valores descrevem os objetivos de longo prazo de
quem aplica XP e definem critérios para se obter sucesso
Para sustentar os valores e torná-los mais concretos, a metodologia define princípios que devem ser seguidos por todos os praticantes da disciplina
Extreme Programming define quatro atividades básicas de desenvolvimento de software, depois define as práticas para estruturar estas atividades de forma que as mesmas sigam os princípios, que sustentam os valores da metodologia
XP - Valores Simplicidade
Fonte: Standish Group
18
XP - Valores Feedback
Comunicação
Coragem
19
XP – Princípios Feedback rápido
Assumir simplicidade
Mudança incremental
Aceitar mudança
Trabalho de qualidade
20
XP – Princípios Investimento inicial pequeno Jogar para vencer Experimentos concretos Comunicação aberta e honesta Trabalhar a favor do instinto das pessoas e não
contra Aceitar responsabilidades Adaptação ao local Viajar leve Medidas honestas
21
XP – Atividades e Práticas As atividades básicas de XP são:
codificar, testar, escutar e projetar Práticas:
O jogo do planejamento Releases pequenas Metáforas
“Este sistema funciona como uma colméia de abelhas, buscando pólen e o trazendo para a colméia" (sistema de recuperação de dados baseados em agentes) [XPRO]“Este sistema funciona como uma agência de correios” (sistema de mensagens) [Objective]
Projeto de software simples Teste
22
XP – Práticas Refactoring Programação em pares Propriedade coletiva Integração contínua 40 horas semanais Cliente no local Padrão de codificação
23
Projeto XP Vamos ,então, colocar todos esses
conceitos em prática Como as práticas e valores definidos
pelo XP são empregados no dia-a-dia de um projeto
24
Projeto XP Etapas:
ESCOPO PLANEJAR próxima release PLANEJAR próxima iteração PRODUÇÃO do software na iteração
E os papéis e as responsabilidades?
25
Projeto XP - Papéis Programador
Cliente
Testador
Acompanhador (tracker)
Técnico (coach)
26
Projeto XP - Planejamento Definição de viabilidade e escopo
Responsabilidade: gerente do projeto (coach)
Big Plan é elaborado Poucas horas ou um dia é necessário para
elaborar este plano que irá guiar o planejamento detalhado do projeto
27
Projeto XP - Planejamento Planejando a release
XP é contra a definição inicial de um plano detalhado para todo o projeto
O planejamento deve ser feito apenas para a próxima release
Para isto se aplica a prática “O Jogo do Planejamento”
28
Projeto XP - Planejamento Planejando a release
Reuniões com os participantes: clientes e desenvolvedores
Clientes levam as “estórias” (Story Cards) Desenvolvedores estimam cada “estória” Em que unidade?
Ideal Weeks Sugestões: estimar em grupos, spike
solution, estimar baseado em estórias já implementadas, estimar inicialmente as estórias mais simples…
29
Projeto XP - Planejamento Planejando o release
Cliente define o que será implementado na próximo release
“Releases Pequenas” – prazo ideal para a liberação = 2 meses [R. Jeffries]
Lembrando que sempre deve ser entregue um software de valor
30
Projeto XP - Planejamento Planejando a iteração
O período até a data da release é dividido em iterações de poucas semanas
Lembrando novamente – todas as iterações produzem software de valor
A seleção das estórias para uma iteração possui a mesma lógica da seleção para a release
Desenvolvedores quebram as estórias em tarefas
31
Projeto XP - Planejamento Planejando a iteração
As tarefas são as atividades de desenvolvimento propriamente ditas e são definidas em detalhes suficientes para prover o conhecimento necessário a sua implementação
Desenvolvedores estimam tarefas em perfect days
32
Projeto XP – Praticando XP Projeto Besta (Fonte: XPRecife)
O objetivo é ter um aplicação de cadastro besta
Uma maneira bem besta de mostrar na prática um modo de fazer XP em “Projetão”
33
Projeto XP – Praticando XP Um Plano de Projeto Besta
Nós vamos fazer duas entregas, a saber: a entrega 1 e a entrega 2
Na primeira entrega nós pretendemos prototipar uma interface besta para o sistema
Na segunda, entregamos o resto (implementamos as funcionalidades)
No máximo as coisas podem dar errado e o projeto não sair
34
Projeto XP – Praticando XP Plano da Segunda Entrega Besta
Eu quero poder cadastrar bestas através da aplicação;–Muito importante
–14 horas Eu quero poder procurar e ver as informações dos bestas
que eu cadastrei–Muito importante–10 horas
Eu quero poder remover bestas do cadastro, através da aplicação
–Muito importante–¼ de hora
Eu quero bolinhas amarelas e azuis piscando na interface;–Desejável (?)–Eu me recuso a estimar isto!
35
Projeto XP – Praticando XP
36
Projeto XP - Desenvolvimento Pronto, o planejamento está feito, e agora? A equipe, então, passa a implementar as
estórias selecionadas para a iteração corrente Neste momento as maiorias das práticas são
utilizadas. Que práticas?
37
Projeto XP - Desenvolvimento “Projeto de software simples” “Metáforas” “Refactoring”
Uma premissa utilizada para sustentar as práticas “Projeto de software simples” e “Refactoring” é a de que não é tão caro realizar mudanças no código como a Engenharia de Software tradicional prega
38
Projeto XP - Desenvolvimento
Curva do Custo da Mudança, adotada também por Summervile
39
Projeto XP - Desenvolvimento
Custo da Mudança no Tempo de Desenvolvimento, adotada por Pressman
40
Projeto XP - Desenvolvimento
Custo da Mudança, segundo XP (K. Beck)
41
Projeto XP - Desenvolvimento ...cotinuando com as práticas utilizadas no
desenvolvimento... “Programação em pares”
Driver Partner
“Padrão de Codificação” “Teste”
Testes Unitários Testes de Aceitação
“Integração Contínua” Necessário o uso de ferramentas
“Propriedade Coletiva”
42
Projeto XP - Acompanhamento Como comparar o progresso de um projeto XP
e compará-lo ao planejado? O Tracker deve perguntar algumas vezes por
semana: “Quantos dias ideais o programador
trabalhou na tarefa que está realizando?” (K. Beck)
“Quantos dias ideais o programador considera necessário para cumprir a tarefa?” (K. Beck)
Outra forma: Stand-up Meetings Gráficos Visíveis
Projeto XP - Acompanhamento
Fonte: Internet
44
XP - Considerações Importantes Importante = AMBIENTE
Segundo Beck “Se você não tem um lugar razoável para trabalhar, seu projeto não terá sucesso”
Razoável? Deve ser: “amplo, com pequenos espaços
privados e uma área de programação no centro. As mesas devem promover a programação em pares” (k. Beck)
Fonte: XPRecife
Fonte: XPRecife
47
XP - Considerações Importantes XP deve ter comemorações K. Beck diz: “Projetos XP sempre
possuem comida em volta” XP é só maravilha?! Só tem
vantagens? Não, existem algumas críticas para
um projeto XP.
48
XP - Considerações Importantes (Críticas) Dificuldade em manutenção (J.R. Nawrocki ) Questões associadas à efetividade da programação em
pares 100 % do código? (Schuh apenas 30%) Custo? (Nosek 43% mais esforço, Nawrocki 50% mais
esforço, já Williams 40% a 50% a menos de trabalho) E Inspeções? (Nawrocki relata o uso de inspeções em
um projeto XP) E a equipe?
Experiência da equipe (Nawrocki) Dificuldade associada ao cliente no local (Beck) Dificuldade para estabelecer contrato de custo, tempo e
escopo variável (Beck)
XP x RUPRUP XP
Modelagem de Negócio
- Processo Formal- Use Cases
- User Stories- Releases Pequenas
Arquitetura - Centrado na arquitetura- Preocupação constante-“Arquiteto de Software”- Ordem definida pelos desenvovedores
- Arquitetura = textos + diagramas- Alto nível- Metáforas- Ordem definida pelo cliente
Fonte: XPRecife
XP x RUPRUP XP
Projeto - Realização dos casos de uso- Diagrama de classes- Diagramas de estado- Antes da codificação- Documentação
- Código- Testes unitários- Testes Permanentes
Implementação -Diagrama de Componentes- Processo lento e demorado
- Principal fase- Praticamente tudo!
Fonte: XPRecife
XP x RUPRUP XP
Testes - Testes unitários- Testes funcionais
- Testes unitários (escritos antes do código - TDD)- Testes de aceitação (baseado nas User Stories)
Gerenciamento - Templates- Cronogramas- Métricas
- Tracking (acompanhamento)
Fonte: XPRecife
XP x RUP
Fonte: Internet
53
XP e Software Livre Publicação do famoso artigo The Cathedral and
Bazaar do [Eric S. Raymond 1999] Graças a ele a comunidade da engenharia de
software vem aos poucos mudando a forma de pensar, deixando de lado todo o conservadorismo que existia como por exemplo: A produção de muita documentação Resistir a mudanças, iterações longas e estáveis
Se aproxima das metodologias ágeis
54
XP e Software Livre“XP é uma espécie de modelo comercial
do paradigma de desenvolvimento de software livre, acrescentado de
mecanismos de acompanhamento e gerenciamento de projeto”
Fernando Lozano
55
XP e Java Automação de testes unitários
JUNIT Construção de Aplicações
ANT Controle de Versões
CVS Subversion
Integração Contínua ANT Cruise Control
56
Conclusão XP é uma disciplina ágil baseada na aplicação
de práticas, as quais promovem alguns valores O planejamento de um projeto XP é simples, e
se dá para os releases e iterações O desenvolvimento de software é feito de
forma bastante dinâmica favorecendo a comunicação entre a equipe e o feedback contínuo do funcionamento do sistema e da satisfação do cliente
57
Conclusão O acompanhamento em um projeto XP é realizado
em curtos intervalos de tempos Métricas são constantemente colhidas e tornadas
visíveis para todos os membros da equipe Reuniões curtas ocorrem diariamente Há um responsável para acompanhar o progresso
das atividades de cada programador Conjunto de boas práticas levadas ao eXtremo! Pertence as metodologias ágeis que é uma
tendência na engenharia de softwre Apesar de vários relatos de sucesso no emprego de
XP, algumas críticas são relacionadas e ainda não completamente respondidas.
Referências[Beck 2000] Kent Beck. ExtremeProgramming Explained. Addison- Wesley, 2000.[Renata Endriss 2003] Campelo, R. C. XP-CMM2: Um Guia para Utilização de Extreme
Programming em um Ambiente Nível 2 do CMM. Centro de Informática, Universidade Federal de Pernambuco, Recife, Brasil, 2003.
[Pair] www.pairprogramming.com[XPRO] www.xprogramming.com[XISPE] http://www.xispe.com.br/index.html[XPRecife] Apresentações do grupo XPRecife. [Sommerville 1995] Sommerville, I. Software Engineering, Fifth Edition, Addison-Wesley, 1995.[Pressman 1997] Pressman, R. S. Software Engineering: A Practitioner’s Approach, Fourth
Edition, McGraw-Hill, 1997.[J.R. Nawrocki et al] Comparison of CMM Level 2 and eXtreme Programming, Quality
Connection - 7th European Conference on SoftwareQuality, Helsinki (Finland), Junho de 2002.
[P. Schuh] Redemption, and Extreme Programming, IEEE Software, vol. 18, No. 6, Novembro de 2001.
[J.T. Nosek] The case for collaborative programming, Communications of the ACM, vol. 41, No. 3, 1998.
[L. Williams et al] Strengthening the case for pair programming, IEEE Software, vol. 17, No. 4, 2000.
59
Reflexão "Da mais perfeita ordem emana a
profunda desordem e da mais aparente desordem emana a perfeita ordem" [Internet]
Perguntas?
Obrigado!!!