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ção

No final da década de 60, duas conferências organizadas pelo Comitê de Ciências da OTAN1 foram responsáveis por um marco na história da computação: o nascimento do termo “Engenharia de Software”. Um dos objetivos destas conferências era discutir os problemas da indústria de software. O termo engenharia de software foi escolhido para evidenciar a preocupação com a produção de software e a necessidade de basear a produção em fundamentos teóricos e práticas conhecidas dos diversos ramos da engenharia [Naur e Randell 1968].

A engenharia de software tem como objetivo viabilizar maior produtividade na construção de aplicações e qualidade dos artefatos de software [Ghezzi, Jazayeri e Madrioli 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ção de 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 como premissa a grande ênfase em planejamento, assumindo que os requisitos não sofreriam mudanças ao longo do projeto. Era baseado em ciclos seqüenciais onde cada etapa dependia 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 da modificação em relação ao tempo de projeto [Beck 2004]. À medida que se avança nas etapas de desenvolvimento e, caso sejam solicitadas mudanças, deve-se voltar para etapas anteriores de planejamento para ajustar as atividades, tornando-a caras para incluí-las e adaptá-las.

1 OTAN: Organização do Tratado do Atlântico Norte

Figura 1. Custos da modificação em relação às etapa s do ciclo de vida [Beck 2004]

Outras abordagens também surgiram, dando ênfase em aspectos diversos da construçã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 e esforços para definir processos, métodos, técnicas e ferramentas para desenvolvimento de 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ão presentes. No último Chaos Report2 [Standish Group 2009], somente 32% dos projetos de software são considerados como entregues com sucesso, 24% falharam integralmente e 44% não tiveram seus objetivos plenamente satisfeitos.

Estes dados comprovam que a atividade desenvolver software é complexa e que envolve 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 e comunicação do time e com clientes.

A ênfase em planejamento pleno do projeto, logo de início, tentando prever tudo que 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 maior problema é que não se sabe exatamente o que será desenvolvido. À medida que se aproxima da construção do software, a realidade do trabalho emerge, ficando mais claro para se definir as estimativas [McConnell 1998]. A figura 2, denominada cone da incerteza, apresenta esta relação, desde o planejamento até a conclusão do software. O cone da incerteza mostra que a fase de viabilidade (visão do produto) e estimativas iniciais pode variar de 25% a 400%. Isto representa que, caso o projeto tenha uma previsão de 10 semanas de trabalho, esta estimativa pode variar de 2,5 semanas a 40 semanas.

2 Relatório publicado periodicamente pelo Standish Group International, sobre pesquisas relacionadas a sucessos e fracassos de projetos de software.

Figura 2. Cone da Incerteza [McConnell 1998]

Nas abordagens mais tradicionais, como Waterfall (figura 3, a), as etapas de desenvolvimento podem variar de meses chegando a anos, quando o software é entregue ao cliente, em função de postergar ao máximo o desenvolvimento, dando ênfase maior no 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 as entregas ocorrerão de forma incremental. O cliente tem condições de fornecer feedback mais freqüente. Com isso, o custo da mudança durante a construção é reduzido em relaçã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 Pr ocessos Incrementais e Iterativos [Beck 2004]

Em XP, principal assunto abordado neste trabalho, o objetivo é dividir as iterações em menor escala, onde o planejamento é constantemente revisto e repriorizado com 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 uma visão geral sobre as metodologias ágeis, seus valores, princípios e exemplos destas abordagens; 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 foco em planejamento de releases, iterações e trabalho diário; Na seção 5, são apresentadas algumas 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 de metodologias ágeis.

2. Metodologias Ágeis

Na década de 90, alguns profissionais da indústria de software propuseram novos processos e metodologias para desenvolvimento de software, adequados para lidar com aspectos 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 discutir alternativas aos processos e práticas burocráticas utilizadas nas abordagens tradicionais de 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. No quadro 1, é apresentado um trecho do manifesto ágil, que define os seus principais valores.

A principal diferença das metodologias ágeis em relação às metodologias tradicionais é o enfoque na adaptação, visando ter o mínimo necessário5 para a realizaçã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 ajudam na 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 uma mudança de atitude [Smith e Sidky 2009]. O cliente consegue enxergar valor mais rapidamente 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 cada vez 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 deste produto. Uma das práticas presentes neste fluxo é o constante aprendizado e a troca de conhecimento 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 apresentados exemplos destas abordagens.

2.1. Lean Software Development

O Sistema Toyota de Produção (STP) revolucionou a indústria da manufatura, desde geraçã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 identificar semelhanças entre estes princípios e valores com o desenvolvimento de software. Com base nestes pensamentos, foram identificados sete princípios para o desenvolvimento de software. Estes princípios são: 1) eliminar desperdícios; 2) incluir qualidade no processo; 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. Scrum

O Scrum surgiu na década de 90, criado por Ken Schwaber, Jeff Shuterland e Mike Beedle [Schwaber 2004; Schwaber e Beedle 2001]. Seu principal objetivo é prover um framework para gerenciamento de projetos, onde, a partir de um backlog inicial, prioriza-se o trabalho que será realizado na iteração (denominado sprint), gerando um potencial produto no final de cada ciclo. Este trabalho é desenvolvido com acompanhamento diários (daily scrum meetings) e de final de sprint (sprint retrospective), com o objetivo de reduzir riscos e promover a melhoria contínua. Por mais dar ênfase no gerenciamento de atividades e tarefas, o Scrum pode ser utilizado em conjunto com outros métodos e processos, que dão ênfase na engenharia, como XP. Na figura 7, é apresentado o fluxo do Scrum.

Figura 7. Fluxo do Scrum [Hunt 2006]

2.3. Familia Crystal

A família Crystal é um conjunto de metodologias criadas por Alistair Cockburn para equipes de tamanhos diferentes [Cockburn 2004]. Os primeiros trabalhos e estudos sobre esta metodologia foi cunhado na IBM, em meados de 1990. A partir das características dos projetos, se escolhe a mais apropriada. No Crystal, as metodologias compartilham alguns princípios como entrega incremental em períodos de tempo, testes funcionais e de regressão, revisões e workshops de produto. Um outro ponto forte que se deve ter em mente, abordado por Cockburn, é a utilização do mínimo necessário para alcançar o sucesso no projeto.

2.4. Adaptive Software Development (ASD)

Segundo [Highsmith 1997], o principal objetivo do ASD é identificar a natureza adaptativa dos projetos de software, tratando as incertezas que são inerentes a esta natureza. Para isso, Jim Highsmith baseou seus estudos na teoria de Sistemas Adaptativos 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 ciclo de 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 de prototipaçõ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 e iterativo. 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 ciclos iterativos de desenvolvimento. O DSDM tem como princípios a participação ativa do cliente, entregas freqüentes, times com poder de decisão e testes durante o ciclo de vida do 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]. É um processo 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 a criaçã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 10 representa 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, para representar 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 disciplina de desenvolvimento de software voltada para pequenas e médias equipes, onde os requisitos são vagos e mudam freqüentemente. Desenvolvido por Kent Beck, Ward Cunningham e Ron Jeffries, o XP tem como principal tarefa a codificação, com ênfase

menor nos processos formais de desenvolvimento, com uma maior disciplina de codificação e testes. Tem como valores a comunicação, simplicidade, feedback e coragem.

A comunicação é essencial em projetos de software. É a principal forma de se transmitir e trocar informações e conhecimentos do projeto. Por esta razão, é importante incentivar 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. Da mesma forma, quanto mais se afasta das pessoas, mais ruídos e barreiras surgem.

Figura 11. Riqueza dos Canais de Comunicação [Amble r 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 a requisitos do cliente, seja em relação ao resultado da execução de testes unitários, seja na compilação do código. A compreensão das necessidades dos usuários e do negócio propriamente dito é um aprendizado contínuo. Segundo [Cockburn 2002], a razão de adotar estratégias incrementais e iterativas é permitir que os inevitáveis erros das pessoas 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 forma desnecessária complica o design e eleva o esforço de para desenvolver incrementos subseqüentes.

A coragem também é incentivada através do uso das práticas. O desenvolvedor só sentirá confiança em alterar o código de outro colega se conhecer o padrão de codificação, por exemplo. Além desta prática, o uso de controle de versão e testes unitários também encorajam tal investida. Segundo [Beck e Fowler 2000], além destes medos naturais de alteração de código, tem-se uma série de medos que exercem influê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 um plano relevante; e) não saber o que está acontecendo e, f) aterem-se nas primeiras decisões de projeto e não serem capazes de reagir à mudança dos negócios. O time de desenvolvimento teme: a) ser solicitados a fazer mais do que sabem fazer; b) ser ordenados 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 que precisa ser feito; f) sacrificar a qualidade em função do prazo; g) resolver problemas complexos sem ajuda e, h) não ter tempo suficiente para fazer um bom trabalho [Beck e Fowler 2000].

O XP valoriza a criação e automação dos testes, sendo criados antes, durante e depois da codificação. É flexível a mudanças de requisitos, valorizando o feedback com o 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, abandonando todo 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 de que as pessoas são peças intercambiáveis dentro do processo de desenvolvimento.

3.1. Origens do XP

Os principais fundamentos de XP tiveram origem na década de 80, nas raízes do desenvolvimento em Smalltalk [Cunningham 2008]. Nesta época, Kent Beck e Ward Cunningham trabalhavam na Tektronixs. Os projetos realizados nesta época serviram de laboratório para que fossem aperfeiçoadas práticas como refactoring, programação em pares, mudanças rápidas, feedback constante do cliente, desenvolvimento iterativo, testes frequentes. Neste período, também surgiram importantes contribuições, como a tese de doutorado de Bill Opdyke [Opdyke 1992], sobre técnicas de refactoring que Beck e Cunningham já usavam na indústria.

Em 1996, todas as práticas criadas e experimentadas ao longo de anos realmente se fundiram [Anderson et al 1998]. Foi em um projeto da Daimler Chrysler, denominado Chrysler Comprehensive Compensation (C3). O C3 era o projeto de folha de pagamento da Companhia. Na época, Beck trabalhava como consultor para problemas de desempenho em Smalltalk. Neste mesmo ano, Beck publicou um livro com relevantes contribuições, que apresentava excelentes técnicas de desenvolvimento nesta tecnologia [Beck 1996]. Sue Unger, CIO da Chrysler, entrou em contato com Beck para fazer uma análise do projeto.

Após um período trabalhando com a equipe, Beck apresentou um relatório para a diretora com a descrição dos problemas, desde problemas contratuais até problemas de ambiente. As alternativas eram: a) deixar as coisas como estavam; b) cancelar o projeto e, c) dar folga para a equipe e começar do zero. Unger escolheu a última opção e colocou Beck a frente do time. A primeira medida do Beck perante o time foi dar folga para o pessoal. Assim, o time pode recuperar o ânimo para começar uma nova etapa.

Beck realizou entrevistou os 20 membros do time individualmente, explicando como funcionaria o processo de trabalho. Para cada um dos membros, ele explicava uma prática. Nasceu, desta forma, as práticas de XP [Anderson et al 1998].

3.2. Papéis

Os papéis de um time XP são formados por uma variedade de pessoas, com características e habilidades necessárias para o sucesso do projeto. Em geral, os papéis não variam muito em relação ao de outros processos e metodologias. A seguir, são apresentados 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éis até podem ser acumulados por mais de uma pessoa dentro do time, porém deve tomar certos cuidados [Cunningham 2006].

3.3. Práticas

O funcionamento do XP é baseado em um conjunto de valores e práticas. As práticas do XP são divididas organizacionais (círculo vermelho), equipe (círculo verde) e individuais (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 Programming

Nesta 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 time XP.

4.1. Ciclo de Trabalho

O 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 20 01a]

Na fase de exploração, são definidos as user stories iniciais e o rascunho da arquitetura. Do ponto de vista de requisitos, é interessante detalhá-los de forma que se tenha uma visão suficiente para começar o projeto, com uma definição básica para as estimativas [Beck 2004]. À medida que se avança em etapas posteriores de planejamento, as user stories são priorizadas e mais detalhadas. Outro ponto tratado nesta fase é o spike de arquitetura. A arquitetura é tratada em XP como algo primordial e que 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 de modelagem de arquitetura é explorado com mais detalhes, como propósitos, diagramas para modelagem, ferramentas e estatísticas de adoção desta abordagem. O principal objetivo desta fase é a redução de riscos, tanto de planejamento, quanto de desenvolvimento.

Na fase de planejamento, os requisitos são detalhados para compor o plano de release. Este trabalho é realizado durante a reunião de planejamento de release. Neste plano, são definidos com maiores detalhes os requisitos do software. Os requisitos técnicos também são explorados, de forma que, caso se tenha alguma dúvida de implementação, é possível fazer uso de spikes [Wells 2001a]. O principal objetivo desta fase é definir o plano do produto de software e a definição das entregas, ocorrendo o mais cedo possível [Beck e Fowler 2000]. Esta é a base para o planejamento das iterações. Na figura 14, é apresentada uma lista de requisitos (potenciais user stories), onde são analisados diferentes aspectos como prioridade, volatilidade técnica e de requisitos, acesso e dependências. Ela servirá de base para a elaboração dos planos de iteraçõ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 das iterações são diferentes de time para time, podendo variar de 1 a 3 semanas [Wells 2001a]. Nesta fase, o plano de release serve de base para o trabalho e as user stories planejadas para a iteração atual são exploradas e detalhadas [Beck e Fowler 2000]. Caso nã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 o planejamento atual. Com base neste plano de iteração, é que o time realiza o trabalho diário de construção. A cada dia, é realizado o stand up meeting para que o trabalho realizado seja exposto para o time. O tracker coleta métricas diárias e as expõe para o time. No final da iteração, o time realiza uma avaliação da iteração, promovendo a melhoria para a iteração posterior. O principal objetivo desta fase é a construção do software, 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 o lançamento do produto para produção. Esta é a principal característica desta fase, o pequeno incremento do produto, com objetivo de colocá-lo mais cedo possível em produção [Beck 2004]. Assim, o cliente terá a real noção da evolução do produto e poderá dar também um feedback mais fidedigno sobre o trabalho realizado.

Nas metodologias ágeis e, em especial o XP, as fases de planejamento de release, 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, de origem reativa (correção) e pró-ativa (aprimoramento). Essa abordagem de não separar o desenvolvimento da manutenção e entender que o software evolui continuamente é uma característica de XP. Esta evolução é tratada de forma natural, através das práticas em promover pequenos planejamentos (release, iterações), implementando poucas funcionalidades e entregando software mais rapidamente. Com isso, o cliente consegue dar um feedback mais rápido, pois são menos funcionalidades a testar e validar. Como o feedback é mais rápido, se consegue rever o planejamento do trabalho a ponto de realizar mudanças, se necessário.

4.2. Planejamento de Projeto

Em 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]. O cliente é parte primordial do planejamento, participando da priorização dos requisitos, detalhando-os junto com os analistas em formato de user stories e tarefas. O principal foco 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 (a daptado de [Cohn 2005])

Existem requisitos que são de alto risco de implementação e baixo valor de negó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 de agregar mais valor rapidamente para o software, evitar desperdícios. Na figura 17, é apresentada a ordem de implementação dos requisitos. Com base nestas premissas, a implementação dos requisitos de maior prioridade são essenciais para agregar valor ao produto. Este exercício de repriorização é realizado no inicio de cada iteração. Para a priorização, usa-se o feedback da iteração anterior juntamente com o planejamento definido para a iteração atual.

Figura 17. Ordem de implementação dos requisitos (a daptado de [Cohn 2005])

Na figura 18, apresenta-se a forma de priorização, onde sempre tem-se os requisitos mais importantes para negócio no topo da pilha. Este é um exercício comum do 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 Stories

Os requisitos são registrados no formato de user stories. As user stories tem o mesmo propósito dos casos de uso, porém escritos de forma mais curta e enxuta, levando em consideração a perspectiva do usuário [Cohn 2004]. Segundo [Jeffries 2001], as user stories devem ser escritas, com base nas propriedades 3Cs (Card, Conversation e Confirmation). 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, podendo ser escritas informalmente ou mais estruturadas seguindo um template. Segundo [Wake 2003], uma boa prática para o time na escrita de user stories é levar em consideração das características desejáveis INVEST. No quadro 3, é apresentado especificamente cada 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 uso do template.

Figura 19. Exemplos de User Stories [Cohn 2004]

No quadro 4, é apresentado um exemplo de template onde é identificado os componentes de uma user story. A persona representa um tipo de usuário que interage com o sistema [Cooper 2003]. A principal diferença entre atores e personas é que as personas são instâncias de um tipo de usuário/papel (ator), tentando analisar seu contexto no mundo real. Para as personas, são definidas as funcionalidades e seu propó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 chaves como: “Quem é afetado pelo requisito? O que deve ser implementado? Por quê?” Estes questionamentos estão atrelados aos critérios de aceitação, algo fundamental na escrita da user story. Quando um requisito é definido, os critérios de aceitação devem estar presentes. É 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$480

4.4. Dia a dia em um time XP

O trabalho diário de um time XP é baseado no plano de iteração [Wells 2001a]. Todo o dia é realizado o stand up meeting, com o objetivo de expor o trabalho individual para o time, 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 do time. 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 de desenvolvimento diário em XP.

Figura 20. Ciclo de Desenvolvimento diário [Wells 2 001a]

Em [Wake 2000], é apresentado uma visão alternativa do trabalho diário. Nesta outra 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. Dentro deste contexto, o uso de práticas de modelagem ágil [Ambler 2004b] se torna primordial. 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 X P [Wake 2000]

No trabalho diário vale destacar que a prática de programação em pares pode ser utilizada no formato de sessões. Desta forma, user stories mais complexas e que exijam mais revisões pode ser candidatas para a prática em sessão. Mais importante que adotar a prática de programação em pares é promover a rotação entre estes pares11. Além de disseminar o conhecimento do projeto para o time, mantém a simplicidade nas atividades, maximizando o valor entregue no software.

5. Ferramentas de Apoio

Para apoiar a adoção dos princípios, valores e práticas do XP, existem uma série de ferramentas 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 o ambiente 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 o desenvolvimento do trabalho em XP.

5.1. Ambiente e Hard Tools

O ambiente é essencial para apoiar as práticas, tanto de gerenciamento quando de construção. Para isso, é necessário adequá-lo para as necessidades de um time ágil. Para adequá-lo, pode-se utilizar uma série de gráficos de acompanhamento, murais e quadros tornando o ambiente informativo12 [Shore e Warden 2008]. A figura 22 apresenta um layout 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ém conhecida como Move People Around. Mais informações em [Wells 2001b] 12 Existem dois termos utilizados para representar o ambiente informativo em times ágeis: Big Visible Charts (Ron Jeffries) e Information Radiator (Alistair Cockburn).

Figura 22. Ambiente de trabalho para um time XP [Sh ore 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. O ambiente fornece mecanismos para que a comunicação, um dos valores do XP, esteja sempre presente.

Os quadros e murais expostos para time são melhores que sites na Web ou planilhas eletrônicas dentro das estações de trabalho [Jeffries 2004a]. Nestas ferramentas, a informação não está exposta para o time, os membros do time têm que buscá-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ível para o time. Por exemplo, um dos gráficos utilizados, é a quantidade de testes de aceitação existentes, para cada período de tempo (dia, semana, iteração), apresentados na figura 23.

É possível ver a evolução e verificar se algo não está indo não está bem [Jeffries 2004a]. Utilizando gráficos como ferramentas de acompanhamento, é possível identificar certos padrões. Estes padrões podem indicar informações relevantes para o time, entre elas como descobrir sua própria velocidade de produção. Outros gráficos muito usados por times ágeis são os gráficos de burndown e burnup [Cockburn 2005]. O primeiro (burndown chart) é relacionado com a queima de horas da iteração, onde em cada período de trabalho marca-se quanto já foi realizado. Assim, é possível projetar as próximas iterações com base no trabalho feito, fazendo-se uma projeção se será possível entregar no prazo. O segundo, é relacionado com a implementação das tarefas e em relação ao que foi planejado. Também é possível analisar neste gráfico o valor agregado para 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 20 08]

Além dos gráficos, um time ágil utiliza quadros para execução e acompanhamento do trabalho do time. Nestes quadros, é possível verificar o trabalho que está planejado, os que estão em andamento e os que já estão prontos. Estes quadros são também conhecidos como quadros de Kanban13 [Kniberg e Skarin 2009]. Existem variaçõ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ções serão criadas. O quadro pode conter seções para exposição de marcos de entrega de releases, mural de recados, mural de lembretes, classificação de requisitos, exposição de grá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 o quadro, mas o quadro também faz esta tarefa para o time. Por exemplo, um quadro onde se tem as seguintes seções: tarefas planejadas, em execução e testes. No momento que tarefas são colocadas em planejamento e, esta seção ficar lotada, é hora de começar a execução. Da mesma forma que, quando a execução já está lotada, é necessário passar tarefas para a seção de testes. Este tipo de fluxo é chamado de Just in Time14. Caso aconteça algum problema na execução das tarefas, é possível sinalizar com o quadro

13 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ível planejar 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 acompanhamento

5.2. Soft Tools

Existem 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áticas que são apoiadas, a licença disponível e endereço web do fornecedor.

Quadro 6. Lista de ferramentas por tecnologia

Práticas/

Intenções

Ferramenta Suporte a Tecnologia

Licença URL

Planejamento de Releases e Iterações

XPlanner Java LGPL http://www.xplanner.org/

ExtremePlanner Java Comercial http://www.extremeplanner.com/

AgileTrack Java Comercial http://agiletrack.net/

RallyDev Não informado

Free e Comercial

http://www.rallydev.com/

XPWeb PHP GPL http://xpweb.sourceforge.net/

Testes de Aceitação, Integrados

FIT Várias GPL http://fit.c2.com/

FITNesse Várias L http://fitnesse.org/

Selenium Várias GPL http://seleniumhq.org

15 A escolha das tecnologias foi baseada em sua adoção na indústria de software para aplicações comerciais. Mais informações sobre linguagens de programação em http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Práticas/

Intenções

Ferramenta Suporte a Tecnologia

Licença URL

Testes Unitários, Cobertura

JUnit Java GPL http://www.junit.org

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 Contínua

Apache ANT Java Apache http://ant.apache.org/

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 Codificação, Auditoria, Controle de Versões, IDEs

NDepend .NET Comercial http://www.ndepend.com/

NDoc .NET GPL http://ndoc.sourceforge.net/

PMD/CPD Java GPL http://pmd.sourceforge.net/

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 e Gratuito

http://www.microsoft.com/exPress/

5.4. Métricas

Para controlar o andamento do trabalho, as equipes de desenvolvimento definem métricas. Nas metodologias ágeis, as métricas não são diferentes. Segundo [Hartmann e Dymond 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ão Running Tested Features (RTF), Project Velocity e Load Factor [Jeffries 2004b; Beck 2004; Cunningham 2007; Cunningham 2009].

A métrica Running Tested Features (RTF) é referente à taxa de valor de negócio entregue por funcionalidade testada e implantada. Desta forma, o cliente define quando uma funcionalidade está pronta, através de testes de aceitação [Jeffries 2004b].

A métrica Project Velocity está relacionada a quanto de software o time consegue entregar por iteração, em relação às atividades planejadas [Cunningham 2007]. A base para medição são as story points ou dias ideais de desenvolvimento. Esta métrica é extremamente importante para o time, pois é através dela que se consegue fazer um nivelamento de produção e encontrar o takt time16. Aí está a importância de ter uma iteração time-boxed17. Esta métrica pode ser afetada por inúmeros fatores, como impedimentos, 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 um dia de trabalho ideal [Cunningham 2009]. Este fator é utilizado, juntamente com o Project 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 XP

O XP é uma disciplina ágil, que requer total integração da equipe. Por isso, os valores de comunicação, simplicidade, coragem e feedback são sempre levados em consideração antes da aplicação da disciplina. Como o XP é voltado para testes, é muito importante a projeçã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 é uma barreira. Outra situação onde se torna complicado aplicar o XP é quando não se tem controle sobre o código e quando o feedback é demorado, sem uma comunicação eficiente [Astels, Miller e Novak 2002].

Outras questões que dificultam o uso de XP são barreiras culturais, como alteração de código de terceiros e relevância de hábitos antigos, procurando manter as coisas simples. O XP também não pode ser aplicado quando o cliente quer uma especificação detalhada do sistema antes de começar o desenvolvimento. 16 Termo utilizado no Lean para representar o compasso de trabalho do time 17 Períodos de tempo distintos e fixos, sem variações.

O XP tem obtido um crescimento contínuo como disciplina de desenvolvimento dentro da indústria do software, sendo discutida pelos principais engenheiros de software do mercado. Existem vários trabalhos relacionando XP com processos incrementais e iterativos, como [Martin 2002; Smith 2003], abordando características em termos de tempo e alocação de recursos, artefatos, disciplinas e atividades.

As práticas do XP podem ser abordadas dentro de diferentes ciclos de desenvolvimento e metodologias. Ao trabalhar com modelos de maturidade como SW-CMM/CMMI, as práticas de metodologias ágeis podem ajudar nos processos relacionados à engenharia, nos processos de qualidade do produto, métricas, e melhoria contínua [Paulk 2001; Sutherland, Jakobsen e Johnson 2007; Glazer 2008]. As metodologias ágeis também são relacionadas a sistemas de gestão da qualidade como ISO 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 o trabalho de melhoria dos fornecedores [ISO 2010].

Referências

Ambler, 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.