Conhecendo o eXtreme Programming

Conhecendo o eXtreme Programming (XP) Daniel de Freitas Wildt, Guilherme Silva de Lacerda {dwildt,guilhermeslacerda}@gmail.com Abstract. The main goal of this work is to show a comprehensive view of Agile Methods, with emphasis in principles, values, and practices of eXtreme Programming. Resumo. O principal objetivo deste artigo é apresentar uma visão abrangente das metodologias ágeis, com ênfase em princípios, valores e práticas do eXtreme Programming.1. IntroduçãoNo final da década de 60, duas conferências organizadas pelo Comitê de Ciências daOTAN1 foram responsáveis por um marco na história da computação: o nascimento dotermo “Engenharia de Software”. Um dos objetivos destas conferências era discutir osproblemas da indústria de software. O termo engenharia de software foi escolhido paraevidenciar a preocupação com a produção de software e a necessidade de basear aprodução em fundamentos teóricos e práticas conhecidas dos diversos ramos daengenharia [Naur e Randell 1968]. A engenharia de software tem como objetivo viabilizar maior produtividade naconstrução de aplicações e qualidade dos artefatos de software [Ghezzi, Jazayeri eMadrioli 1991; Pressman 1995]. Diversos foram os modelos e processos que surgiram com tais perspectivas,fornecendo descrições de como o software deveria ser criado e mantido [Ortigosa 1995].De uma forma geral, estas descrições envolvem uma contínua produção e transformaçãode notações, desde a especificação de requisitos até o código do software produzido. O primeiro deles, conhecido como modelo Waterfall [Royce 1970], tinha comopremissa a grande ênfase em planejamento, assumindo que os requisitos não sofreriammudanças ao longo do projeto. Era baseado em ciclos seqüenciais onde cada etapadependia totalmente do término da etapa anterior, acarretando, dentre outros problemas,o desânimo e impaciência do cliente. A figura 1 apresenta um gráfico sobre custo damodificação em relação ao tempo de projeto [Beck 2004]. À medida que se avança nasetapas de desenvolvimento e, caso sejam solicitadas mudanças, deve-se voltar paraetapas anteriores de planejamento para ajustar as atividades, tornando-a caras paraincluí-las e adaptá-las.1 OTAN: Organização do Tratado do Atlântico Norte

Figura 1. Custos da modificação em relação às etapas do ciclo de vida [Beck 2004] Outras abordagens também surgiram, dando ênfase em aspectos diversos daconstrução de software, como construção de modelos formais, modelos evolucionários,modelo espiral e incrementais/iterativos [Balzer 1981; Gilb 1981; Boehm 1986;Jacobson, Rumbaugh e Booch 1999]. Embora exista cada vez mais a preocupação eesforços para definir processos, métodos, técnicas e ferramentas para desenvolvimentode software, não existe uma única solução ou “bala de prata” para todos os problemas[Brooks 1987]. Mesmo assim, as estatísticas de falha em projetos de software ainda estãopresentes. No último Chaos Report2 [Standish Group 2009], somente 32% dos projetosde software são considerados como entregues com sucesso, 24% falharam integralmentee 44% não tiveram seus objetivos plenamente satisfeitos. Estes dados comprovam que a atividade desenvolver software é complexa e queenvolve uma série de fatores técnicos e humanos, desde planejamento do projeto,entendimento dos requisitos, construção e evolução do software até relacionamento ecomunicação do time e com clientes. A ênfase em planejamento pleno do projeto, logo de início, tentando prever tudoque poderá acontecer também é dos fatores que levam a aumentar estas estatísticas.Tenta-se prever todas as atividades para poder definir as estimativas a priori. O maiorproblema é que não se sabe exatamente o que será desenvolvido. À medida que seaproxima da construção do software, a realidade do trabalho emerge, ficando mais claropara se definir as estimativas [McConnell 1998]. A figura 2, denominada cone daincerteza, apresenta esta relação, desde o planejamento até a conclusão do software. Ocone da incerteza mostra que a fase de viabilidade (visão do produto) e estimativasiniciais pode variar de 25% a 400%. Isto representa que, caso o projeto tenha umaprevisão de 10 semanas de trabalho, esta estimativa pode variar de 2,5 semanas a 40semanas.2 Relatório publicado periodicamente pelo Standish Group International, sobre pesquisas relacionadas asucessos e fracassos de projetos de software.

Figura 2. Cone da Incerteza [McConnell 1998] Nas abordagens mais tradicionais, como Waterfall (figura 3, a), as etapas dedesenvolvimento podem variar de meses chegando a anos, quando o software é entregueao cliente, em função de postergar ao máximo o desenvolvimento, dando ênfase maiorno planejamento. Desta forma, demora-se a obter o software e, nos casos atuais, o ROI3.O lead time4 é gigantesco. Figura X. Ciclos de vida Waterfall e Iterativo [Shore e Warden 2008] No ciclo de vida iterativo (figura 3, b), o lead time é reduzido e assume-se que asentregas ocorrerão de forma incremental. O cliente tem condições de fornecer feedbackmais freqüente. Com isso, o custo da mudança durante a construção é reduzido emrelação ao modelo Waterfall [Beck 2004].3 ROI (Return on Investiment). Os softwares hoje são estratégicos para os negócios das empresas.4 Tempo considerado entre o início de uma atividade e o seu término.

Figura 4. Custo da mudança em função do tempo em Processos Incrementais e Iterativos [Beck 2004] Em XP, principal assunto abordado neste trabalho, o objetivo é dividir asiterações em menor escala, onde o planejamento é constantemente revisto e repriorizadocom o cliente, objetivando sempre entregar maior valor no software, aumentando o ROI. Figura 5. Ciclo de vida do XP [Shore e Warden 2008] Este artigo está organizado da seguinte forma: na seção 2 é apresentada umavisão geral sobre as metodologias ágeis, seus valores, princípios e exemplos destasabordagens; na seção 3, é apresentado o XP, sua origem, principais papéis e práticas; Ãseguir, na seção 4, são apresentadas características de implementação do XP, com focoem planejamento de releases, iterações e trabalho diário; Na seção 5, são apresentadasalgumas ferramentas que apóiam as práticas de XP e, finalmente na seção 6, éapresentada dicas de adaptação das práticas em contextos difíceis para a adoção demetodologias ágeis.2. Metodologias ÁgeisNa década de 90, alguns profissionais da indústria de software propuseram novosprocessos e metodologias para desenvolvimento de software, adequados para lidar comaspectos humanos dos projetos de software. Em fevereiro de 2001, em Utah, 17 profissionais experientes (consultores,desenvolvedores e líderes) da comunidade de software se reuniram para discutiralternativas aos processos e práticas burocráticas utilizadas nas abordagens tradicionaisde Engenharia de Software e Gerência de Projetos. Assim nasceu o Manifesto Ágil[Beck et al 2001], que destaca as diferenças em relação as abordagens tradicionais. Noquadro 1, é apresentado um trecho do manifesto ágil, que define os seus principaisvalores.

A principal diferença das metodologias ágeis em relação às metodologiastradicionais é o enfoque na adaptação, visando ter o mínimo necessário5 para arealização do trabalho. Com esta estratégia, busca-se aceitar e trabalhar a mudança,reduzindo custos de implementação [Highsmith e Cockburn 2001]. Quadro 1. Trecho do Manifesto Ágil (tradução livre de [Beck et al 2001]) “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar: 1. Indivíduos e interação MAIS QUE processos e ferramentas; 2. Software em funcionamento MAIS QUE documentação abrangente; 3. Colaboração com o cliente MAIS QUE negociação de contratos; 4. Responder a mudanças MAIS QUE seguir um plano. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas Além dos valores, o Manifesto Ágil também apresenta 12 princípios que ajudamna promoção de suas idéias [Beck et al 2001]. Estes princípios são descritos a seguir: 1. A maior prioridade é a satisfação do cliente por meio da entrega rápida e contínua de software que agregue valor; 2. Mudanças nos requisitos são aceitas, mesmo em estágios avançados de desenvolvimento. Processos ágeis aceitam mudanças que trarão vantagens competitivas para o cliente; 3. Entregue software em funcionamento frequentemente, em períodos de poucas semanas a poucos meses, com preferência para a menor escala de tempo; 4. As pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar juntos no dia a dia do projeto; 5. Desenvolva projetos com indivíduos motivados, fornecendo ambiente e o suporte necessário e confiando que realizarão o trabalho; 6. A forma mais eficiente e eficaz de transmitir informações dentro e fora do time de desenvolvimento é a comunicação face a face; 7. A principal medida de progresso é software funcionando; 8. Processos ágeis promovem o desenvolvimento em ritmo sustentável. Os investidores, desenvolvedores e usuários devem ser capazes de manter este ritmo constante; 9. Cuidar continuamente da excelência técnica e do bom design ajuda a aprimorar a agilidade;5 barelly suficient

10. Simplicidade – a arte de maximizar a quantidade de trabalho não necessário - é essencial; 11. Os melhores requisitos, arquiteturas e design surgem de equipes auto- organizadas, e; 12. Em intervalos regulares, o time reflete sobre como se tornar mais eficiente, refinando e ajustando seu comportamento. Esses princípios, se entendidos pelo cliente e pelo time, promovem umamudança de atitude [Smith e Sidky 2009]. O cliente consegue enxergar valor maisrapidamente nas entregas freqüentes do software e, à medida que visualiza a solução,consegue refletir sobre alternativas e prioridades. O time trabalha mais motivado,porque consegue enxergar valor no seu trabalho que, através de feedback constante,evolui continuamente. Essa relação aumenta para ambos, pois a confiança se faz cadavez mais presente. Na figura 6, é mostrado o fluxo de valor das abordagens ágeis,partindo da visão do produto, construção até a entrega implantação incremental desteproduto. Uma das práticas presentes neste fluxo é o constante aprendizado e a troca deconhecimento do time com o cliente. Figura 6. Fluxo de Valor (adaptado de [Shalloway e Trott 2009]) Com base nestes valores e princípios, aparecem abordagens mais específicas,algumas com focos diferentes, mas com o mesmo núcleo. A seguir, são apresentadosexemplos destas abordagens.2.1. Lean Software DevelopmentO Sistema Toyota de Produção (STP) revolucionou a indústria da manufatura, desdegeração de valor para o cliente quanto à satisfação de trabalho para o time [Ohno 1998;Liker 2004]. Estes princípios serviram de base para Mary e Tom Poppendieck identificarsemelhanças entre estes princípios e valores com o desenvolvimento de software. Combase nestes pensamentos, foram identificados sete princípios para o desenvolvimento desoftware. Estes princípios são: 1) eliminar desperdícios; 2) incluir qualidade noprocesso; 3) criar conhecimento; 4) adiar comprometimentos; 5) entregar rápido; 6)respeitar as pessoas e, 7) otimizar o todo [Poppendieck e Poppendieck 2003;Poppendieck e Poppendieck 2005].

2.2. ScrumO Scrum surgiu na década de 90, criado por Ken Schwaber, Jeff Shuterland e MikeBeedle [Schwaber 2004; Schwaber e Beedle 2001]. Seu principal objetivo é prover umframework para gerenciamento de projetos, onde, a partir de um backlog inicial,prioriza-se o trabalho que será realizado na iteração (denominado sprint), gerando umpotencial produto no final de cada ciclo. Este trabalho é desenvolvido comacompanhamento diários (daily scrum meetings) e de final de sprint (sprintretrospective), com o objetivo de reduzir riscos e promover a melhoria contínua. Pormais dar ênfase no gerenciamento de atividades e tarefas, o Scrum pode ser utilizado emconjunto com outros métodos e processos, que dão ênfase na engenharia, como XP. Nafigura 7, é apresentado o fluxo do Scrum. Figura 7. Fluxo do Scrum [Hunt 2006]2.3. Familia CrystalA família Crystal é um conjunto de metodologias criadas por Alistair Cockburn paraequipes de tamanhos diferentes [Cockburn 2004]. Os primeiros trabalhos e estudossobre esta metodologia foi cunhado na IBM, em meados de 1990. A partir dascaracterísticas dos projetos, se escolhe a mais apropriada. No Crystal, as metodologiascompartilham alguns princípios como entrega incremental em períodos de tempo, testesfuncionais e de regressão, revisões e workshops de produto. Um outro ponto forte que sedeve ter em mente, abordado por Cockburn, é a utilização do mínimo necessário paraalcançar o sucesso no projeto.2.4. Adaptive Software Development (ASD)Segundo [Highsmith 1997], o principal objetivo do ASD é identificar a naturezaadaptativa dos projetos de software, tratando as incertezas que são inerentes a estanatureza. Para isso, Jim Highsmith baseou seus estudos na teoria de SistemasAdaptativos Complexos e na Teoria do Caos. O ASD é dividido em fases que se

sobrepõem: especulação, colaboração e aprendizado. Na figura 8, é apresentado o ciclode fases do ASD. Figura 8. Fases do ASD [Highsmith 2000] Através de iterações curtas, a equipe cria o conhecimento através do uso deprototipações. No final de cada ciclo, ocorrem reuniões e revisões em grupo.2.5. Dynamic System Development Method (DSDM)O DSDM foi criado em 1994, desenvolvido por um consórcio de empresas britânicas. Ébaseado nas melhores práticas do RAD6 [Martin 1991] e no modelo incremental eiterativo. O DSDM inicia com fases de análise de viabilidade de descrição do negócio.Nas fases de construção (modelagem/design/implementação) são realizados ciclositerativos de desenvolvimento. O DSDM tem como princípios a participação ativa docliente, entregas freqüentes, times com poder de decisão e testes durante o ciclo de vidado produto [Stapleton 1997]. A figura 9 apresenta o fluxo do DSDM. Figura 9. Fases e Processos do DSDM [Hunt 2006]6 Rapid Application Development

2.6. Feature Driven Development (FDD)A FDD foi criada por Jeff De Luca e Peter Coad [Palmer e Felsing 2002]. É umprocesso de software baseado em curtas iterações, definindo duas fases:Concepção/Planejamento e Construção. Dentro da fase de Concepção/Planejamento,existem os processos de criação de um modelo abrangente, que serve de base para acriação da lista de features. Com base nesta lista, é que é realizado o planejamento. Na fase de construção, estas features serão detalhadas e construídas. A figura 10representa as fases e os processos da FDD. Figura 10. Fases e Processos do FDD [Hunt 2006] Neste projeto é que surgiu a idéia de utilizar modelos UML em cores, pararepresentar classes com diferentes responsabilidades, denominados arquétipos [Coad,Luca e Lefebvre 1999]. O eXtreme Programming, principal objeto de estudo deste trabalho, seráapresentado com mais detalhes nas próximas seções.3. eXtreme Programming (XP)Segundo [Beck 2004; Cunningham 2002], eXtreme Programming (XP) é uma disciplinade desenvolvimento de software voltada para pequenas e médias equipes, onde osrequisitos são vagos e mudam freqüentemente. Desenvolvido por Kent Beck, WardCunningham e Ron Jeffries, o XP tem como principal tarefa a codificação, com ênfase

menor nos processos formais de desenvolvimento, com uma maior disciplina decodificação e testes. Tem como valores a comunicação, simplicidade, feedback ecoragem. A comunicação é essencial em projetos de software. É a principal forma de setransmitir e trocar informações e conhecimentos do projeto. Por esta razão, é importanteincentivar meios eficazes de comunicação. A comunicação está presente no ManifestoÁgil [Beck et al 2001] e na maioria das práticas de XP [Beck 2004]. Na figura 11, éapresentado um gráfico que representa ferramentas de comunicação e sua efetividade. Àmedida que se aproxima dos membros do time (pessoas), mais rica é a comunicação. Damesma forma, quanto mais se afasta das pessoas, mais ruídos e barreiras surgem. Figura 11. Riqueza dos Canais de Comunicação [Ambler 2005] A comunicação incentiva diretamente outro valor, essencial em XP: o feedback.Na adoção das práticas, o feedback é realizado a todo momento, seja em relação arequisitos do cliente, seja em relação ao resultado da execução de testes unitários, sejana compilação do código. A compreensão das necessidades dos usuários e do negóciopropriamente dito é um aprendizado contínuo. Segundo [Cockburn 2002], a razão deadotar estratégias incrementais e iterativas é permitir que os inevitáveis erros daspessoas sejam descobertos o mais cedo possível e reparados de forma metódica. A simplicidade é outro valor presente nas práticas XP. É a diretriz de um projetoágil. A simplicidade visa manter o trabalho o mais simples e focado possível,entregando o que realmente agrega valor [Poppendieck e Poppendieck 2003]. Conforme[Boehm e Turner 2003], acrescentar suporte para futuras funcionalidades de formadesnecessária complica o design e eleva o esforço de para desenvolver incrementossubseqüentes. A coragem também é incentivada através do uso das práticas. O desenvolvedorsó sentirá confiança em alterar o código de outro colega se conhecer o padrão decodificação, por exemplo. Além desta prática, o uso de controle de versão e testesunitários também encorajam tal investida. Segundo [Beck e Fowler 2000], além destesmedos naturais de alteração de código, tem-se uma série de medos que exerceminfluência nos processos de desenvolvimento. Os clientes temem: a) não obter o que

pediram; b) pedir a coisa errada; c) pagar de mais por muito pouco; d) jamais ver umplano relevante; e) não saber o que está acontecendo e, f) aterem-se nas primeirasdecisões de projeto e não serem capazes de reagir à mudança dos negócios. O time dedesenvolvimento teme: a) ser solicitados a fazer mais do que sabem fazer; b) serordenados a fazer coisas que não façam sentido; c) ficar defasados tecnicamente; d)receber responsabilidades, sem autoridade; e) não receber definições claras sobre o queprecisa ser feito; f) sacrificar a qualidade em função do prazo; g) resolver problemascomplexos sem ajuda e, h) não ter tempo suficiente para fazer um bom trabalho [Beck eFowler 2000]. O XP valoriza a criação e automação dos testes, sendo criados antes, durante edepois da codificação. É flexível a mudanças de requisitos, valorizando o feedback como usuário e a qualidade do código fonte final [Astels, Miller e Novak 2002]. A idéia principal do XP é a criação de software de alta qualidade, abandonandotodo tipo de overhead de processo que não suporte diretamente esse objetivo. A XP éorientada explicitamente a pessoas e vai contra o senso comum do gerenciamento deque as pessoas são peças intercambiáveis dentro do processo de desenvolvimento.3.1. Origens do XPOs principais fundamentos de XP tiveram origem na década de 80, nas raízes dodesenvolvimento em Smalltalk [Cunningham 2008]. Nesta época, Kent Beck e WardCunningham trabalhavam na Tektronixs. Os projetos realizados nesta época serviram delaboratório para que fossem aperfeiçoadas práticas como refactoring, programação empares, mudanças rápidas, feedback constante do cliente, desenvolvimento iterativo,testes frequentes. Neste período, também surgiram importantes contribuições, como atese de doutorado de Bill Opdyke [Opdyke 1992], sobre técnicas de refactoring queBeck e Cunningham já usavam na indústria. Em 1996, todas as práticas criadas e experimentadas ao longo de anos realmentese fundiram [Anderson et al 1998]. Foi em um projeto da Daimler Chrysler,denominado Chrysler Comprehensive Compensation (C3). O C3 era o projeto de folhade pagamento da Companhia. Na época, Beck trabalhava como consultor paraproblemas de desempenho em Smalltalk. Neste mesmo ano, Beck publicou um livrocom relevantes contribuições, que apresentava excelentes técnicas de desenvolvimentonesta tecnologia [Beck 1996]. Sue Unger, CIO da Chrysler, entrou em contato com Beckpara fazer uma análise do projeto. Após um período trabalhando com a equipe, Beck apresentou um relatório para adiretora com a descrição dos problemas, desde problemas contratuais até problemas deambiente. As alternativas eram: a) deixar as coisas como estavam; b) cancelar o projetoe, c) dar folga para a equipe e começar do zero. Unger escolheu a última opção ecolocou Beck a frente do time. A primeira medida do Beck perante o time foi dar folgapara o pessoal. Assim, o time pode recuperar o ânimo para começar uma nova etapa. Beck realizou entrevistou os 20 membros do time individualmente, explicandocomo funcionaria o processo de trabalho. Para cada um dos membros, ele explicava umaprática. Nasceu, desta forma, as práticas de XP [Anderson et al 1998].

3.2. PapéisOs papéis de um time XP são formados por uma variedade de pessoas, comcaracterísticas e habilidades necessárias para o sucesso do projeto. Em geral, os papéisnão variam muito em relação ao de outros processos e metodologias. A seguir, sãoapresentados alguns destes papéis [Astels, Miller e Novak 2002]: • Dono do Ouro: É o cliente que paga pelo desenvolvimento do projeto; • Usuário/Cliente: Define os requisitos do software e utiliza o produto final e executam os testes de aceitação; • Gerente: Gerencia e acompanha o planejamento do projeto; • Coach: É o técnico do time. Orienta o time, mantendo a disciplina na aplicação das práticas que são padrões da equipe; • Testadores: Ajudam os clientes com a definição dos testes. Realizam os testes do sistema; • Desenvolvedores: Definem a arquitetura, realizam estimativas e implementa o código; • Tracker: Responsável por coletar as métricas de projeto. O tracker é capaz de contar uma história da iteração ao final da mesma, através dos apontamentos que realizou e das informações que foram coletadas; • Analistas: Ajudam o cliente na definição dos requisitos. Existem variações e diferentes referências sobre os papéis em XP. Estes papéisaté podem ser acumulados por mais de uma pessoa dentro do time, porém deve tomarcertos cuidados [Cunningham 2006].3.3. PráticasO funcionamento do XP é baseado em um conjunto de valores e práticas. As práticas doXP são divididas organizacionais (círculo vermelho), equipe (círculo verde) eindividuais (círculo azul), conforme figura 12. Figura 12. Práticas XP [Jeffries 2000]

As práticas são descritas a seguir:• Equipe (Whole Team): todos em um projeto XP são partes da equipe, integrando os clientes à equipe de desenvolvimento. É importante salientar que um membro da equipe pode assumir mais de um papel. Os papéis foram abordados com mais detalhes na seção 3.1;• Clientes no Local (Client on Site): Para total funcionamento do XP, é necessário que o cliente se integre à equipe de desenvolvimento;• Jogo do Planejamento (Planning Game): São definidas estimativas e prioridades. Ótimo feedback para que cliente possa dirigir o projeto, podendo-se ter uma idéia clara do avanço do projeto minimizando os riscos. Nesta prática é onde são definidas as histórias que descrevem as funcionalidades a serem implementadas;• Testes de Aceitação (Customer Tests): São testes elaborados pelo cliente, sendo os critérios de aceitação do software. Devem ser rodados a cada interação futura. Oferecem feedback do desenvolvimento da aplicação;• Pequenas entregas (Small Releases): Disponibiliza a cada interação o software 100% funcional. Desta forma, é disponibilizado pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível, minimizando os riscos;• Posse Coletiva (Collective Ownership): Em um projeto XP, qualquer dupla de programadores pode melhorar o software a qualquer momento. O código tem um único dono: a equipe. Todos compartilham a responsabilidade pelas alterações;• Integração Contínua (Continuous Integration): XP mantém o projeto integrado continuamente, expondo o estado atual de desenvolvimento (viabiliza lançamentos pequenos e frequentes), oferencendo um feedback sobre todo o sistema, em qualquer etapa do processo;• Metáfora (Metaphor): A equipe mantém uma visão compartilhada do funcionamento do software. Serve de base para estabelecimento dos padrões de codificação e da forma de comunicação com o cliente. Uma metáfora deve funcionar como uma forma de comunicação comum entre equipe e cliente. Em se tratando da metáfora do software, é entender o que precisa ser desenvolvido, entender a visão do produto que está sendo construindo;• Ritmo Saudável (Sustainable Pace): Os projetos XP procuram obter a maior produtividade dos programadores e entregar o software na melhor qualidade possível, obtendo a satisfação do cliente. Para isso há uma grande preocupação com o cronograma. Definir um número de horas de trabalho, que gerem um ritmo sustentável na equipe, exemplo de uma semana de 40 horas, é fundamental para o maior rendimento da equipe;• Padrões de Codificação (Coding Standards): Todo o código escrito segue o padrão definido pela equipe, facilitando a comunicação e refinamento do design;• Testes (Test-Driven Development): Todo o desenvolvimento XP é guiado por testes. Os testes dão segurança necessária para garantir a qualidade de forma contínua, dão coragem para mudar. Os testes são a base do feedback do código

para o programador. Os testes dão ritmo ao desenvolvimento, porque o código a ser desenvolvido é o código para fazer um determinado teste passar; • Programação em Pares (Pair Programming): Todo o desenvolvimento é feito em pares, obtendo uma melhor qualidade do design, código e testes, uma revisão constante do código e uma maior comunicação; • Design Simples (Simple Design): O código está, a qualquer momento, na forma mais simples para a realização dos testes. Esta prática está presente em todas as outras etapas do XP. • Refinamento (Refactoring): O design é melhorado continuamente através do refinamento. Em XP, o código é o próprio design. O refinamento é um processo formal realizado através de etapas reversíveis, melhorando a estrutura do código sem alterar sua função [Fowler 1999]. O refinamento do código deve ser feito sempre após um teste que passa. Isto dá liberdade ao desenvolvedor de modificar o código fonte, pois sabe que os testes devem continuar passando. Se um teste passa a falhar, alguma coisa na lógica da aplicação foi alterada e precisa ser revista; • Reuniões em Pé (Stand Up Meetings): Além das cerimônias de planejamento de release e iterações, XP possuem uma prática que ajuda a expor para o time como está o desenvolvimento das tarefas. Nestas reuniões, é exposto o andamento do trabalho (o que se fez ontem, o que está sendo feito, quais são os problemas), de forma que o time possa avaliar as dificuldades e analisar possíveis soluções. • Spikes de Planejamento (Spikes Solution): Muitas vezes, nos projetos, é necessário fazer investigações e avaliações de tecnologias que serão incorporados no desenvolvimento [Wells 2001a]. Estas investigações são chamadas de spikes. Os spikes forçam que, em um momento apropriado e necessário, seja realizada uma análise de recursos tecnológicos (em geral, ferramentas, frameworks, APIs7) para inclusão nas tecnologias usadas no projeto. Os spikes de planejamento ajudam o time a gerar o conhecimento necessário para que possam estimar novas funcionalidades a serem desenvolvidas no projeto.4. Implementando eXtreme ProgrammingNesta seção, é descrito o uso de práticas XP para definição de planejamento do projeto,releases, iterações. Também é apresentado como funciona o trabalho diário em um timeXP.4.1. Ciclo de TrabalhoO ciclo de trabalho em XP é dividido em fases, conforme mostrado na figura 13.7 Application Programming Interface

Figura 13. Ciclo de vida de um Projeto XP [Wells 2001a] Na fase de exploração, são definidos as user stories iniciais e o rascunho daarquitetura. Do ponto de vista de requisitos, é interessante detalhá-los de forma que setenha uma visão suficiente para começar o projeto, com uma definição básica para asestimativas [Beck 2004]. À medida que se avança em etapas posteriores deplanejamento, as user stories são priorizadas e mais detalhadas. Outro ponto tratadonesta fase é o spike de arquitetura. A arquitetura é tratada em XP como algo primordial eque evolui naturalmente com as iterações. Para que esta evolução seja tranqüila, éimportante o conhecimento e uso de patterns. Em [Ambler 2004a], o assunto demodelagem de arquitetura é explorado com mais detalhes, como propósitos, diagramaspara modelagem, ferramentas e estatísticas de adoção desta abordagem. O principalobjetivo desta fase é a redução de riscos, tanto de planejamento, quanto dedesenvolvimento. Na fase de planejamento, os requisitos são detalhados para compor o plano derelease. Este trabalho é realizado durante a reunião de planejamento de release. Nesteplano, são definidos com maiores detalhes os requisitos do software. Os requisitostécnicos também são explorados, de forma que, caso se tenha alguma dúvida deimplementação, é possível fazer uso de spikes [Wells 2001a]. O principal objetivo destafase é definir o plano do produto de software e a definição das entregas, ocorrendo omais cedo possível [Beck e Fowler 2000]. Esta é a base para o planejamento dasiterações. Na figura 14, é apresentada uma lista de requisitos (potenciais user stories),onde são analisados diferentes aspectos como prioridade, volatilidade técnica e derequisitos, acesso e dependências. Ela servirá de base para a elaboração dos planos deiterações. Figura 14. Exemplo de uma lista de requisitos, com atributos classificatórios A fase de iterações é onde o trabalho será realmente realizado. O tamanho dasiterações são diferentes de time para time, podendo variar de 1 a 3 semanas [Wells2001a]. Nesta fase, o plano de release serve de base para o trabalho e as user storiesplanejadas para a iteração atual são exploradas e detalhadas [Beck e Fowler 2000]. Casonão seja a primeira iteração, além do plano de release, informações como problemas

reportados e project velocity8 da iteração anterior também são considerados para oplanejamento atual. Com base neste plano de iteração, é que o time realiza o trabalhodiário de construção. A cada dia, é realizado o stand up meeting para que o trabalhorealizado seja exposto para o time. O tracker coleta métricas diárias e as expõe para otime. No final da iteração, o time realiza uma avaliação da iteração, promovendo amelhoria para a iteração posterior. O principal objetivo desta fase é a construção dosoftware, baseado em um planejamento incremental. Uma versão do produto édisponibilizada. A figura 15 apresenta o fluxo de uma iteração em XP. Figura 15. Ciclo de Iteração XP [Wells 2001a] A fase de produção é caracterizada pela realização dos testes de aceitação e olançamento do produto para produção. Esta é a principal característica desta fase, opequeno incremento do produto, com objetivo de colocá-lo mais cedo possível emprodução [Beck 2004]. Assim, o cliente terá a real noção da evolução do produto epoderá dar também um feedback mais fidedigno sobre o trabalho realizado. Nas metodologias ágeis e, em especial o XP, as fases de planejamento derelease, iterações e produção estão inseridas em uma fase maior, a fase de manutenção[Beck 2004]. O [SWEBoK 2004] aborda diferentes categorias de manutenção, deorigem reativa (correção) e pró-ativa (aprimoramento). Essa abordagem de não separar odesenvolvimento da manutenção e entender que o software evolui continuamente é umacaracterística de XP. Esta evolução é tratada de forma natural, através das práticas empromover pequenos planejamentos (release, iterações), implementando poucasfuncionalidades e entregando software mais rapidamente. Com isso, o cliente conseguedar um feedback mais rápido, pois são menos funcionalidades a testar e validar. Como ofeedback é mais rápido, se consegue rever o planejamento do trabalho a ponto derealizar mudanças, se necessário.4.2. Planejamento de ProjetoEm XP, o planejamento de projeto é encarado como um jogo, onde o adversário éentregar software de qualidade, dentro do prazo e custo estimados [Beck 2004]. Ocliente é parte primordial do planejamento, participando da priorização dos requisitos,detalhando-os junto com os analistas em formato de user stories e tarefas. O principalfoco do planejamento é a priorização, baseados em risco e maior valor para o negócio. Na figura 16, é apresentada esta relação de risco e valor.8 Project Velocity é uma métrica utilizada para representar o esforço de trabalho realizado na iteração(planejado X construído). Está métrica é usada para planejar futuras iterações.

Figura 16. Priorização com base em risco e valor (adaptado de [Cohn 2005]) Existem requisitos que são de alto risco de implementação e baixo valor denegócio9. Estes devem ser evitados. O time se concentra no que realmente é importante(maior valor) e maior risco para o negócio e de implementação. Assim, o problema étratado sempre com maior prioridade [Wake 2000]. A principal intenção é, além deagregar mais valor rapidamente para o software, evitar desperdícios. Na figura 17, éapresentada a ordem de implementação dos requisitos. Com base nestas premissas, aimplementação dos requisitos de maior prioridade são essenciais para agregar valor aoproduto. Este exercício de repriorização é realizado no inicio de cada iteração. Para apriorização, usa-se o feedback da iteração anterior juntamente com o planejamentodefinido para a iteração atual. Figura 17. Ordem de implementação dos requisitos (adaptado de [Cohn 2005]) Na figura 18, apresenta-se a forma de priorização, onde sempre tem-se osrequisitos mais importantes para negócio no topo da pilha. Este é um exercício comumdo time com o cliente, avaliando a importância do será implementado.9 Algo que não agrega valor, que não foi planejado e que foi implementado é chamado de Gold Plating.Mais informações podem ser obtidas em [Wiegers 2003]

Figura 18. Troca de prioridade dos itens planejados [Ambler 2007]4.3. Escrevendo User StoriesOs requisitos são registrados no formato de user stories. As user stories tem o mesmopropósito dos casos de uso, porém escritos de forma mais curta e enxuta, levando emconsideração a perspectiva do usuário [Cohn 2004]. Segundo [Jeffries 2001], as userstories devem ser escritas, com base nas propriedades 3Cs (Card, Conversation eConfirmation). No quadro 2, é apresentado as propriedades 3Cs. Quadro 2. Propriedades de uma User Story [Jeffries 2001] Propriedade Significado Card As user stories são registradas em cartões. Existe um fator psicológico em relação ao tamanho do é passado para o usuário registrar a user story. Se o tamanho do cartão for pequeno, o usuário tem que se concentrar no que realmente é importante na user story. Conversation Assim como os casos de uso, as user stories são escritas em formato de narrativa, sob a perspectiva da persona, levando em consideração a descrição da funcionalidade e o propósito/benefício. Confirmation Para as user stories, é necessário definir os critérios de aceitação. Estes critérios servirão de base para a descrição dos testes de aceitação. Nas user stories, são registradas funcionalidades de valor para o cliente, podendoser escritas informalmente ou mais estruturadas seguindo um template. Segundo [Wake2003], uma boa prática para o time na escrita de user stories é levar em consideraçãodas características desejáveis INVEST. No quadro 3, é apresentado especificamentecada uma das características desejáveis.

Quadro 3. Características desejáveis para User Story [Wake 2003] Característica Significado Independent Deve ser independente, para facilitar negociação, priorização e implementação Negotiable Deve ser negociável, para facilitar a priorização. Deve capturar a essência e não os detalhes Valueable Deve agregar valor Estimable Uma boa user story é que pode se definir uma estimativa. Não precisa ser exata, mas boa o bastante para se levar em conta no planejamento Small Deve ser pequena. User stories pequenas facilitam a implementação e o processo de estimativas Testable Deve permitir a realização de testes. Se não foi possível definir um teste para esta user story, deve-se rever seu propósito e escrita Na figura 19, são apresentadas dois exemplos de user stories escritas sem o usodo template. Figura 19. Exemplos de User Stories [Cohn 2004] No quadro 4, é apresentado um exemplo de template onde é identificado oscomponentes de uma user story. A persona representa um tipo de usuário que interagecom o sistema [Cooper 2003]. A principal diferença entre atores e personas é que aspersonas são instâncias de um tipo de usuário/papel (ator), tentando analisar seucontexto no mundo real. Para as personas, são definidas as funcionalidades e seupropósito. Quadro 4. Template de User Story [Cohn 2004] As (Como) <persona> I can (Posso) <funcionalidade> So that (Pois assim) <benefício> Dentro destes elementos das user stories, é possível reconhecer questões chavescomo: “Quem é afetado pelo requisito? O que deve ser implementado? Por quê?” Estesquestionamentos estão atrelados aos critérios de aceitação, algo fundamental na escritada user story. Quando um requisito é definido, os critérios de aceitação devem estarpresentes. É uma forma de comprovação da user story.

No quadro 5, é apresentado um exemplo prático da escrita de user story,incluindo os testes de aceitação, baseadas no Behavior Driven Development (BDD)10. Quadro 5. Exemplo de User Story com BDD Sendo uma pessoa que precisa de crédito Posso acessar o simulador de crédito ACME Pois assim saberei das opções que tenho para requisitar. Dado que sou um usuário do site de simulação de crédito Quando peço uma simulação de crédito abaixo de R$500 Então o máximo de parcelas que poderei parcelar serão de 5 Dado que sou um estagiário Quando peço R$500 e tenho renda de R$800 e indico parcelamento em 4 vezes Então o Sistema vai negar o empréstimo indicando que tenho acesso apenas a 60% da minha renda, ou seja, R$4804.4. Dia a dia em um time XPO trabalho diário de um time XP é baseado no plano de iteração [Wells 2001a]. Todo odia é realizado o stand up meeting, com o objetivo de expor o trabalho individual para otime, suas dificuldades e como estão sendo resolvidos os problemas. Nestas atividades,estão previstas atividades de programação em pares e integração contínua por parte dotime. Esta última dita a junção dos componentes de software produzidos pelos pares,sendo realizada várias vezes ao dia. Na figura 20, é apresentado o ciclo dedesenvolvimento diário em XP. Figura 20. Ciclo de Desenvolvimento diário [Wells 2001a] Em [Wake 2000], é apresentado uma visão alternativa do trabalho diário. Nestaoutra visão, o design inicial é algo explorado, que servirá de base para a implementação.Todo o trabalho é realizado em pares, desde análise, projeto, codificação e testes. Dentrodeste contexto, o uso de práticas de modelagem ágil [Ambler 2004b] se tornaprimordial. A figura 21 descreve as atividades diárias de um desenvolvedor XP.10 Mais informações sobre BDD em http://blog.dannorth.net/introducing-bdd/

Figura 21. Atividades diárias de um desenvolvedor XP [Wake 2000] No trabalho diário vale destacar que a prática de programação em pares pode serutilizada no formato de sessões. Desta forma, user stories mais complexas e que exijammais revisões pode ser candidatas para a prática em sessão. Mais importante que adotara prática de programação em pares é promover a rotação entre estes pares11. Além dedisseminar o conhecimento do projeto para o time, mantém a simplicidade nasatividades, maximizando o valor entregue no software.5. Ferramentas de ApoioPara apoiar a adoção dos princípios, valores e práticas do XP, existem uma série deferramentas que podem ser utilizadas nos projetos de software. Nesta seção, apresenta-se duas categorias: hard tools, que são as ferramentas mais simples, relacionadas com oambiente e as soft tools, que são as ferramentas de software que apóiam as práticas.Além das ferramentas, as métricas são outro recurso muito utilizado para acompanhar odesenvolvimento do trabalho em XP.5.1. Ambiente e Hard ToolsO ambiente é essencial para apoiar as práticas, tanto de gerenciamento quando deconstrução. Para isso, é necessário adequá-lo para as necessidades de um time ágil. Paraadequá-lo, pode-se utilizar uma série de gráficos de acompanhamento, murais e quadrostornando o ambiente informativo12 [Shore e Warden 2008]. A figura 22 apresenta umlayout de sala para um time ágil.11 Prática que não está presente no círculo de práticas de XP, mas que tem enorme valor. Tambémconhecida como Move People Around. Mais informações em [Wells 2001b]12 Existem dois termos utilizados para representar o ambiente informativo em times ágeis: Big VisibleCharts (Ron Jeffries) e Information Radiator (Alistair Cockburn).

Figura 22. Ambiente de trabalho para um time XP [Shore e Warden 2008] Este ambiente é propício para postar informações de andamento do projeto,fazendo com o que o time visualize estes resultados de forma mais simples e rápida. Oambiente fornece mecanismos para que a comunicação, um dos valores do XP, estejasempre presente. Os quadros e murais expostos para time são melhores que sites na Web ouplanilhas eletrônicas dentro das estações de trabalho [Jeffries 2004a]. Nestasferramentas, a informação não está exposta para o time, os membros do time têm quebuscá-las. Com quadros e murais, estão sempre disponíveis para o time, sempre visíveis.Segundo [Jeffries 2004a], é interessante usar planilhas e wikis como forma de registro,porém é necessário criar mecanismos para que a informação fique sempre disponívelpara o time. Por exemplo, um dos gráficos utilizados, é a quantidade de testes deaceitação existentes, para cada período de tempo (dia, semana, iteração), apresentadosna figura 23. É possível ver a evolução e verificar se algo não está indo não está bem [Jeffries2004a]. Utilizando gráficos como ferramentas de acompanhamento, é possívelidentificar certos padrões. Estes padrões podem indicar informações relevantes para otime, entre elas como descobrir sua própria velocidade de produção. Outros gráficosmuito usados por times ágeis são os gráficos de burndown e burnup [Cockburn 2005]. Oprimeiro (burndown chart) é relacionado com a queima de horas da iteração, onde emcada período de trabalho marca-se quanto já foi realizado. Assim, é possível projetar aspróximas iterações com base no trabalho feito, fazendo-se uma projeção se será possívelentregar no prazo. O segundo, é relacionado com a implementação das tarefas e emrelação ao que foi planejado. Também é possível analisar neste gráfico o valor agregadopara o produto (figura 24).

Figura 23. Gráficos do uso de testes de aceitação (o da esquerda, evoluindo naturalmente e o da direita com testes que não estão passando) [Jeffries 2004a] Figura 24. Gráficos de Burndown e Burnup [Silver 2008] Além dos gráficos, um time ágil utiliza quadros para execução eacompanhamento do trabalho do time. Nestes quadros, é possível verificar o trabalhoque está planejado, os que estão em andamento e os que já estão prontos. Estes quadrossão também conhecidos como quadros de Kanban13 [Kniberg e Skarin 2009]. Existemvariações de quadros, que podem estar relacionados ao time ou natureza do projeto.Estas variações é que vão indicar os tipos de quadros que serão utilizados e que seçõesserão criadas. O quadro pode conter seções para exposição de marcos de entrega dereleases, mural de recados, mural de lembretes, classificação de requisitos, exposição degráficos de acompanhamento, métricas sobre o andamento do trabalho, entre outros. O objetivo do ambiente visual é que não é somente o time que visualiza oquadro, mas o quadro também faz esta tarefa para o time. Por exemplo, um quadro ondese tem as seguintes seções: tarefas planejadas, em execução e testes. No momento quetarefas são colocadas em planejamento e, esta seção ficar lotada, é hora de começar aexecução. Da mesma forma que, quando a execução já está lotada, é necessário passartarefas para a seção de testes. Este tipo de fluxo é chamado de Just in Time14. Casoaconteça algum problema na execução das tarefas, é possível sinalizar com o quadro13 Termo japonês utilizado que significa semáforo. Os kanbans surgiram na Toyota, na década de 50[Ohno 1998].14 Fluxo puxado.

para o time. Outra questão interessante na adoção destes quadros é que, só será possívelplanejar novas tarefas para desenvolvimento, somente quando liberar espaço nas seções. Pode-se ampliar as seções destes quadros para registrar potenciais melhorias,identificar problemas e, na retrospectiva da iteração, discutir as soluções com o time. Figura 24. Exemplo de quadro de acompanhamento5.2. Soft ToolsExistem inúmeros softwares utilizados para apoiar as práticas do XP. No quadro 6, éapresentado uma lista de ferramentas para as tecnologias Java, PHP e .NET15, práticasque são apoiadas, a licença disponível e endereço web do fornecedor. Quadro 6. Lista de ferramentas por tecnologia Práticas/ Ferramenta Suporte a Licença URL Tecnologia IntençõesPlanejamento XPlanner Java LGPL http://www.xplanner.org/de Releases eIterações ExtremePlanner Java Comercial http://www.extremeplanner.com/ AgileTrack Java Comercial http://agiletrack.net/ RallyDev Não Free e http://www.rallydev.com/ informado Comercial XPWeb PHP GPL http://xpweb.sourceforge.net/Testes de FIT Várias GPL http://fit.c2.com/Aceitação,Integrados FITNesse Várias L http://fitnesse.org/ Selenium Várias GPL http://seleniumhq.org15 A escolha das tecnologias foi baseada em sua adoção na indústria de software para aplicaçõescomerciais. Mais informações sobre linguagens de programação emhttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Práticas/ Ferramenta Suporte a Licença URL Tecnologia IntençõesTestes JUnit Java GPL http://www.junit.orgUnitários,Cobertura NUnit .NET (C#) GPL http;//www.nunit.org CsUnit .NET (C#) GPL http://www.csunit.org/tutorials/tutorial7/ Cobertura Java GPL http://cobertura.sourceforge.net/ Emma Java GPL http://emma.sourceforge.net/ NCover .NET Comercial http://www.ncover.com/ PHPUnit PHP GPL http://www.phpunit.de/Integração Apache ANT Java Apache http://ant.apache.org/Contínua CruiseControl Várias BSD http://cruisecontrol.sourceforge.net/ Hudson Java GPL https://hudson.dev.java.net/ Apache Maven Java Apache http://maven.apache.org/ PHPUnderControl PHP GPL http://www.phpundercontrol.org/ Phing PHP GPL http://phing.info/Padrões de NDepend .NET Comercial http://www.ndepend.com/Codificação,Auditoria, NDoc .NET GPL http://ndoc.sourceforge.net/Controle de PMD/CPD Java GPL http://pmd.sourceforge.net/Versões,IDEs Javadoc Java Gratuito http://java.sun.com/j2se/javadoc/ PHPCodeSniffer PHP GPL http://pear.php.net/package/PHP_CodeSniffer/redirected PHPDoc PHP GPL http://www.phpdoc.org/ CheckStyle Java GPL http://checkstyle.sourceforge.net/ Eclipse Várias Eclipse http://www.eclipse.org NetBeans Várias GPL http://www.netbeans.org Visual Studio .NET Comercial http://www.microsoft.com/exPress/ e Gratuito5.4. MétricasPara controlar o andamento do trabalho, as equipes de desenvolvimento definemmétricas. Nas metodologias ágeis, as métricas não são diferentes. Segundo [Hartmann eDymond 2006], uma boa métrica ágil deve: • Reforçar princípios ágeis: entregar valor e colaborar com o cliente são princípios fundamentais das metodologias ágeis; • Seguir tendências e não números: a tendência é mais importante que os valores representados pela métrica; • Medir resultados e não saídas: medir os resultados obtidos é mais importante que medir saídas de atividades de processos; • Foco no necessário: é impossível medir tudo. Muita informação pode esconder o que realmente é importante;

• Ser facilmente coletada: as métricas devem ser facilmente identificadas e coletadas, para facilitar o trabalho do tracker; • Revelar contextos e variáveis: métricas devem expor influências e contextos, facilitando a melhoria; • Apoiar os valores ágeis: as métricas devem apoiar a comunicação e feedback, promovendo o aprendizado e a melhoria contínua. Existem inúmeras métricas, como as aplicadas a código, planejamento,automação e valor de negócio [Mittal 2008]. As métricas mais utilizadas em XP sãoRunning Tested Features (RTF), Project Velocity e Load Factor [Jeffries 2004b; Beck2004; Cunningham 2007; Cunningham 2009]. A métrica Running Tested Features (RTF) é referente à taxa de valor de negócioentregue por funcionalidade testada e implantada. Desta forma, o cliente define quandouma funcionalidade está pronta, através de testes de aceitação [Jeffries 2004b]. A métrica Project Velocity está relacionada a quanto de software o timeconsegue entregar por iteração, em relação às atividades planejadas [Cunningham2007]. A base para medição são as story points ou dias ideais de desenvolvimento. Estamétrica é extremamente importante para o time, pois é através dela que se conseguefazer um nivelamento de produção e encontrar o takt time16. Aí está a importância de teruma iteração time-boxed17. Esta métrica pode ser afetada por inúmeros fatores, comoimpedimentos, mudanças no time, conhecimento do negócio e tecnologia. A métrica Load Factor está relacionada com o trabalho individual do time,levando em consideração o que foi planejado e o que foi efetivamente realizado em umdia de trabalho ideal [Cunningham 2009]. Este fator é utilizado, juntamente com oProject Velocity para o planejamento das iterações. Além destas métricas, éextremamente importante o time levar em conta seu histórico de desenvolvimento.6. Adotando e Escalando XPO XP é uma disciplina ágil, que requer total integração da equipe. Por isso, os valoresde comunicação, simplicidade, coragem e feedback são sempre levados em consideraçãoantes da aplicação da disciplina. Como o XP é voltado para testes, é muito importante aprojeção dos testes antes da codificação. Isto permite o refactoring sem qualquer temor,dando mais segurança ao time. Entretanto, é mais complexo aplicar XP em projetos onde a comunicação é umabarreira. Outra situação onde se torna complicado aplicar o XP é quando não se temcontrole sobre o código e quando o feedback é demorado, sem uma comunicaçãoeficiente [Astels, Miller e Novak 2002]. Outras questões que dificultam o uso de XP são barreiras culturais, comoalteração de código de terceiros e relevância de hábitos antigos, procurando manter ascoisas simples. O XP também não pode ser aplicado quando o cliente quer umaespecificação detalhada do sistema antes de começar o desenvolvimento.16 Termo utilizado no Lean para representar o compasso de trabalho do time17 Períodos de tempo distintos e fixos, sem variações.

O XP tem obtido um crescimento contínuo como disciplina de desenvolvimentodentro da indústria do software, sendo discutida pelos principais engenheiros desoftware do mercado. Existem vários trabalhos relacionando XP com processosincrementais e iterativos, como [Martin 2002; Smith 2003], abordando característicasem termos de tempo e alocação de recursos, artefatos, disciplinas e atividades. As práticas do XP podem ser abordadas dentro de diferentes ciclos dedesenvolvimento e metodologias. Ao trabalhar com modelos de maturidade como SW-CMM/CMMI, as práticas de metodologias ágeis podem ajudar nos processosrelacionados à engenharia, nos processos de qualidade do produto, métricas, e melhoriacontínua [Paulk 2001; Sutherland, Jakobsen e Johnson 2007; Glazer 2008]. Asmetodologias ágeis também são relacionadas a sistemas de gestão da qualidade comoISO 9001, pois os princípios de qualidade da ISO são muito próximos dos princípioságeis, como foco no cliente, liderança, envolvimento das pessoas, melhoria contínua e otrabalho de melhoria dos fornecedores [ISO 2010].ReferênciasAmbler, Scott (2004a) “Architecture Envisioning: An Agile Best Practice”, http://www.agilemodeling.com/essays/initialArchitectureModeling.htm, Última Visita: Abril de 2010.Ambler, Scott (2004b) “Modelagem Ágil: Práticas Eficazes para Programação Extrema e o Processo Unificado”, Bookman.Ambler, Scott (2005) “Communication on Agile Software Projects”, http://www.agilemodeling.com/essays/communication.htm, Última Visita: Abril de 2010.Ambler, Scott (2007) “Introduction to User Stories”, http://www.agilemodeling.com/artifacts/userStory.htm, Última Visita: Abril de 2010.Anderson, Ann et al (1998) “Chrysler goes to Extremes”, Computing Distributed, October.Astels, David; Miller, Granville e Novak, Miroslav (2002) “Extreme Programming: Guia Prático”, Campus.Balzer, Robert (1981) “Transformational Implementation: an example”, In: IEEE Transactions of Software Engineering, volume 7.Beck, Kent (1996) “Smalltalk Best Practices Paterns”, Prentice Hall.Beck, Kent e Fowler, Martin (2000) “Planning Extreme Programming”, Addison- Wesley.Beck, Kent et al (2001) “Agile Manifesto”, http://www.agilemanifesto.org, Última Visita: Abril de 2010.Beck, Kent (2004) “Programação eXtrema Explicada”, Bookman.Boehm, Barry (1986) “A Spiral Model of Software Development and Enhancement”, ACM SIGSOFT Software Engineering Notes, volume 11.

Boehm, Barry e Turner, Richard (2003) “Balancing Agility and Discipline: a guide for the perplexed”, Addison-Wesley.Brooks, Frederic (1987) “No Silver Bullet: Essence and Accidents of Software Enginnering”, IEEE Computer, volume 20.Coad, Peter; Luca, Jeff e Lefebvre (1999) “Java Modeling Color with UML: Enterprise Components and Process with CDRom”, Prentice Hall.Cockburn, Alistair (2002) “Agile Software Development”, Addison-Wesley.Cockburn, Alistair (2004) “Crystal Clear: A human-powered methodology for small teams”, Addison-Wesley.Cockburn, Alistair (2005) “Earned-values and Burn Charts”, http://alistair.cockburn.us/Earned-value+and+burn+charts, Última Visita: Abril de 2010.Cohn, Mike (2004) “User Stories Applied”, Addison-Wesley.Cohn, Mike (2005) “Agile Estimating and Planning”, Prentice Hall.Cooper, Alan (2003) “Cooper Journal: The Origin of Personas”, http://www.cooper.com/journal/2003/08/the_origin_of_personas.html, Última Visita: Abril de 2010.Cunningham, Ward (2002) “Extreme Programming”, http://www.c2.com/cgi/wiki? ExtremeProgramming, Última Visita: Abril de 2010.Cunningham, Ward (2006) “Extreme Roles”, http://www.c2.com/cgi/wiki? ExtremeRoles, Última Visita: Abril de 2010.Cunningham, Ward (2007) “Project Velocity”, http://c2.com/cgi/wiki?ProjectVelocity, Última Visita: Abril de 2010.Cunningham, Ward (2008) “History of Extreme Programming”, http://www.c2.com/cgi/wiki? HistoryOfExtremeProgramming, Última Visita: Abril de 2010.Cunningham, Ward (2009) “Load Factor”, http://c2.com/cgi/wiki?LoadFactor, Última Visita: Abril de 2010.Fowler, Martin (1999) “Refactoring: Improving the Design of Existing Code”, Addison- Wesley.Ghezzi, Carlo; Jazayeri, Mehdi e Mandrioli, Dino (1991) “Fundamentals of Software Enginnering”, Prentice Hall.Gilb, Tom (1981) “Evolutionary Development”, ACM SIGSOFT Software Engineering Notes, volume 6.Glazer, Hillel et al (2008) “CMMI or Agile: Why not embrace both!”, Technical Note, SEI/CMU.Hartmann, Deborah e Dymond, Robin (2006) “Appropriate Agile Measurements: Using metrics and diagnostics to deliver business value”, In: Agile 2006 Conference.

Highsmith, Jim (1997) “Messy, exciting, and anxiety-ridden: Adaptive software development”, In: American Programmer, volume 10.Highsmith, Jim (2000) “Retiring lifecycle dinosaurs: Using adaptive software development to meet the challenges of a high-speed, high-change environment”, In: Software Testing & Quality Engineering, July/August.Highsmith, Jim e Cockburn, Alistair (2001) “Agile Software Development: The business of innovation”, Prepared by the IEEE Computer Society/ACM Joint Task Force.Hunt, John (2006) “Agile Software Construction”, Springer-Verlag London.ISO (2010) “ISO Quality Management Principles”, http://www.iso.org/iso/qmp, Última Visita: Abril de 2010.Jacobson, Ivar; Rumbaugh, James e Booch, Grady (1999) “The Unified Software Development Process”, Addison-Wesley.Jeffries, Ron (2000) “Extreme Programming”, http://www.xprogramming.com, Última Visita: Abril de 2010.Jeffries, Ron (2001) “Essencial XP: Card, Conversation and Confirmation”, XP Magazine.Jeffries, Ron (2004a) “Big Visible Charts”, http://xprogramming.com/xpmag/BigVisibleCharts, Última Visita: Abril de 2010.Jeffries, Ron (2004b) “A Metric leading Agility”, http://xprogramming.com/xpmag/jatRtsMetric, Última Visita: Abril de 2010.Kniberg, Henrik e Skarin, Mattias (2009) “Kanban and Scrum: making the most of both”, C4 Media Inc., Published by InfoQ.Liker, Jeffrey (2004) “The Toyota Way: 14 Management Principles from the World´s Greatest Manufacturer”, McGraw-Hill.Martin, James (1991) “Rapid Application Development”, Macmillan Publishing Co.Martin, Robert (2002) “RUP vs XP”, http://www.objectmentor.com/resources/articles/RUPvsXP.pdf, Última Visita: Abril de 2010.McConnell, Steve (1998) “Software Project Survival Guide”, Microsoft Press.Mittal, Deepak (2008) “Metrics for Agile Projects”, In: Agile NCR 2008 Conference.Naur, Peter e Randell, Brian (1968) “Software Engineering: report of a conference sponsored by the NATO Science Committee”, Scientific Affairs Division.Ohno, Taiichi (1998) “Toyota Production System: Beyond Large-Scale Production”, Productivity Press.Opdyke, William (1992) “Refactoring Object-Oriented Frameworks”, PhD Thesis, University of Illinois.Ortigosa, Alvaro (1995) “Proposta de um Ambiente Adaptavel de Apoio ao Processo de Desenvolvimento de Software”, Dissertacao de Mestrado, UFRGS.

Palmer, Stephen e Felsing, John (2002) “A practical Guide to Feature Driven Development”, Prentice Hall.Paulk, Mark (2001) “Extreme Programming from a CMM Perspective”, In: IEEE Software, volume 18.Pressman, Roger (1995) “Engenharia de Software”, Makron Books.Poppendieck, Mary e Poppendieck, Tom (2003) “Lean Software Development: An agile toolkit”, Addison-Wesley.Poppendieck, Mary e Poppendieck, Tom (2005) “Implementing Lean Software Development: from concept to cash”, Addison-Wesley.Royce, Winston (1970) “Managing the development of large software systems”, In: Proceedings of IEEE WESCON.Schwaber, Ken e Beedle, Mike (2001) “Agile Software Development with Scrum”, Prentice Hall.Schwaber, Ken (2004) “Agile Project Management with Scrum”, Microsoft Press.Shalloway, Alan e Trott, James (2009) “Lean-Agile Pocket Guide for Scrum Teams”, Net Objectives Press.Shore, Jim e Warden, James (2008) “The Art of Agile Development”, O’Reilly.Silver, Nik (2008) “Burndown and Burnup Charts”, http://niksilver.com/2008/01/19/burn-up-and-burn-down-charts/, Última Visita: Abril de 2010.Smith, John (2003) “A Comparison of the IBM Rational Unified Process and eXtreme Programming”, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP167.pdf, Última Visita: Abril de 2010.Smith, Greg e Sidky, Ahmed (2009) “Becoming Agile: in an imperfect world”, Manning Publications Co.Standish Group (2009) “The Chaos Report”, Technical Report.Stapleton, Jennifer (1997) “DSDM: A framework for business centered development”, Addison-Wesley.Sutherland, Jeff; Jakobsen, Carsten e Johnson, Kent (2007) “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, In: Agile 2007 Conference.SWEBoK (2004) “Guide to the Software Engineering Body of Knowledge”, IEEE Computer Society.Wake, William (2000) “Extreme Programming Explored”, Addison-Wesley.Wake, William (2003) “INVEST in Stories / SMART Tasks”, http://xp123.com/xplor/xp0308/, Última Visita: Abril de 2010.Wells, Donovan (2001a) “Extreme Programming: A Gentle Introdution”, http://www.extremeprogramming.org/. Última Visita: Abril de 2010.

Wells, Donovan (2001b) “Move People Around”, http://www.extremeprogramming.org/rules/movepeople.html. Última Visita: Abril de 2010.Wiegers, Karl (2003) “Software Requirements”, Microsoft Press, 2º. Edição.

Conhecendo o eXtreme Programming

by Daniel Wildt on Oct 06, 2011

Accessibility

Upload Details

Usage Rights

Statistics

Conhecendo o eXtreme Programming Document Transcript