Extreme Programming (XP)

Situação da área de desenvolvimento dosoftware

n Sociedade demandan grande quantidade de sistemas/aplicaçõesn software complexo, sistemas distribuídos, heterogêneosn requisitos mutantes (todo dia, mês, ano)

n Mas, infelizmente,n não há gente suficiente para desenvolver tanto software com

qualidade...

2

Problemas

n Com metodologias de desenvolvimenton Supõem que é possível prever o futuron Pouca interação com os clientesn Ênfase em burocracias (documentos, formulários,

processos, controles rígidos, etc.)n Avaliação do progresso baseado na evolução da

burocracia e não do códigon Com software

n Grande quantidade de errosn Falta de flexibilidade

3

Como resolver esse impasse?

n Melhores Tecnologiasn Padrões de Projeto (reutilização de idéias)n Componentes (reutilização de código)n Middleware (aumenta a abstração)

n Melhores Metodologiasn Métodos Ágeisn outras...

4

Metodologias de desenvolvimento desoftware OO

n “Tradicionais”n Comunidade de Engenharia de Softwaren IEEE/ACM ICSEn p.ex. Carnegie-Mellon SEIn RUP, CMM, etc.

n Ágeisn Comunidade de POOn ACM OOPSLAn p.ex. Johnson @ Illinois, Beck, Cockburn, Jeffries,

Cunningham…n XP, Crystal, Scrum, etc.

5

Métodos Ágeis de Desenvolvimento deSoftware

n Movimento iniciado por programadores experientes econsultores em desenvolvimento de software.

n Questionam e se opõem a uma série de mitos/práticasadotadas em abordagens tradicionais de Engenharia deSoftware e Gerência de Projetos.

n Manifesto Ágil:• Assinado por 17 desenvolvedores em Utah em

fevereiro/2001.

6

O Manifesto do Desenvolvimento Ágil deSoftware

1. Indivíduos e interações são mais importantesque processos e ferramentas.

2. Software funcionando é mais importante do quedocumentação completa e detalhada.

3. Colaboração com o cliente é mais importante doque negociação de contratos.

4. Adaptação a mudanças é mais importante doque seguir o plano inicial.

7

Princípios do Manifesto Ágil

n Objetivo: satisfazer o cliente entregando, rapidamente ecom freqüência, sistemas com algum valor.n Entregar versões funcionais em prazos curtos.n Estar preparado para requisitos mutantes.n Pessoal de negócios e desenvolvedores juntos.n Troca de informações através de conversas diretas.

8

Programação eXtrema

n Metodologia de desenvolvimento de software aperfeiçoadanos últimos 5 anos.

n Ganhou notoriedade a partir da OOPSLA’2000 (ConferenceOn Object-Oriented Programming).

n Nome principal: Kent Beck.

9

Visão geral

n Processo de desenvolvimento de software voltado para:n Projetos cujos requisitos são vagos e mudam com

freqüêncian Desenvolvimento de sistemas orientados a objetosn Equipes pequenas, de 2 até 12 programadoresn Projetos de 1 a 36 mesesn De 1000 a 250.000 linhas de códigon Desenvolvimento incremental (ou iterativo)

n Organizado em torno de um conjunto de valores epráticas para assegurar que o cliente receba um altoretorno do investimento em software

10

Valores do XP

n Feedback: o cliente aprende com o sistema que utiliza ere-avalia as suas necessidades, gerando feedback paraequipe de desenvolvimento

n Comunicação: permite que todos os detalhes do projetosejam tratados com a atenção e a agilidade que merecem

n Simplicidade: implementar apenas aquilo que é suficientepara atender a necessidade do cliente

n Coragem: a equipe precisa ser corajosa e acreditar que,utilizando as práticas e valores do XP, será capaz de fazero software evoluir com segurança e agilidade

11

Práticas do XPn Cliente Presenten Jogo do Planejamenton Stand Up Meetingn Programação em Parn Desenvolvimento Guiado pelos Testesn Refactoringn Código Coletivon Código Padronizadon Design Simplesn Metáforan Ritmo Sustentáveln Integração Contínuan Releases Curtos

12

Características da equipe

n Gerente de Projeto: responsável pelos assuntosadministrativos do projeto

n Coach: responsável técnico do projeton Analista de Teste: responsável por ajudar o cliente a

escrever os testes de aceitaçãon Redator Técnico: ajuda a equipe de desenvolvimento a

documentar o sisteman Desenvolvedor: analisa, projeta e codifica o sistema

13

Desafios do desenvolvimento de software

n Modelo tradicionaln Análise – a equipe faz o levantamento dos requisitos e busca

compreendê-los detalhadamenten Projeto – com base na análise a equipe projeta a arquitetura do

sisteman Implementação – a equipe se baseia na arquitetura e na análise

para implementar as diversas partes do softwaren Teste – para verificar se o sistema atende às necessidades

especificadas pelo usuário, a equipe testa o software e faz ascorreções necessárias

n Implantação – o sistema é colocado em produção e os usuáriosfinais passam a utilizá-lo

n Manutenção – até o fim da sua vida, o software poderá sofreralterações por diversas razões, tais como correção e inclusão denovas funcionalidades 14

15

Modelo em cascata (Winston Royce, 1970)

Premissas Básicas do Modelo Tradicional

n É necessário fazer uma análise de requisitos profunda edetalhada antes de projetar a arquitetura do sistema.

n É necessário fazer um estudo minucioso e elaborar umadescrição detalhada da arquitetura antes de começar aimplementá-la.

n É necessário testar o sistema completamente antes demandar a versão final para o cliente.

16

17

Problemas do modelo em cascata

n Inflexível divisão do projeto em estágios distintosn Isso torna difícil responder a mudanças nos requisitos do

clienten Portanto, este modelo somente é apropriado quando os

requisitos forem bem compreendidos

O que está por trás deste modelo?

18

Cus

to d

e m

udan

ças

requisitos desenho testesanálise implementação produção

Desenvolvimento Ágil

n Utilizam o desenvolvimento iterativo (em espiral)

19

Premissas do Desenvolvimento Ágil

n Satisfazer o cliente entregando rapidamente e comfreqüência, sistemas com algum valorn Entregar versões funcionais em prazos curtosn Estar preparado para requisitos mutantesn Pessoal de negócios e desenvolvedores devem trabalhar juntosn Troca de informações através de conversas diretas

n O cliente aprende ao longo do desenvolvimento, à medidaque é capaz de manipular o sistema

n Este aprendizado pode ser utilizado para realimentar oprocesso de desenvolvimento

20

O que está por trás deste modelo?

21

Cus

to d

e m

udan

ças

tempo

Mais sobre os valores do XP

n Feedbackn Comunicaçãon Simplicidaden Coragem

22

Feedback

n Realimentação que o cliente fornece à equipe dedesenvolvimento quando:n aprende algo novo sobre o sisteman aprende mais sobre os requisitosn aprende mais sobre a forma como os requisitos foram

implementadosn Realimentação que os desenvolvedores fornecem ao

cliente quando:n apresentam estimativasn apontam riscos técnicosn sugerem alternativas de design

23

Comunicação

n Para que o feedback exista em um projeto de software, é necessário que a comunicação esteja presente de forma muito intensa

n Componentes da equipe e o cliente precisam trocar idéias e informações para que o software ganhe forma e atinja os objetivos desejados

24

Comunicação

n Formas de comunicar uma idéia para outra pessoan Conversar face-a-facen Telefonen E-mailn Mensagens instantâneasn Etc

n Comunicação face-a-face: interlocutor leva em conta oconteúdo da fala, gestos, expressão facial, tom de voz etcn Existe uma riqueza de elementos que facilitam a compreensão da

nossa mensagem, além de uma dinâmica que viabilizaquestionamentos e respostas

25

Comunicação

n XP procura explorar a comunicação direta entre aspessoas, de modo a diminuir as falhas de comunicação eevitar retrabalhos desnecessários, frutos dessas falhas

n No XP documentos são usados principalmente pararegistrar o trabalho que já foi executado, ao invés dediscutirem exaustivamente o que deverá ser feito

n A explicação sobre o que precisa ser feito é fornecidapessoalmente face-a-face

26

Simplicidade

n Deve-se desenvolver a funcionalidade requerida APENASCOM O SUFICIENTE para que o cliente tenha o seu pedidoatendido e possa validar se foi atendido da forma comogostaria

n Trabalho especulativo é evitado: aquele executadoutilizando-se premissas sobre as quais não se tem totalcerteza

n Overengineering também é evitada: criar uma soluçãoexcessivamente sofisticada para um dado problema

27

Coragem

n Adoção do XP exige que a equipe de desenvolvimentotenha coragem para:n Desenvolver o software de forma incremental: uma alteração

poderá inserir erro naquilo que vinha funcionando até então.n Manter o sistema simples: a equipe precisa acreditar que será

capaz de incorporar possíveis necessidades futuras que ela jávisualiza no presente, mas que não foram especificadas pelocliente.

n Permitir que o cliente priorize as funcionalidades: no XP asfuncionalidades são especificadas através de estórias.

n Fazer os desenvolvedores trabalharem em par.n Investir tempo em refactoring: melhorar a qualidade do código

do sistema, sem alterar a funcionalidade que ele implementa

28

Coragemn Investir tempo em testes automatizados.n Estimar as estórias na presença do cliente.n Expor o código a todos os membros da equipe: o

desenvolvedor precisa ter humildade e serenidade para tratareventuais críticas como um aprendizado que o ajudará a melhoraro seu código.

n Integrar o sistema diversas vezes ao dia.n Adotar um ritmo sustentável: para obter grandes saltos de

produtividade, os desenvolvedores devem começar cada dia detrabalho bem dispostos, criativos, atentos e motivados a fazer umsoftware de alta qualidade.

29

Coragemn Abrir mão de documentações que servem como defesa:

muitas equipes de desenvolvimento jogam para não perder.Partem da premissa que o projeto passará por vários problemasserá necessário precaver com todo o tipo de documentação paraisentar a equipe de qualquer responsabilidade.

n Propor contratos de escopo variável: permite que a equipeincorpore o aprendizado do cliente na forma de mudanças nosoftware.

n Propor a adoção de um processo novo.

30