SlideShare une entreprise Scribd logo
1  sur  31
Télécharger pour lire hors ligne
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 etapas 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 Processos 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 [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 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 2001a]

        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 (adaptado 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 (adaptado 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 2001a]

       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 XP [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 [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. 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 2008]

       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/         Ferramenta   Suporte a        Licença                              URL
                                    Tecnologia
 Intenções
Planejamento     XPlanner           Java         LGPL          http://www.xplanner.org/
de Releases e
Iteraçõ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.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/         Ferramenta     Suporte a     Licença                                   URL
                                   Tecnologia
 Intenções
Testes           JUnit             Java         GPL          http://www.junit.org
Unitá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 Gratuito


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.

Contenu connexe

Tendances

Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme ProgrammingMilfont Consulting
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Fernando Kenji Kamei
 
Extreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumExtreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumRafael Souza
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Claudia Melo
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme ProgrammingDenis L Presciliano
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Softwarealexandre_malaquias
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPWildtech
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XPWildtech
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareLuciano Almeida
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixCris Fidelix
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilRebecca Betwel
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareEverton vitor
 
Métricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareMétricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareLuiz Borba
 

Tendances (20)

Extreme Programming XP
Extreme Programming XPExtreme Programming XP
Extreme Programming XP
 
Apresentando Extreme Programming
Apresentando Extreme ProgrammingApresentando Extreme Programming
Apresentando Extreme Programming
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Extreme Programming (XP) e Scrum
Extreme Programming (XP) e ScrumExtreme Programming (XP) e Scrum
Extreme Programming (XP) e Scrum
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme Programming
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XP
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XP
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
 
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane FidelixModelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
Modelos de Processo e Desenvolvimento de Software 3 - Prof.ª Cristiane Fidelix
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Métricas Em Fabricas De Software
Métricas Em Fabricas De SoftwareMétricas Em Fabricas De Software
Métricas Em Fabricas De Software
 

Similaire à Conhecendo o eXtreme Programming

Feature driven development
Feature driven developmentFeature driven development
Feature driven developmentIzabel Rodrigues
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Maicon Zerbielli
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Wildtech
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLAnnkatlover
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Diógenes Almeida
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...André Luis Celestino
 
Gerenciamento estratégico de projetos em tecnologia da informação
Gerenciamento estratégico de projetos em tecnologia da informaçãoGerenciamento estratégico de projetos em tecnologia da informação
Gerenciamento estratégico de projetos em tecnologia da informaçãoDouglas Souza
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREKéllyson Gonçalves da Silva
 
Processos de software
Processos de softwareProcessos de software
Processos de softwareDann Volpato
 
Desenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanDesenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanRenan Daré
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareThiago Reis da Silva
 

Similaire à Conhecendo o eXtreme Programming (20)

O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Metodologias de desenvolvimento
Metodologias de desenvolvimentoMetodologias de desenvolvimento
Metodologias de desenvolvimento
 
Jucelir
JucelirJucelir
Jucelir
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
 
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
Desenvolvimento de um microprocesso utilizando métricas e indicadores como a...
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Implantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SLImplantacao.Processo.Fabrica.SL
Implantacao.Processo.Fabrica.SL
 
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
Proposta De Um Protótipo Para Avaliação Da Maturidade em Gestão Da Inovação D...
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
Gerenciamento estratégico de projetos em tecnologia da informação
Gerenciamento estratégico de projetos em tecnologia da informaçãoGerenciamento estratégico de projetos em tecnologia da informação
Gerenciamento estratégico de projetos em tecnologia da informação
 
Metodos ageis
Metodos ageisMetodos ageis
Metodos ageis
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
Apostila introdutória ao Scrum (V1)
Apostila introdutória ao Scrum (V1)Apostila introdutória ao Scrum (V1)
Apostila introdutória ao Scrum (V1)
 
Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Processos de software
Processos de softwareProcessos de software
Processos de software
 
Desenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanDesenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas Lean
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 

Plus de Daniel Wildt

Pré-Jogo / Inception - Descobrindo Produtos Viáveis
Pré-Jogo / Inception - Descobrindo Produtos ViáveisPré-Jogo / Inception - Descobrindo Produtos Viáveis
Pré-Jogo / Inception - Descobrindo Produtos ViáveisDaniel Wildt
 
O que é inovação?
O que é inovação?O que é inovação?
O que é inovação?Daniel Wildt
 
GoF Design Patterns - Borland Conference (BorCon) 2004
GoF Design Patterns - Borland Conference (BorCon) 2004GoF Design Patterns - Borland Conference (BorCon) 2004
GoF Design Patterns - Borland Conference (BorCon) 2004Daniel Wildt
 
O potencial Mobile [GUDAY 2016]
O potencial Mobile [GUDAY 2016]O potencial Mobile [GUDAY 2016]
O potencial Mobile [GUDAY 2016]Daniel Wildt
 
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014Daniel Wildt
 
Aula: Agile Kickstart - Como criar equipes de alto desempenho?
Aula: Agile Kickstart - Como criar equipes de alto desempenho?Aula: Agile Kickstart - Como criar equipes de alto desempenho?
Aula: Agile Kickstart - Como criar equipes de alto desempenho?Daniel Wildt
 
Causas - Qual é a sua?
Causas - Qual é a sua?Causas - Qual é a sua?
Causas - Qual é a sua?Daniel Wildt
 
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.Daniel Wildt
 
Tarefas! O Que fazer?
Tarefas! O Que fazer?Tarefas! O Que fazer?
Tarefas! O Que fazer?Daniel Wildt
 
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)Daniel Wildt
 
Mantra das Possibilidades - AgileBrazil 2013
Mantra das Possibilidades - AgileBrazil 2013Mantra das Possibilidades - AgileBrazil 2013
Mantra das Possibilidades - AgileBrazil 2013Daniel Wildt
 
JustJava 2013 - Indo para as nuvens?
JustJava 2013 - Indo para as nuvens?JustJava 2013 - Indo para as nuvens?
JustJava 2013 - Indo para as nuvens?Daniel Wildt
 
Agile KickStart 2 - Escrevendo User Stories
Agile KickStart 2 - Escrevendo User StoriesAgile KickStart 2 - Escrevendo User Stories
Agile KickStart 2 - Escrevendo User StoriesDaniel Wildt
 
Agile KickStart 3 - Planejamento e Dia a Dia de Projeto
Agile KickStart 3 - Planejamento e Dia a Dia de ProjetoAgile KickStart 3 - Planejamento e Dia a Dia de Projeto
Agile KickStart 3 - Planejamento e Dia a Dia de ProjetoDaniel Wildt
 
Agile KickStart 4 - Melhoria Contínua
Agile KickStart 4 - Melhoria ContínuaAgile KickStart 4 - Melhoria Contínua
Agile KickStart 4 - Melhoria ContínuaDaniel Wildt
 
Agile Kickstart 1 - Cultura Ágil
Agile Kickstart 1 - Cultura ÁgilAgile Kickstart 1 - Cultura Ágil
Agile Kickstart 1 - Cultura ÁgilDaniel Wildt
 
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...Daniel Wildt
 

Plus de Daniel Wildt (20)

Não Espere!
Não Espere! Não Espere!
Não Espere!
 
Pré-Jogo / Inception - Descobrindo Produtos Viáveis
Pré-Jogo / Inception - Descobrindo Produtos ViáveisPré-Jogo / Inception - Descobrindo Produtos Viáveis
Pré-Jogo / Inception - Descobrindo Produtos Viáveis
 
O que é inovação?
O que é inovação?O que é inovação?
O que é inovação?
 
GoF Design Patterns - Borland Conference (BorCon) 2004
GoF Design Patterns - Borland Conference (BorCon) 2004GoF Design Patterns - Borland Conference (BorCon) 2004
GoF Design Patterns - Borland Conference (BorCon) 2004
 
O potencial Mobile [GUDAY 2016]
O potencial Mobile [GUDAY 2016]O potencial Mobile [GUDAY 2016]
O potencial Mobile [GUDAY 2016]
 
Lean Canvas
Lean CanvasLean Canvas
Lean Canvas
 
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014
O que aprendemos com o eXtreme Programming e com o mundo Ágil | #XPConfBR 2014
 
Aula: Agile Kickstart - Como criar equipes de alto desempenho?
Aula: Agile Kickstart - Como criar equipes de alto desempenho?Aula: Agile Kickstart - Como criar equipes de alto desempenho?
Aula: Agile Kickstart - Como criar equipes de alto desempenho?
 
Causas - Qual é a sua?
Causas - Qual é a sua?Causas - Qual é a sua?
Causas - Qual é a sua?
 
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.
[RS on Rails 2013] Construa um produto. Quando? Neste final de semana.
 
Tarefas! O Que fazer?
Tarefas! O Que fazer?Tarefas! O Que fazer?
Tarefas! O Que fazer?
 
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)
#StartupDojo Porto Alegre - Julho/2013 (Nós Coworking)
 
Mantra das Possibilidades - AgileBrazil 2013
Mantra das Possibilidades - AgileBrazil 2013Mantra das Possibilidades - AgileBrazil 2013
Mantra das Possibilidades - AgileBrazil 2013
 
JustJava 2013 - Indo para as nuvens?
JustJava 2013 - Indo para as nuvens?JustJava 2013 - Indo para as nuvens?
JustJava 2013 - Indo para as nuvens?
 
Agile KickStart 2 - Escrevendo User Stories
Agile KickStart 2 - Escrevendo User StoriesAgile KickStart 2 - Escrevendo User Stories
Agile KickStart 2 - Escrevendo User Stories
 
Agile KickStart 3 - Planejamento e Dia a Dia de Projeto
Agile KickStart 3 - Planejamento e Dia a Dia de ProjetoAgile KickStart 3 - Planejamento e Dia a Dia de Projeto
Agile KickStart 3 - Planejamento e Dia a Dia de Projeto
 
Agile KickStart 4 - Melhoria Contínua
Agile KickStart 4 - Melhoria ContínuaAgile KickStart 4 - Melhoria Contínua
Agile KickStart 4 - Melhoria Contínua
 
Agile Kickstart 1 - Cultura Ágil
Agile Kickstart 1 - Cultura ÁgilAgile Kickstart 1 - Cultura Ágil
Agile Kickstart 1 - Cultura Ágil
 
Quem é você?
Quem é você?Quem é você?
Quem é você?
 
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
Agile Transition. PMBOK knowledge areas and how values, principles and agile ...
 

Conhecendo o eXtreme Programming

  • 1. 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
  • 2. 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 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.
  • 3. 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.
  • 4. 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 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.
  • 5. 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
  • 6. 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].
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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 [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 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
  • 11. 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].
  • 12. 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]
  • 13. 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
  • 14. 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
  • 15. 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 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
  • 16. 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.
  • 17. 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 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 (adaptado 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]
  • 18. 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.
  • 19. 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.
  • 20. 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 2001a] 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/
  • 21. 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 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).
  • 22. 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. 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).
  • 23. 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 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.
  • 24. 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/ Ferramenta Suporte a Licença URL Tecnologia Intenções Planejamento XPlanner Java LGPL http://www.xplanner.org/ de Releases e Iteraçõ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.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
  • 25. Práticas/ Ferramenta Suporte a Licença URL Tecnologia Intenções Testes JUnit Java GPL http://www.junit.org Unitá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 Gratuito 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;
  • 26. 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.
  • 27. 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.
  • 28. 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.
  • 29. 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.
  • 30. 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.
  • 31. 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.