1 extreming programming - xp Évisson lucena efl@cin.ufpe.br mestrado – cin – ufpe

1

eXtreming Programming - XP

Évisson Lucenaefl@cin.ufpe.brMestrado – 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!!!