eXtreme Programming (XP)

Carlos Henrique M. da [email protected]

eXtremeProgramming

mailto:[email protected]

Extreme Programming (XP) é uma metodologia de desenvolvimentode software, nascida nos Estados Unidos ao final da década de 90.Vem fazendo sucesso em diversos países, por ajudar a criarsistemas de melhor qualidade, que são produzidos em menostempo e de forma mais econômica que o habitual. Tais objetivossão alcançados através de um pequeno conjunto de valores epráticas, que diferem substancialmente da forma tradicional de sedesenvolver software.

Estudos demonstram que a maioria dos projetos de software falha,seja porque não cumprem o orçamento, ou não cumprem ocronograma, ou as funcionalidades não atendem às necessidadesdos usuários ou porque todos estes fatores estão presentes emconjunto.

VINÍCIUS MANHÃES TELES

eXtreme Programming - Conceito

http://improveit.com.br/xp/metodologia

http://improveit.com.br/xp/valores

http://improveit.com.br/xp/praticas

http://improveit.com.br/xp/desenvolvimento_tradicional

eXtreme Programming - Introdução

Por que cerca de 80% a 90% dos

projetos de Software fracassam?


Desenvolver software é uma atividade arriscada. Segundo asestatísticas, os principais problemas são:

Gastos que superam o orçamento;

Consumo de tempo que supera o cronograma;

Funcionalidades que não resolvem os problemasdos usuários;

Mudanças constantes podendo estar relacionadasa requisitos, cronograma, equipe...

Baixa qualidade dos sistemas desenvolvidos.


Há algumas décadas a indústria de software vem buscando técnicasde desenvolvimento que possam reduzir os riscos dos projetos desoftware e tornar essa atividade mais produtiva. Um marco nestesentido é a criação da disciplina de Engenharia de Software em1968. De lá para cá, inúmeras propostas foram feitas para melhoraro desempenho dos projetos, começando pelo processo dedesenvolvimento linear e seqüencial (em cascata) até chegar aosatuais processos ágeis de desenvolvimento.

O XP é um dos representantes destes processos e foi criado por KentBeck em 1997 em um projeto para a Chrysler (fabricante de veículosnorte-americana). O XP é composto por um conjunto reduzido depráticas de desenvolvimento que se organizam em torno de valoresbásicos. Essas práticas possuem fortes inter-relacionamentosformando um conjunto de elevada sinergia.


Desenvolvimento de SW no passado Processos Tradicionais

Analisar, projetar e só depois iniciar codificação Prever o futuro

Ter certeza do que se sabe hoje será exatamente o que se queramanhã

TemoresMudança de requisitos depois de concluída a fase de análise eprojeto

Custo

Análise Projeto Codificação Testes

Tempo


Desenvolvimento de SW hoje Processos modernos incentivam pequenas iterações

Mudanças em etapas posteriores se tornam mais baratas

Adotar a mudança- A Engenharia de SW é diferente das outras engenharias- Componentes, frameworks, BDs podem absorver o alto custo da mudança


A crise do software Em média, os atrasos representaram 63% mais tempo do que o estimado;

Os projetos que não cumpriram o orçamento custaram em média 45% mais;

No geral, apenas 67% das funcionalidades prometidas foram efetivamenteentregues.

Resultado final de projetos de software (Standish Group,2000)


Utilização de Funcionalidades


Utilização de Funcionalidades


Desperdício Falha na comunicação

Falta de tempo


Manifesto ÁgilEstamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

Interação entre pessoas MAIS QUE processos e ferramentas;

Software em funcionamento MAIS QUE documentação abrangente;

Colaboração com o cliente MAIS QUE negociação de contratos;

Responder a mudanças MAIS QUE seguir um plano.

“Ou seja, mesmo tendo valor os itens à direita, valorizamosmais os itens à esquerda.”

Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn,Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arievan Bennekum, Martin Fowler, James Grenning, Jim Highsmith,Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, DaveThomas

Referência

eXtreme Programming

eXtreme Programming

Extreme Programming ou XP, é um processo de desenvolvimento de software voltado para:

Projetos cujos requisitos são vagos e mudam com frequência;

Desenvolvimento de sistemas orientados a objetos;

Equipes pequenas, preferencialmente até 12 desenvolvedores;

Desenvolvimento incremental (ou iterativo), onde o sistema começa a serimplementado logo no início do projeto e vai ganhando novas funcionalidades aolongo do tempo.

VISÃO GERAL

O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximode valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em tornode um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurarque o cliente sempre receba um alto retorno do investimento em software.

Valores do XP Comunicação

Simplicidade

Feedback

Coragem

Respeito

Práticas do XP Cliente Presente Jogo do Planejamento Stand Up Meeting Programação em Par Desenvolvimento Guiado pelos Testes Refactoring Código Coletivo Código Padronizado Design Simples Metáfora Ritmo Sustentável Integração Contínua Releases Curtos

eXtreme Programming

Valores do XP

eXtreme Programming

Comunicação

A comunicação entre o cliente e a equipe permite que todos osdetalhes do projeto sejam tratados com a atenção e a agilidadeque merecem.

O XP procura assegurar que a comunicação ocorra da formamais direta e eficaz possível. Sendo assim, ele busca aproximartodos os envolvidos do projeto de modo que todos possam secomunicar face-a-face ou da forma mais rica que for viável.

eXtreme Programming

Simplicidade

A comunicação, embora seja essencial, não é suficiente paragarantir que o cliente possa aprender durante o projeto e gerarfeedback rapidamente. Também é necessário que a equipecompreenda e utilize o valor da simplicidade, que nos ensina aimplementar apenas aquilo que é suficiente para atender acada necessidade do cliente. Ou seja, ao codificar umafuncionalidade devemos nos preocupar apenas com osproblemas de hoje e deixar os problemas do futuro para ofuturo (NÃO DEVEMOS TENTAR PREVER O FUTURO), poisraramente acertamos as previsões.

eXtreme Programming

Feedback

Quando o cliente aprende com o sistema que utiliza e re-avaliaas suas necessidades, ele gera feedback para a equipe dedesenvolvimento.

O feedback é o mecanismo fundamental que permite que ocliente conduza o desenvolvimento diariamente e garanta quea equipe direcione as suas atenções para aquilo que irá gerarmais valor.

eXtreme Programming

CoragemExistem temores que costumam assombrar os participantes de um projeto de software. Beck eFowler (2001) destacam alguns destes medos que exercem influência significativa nosprocessos de desenvolvimento.

Desenvolvedores, por sua vez, temem:

Ser solicitados a fazer mais do que sabem fazer; Ser ordenados a fazer coisas que não façamsentido; Ficar defasados tecnicamente; Receber responsabilidades, sem autoridade; Não receber definições claras sobre o que precisaser feito; Sacrificar a qualidade em função de prazo; Ter que resolver problemas complicados semajuda e Não ter tempo suficiente para fazer um bomtrabalho.

Clientes temem:

Não obter o que pediram; Pedir a coisa errada; Pagar demais por muito pouco; Jamais ver um plano relevante; Não saber o que está acontecendo e Fixarem-se em suas primeirasdecisões e não serem capazes de reagira mudanças nos negócios.

eXtreme Programming

Respeito

eXtreme Programming

Todo mundo dá e se sente o respeito que merecem como um membro da equipevalorizada. Todos contribuem valor mesmo que seja simplesmente entusiasmo.Desenvolvedores respeitam a experiência dos clientes e vice-versa. Gestoresrespeitam o direito de aceitar a responsabilidade e receber autoridade sobre nossopróprio trabalho.

Respeito é um valor que dá sustentação a todos os demais. Membros de umaequipe só irão se preocupar em comunicar-se melhor, por exemplo, se seimportarem uns com os outros. Respeito é o mais básico de todos os valores. Se elenão existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, sabercompreender e respeitar o ponto de vista do outro é essencial para que um projetode software seja bem sucedido.

eXtreme Programming

eXtreme Programming

Equipe (Whole Team)

Equipe XP = Cliente + Time de Desenvolvimento

Os papéis do time de desenvolvimentoenglobam:

• Desenvolvedores• Testadores(ajudam o cliente com os testes de aceitação)• Analistas/projetistas(ajudam o cliente a definir requisitos)• Gerente (garante os recursos necessários)• Coach(orienta a equipe, controlando a aplicação do XP)• Tracker (coleta as métricas do projeto)

As funções do cliente englobam:

• Definição dos requisitos doprojeto• Definição de prioridades• Controle do rumo do projeto• Definir os testes de aceitaçãodo Software

eXtreme Programming

Jogo de Planejamento(Planning Game)

Principais definições• Estimativas de cada tarefa

• Prioridades (tarefas + importantes)

Próximos passos• Planejamento de release(cliente propõe as funcionalidades e desenvolvedores avaliam)

• Planejamento da iteração(define as funcionalidades da iteração e os desenvolvedores estimam)

Ótimo feedback para o cliente, que dirige o projeto• Ideia clara do avanço do projeto

• Clareza: Redução de Riscos, aumentando a chance de sucesso

eXtreme Programming

Pequenos Lançamentos(Small Releases)

Disponibiliza a cada iteração Software 100% funcional• Versão• Redução (se o projeto terminar, parte existe e funciona)• Detecção prévia de problemas• Comunicação entre cliente e desenvolvedor

Cada lançamento possui funcionalidades prioritárias para a iteração

Lançamento pode ser destinado a• Usuário/cliente (testa, avalia e oferece feedback)• Usuário/final (sempre que possível)

Design simples e integração contínua são práticas essenciais

eXtreme Programming

Testes de Aceitação(Customer Tests)

São elaborados pelo cliente em conjunto com analistas e testadores

• São automatizados• Quando rodarem com sucesso, funcionalidade foi implementada• Devem ser rodados a cada iteração

Ótimo feedback para o cliente• Pode se saber, a qualquer momento, o percentual de implementação do Software e quanto falta

eXtreme Programming

Projetos Simples (Simple Design)

Projeto está presente em todas as etapas XP• Projeto começa simples e se mantém assim através de testes de refinamento de código (refactoring)

Em XP, é levado ao extremo• Não é Permitido qualquer funcionalidade adicional que não será usada na iteração atual

Implementação ideal é aquela que• Passa por todos os testes• Expressa as ideias definidas no planejamento• Não contém código duplicado ou que “cheire”

Prever o futuro é impossível e é “anti-XP”

eXtreme ProgrammingProgramação em Pares

(Pair Programming) Software é desenvolvido em pares

• “2 cabeças juntas são melhores que 2 cabeças separadas”• 1 piloto e 1 copiloto• Papéis são alternados frequentemente

Benefícios•Melhor qualidade de código (refactoring e testes)•Revisão constante do código•Nivelamento da equipe•Maior comunicação

“Um” pelo preço de “Dois”Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos

eXtreme Programming

Desenvolvimento Dirigido por Testes (Test-driven Development)

eXtreme Programming

Refinamento de código(Refactoring)

http://www.refactoring.com/catalog/

http://www.refactoring.com/catalog/

eXtreme Programming

Integração Contínua(Continuous Integration)

eXtreme Programming

Posse Coletiva(Collective Ownership)

eXtremme Programming

Padrões de Codificação(Coding Standards)


Ritmo Saudável (Sustainable Pace)


Metáfora (Metaphor)


Reuniões em Pé (Stand-up Meeting)


Spikes de Planejamento(Spike Solution)


Como Implantar? Uma prática de cada vez

• Enfatize o problema mais importante

Dificuldades culturais

• Deixar alguém mexer no seu código• Trabalhar em pares

Dificuldades devido a mudança de hábitos

• Manter as coisas simples (e não tentar prever o futuro escrevendo "designflexível")• Jogar fora código desnecessário• Escrever testes antes de codificar• Refatorar com frequência (vencer o medo)


Quando Não Usar XP Equipes grandes e espalhadas geograficamente

• Comunicação é um valor fundamental do XP• Não é fácil garantir o nível de comunicação requerido em projetos XP em grandes equipes

Situações onde não se tem controle sobre o código

• Código legado que não pode ser modificado

Situações onde o feedback é demorado

• Compile-link-build-test que leva 24 horas• Testes muito difíceis, arriscados e que levam tempo• Programadores espalhados em ambientes físicos distantes e sem comunicação eficiente

eXtreme Programming

Características da Equipe

Uma equipe que utilize o XP normalmente é composta por pessoasque representam os seguintes papéis:

Gerente de Projeto

Coach

Analista de Teste

Redator Técnico

Desenvolvedor

eXtreme Programming

Gerente de Projeto

O gerente de projeto é responsávelpelos assuntos administrativos doprojeto. Ele procura liberar a equipe dequestões que não estejam diretamenteligadas à atividade diária dedesenvolvimento. Além disso, administrao relacionamento com o clienteassegurando que o mesmo participeativamente do desenvolvimento eforneça as informações essenciais paraque a equipe possa implementar osistema desejado.

eXtreme Programming

CoachO coach é o profissional técnico doprojeto. O XP recomenda que umprofissional tecnicamente bempreparado seja destacado para orientar aequipe de modo que ela siga as boaspráticas recomendadas pelo XP. Emboratambém possa atuar na implementaçãodo sistema, sua tarefa principal éassegurar o bom funcionamento doprocesso e buscar formas de melhorá-locontinuamente.

eXtreme Programming

Analista de Testes

O analista de teste é responsável porajudar o cliente a escrever os testes deaceitação. Quando estes testes não sãoautomatizados, o analista de teste devefazer com que eles sejam executadosdiversas vezes ao longo das iterações doprojeto. Ele procura fazer com que oseventuais defeitos do sistema sejamidentificados tão logo apareçam. Destaforma, fornece feedback para a equiperapidamente, de modo que ela possafazer as correções com rapidez e evitarque os problemas se propaguem.

eXtreme Programming

Redator Técnico

O redator técnico ajuda a equipede desenvolvimento adocumentar o sistema. A suapresença permite que osdesenvolvedores se concentremprioritariamente naimplementação do software.Embora eles possam continuarfazendo algumas documentações,o redator técnico é quem faz amaior parte do trabalho dedocumentação.

eXtreme Programming

DesenvolvedorO desenvolvedor é a pessoa que analisa,projeta e codifica o sistema. Em suma, éa pessoa que efetivamente constrói osoftware. Dentro do XP, não existemdivisões entre analista, projetista,programador, etc. Cada desenvolvedorexerce estes diferentes papéis emdiversos momentos do projeto.

eXtreme Programming

Desafios de Desenvolvimento de Software

Modelo em Cascata

eXtreme Programming

Análise: a equipe faz o levantamento de requisitos e busca compreendê-lodetalhadamente

Design: com base na análise a equipe projeta a arquitetura do sistema

Implementação: a equipe se baseia na arquitetura e na análise paraimplementar as diversas partes do software

Teste: para verificar se o sistema atende às necessidades especificadaspelo usuário, a equipe testa o software e faz as correções necessárias

Implantação: o sistema é colocado em produção e os usuários finaispassam a utilizá-lo

Manutenção: até o fim da sua vida, o software poderá sofrer alteraçõespor diversas razões, tais como correção e inclusão de novas funcionalidades

Desafios de Desenvolvimento de Software

eXtreme Programming

Desenvolvimento ÁgilO termo “desenvolvimento ágil”, fazreferência ao desenvolvimentoiterativo, em espiral. Ele recomendaque todas as fases descritas nomodelo em cascata sejam executadasdiversas vezes ao longo do projeto,produzindo ciclos que se repetem aolongo de todo o desenvolvimento.Cada ciclo (da análise àimplementação) recebe o nome deiteração. No desenvolvimento iterativo,o software cresce a cada iteração, istoé, o resultado de cada iteração é umsoftware pronto, testado e aprovado,sendo que a primeira contém poucasfuncionalidades, enquanto a últimacontém todas as funcionalidades dosistema.

eXtreme Programming

Cliente PresenteIntrodução

Tradicionalmente, quando pensamos no desenvolvimento desoftware, delegamos ao cliente a tarefa de manifestar as suasnecessidades e à equipe de desenvolvimento a de implementar. Ouseja, há uma divisão implícita entre as responsabilidades de cadaparte e um certo distanciamento entre elas.

eXtreme Programming

O XP trabalha com uma visão diferente

O XP sugere que o cliente estejapresente durante o dia-a-dia doprojeto. A sua participaçãocontribui para o sucesso doprojeto, enquanto sua a suaausência é um sério fator derisco.

A participação do cliente viabilizaa simplicidade do processo. Alémdisso, ela permite que o projetoseja conduzido através de umasérie de pequenos ajustes e nãoatravés de mudanças bruscas aolongo do caminho.

eXtreme Programming

Estórias

As funcionalidades do sistemas são descritas brevemente emcartões e recebem o nome de estórias. Estas estórias nada mais sãodo que um convite ao diálogo. Sendo assim, quando osdesenvolvedores decidem começar a implementar uma determinadaestória, eles precisam dialogar com o cliente para entendê-lasmelhor. Essa é uma das razões pelas quais é essencial que o clienteesteja presente no dia-a-dia do desenvolvimento.

eXtreme Programming

Dúvidas Durante a Implementação

Enquanto os desenvolvedores se aprofundam namodelagem da nova funcionalidade e começam aimplementá-la, dúvidas podem surgir. Mais uma vez, apresença do cliente permite que as dúvidas sejamrespondidas rapidamente. Isso contribui com a agilidadedo processo e evita o trabalho especulativo.

eXtreme Programming

O Trabalho Especulativo

O trabalho especulativo, que ocorre quando a equipe não consegueter as dúvidas respondidas e assume premissas, representa umenorme risco de retrabalho negativo. Assumindo premissas, aequipe pode vir a construir partes da funcionalidades de formacompletamente incorreta, o que poderia ter sido evitado se o clienteestivesse presente para responder às dúvidas.

eXtreme Programming

Confiança: um sub-produto da presença do cliente

Além do feedback entre cliente e equipe de desenvolvimento, aparticipação do cliente no desenvolvimento também contribui paramelhorar o relacionamento de ambas as partes. A aproximaçãoaumenta a confiança de todos os envolvidos.

É preciso notar que serviço é um produto intangível, como o própriosoftware. Normalmente, temos mais facilidade em medir o valor dealgo que é concreto, que podemos ver, tocar, manipular. Ou seja,normalmente, é mais fácil medir o valor de um carro, por exemplo,que o valor de um serviço.

eXtreme Programming

Para a equipe de desenvolvimento, a aproximação docliente permite que muitas dúvidas sejam respondidas.Além disso, com o cliente próximo, a equipe podeapontar questões que tenham passados desapercebidasaos olhos dele. Desta forma, a equipe pode preveni-lo desituações incorretas.

Aproximação da equipe com o cliente

eXtreme Programming

Por que é difícil ter o cliente presente?

A sala de guerra (war room) com o cliente presente

A sala de guerra com o cliente ausente

A sala de guerra em outro prédio

O que acontece com os projetos quando o cliente não estápresente?

Questionamentos importantes Equipe X Cliente

eXtreme Programming

O Jogo do PlanejamentoO XP utiliza o planejamento para assegurar que a equipe dedesenvolvimento esteja sempre trabalhando naquilo que irá gerarmais valor para o cliente a cada dia de trabalho. Este planejamento éfeito diversas vezes ao longo do projeto, para que todos tenham aoportunidade de revisar as prioridades (Beck e Fowler, 2001).

Dividindo as Responsabilidades

Escrevendo Estórias

Estimando Estórias

Planejando os Releases

Planejando as Iterações

Encerrando uma Iteração

Encerrando um Release

eXtreme Programming

Dividindo as ResponsabilidadesA chave para gestão de um projeto de software é o equilíbrio depoderes entre o cliente e a equipe de desenvolvimento. Por estarazão, o XP procura separar claramente o papel de cada um, paraassegurar que o cliente tome todas as decisões de negócio, enquantoa equipe de desenvolvimento cuida das decisões técnicas. (Beck eFowler, 2001). Isso dá origem a declaração de direitos do cliente e dodesenvolvedor (Jeffries et al., 2001).

eXtreme Programming

Direitos do Cliente Receber um plano geral para que saiba o que poderá ser feito, quando e com que custo;

Receber o máximo de valor de cada semana de trabalho da equipe de desenvolvimento;

Acompanhar o progresso do projeto através de um sistema executável, que demonstra estar correto por passar nos testes que você especifica;

Mudar de ideia, substituir funcionalidades e alterar prioridades sem ter que pagar um preço exorbitante;

Ser informado sobre mudanças no cronograma a tempo de decidir como reduzir o escopo para ser capaz de manter a data original;

Cancelar o projeto a qualquer momento e receber um sistema executável que reflete todo o investimento que foi feito até a data do cancelamento.

eXtreme Programming

Direitos do Desenvolvedor

Saber quais são as necessidades, bem como suas prioridades;

Produzir um trabalho de alta qualidade permanentemente;

Pedir e receber ajuda de seus colegas e do cliente;

Gerar e atualizar as suas estimativas;

Escolher as suas responsabilidades, ao invés delas serem determinadas para você.

eXtreme Programming

Escrevendo EstóriasTodas as funcionalidades do sistema são levantadas através de estórias que são registradas em pequenos cartões. Estas estórias devem ser escritas pelo cliente, com suas próprias palavras.

eXtreme Programming

Escrevendo EstóriasEmbora possa parecer estranho pedir ao cliente para escrever asestórias, existem fortes razões para isso:

O cliente é forçado a pensar melhor na funcionalidade;

O cliente se torna responsável sobre aquilo que está sendosolicitado;

Fazer o cliente perceber que está gastando ao pedir umafuncionalidade.

eXtreme Programming

TarefasA equipe de desenvolvimento utiliza os cartões para saber quais sãoas funcionalidades desejadas pelo cliente. Os desenvolvedoresescolhem as estórias que irão implementar a cada dia de trabalho.Entretanto, em projeto muito grande, os cartões podem acabarrepresentando estórias que consomem muito esforço paraimplementar. Nestes casos, é comum a equipe dividir os cartões emtarefas. Elas são registradas em novos cartões de modo que possamser distribuídas facilmente entre a equipe de desenvolvedores.

Exemplos:

1. Apresente ao cliente 10 tarifas maisbaratas para uma determinada rota;

2. O usuário deve poder alterar o seu perfil(email, senha, primeiro nome, ultimo nomee filiação). Dois campos de senha paraconfirmação.

eXtreme Programming

Estimando EstóriasPara estimar a equipe de desenvolvimento precisa adotar umaunidade de medida que será usada para todas as estórias.

Os desenvolvedores costumam estimar indicando a quantidade detempo (horas) que uma funcionalidade irá consumir.

O XP utiliza o conceito de dia ideal de desenvolvimento, querepresenta um dia no qual o desenvolvedor trabalha naimplementação de funcionalidades, sem ter que se preocupar comnenhuma atividade extra.

Usando pontos para estimar

Estimando por comparação

Estimando em equipe

eXtreme Programming

Planejando os ReleasesO XP trabalha com o objetivo de gerar valor para o cliente ao longode todo o projeto. Para fazer isso, é importante que o software sejaentregue de forma incremental, de modo que após cada entrega ocliente possa começar a utilizar o sistema e obter os benefícios queele oferece. Estas entregas recebem o nome de release em XP.

Os projetos em XP costumas ser divididos em releases, de modo quecada release implementa um conjunto de funcionalidades que possuium valor bem definido para o cliente. Por exemplo, imagine que oprojeto de oito meses seja dividido em quatro releases, comoilustrado na figura abaixo.

8 sem.

Projeto dividido em releases

eXtreme Programming

Projeto Dividido em ReleasesSuponha que este seja o projeto de um site de vendas on-line deuma grande loja de departamentos. Poderíamos imaginar a seguintedistribuição para os releases:

R1: Consulta dos produtos em estoque; R2: Processamento de compras on-line; R3: Acompanhamento de pedidos; R4: Campanha de marketing de relacionamento.

Projetos XP procuram trabalhar com o conceito de releasespequenos, isto é, os releases têm curta duração. Preferencialmente,devem ter em torno de dois meses. Com isso, o cliente podecomeçar a usufruir os benefícios do software e a equipe dedesenvolvimento passa a ter a oportunidade de receber feedback dosusuários finais do sistema, o que permite que ela faça ajustes, demodo a aprimorar a qualidade dos releases subsequentes.

eXtreme Programming

Priorizando as Estórias de Cada Release

As releases devem ter tamanhos fixos e pequenos

Estabelecer a ordem (necessidades do cliente)

Verificar a NECESSIDADE X ASPECTOS TÉCNICOS. Observar asdependências técnicas

Distribuir as estórias nos seus respectivos releases

Não é necessário escrever todas as estórias do sistema no iníciodo projeto

O cliente deve se concentrar nas estórias da primeira release (asoutras, deixar para o futuro para evitar trabalho especulativo)

Dedicação nas estórias do release corrente e criar estórias para osreleases futuros

eXtreme Programming

Planejando as IteraçõesUma iteração é basicamente um pequeno espaço de tempo dedicadopara a implementação de um conjunto de estórias. Em sua maioria,os projetos XP utilizam iterações de duas semanas.

O início de cada iteração é caracterizado por uma reunião que recebeo nome de reunião de planejamento da iteração.

Tamanho da iteração = 2 semanas = 10 dias úteis

Deve-se descontar: 1 dia útil para a reunião de planejamento de iteração 1 dia útil para o encerramento da iteração

Dias úteis para desenvolvimento = 10 – 2 = 8 Número de desenvolvedores = 4 = 2 x 2 = 2 pares 1 par/dia = 1 ponto 1 par em 8 dias = 1 x 8 = 8 pontos 2 pares em 8 dias = 2 x 8 = 16 pontos

eXtreme Programming

Dependências TécnicasA ordem em que o cliente deseja que as estórias sejamimplementadas é afetada por dependências técnicas que a equipedeve identificar e lhe apresentar.

O XP recomenda que a equipe procure sempre respeitar a ordemindicada pelo cliente. Na maioria dos casos isso é perfeitamentepossível, desde que a equipe implemente algumas simplificações.

As dependências técnicas costumam ser bem menos criticas do queaparentam. Para contorná-las a equipe deve ser criativa e buscarsoluções que permitam ao cliente acesso às estórias tal como ele asordena.

Iterações são diferentes de releases: O XP apresenta um meio termoque permite que o cliente tenha flexibilidade e a equipe trabalhe comestabilidade. Durante todo o projeto, o cliente pode fazer alteraçõesnas estórias. Já dentro de uma iteração, e apenas neste caso, ocliente tem que respeitar o acordo da reunião de planejamento.

eXtreme Programming

Encerrando uma IteraçãoO último dia da iteração é reservado para uma reunião deencerramento. Nela, o cliente executa todos os teste de aceitaçãoque foram escritos para as estórias da iteração.

O objetivo é que ele valide todo sistema e verifique se o resultado daiteração está satisfatório.

Utilizando o sistema ele poderá detectar eventuais erros, bem comoaprender mais sobre os requisitos e, se houver necessidade, fazermudanças nos mesmos.

eXtreme Programming

Encerrando um ReleaseUm release se encerra ao final da ultima iteração prevista pra ele. Aofinal do release, a equipe coloca o sistema em produção para quetodos os usuários passem a ter acesso a ele.

Quanto mais entradas em produção o projeto tiver, melhor será oseu resultado para os usuários, visto que a cada release eles terão aoportunidade de fornecer feedback para a equipe dedesenvolvimento. Isso ajudará a equipe a direcionar seus esforçospata fazer com que o sistema fique cada vez mais adequado àsnecessidades de seus usuários.

eXtreme Programming

Stand up MeetingUm dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Estenome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo deavaliar o passado. Ela também é utilizada para decidir o que será feito no dia que se inicia.Ela serve para priorizar as atividades dos membros da equipe ao longo do dia.

eXtreme Programming

Diariamente, no stand up meeting, a equipe decide em conjunto quecartões serão tratados naquele dia e quem cuidará de cada cartão.

No fim do stand up meeting, cada membro da equipe sabe o quedeverá fazer ao longo do dia. É importante notar que a decisão sobreo que fazer ao longo do dia não é tomada por uma única pessoa. Essadecisão é tomada em equipe.

Stand up Meeting

eXtreme Programming

Programação em ParOs desenvolvedores não trabalham sozinhos em um projeto queutilize XP. Eles sempre trabalham em pares. Trata-se da programaçãoem par ou pair programming, como é conhecido em inglês.

eXtreme Programming

Os efeitos sobre a produtividade da equipe

A ideia da programação em par parece estranha a princípio porque“enquanto um desenvolvedor o outro fica parado”. Isto é, “umtrabalha enquanto o outro não faz nada”. Obviamente não é isso oque ocorre, mas é isso o que muita gente acaba interpretandoerroneamente.

Na verdade, um desenvolvedor digita enquanto o outro não digita.Mas, ambos estão programando juntos. A programação em parpressupõe uma comunicação contínua entre os desenvolvedores queformam o par. Através da conversa, eles discutem as melhoresalternativas, corrigem erros, analisam cenários, enfim, discutem asmelhores ideias para a resolução de cada problema. Portanto, éabsolutamente incorreto acreditar que um trabalha enquanto o outrofica parado. Ambos estão trabalhando o tempo todo.

eXtreme Programming

A pressão do ParO ato de programar demanda grande concentração e produz umgasto de energia considerável. Entretanto, no dia-a-dia de umprogramador, ele se depara com diversas fontes de distração: email,bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalhono código.

A programação em par corrige estes desvios através da pressão empar. O programador quando está acompanhado de outra pessoa, eledeixa de ter um compromisso apenas consigo mesmo. O seucompromisso se expande e passa a englobar também o seu colega.Ou seja, sua responsabilidade aumenta já que passa a envolver maisalguém. O efeito disso é que diversos focos de distração sãoeliminados.

eXtreme Programming

RevezamentoA condução da programação é uma atividade que deve ser realizadasempre por ambos os programadores que formam um par. Um decada vez, naturalmente. Para isso, é fundamental que eles se revezemdiversas vezes ao longo de um dia de trabalho.

O revezamento não se aplica apenas à questão de quem conduz oteclado. Ele também nos leva à questão de quem será o nosso par.Em um projeto, devemos trocar de par com frequência. Esta troca depar é importante para a disseminação do conhecimento.

eXtreme Programming

Desafios

A organização do escritório

A visão gerencial

O relacionamento humano

Competição

eXtreme Programming

Refactoring

Desenvolvimento Guiado por Testes (TDD)

eXtreme Programming

Refactoring – Conceitos básicos

Refactoring é o processo de modificar um software para melhorar aestrutura interna do código.

Esse processo não repara erros e nem adiciona novasfuncionalidades.

Outra consequência é a melhora no entendimento do código, o quefacilita a manutenção e evita a inclusão de bugs. Esta melhora noentendimento vem da constante alteração do código com objetivo defacilitar a comunicação de motivações, intenções e objetivos porparte do programador.

eXtreme Programming

Obter um código-fonte claro e de fácil manutenção

Reduzir a complexidade da aplicação

Remover redundâncias desnecessárias

Reutilizar código

Otimizar o desempenho do software.

Objetivos Básicos

eXtreme Programming

Desenvolvimento Guiado pelos Testes (TDD)

Teste é parte do desenvolvimento de software que todo mundo sabeque precisa ser feita, mas ninguem quer fazer.

Testar costuma ser considerado uma atividade chata, que consometempo e só é valorizada depois que o sistema entra em produção ediversos problemas começam a surgir.

Grande parte dos projetos deixam os testes para serem feitos no final(isso quando são feitos!)

eXtreme Programming

Por que Devemos Testar?

Se o desenvolvedor escreve um código incorreto e descobre isso doismeses depois, a sua capacidade de aprendizado é muito baixa. Poroutro lado, se ele descobre alguns segundos após introduzir o erro,ele aprende rapidamente que tipo de coisa ele fez que gera erro.Sendo assim, ele provavelmente não errará de novo no futuro.

Quando os testes fazem parte do desenvolvimento, osprogramadores recebem feedback rapidamente sobre aquilo queestão fazendo. Com isso aprendem mais, resolvem os defeitos e temmais tempo para desenvolver funcionalidades e gerar valor para ocliente.

eXtreme Programming

Testar é Investir

Quando testamos, estamos fazendo um investimento e esperamosque ele gere um retorno no futuro. No caso de testes, este retornoacontece quando:

• O desenvolvedor testa alguma coisa que deveria falhar e elasimplesmente funciona.

• O teste falha quando já vinha funcionando normalmente, ouseja, surgiu um defeito no sistema e o teste detectou.

eXtreme Programming

Testando o XP

O XP trabalha com dois tipos de testes: testes de unidade e testes deaceitação.

Testes de unidade: é aquele realizado em cada classe do sistema paraverificar se os resultados gerados são corretos.

Testes de aceitação: São efetuados sobre cada funcionalidade, ouestória do sistema.

eXtreme Programming

Testes de Unidade

Devem ser automatizados 100% deles devem rodar corretamente ao longo de todo o

desenvolvimento

Desafios

Visto como aumento de trabalho pela equipe A programação em par Início difícil de trabalhar e automatizar

Fatores essenciais

Conhecimento Ferramentas Programação em par Persistência

eXtreme Programming

Questões sobre os Testes de Unidade

Testes com acesso a um BD?

Testes rodando muito lentamente?

E quando não consigo imaginar como testar uma classe?

Como saber se testei tudo que podera quebrar?

Código já escrito e não existem testes pra ele?

Erros que aparecem da colaboração entre diferentes classes?

GUIs?

Meu código não pode ser testado porque…

Testar a entrega

eXtreme ProgrammingTestes de Aceitação

Além de verificar se cada classe está funcionando corretamente, éimportante verificar se as classes englobadas por uma estória estão serelacionando corretamente.

Quem cria e executa estes testes?

Cliente? Analista de testes? Os dois?

Testando em cada iteração

Descrever os testes em cartões, depois juntem estes aos cartõesda estória.

Um cartão só pode ser considerado finalizado quando o teste deaceitação do mesmo for executado com sucesso.

Automatizando

HTML HttpUnit

Java Jbehave, Selenium WebDriver, …

Exemplo de Teste de Aceitação

Estória Visualizar os itens do carrinho de compras

Número Ação Resultado esperado

1

Entrar no site

Visualizar os itens do carrinho de compras

Mostra a mensagem: “Seu carrinho de

compras está vazio”

2

Adicionar ao carrinho o produto: “Geladeira 380L”


Mostra uma linha contendo a

informação:

Geladeira 380L – 1 unidade – R$1500,00

3

Adicionar ao carrinho o produto: “Fogão 4 bocas”



informação:

Geladeira 380L – 1 unidade – R$1500,00

Fogão 4 bocas – 1 unidade – R$750,00

4


Clicar em “Excluir” ao lado da linha que contém a

geladeira


informação:

Fogão 4 bocas – 1 unidade – R$750,00

5


Clicar em “Excluir” ao lado da linha que contém o fogão

Mostra a mensagem: “Seu carrinho de

compras está vazio”

eXtreme Programming

eXtreme Programming

Código Coletivo Padrões de Codificação

eXtreme Programming

Código ColetivoQuando um projeto é implementado por uma equipe, é comumdividi-lo em partes, de modo que cada membro da equipe fiqueresponsável por uma ou mais partes. Desta forma, cada pessoa éresponsável por um subconjunto do código que forma o projeto.

A divisão do trabalho é uma prática comum em diversa áreasprofissionais. A forma como esta divisão é feita afeta diretamente oresultado final de um projeto.

É bastante comum encontrarmos “ilhas de conhecimento” nosprojetos de software. Uma “ilha de conhecimento” pode sercompreendida como sendo uma pessoa que possui um domíniosobre uma área do projeto. Somente ela conhece aquela parte ouaquele código. Se outra pessoa precisar mexer naquela parte, deverásolicitar à ilha de conhecimento que entre em ação.

eXtreme Programming

A programação em par, por si só, já colabora para evitar a formaçãode “ilhas de conhecimento”. Porém, o código coletivo vai além. Ele dáa todas as pessoas a chance de mexer em qualquer parte do sistema.

É importante que ele seja sempre escrito da maneira mais legívelpossível. Pois isto é o que garantirá que a equipe conseguirácontinuar a implementar o sistema.

Vale notar também que o código coletivo leva a equipe a ser maiságil no desenvolvimento. Como não existe um responsável por certaparte do código, qualquer pessoa pode mexer nela tão logo sinta anecessidade de fazê-lo. Não é necessário esperar por ninguém, nãoé necessário esperar pelo especialista.

Código Coletivo

eXtreme Programming

Padrões de CodificaçãoSe você analisar o código de diferentes programadores,provavelmente irá notar que existem diferenças de estilo. Por

exemplo, um programador prefere colocar { no final da declaração de

um método, enquanto outro prefere colocar na linha posterior.

O XP recomenda que a equipe adote um padrão no início do projeto.Ela pode construir este padrão em conjunto ou pode adotar um que jáexista e esteja documentado em algum lugar, como por exemplo:

http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html

http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html

eXtreme Programming

Padrões de CodificaçãoProcure adotar um padrão que seja fácil e simples. Isso evitaresistência e facilita a compreensão do código, ou seja, melhora acomunicação.

Jeffries et al. (2001, p.79) apresenta alguns tópicos a considerar:

Identação

Letras maiúsculas e minúsculas

Comentários (evitá-los tanto quanto possível)

Nomes

eXtreme Programming

Design Simples

Metáfora

eXtreme Programming

Design Tradicional

“O custo de se corrigir umproblema em um softwarecresce exponencialmente aolongo do tempo. Um problemaque poderia ter custado umdólar para ser corrigido setivesse sido encontrado durantea análise pode custar milharesde dólares para ser resolvidodepois que o software já estiverem produção.”

eXtreme Programming

O custo de uma alteração no XPA comunidade de desenvolvimento de software investiu uma enormequantidade de recursos nas últimas décadas no sentido de reduzir oscustos de uma alteração em um software. Estes investimentos geroudiversos avanços:

Melhores linguagens de programação Avanços na tecnologia de banco de dados Melhores práticas de programação Novos ambientes e ferramentas de desenvolvimento Computadores mais rápidos e mais baratos Orientação a objetos

eXtreme Programming

Infelizmente a única constante em um projeto de software é amudança:

Os requisitos mudam

O design muda

A tecnologia muda

A equipe muda

Os membros da equipe mudam

O problema não está na mudança em si, porque ela vai acontecer dequalquer jeito. O problema é a incapacidade de lidar com ela quandoela chegar.

Design Tradicional

eXtreme Programming

EstratégiaPara alcançar um design simples, o XP recomenda que você utilize aseguinte estratégia:

1. Comece escrevendo um teste.2. Faça o design e implemente apenas o suficiente para passar

nos testes.3. Execute os passos 1 e 2 novamente tanto quanto necessário.4. Se você identificar a oportunidade de tornar o design mais

simples, faça isso.

No XP, o design é criado de forma incremental. Sendo assim, ao finalda primeira iteração, o seu software terá um design bastante simples,suficiente para as funcionalidades daquela iteração. Na segunda, teráque fazer alguns refactorings e fará alterações no design, de modo aincorporar novas funcionalidades.

eXtreme Programming

SimplicidadeExemplo de quatro regras básicas para definir simplicidade:

1. O sistema (código e testes em conjunto) deve expressar tudoaquilo que você deseja comunicar

2. O sistema não deve conter nenhum código duplicado3. O sistema deve ter o menor número de classes possível4. O sistema deve ter o menor número de métodos possível

Atualmente, existe uma verdadeira febre pela utilização deframeworks que possam facilitar o desenvolvimento de sistemas.Tais frameworks contêm uma série de funcionalidades genéricas quepodem poupar esforço da equipe ao longo do desenvolvimento.Entretanto, existem custos associados à utilização de frameworks:curva de aprendizado e são abrangentes demais.

eXtreme Programming

MetáforaMetáforas são usadas frequentemente durante o desenvolvimento desistemas, na medida em que os desenvolvedores criam elementosdentro do computador para simular outros que existemregularmente fora dele, no mundo físico.

eXtreme Programming

XP procura explorar ao máximo a utilização de metáforas, para queclientes e desenvolvedores sejam capazes de estabelecer umavocabulário apropriado para o projeto, repleto de nomesrepresentando elementos físicos com os quais os clientes estejamhabituados em seu dia-a-dia, de modo a elevar a compreensãomútua.

Metáfora

http://improveit.com.br/xp

eXtreme Programming

Ritmo Sustentável

Integração Contínua

Releases Curtos

eXtreme Programming

Ritmo Sustentável

O XP PROÍBE que os desenvolvedores trabalhem até mais

tarde. O XP sugere um ritmo sustentável de 40 HORAS

SEMANAIS, respeitando assim a individualidade e o físico

de cada desenvolvedor. Desta forma a equipe estará

sempre concentrada e muito menos propensa a pequenas

falhas na implementação.

eXtreme Programming

Integração ContínuaO XP propõe uma integração contínua, se possível deve

ser efetuada diversas vezes ao dia para que toda a equipe

tenha conhecimento do código recém-desenvolvido. Com

esta prática o feedback sobre a alteração efetuada será

obtido em um menor espaço de tempo.

Dificuldades em integrar diversas vezes ao dia:

Tempo de build

Código Coletivo

Programação em Par

eXtreme Programming

Integração ContínuaSegundo Jeffries et al. (2001), em XP o código avança em

3 fases:

Local: As mudanças que o par executou no código

ainda não estão disponíveis para os demais.

Candidato à Liberação: O par terminou a tarefa e está

tudo pornto para a disponibilização.

Disponibilizado: Código pronto. Testes 100%.

eXtreme Programming

Integração ContínuaFerramentas: Para que seja feita a integração contínua,

são necessárias ao menos duas categorias de

ferramentas para auxiliá-lo:

Ferramenta de build – Ant ou Maven

Sistema de controle de versão (Repositório) – CVS,

Git, ClearCase, SourceSafe (Team Foundation Server)

etc.

eXtreme Programming

Releases CurtosO XP recomenda que pequenos investimentos sejam

efetuados de forma gradual e que busquem grandes

recompensas o mais rapidamente possível. Com a prática

de releases curtos, o XP pretende dar o máximo de valor

econômico ao cliente em um curto espaço de tempo.

Release é um conjunto de funcionalidades bem definidas

e que representam algum valor para o cliente.

eXtreme Programming

Releases Curtos

Formado em Análise de Sistemas

Pós-Graduado em Auditoria em T.I.

Gerente de TI da CLIOC – Coleção de Leishmania do

Instituto Oswaldo Cruz – Fiocruz

Certificado em Gestão de Segurança da Informação e

Gerenciamento de T.I. pela Academia Latino-Americana

(Microsoft TechNet / Módulo Security)

Carlos Henrique M. da [email protected]

mailto:[email protected]

Technology

eXtreme Programming (XP)