Carlos Henrique M. da Silva [email protected] eXtreme Programming

Carlos Henrique M. da [email protected]

eXtreme Programmin

g

mailto:[email protected]


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

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

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?

eXtreme Programming - IntroduçãoDesenvolver software é uma atividade arriscada. Segundo as estatí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 problemas dos usuários;

Mudanças constantes podendo estar relacionadas a requisitos, cronograma, equipe...

Baixa qualidade dos sistemas desenvolvidos.

eXtreme Programming - IntroduçãoHá algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. Um marco neste sentido é a criação da disciplina de Engenharia de Software em 1968. De lá para cá, inúmeras propostas foram feitas para melhorar o desempenho dos projetos, começando pelo processo de desenvolvimento linear e seqüencial (em cascata) até chegar aos atuais processos ágeis de desenvolvimento.

O XP é um dos representantes destes processos e foi criado por Kent Beck em 1997 em um projeto para a Chrysler (fabricante de veículos norte-americana). O XP é composto por um conjunto reduzido de práticas de desenvolvimento que se organizam em torno de valores básicos. Essas práticas possuem fortes inter-relacionamentos formando 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 quer amanhã

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

Cust

o

Análise Projeto Codificação TestesTempo


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 efetivamente

entregues.

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, valorizamos mais os itens à esquerda.”

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

ReferênciaeXtreme 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 ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo.

VISÃO GERAL

O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurar que 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 XPeXtreme Programming

ComunicaçãoA comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem.

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

eXtreme Programming

SimplicidadeA comunicação, embora seja essencial, não é suficiente para garantir que o cliente possa aprender durante o projeto e gerar feedback rapidamente. Também é necessário que a equipe compreenda e utilize o valor da simplicidade, que nos ensina a implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. Ou seja, ao codificar uma funcionalidade devemos nos preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro (NÃO DEVEMOS TENTAR PREVER O FUTURO), pois raramente acertamos as previsões.

eXtreme Programming

FeedbackQuando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento.

O feedback é o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e garanta que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.

eXtreme Programming

CoragemExistem temores que costumam assombrar os participantes de um projeto de software. Beck e Fowler (2001) destacam alguns destes medos que exercem influência significativa nos processos 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çam sentido; Ficar defasados tecnicamente; Receber responsabilidades, sem autoridade; Não receber definições claras sobre o que precisa ser feito; Sacrificar a qualidade em função de prazo; Ter que resolver problemas complicados sem ajuda e Não ter tempo suficiente para fazer um bom trabalho.

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 primeiras decisões e não serem capazes de reagir a mudanças nos negócios.

eXtreme Programming

RespeitoeXtreme Programming

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

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

eXtreme Programming

eXtreme ProgrammingEquipe (Whole Team)

Equipe XP = Cliente + Time de Desenvolvimento

Os papéis do time de desenvolvimento englobam:

• 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 do projeto• Definição de prioridades• Controle do rumo do projeto• Definir os testes de aceitação do Software

eXtreme ProgrammingJogo 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 ProgrammingPequenos 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 ProgrammingTestes 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 ProgrammingProjetos 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 ProgrammingDesenvolvimento Dirigido por

Testes (Test-driven Development)

eXtreme ProgrammingRefinamento de código

(Refactoring)

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

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

eXtreme ProgrammingIntegração Contínua

(Continuous Integration)

eXtreme ProgrammingPosse Coletiva

(Collective Ownership)

eXtremme ProgrammingPadrões de Codificação

(Coding Standards)

eXtremme ProgrammingRitmo Saudável (Sustainable

Pace)

eXtremme ProgrammingMetáfora (Metaphor)

eXtremme ProgrammingReuniões em Pé (Stand-up

Meeting)

eXtremme ProgrammingSpikes de Planejamento

(Spike Solution)

eXtremme ProgrammingComo 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 "design flexível")

• Jogar fora código desnecessário• Escrever testes antes de codificar• Refatorar com frequência (vencer o medo)

eXtremme ProgrammingQuando 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 ProgrammingCaracterísticas da Equipe

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

Gerente de Projeto

Coach

Analista de Teste

Redator Técnico

Desenvolvedor

eXtreme Programming

Gerente de ProjetoO gerente de projeto é responsável pelos assuntos administrativos do projeto. Ele procura liberar a equipe de questões que não estejam diretamente ligadas à atividade diária de desenvolvimento. Além disso, administra o relacionamento com o cliente assegurando que o mesmo participe ativamente do desenvolvimento e forneça as informações essenciais para que a equipe possa implementar o sistema desejado.

eXtreme ProgrammingCoachO coach é o profissional técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.

eXtreme ProgrammingAnalista de Testes

O analista de teste é responsável por ajudar o cliente a escrever os testes de aceitação. Quando estes testes não são automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iterações do projeto. Ele procura fazer com que os eventuais defeitos do sistema sejam identificados tão logo apareçam. Desta forma, fornece feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez e evitar que os problemas se propaguem.

eXtreme Programming

Redator TécnicoO redator técnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presença permite que os desenvolvedores se concentrem prioritariamente na implementação do software. Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz a maior parte do trabalho de documentação.

eXtreme ProgrammingDesenvolvedor

O desenvolvedor é a pessoa que analisa, projeta e codifica o sistema. Em suma, é a pessoa que efetivamente constrói o software. Dentro do XP, não existem divisões entre analista, projetista, programador, etc. Cada desenvolvedor exerce estes diferentes papéis em diversos momentos do projeto.

eXtreme ProgrammingDesafios de Desenvolvimento de

SoftwareModelo em Cascata

eXtreme Programming

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

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 para implementar as diversas partes do software

Teste: para verificar se o sistema atende às necessidades especificadas pelo 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 finais passam a utilizá-lo

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

Desafios de Desenvolvimento de Software

eXtreme ProgrammingDesenvolvimento Ágil

O termo “desenvolvimento ágil”, faz referência ao desenvolvimento iterativo, em espiral. Ele recomenda que todas as fases descritas no modelo em cascata sejam executadas diversas vezes ao longo do projeto, produzindo ciclos que se repetem ao longo de todo o desenvolvimento. Cada ciclo (da análise à implementação) recebe o nome de iteração. No desenvolvimento iterativo, o software cresce a cada iteração, isto é, o resultado de cada iteração é um software pronto, testado e aprovado, sendo que a primeira contém poucas funcionalidades, enquanto a última contém todas as funcionalidades do sistema.

eXtreme ProgrammingCliente Presente

IntroduçãoTradicionalmente, quando pensamos no desenvolvimento de software, delegamos ao cliente a tarefa de manifestar as suas necessidades e à equipe de desenvolvimento a de implementar. Ou seja, há uma divisão implícita entre as responsabilidades de cada parte e um certo distanciamento entre elas.

eXtreme ProgrammingO XP trabalha com uma visão diferente

O XP sugere que o cliente esteja presente durante o dia-a-dia do projeto. A sua participação contribui para o sucesso do projeto, enquanto sua a sua ausência é um sério fator de risco.

A participação do cliente viabiliza a simplicidade do processo. Além disso, ela permite que o projeto seja conduzido através de uma série de pequenos ajustes e não através de mudanças bruscas ao longo do caminho.

eXtreme ProgrammingEstórias

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

eXtreme ProgrammingDúvidas Durante a Implementação

Enquanto os desenvolvedores se aprofundam na modelagem da nova funcionalidade e começam a implementá-la, dúvidas podem surgir. Mais uma vez, a presença do cliente permite que as dúvidas sejam respondidas rapidamente. Isso contribui com a agilidade do processo e evita o trabalho especulativo.

eXtreme ProgrammingO Trabalho Especulativo

O trabalho especulativo, que ocorre quando a equipe não consegue ter as dúvidas respondidas e assume premissas, representa um enorme risco de retrabalho negativo. Assumindo premissas, a equipe pode vir a construir partes da funcionalidades de forma completamente incorreta, o que poderia ter sido evitado se o cliente estivesse presente para responder às dúvidas.

eXtreme ProgrammingConfiança: um sub-produto da presença do

clienteAlém do feedback entre cliente e equipe de desenvolvimento, a participação do cliente no desenvolvimento também contribui para melhorar o relacionamento de ambas as partes. A aproximação aumenta a confiança de todos os envolvidos.

É preciso notar que serviço é um produto intangível, como o próprio software. Normalmente, temos mais facilidade em medir o valor de algo 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 do cliente permite que muitas dúvidas sejam respondidas. Além disso, com o cliente próximo, a equipe pode apontar questões que tenham passados desapercebidas aos olhos dele. Desta forma, a equipe pode preveni-lo de situaçõ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 ProgrammingO Jogo do Planejamento

O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar mais valor para o cliente a cada dia de trabalho. Este planejamento é feito diversas vezes ao longo do projeto, para que todos tenham a oportunidade 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 ProgrammingDividindo as Responsabilidades

A chave para gestão de um projeto de software é o equilíbrio de poderes entre o cliente e a equipe de desenvolvimento. Por esta razão, o XP procura separar claramente o papel de cada um, para assegurar que o cliente tome todas as decisões de negócio, enquanto a equipe de desenvolvimento cuida das decisões técnicas. (Beck e Fowler, 2001). Isso dá origem a declaração de direitos do cliente e do desenvolvedor (Jeffries et al., 2001).

eXtreme ProgrammingDireitos 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 ProgrammingEscrevendo Estórias

Todas 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 ProgrammingEscrevendo Estórias

Embora possa parecer estranho pedir ao cliente para escrever as estó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á sendo solicitado;

Fazer o cliente perceber que está gastando ao pedir uma funcionalidade.

eXtreme ProgrammingTarefas

A equipe de desenvolvimento utiliza os cartões para saber quais são as funcionalidades desejadas pelo cliente. Os desenvolvedores escolhem as estórias que irão implementar a cada dia de trabalho. Entretanto, em projeto muito grande, os cartões podem acabar representando estórias que consomem muito esforço para implementar. Nestes casos, é comum a equipe dividir os cartões em tarefas. Elas são registradas em novos cartões de modo que possam ser distribuídas facilmente entre a equipe de desenvolvedores.Exemplos:1. Apresente ao cliente 10 tarifas mais baratas para uma determinada rota;2. O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, ultimo nome e filiação). Dois campos de senha para confirmação.

eXtreme ProgrammingEstimando Estórias

Para estimar a equipe de desenvolvimento precisa adotar uma unidade de medida que será usada para todas as estórias.

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

O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia no qual o desenvolvedor trabalha na implementação de funcionalidades, sem ter que se preocupar com nenhuma atividade extra.

Usando pontos para estimar

Estimando por comparação

Estimando em equipe

eXtreme ProgrammingPlanejando os Releases

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

Os projetos em XP costumas ser divididos em releases, de modo que cada release implementa um conjunto de funcionalidades que possui um valor bem definido para o cliente. Por exemplo, imagine que o projeto de oito meses seja dividido em quatro releases, como ilustrado na figura abaixo.

8 sem.

Projeto dividido em releases

eXtreme ProgrammingProjeto Dividido em Releases

Suponha que este seja o projeto de um site de vendas on-line de uma grande loja de departamentos. Poderíamos imaginar a seguinte distribuiçã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 releases pequenos, isto é, os releases têm curta duração. Preferencialmente, devem ter em torno de dois meses. Com isso, o cliente pode começar a usufruir os benefícios do software e a equipe de desenvolvimento passa a ter a oportunidade de receber feedback dos usuários finais do sistema, o que permite que ela faça ajustes, de modo a aprimorar a qualidade dos releases subsequentes.

eXtreme ProgrammingPriorizando 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 as dependências técnicas Distribuir as estórias nos seus respectivos releases Não é necessário escrever todas as estórias do sistema no início do projeto O cliente deve se concentrar nas estórias da primeira release (as outras, deixar para o futuro para evitar trabalho especulativo) Dedicação nas estórias do release corrente e criar estórias para os releases futuros

eXtreme ProgrammingPlanejando as Iterações

Uma iteração é basicamente um pequeno espaço de tempo dedicado para 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 recebe o 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 ProgrammingDependências Técnicas

A ordem em que o cliente deseja que as estórias sejam implementadas é afetada por dependências técnicas que a equipe deve identificar e lhe apresentar.O XP recomenda que a equipe procure sempre respeitar a ordem indicada pelo cliente. Na maioria dos casos isso é perfeitamente possível, desde que a equipe implemente algumas simplificações.As dependências técnicas costumam ser bem menos criticas do que aparentam. Para contorná-las a equipe deve ser criativa e buscar soluções que permitam ao cliente acesso às estórias tal como ele as ordena.Iterações são diferentes de releases: O XP apresenta um meio termo que permite que o cliente tenha flexibilidade e a equipe trabalhe com estabilidade. Durante todo o projeto, o cliente pode fazer alterações nas estórias. Já dentro de uma iteração, e apenas neste caso, o cliente tem que respeitar o acordo da reunião de planejamento.

eXtreme ProgrammingEncerrando uma Iteração

O último dia da iteração é reservado para uma reunião de encerramento. Nela, o cliente executa todos os teste de aceitação que foram escritos para as estórias da iteração.

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

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

eXtreme ProgrammingEncerrando um Release

Um release se encerra ao final da ultima iteração prevista pra ele. Ao final do release, a equipe coloca o sistema em produção para que todos os usuários passem a ter acesso a ele.

Quanto mais entradas em produção o projeto tiver, melhor será o seu resultado para os usuários, visto que a cada release eles terão a oportunidade de fornecer feedback para a equipe de desenvolvimento. Isso ajudará a equipe a direcionar seus esforços pata fazer com que o sistema fique cada vez mais adequado às necessidades de seus usuários.

eXtreme ProgrammingStand up Meeting

Um dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Este nome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo de avaliar 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 que cartõ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 que deverá fazer ao longo do dia. É importante notar que a decisão sobre o que fazer ao longo do dia não é tomada por uma única pessoa. Essa decisão é tomada em equipe.

Stand up Meeting

eXtreme ProgrammingProgramação em Par

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

eXtreme ProgrammingOs efeitos sobre a produtividade da

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

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

eXtreme ProgrammingA pressão do Par

O ato de programar demanda grande concentração e produz um gasto de energia considerável. Entretanto, no dia-a-dia de um programador, ele se depara com diversas fontes de distração: email, bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalho no código.

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

eXtreme ProgrammingRevezamento

A condução da programação é uma atividade que deve ser realizada sempre por ambos os programadores que formam um par. Um de cada vez, naturalmente. Para isso, é fundamental que eles se revezem diversas vezes ao longo de um dia de trabalho.

O revezamento não se aplica apenas à questão de quem conduz o teclado. 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 de par é importante para a disseminação do conhecimento.

eXtreme ProgrammingDesafios

A organização do escritório

A visão gerencial

O relacionamento humano

Competição

eXtreme Programming

Refactoring

Desenvolvimento Guiado por Testes (TDD)

eXtreme ProgrammingRefactoring – Conceitos básicos

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

Esse processo não repara erros e nem adiciona novas funcionalidades.

Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de bugs. Esta melhora no entendimento vem da constante alteração do código com objetivo de facilitar a comunicação de motivações, intenções e objetivos por parte 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 ProgrammingDesenvolvimento Guiado pelos Testes

(TDD)Teste é parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguem quer fazer.

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

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

eXtreme ProgrammingPor que Devemos Testar?

Se o desenvolvedor escreve um código incorreto e descobre isso dois meses depois, a sua capacidade de aprendizado é muito baixa. Por outro 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, os programadores recebem feedback rapidamente sobre aquilo que estão fazendo. Com isso aprendem mais, resolvem os defeitos e tem mais tempo para desenvolver funcionalidades e gerar valor para o cliente.

eXtreme ProgrammingTestar é Investir

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

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

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

eXtreme ProgrammingTestando o XP

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

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

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

eXtreme ProgrammingTestes 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 ProgrammingQuestõ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 se relacionando 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ões da estória.

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

AutomatizandoHTML HttpUnit

Java Jbehave, Selenium WebDriver, …

Exemplo de Teste de AceitaçãoEstória Visualizar os itens do carrinho de comprasNú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”



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


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 ProgrammingCódigo Coletivo

Quando um projeto é implementado por uma equipe, é comum dividi-lo em partes, de modo que cada membro da equipe fique responsá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 áreas profissionais. A forma como esta divisão é feita afeta diretamente o resultado final de um projeto.

É bastante comum encontrarmos “ilhas de conhecimento” nos projetos de software. Uma “ilha de conhecimento” pode ser compreendida como sendo uma pessoa que possui um domínio sobre uma área do projeto. Somente ela conhece aquela parte ou aquele 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ção de “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ível possí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 certa parte do código, qualquer pessoa pode mexer nela tão logo sinta a necessidade de fazê-lo. Não é necessário esperar por ninguém, não é necessário esperar pelo especialista.

Código Coletivo

eXtreme ProgrammingPadrões de Codificação

Se 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



eXtreme ProgrammingPadrões de Codificação

Procure adotar um padrão que seja fácil e simples. Isso evita resistência e facilita a compreensão do código, ou seja, melhora a comunicaçã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 ProgrammingDesign Tradicional

“O custo de se corrigir um problema em um software cresce exponencialmente ao longo do tempo. Um problema que poderia ter custado um dólar para ser corrigido se tivesse sido encontrado durante a análise pode custar milhares de dólares para ser resolvido depois que o software já estiver em produção.”

eXtreme ProgrammingO custo de uma alteração

no XPA comunidade de desenvolvimento de software investiu uma enorme quantidade de recursos nas últimas décadas no sentido de reduzir os custos de uma alteração em um software. Estes investimentos gerou diversos 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 é a mudanç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 de qualquer jeito. O problema é a incapacidade de lidar com ela quando ela chegar.

Design Tradicional

eXtreme ProgrammingEstratégia

Para alcançar um design simples, o XP recomenda que você utilize a seguinte 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 final da 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 a incorporar novas funcionalidades.

eXtreme ProgrammingSimplicidade

Exemplo de quatro regras básicas para definir simplicidade:

1. O sistema (código e testes em conjunto) deve expressar tudo aquilo 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 de frameworks que possam facilitar o desenvolvimento de sistemas. Tais frameworks contêm uma série de funcionalidades genéricas que podem 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 ProgrammingMetáfora

Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico.

eXtreme Programming

XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua.

Metáfora

http://improveit.com.br/xp

eXtreme Programming

Ritmo

Sustentável

Integração

Contínua

Releases Curtos

eXtreme ProgrammingRitmo 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.


O 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


Segundo 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%.


Ferramentas: 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

OBRIGADO!

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]



Documents

Carlos Henrique M. da Silva [email protected] eXtreme Programming