Sumrio 1 - Introduo ............................................................................................. 3 2 - Histria .................................................................................................. 4 3 - Valores XP ............................................................................................ 5 3.1 - Feedback .................................................................................. 5 3.2 - Comunicao ........................................................................... 5 3.

3 - Simplicidade ............................................................................ 6 3.4 - Coragem ................................................................................... 7 4 - Clientes Presente .................................................................................. 8 5 - O Jogo do Planejamento (Planning Game) ........................................ 8 5.1 - Dividindo Responsabilidades ................................................. 8 5.1.2 - Direitos do Cliente ..................................................... 9 5.1.3 - Direitos do Desenvolvedor ......................................... 9 5.2 - Escrevendo estrias ................................................................. 9 5.2.1 - Tarefas ...................................................................... 10 5.3 - Estimando as estrias ........................................................... 10 5.4 - Estimando a Equipe .............................................................. 10 5.5 - Planejando os Releases ......................................................... 11 5.6 - Planejando as Iteraes ........................................................ 11 5.7 - Encerrando uma Iterao .................................................... 11 5.8 - Encerrando um Release ........................................................ 11 6 - Reunies em P (Stand Up Meeting) ................................................ 12 7- Programao em Par .......................................................................... 12 8 - Refatorao (Refactoring) ................................................................. 12 9 - Desenvolvimento Guiado Pelos Testes ............................................. 13 10 - Cdigo Coletivo ................................................................................ 13 11 - Padres de Codificao .................................................................... 14 12 - Design Simples .................................................................................. 14
1

13 - Metfora ............................................................................................ 15 14 - Ritmo Sustentvel ............................................................................ 15 15 - Integrao Contnua ........................................................................ 15 16 Release Curto ................................................................................... 16 17 A organizao do ambiente de trabalho ........................................ 16 18 - A equipe de desenvolvimento .......................................................... 18 18.1 - Gerente de Projeto .............................................................. 18 18.2 - Coach (Tcnico) .................................................................. 18 18.3 - Analista de Teste ................................................................. 19 18.4 - Redator Tcnico .................................................................. 19 18.5 - Desenvolvedor ..................................................................... 19 19 - Documentao do Projeto ............................................................... 19 19.1 - Requisitos documentar ....................................................... 19 19.2 - Documentao de Design ................................................... 20 19.3 - Documentando Cdigo ....................................................... 21 20 - Manuais ............................................................................................. 22 21 - Outra documentao ........................................................................ 22

1 - Introduo
A Extreme Programming (XP) uma nova metodologia para o desenvolvimento de software e que combina rapidez e eficincia de maneira produtiva disciplinada e sobre tudo humana. Ela (XP) uma metodologia gil, que visa um rpido desenvolvimento, atende s reais necessidades do cliente, para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. O XP um conjunto bem definido de regras, que vem ganhando um grande nmero de adeptos e por oferecer condies para que os desenvolvedores respondam com eficincia a mudanas no projeto, mesmo nos estgios finais do ciclo de vida do processo, devido a quatro lemas adotados por seus seguidores, que correspondem a quatro dimenses a partir das quais os projetos podem ser melhorados. So eles: Comunicao, Simplicidade, Feedback e Coragem. A XP descreve uma maneira de desenvolver software que combina as melhores prticas existentes na rea h muito tempo. Na XP essas prticas se complementam e controlam uma outra. A diferena da XP que ela pega essas prticas do senso comum e as utiliza a nveis extremos.

2 - Histria
O Extreme Programming um modelo de desenvolvimento de software, criado em 1996, por Kent Bech, no Departamento de Computao da montadora de carros Daimler Crysler, ele possui muitas diferenas em relao a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinmicos.

3 - Valores XP
Esses valores definem como as equipes iro proceder durante o processo de desenvolvimento. importante que sejam observadas para se obter o melhor resultado desta metodologia.

3.1 - Feedback
O feedback a realimentao que o cliente fornece equipe de desenvolvimento quando aprende algo novo sobre o sistema, quando aprende mais sobre os requisitos ou quando aprende mais sobre a forma como foram implementados. A partir de como e quando deve ser feito. Ele o mecanismo fundamental que permite ao cliente conduzir o desenvolvimento diariamente e garanta que a equipe direcione as suas atenes para aquilo que ir gerar mais valor. O cliente est sempre acompanhando a equipe de XP e sua evoluo, sendo assim sempre que aprende algo novo no sistema, tem condies de fornecer uma realimentao aos desenvolvedores que por sua vez alteram ou corrigem o que for necessrio. Essa prtica faz o cliente produzir e consumir o produto indefinidamente. O mesmo acorre com a equipe de desenvolvimento que fornece solues tcnicas ou de design ao cliente medida que produz o sistema e medida que consome as idias produzidas por ele.

3.2 - Comunicao
Para que o feedback exista em um projeto de software, necessrio que a comunicao esteja presente de forma muito intensa. Durante a fase de desenvolvimento necessrio que a equipe de desenvolvimento troque informaes com seu cliente para dar continuidade ao projeto, o que fundamental para o Feedback. Essa comunicao em geral feita de forma escrita como documentao. O XP ao contrrio, prega que essa comunicao seja feita face a face. Existem muitas formas de se comunicar seja por telefone, e-mail, mensagem instantnea, carta ou outros meios quaisquer. Quando estamos diante de algum percebemos gestos, as tonalidades da fala, expresses faciais e tudo o mais que 5

enriquece uma comunicao, mas quando usamos algum dos meios descritos, essa comunicao perde essa riqueza, e pior, compromete o entendimento. As prticas de XP como programao em pares, testes e comunicao com o cliente tm o objetivo de estimular a comunicao entre gerentes, programadores e clientes.

3.3 - Simplicidade
A simplicidade visa permitir a criao de cdigo simples que no deve possuir funes desnecessrias. Por cdigo simples entende-se implementar o software com o menor nmero possvel de classes e mtodos. Outra idia importante da simplicidade procurar implementar apenas requisitos atuais, evitando-se adicionar funcionalidades que podem ser importantes no futuro. Alm disso, sempre que h dvida sobre determinada funcionalidade a tendncia de um desenvolvedor produzir um cdigo muito generalizado e que provavelmente nunca ser utilizado. Trata-se ento de desperdcio de tempo e dinheiro do cliente que no solicitou tal implementao.

3.4 - Coragem
Ela necessria para que realmente se aplique XP como deve ser aplicado. Sendo o XP um novo processo de desenvolvimento, suas premissas bsicas contrariam os mtodos de desenvolvimento atuais. Por isso necessrio coragem para: Desenvolver software de forma incremental Exige que os desenvolvedores reavaliar as partes j prontas para adicionar novas funcionalidades de acordo com o Feedback do cliente. Manter o sistema simples necessrio coragem para no se deixar levar por preocupaes futuras, investindo em solues para problemas que no existem, e que caso apaream sejam capazes de alter-los. Permitir que o cliente priorize as funcionalidades Geralmente os desenvolvedores definem qual a ordem segundo um critrio tcnico de dependncia dos mdulos, o que no vai de encontro s

necessidades do cliente. necessrio coragem para deixar para este cliente definir as prioridades. Fazer os desenvolvedores trabalharem em par Esse tipo de programao diminui o tempo de implementao e a ocorrncia de erros. Investir tempo em refactoring Significa melhorar o cdigo j existente sem alterar sua funcionalidade de modo que evolua e permita que alteraes futuras sejam efetuadas mais rapidamente. Investir tempo em testes automatizados O tempo aqui no encarado como desperdcio, mas como investimento, dada a grande reduo de erros no sistema. Estimar as estrias na presena do cliente comum que gerentes de projeto temam que o cliente perceba insegurana em sua equipe, mas a XP um processo de desenvolvimento que se baseia na honestidade e na comunicao aberta. Expor o cdigo a todos os membros da equipe Como o cdigo escrito por um desenvolvedor exposto a todos os integrantes da equipe temido que surjam crticas por parte dos demais. Integrar o sistema diversas vezes ao dia Ao integrar partes do projeto, h o risco de que algumas delas deixem de funcionar, antes que isso ocorra deve se testa-las sistematicamente. Adotar um ritmo sustentvel Para que haja qualidade no cdigo produzido importante que a equipe esteja sempre disposta, necessrio coragem para abandonar a crena que horas excessivas de trabalho adiantaro o projeto. Abrir mo de documentao que servem como defesa geralmente em projetos fracassados, as desconfianas tomam forma e geram atritos entre clientes e desenvolvedores, que por sua vez tomam a documentao como forma de defesa. Em XP essa prtica inadmissvel pois desrespeita a premissa da honestidade. Propor contratos de escopo varivel A maioria dos contratos so confeccionados de forma a impedir que o cliente faa alteraes no

projeto. Como XP visa o aprendizado do cliente, necessrio que os contratos sejam revistos para dar ao cliente, novas chances de fazer alteraes que julgue necessria. Propor a adoo de um processo novo Mudanas de paradigmas so sempre difceis de encara, como o XP rompe com uma abordagem de desenvolvimento bastante tradicional, necessrio coragem para colocar suas premissas em prtica.

4 - Clientes Presente
fundamental a participao do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponvel para sanar todas as dvidas de requisitos, evitando atrasos e at mesmo construes erradas. Uma idia interessante manter o cliente como parte integrante da equipe de desenvolvimento. As funcionalidades do sistema so descritas em cartes, que recebem o nome de estrias. Quando se decide implementar uma dessas estrias o desenvolvedor dialoga com o cliente para compreende-lo melhor. medida que se aperfeioam as funcionalidades, as dvidas emergentes podem ser esclarecidas pelo cliente, o que garante a agilidade ao processo. A terminar de codificar o desenvolvedor pode demonstr-las ao cliente que far o Feedback instantaneamente.

5 - O Jogo do Planejamento (Planning Game)

O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que ir gerar maior valor para o cliente a cada dia de trabalho. Este planejamento feito diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades.

5.1 - Dividindo as Responsabilidades

O cliente o responsvel pelas decises de negcio enquanto que os desenvolvedores, pelas decises tcnicas. Isto origina a declarao de direitos do cliente e do desenvolvedor.

5.1.2 - Direitos do Cliente

1. Voc tem o direito de receber um plano geral para que voc saiba o que poder ser feito, quando e com que custo; 2. Voc tem o direito de receber o mximo de valor de cada semana de trabalho da equipe de desenvolvimento; 3. Voc tem o direito de acompanhar o progresso do projeto atravs de um sistema executvel, que demonstra estar correto por passar nos testes que voc especifica; 4. Voc tem o direito de mudar de idia, substituir funcionalidades e alterar prioridades sem ter que pagar um preo exorbitante; 5. Voc tem o direito de ser informado sobre mudanas no cronograma a tempo de decidir como reduzir o escopo para ser capaz de manter a data original. Voc pode cancelar o projeto a qualquer momento e receber um sistema executvel que reflete todo o investimento que foi feito at a data do cancelamento.

5.1.3 - Direitos do Desenvolvedor

1. Voc tem o direito de saber quais so as necessidades, bem como suas prioridades; 2. Voc tem o direito de produzir um trabalho de alta qualidade permanentemente; 3. Voc tem o direito de pedir e receber ajuda de seus colegas e do cliente; 4. Voc tem o direito de gerar e atualizar as suas estimativas; 5. Voc tem o direito de escolher as suas responsabilidades, ao invs delas serem determinadas para voc;

5.2 - Escrevendo estrias

Todas as funcionalidades do sistema so levantadas atravs de estrias escritas em cartes, elas devem sempre ser escritas pelo prprio cliente com suas prprias palavras e no deve haver regra para escrev-las. Quando o cliente escreve uma estria, ele pensa melhor sobre o que deseja, e passa uma idia bem resolvida da funcionalidade que deseja. Com essa prtica o cliente se sente responsvel por tudo o que est escrevendo nos cartes. Como cada um gera um custo de desenvolvimento, o cliente, pensa melhor antes de pedir novas funcionalidades.

5.2.1 - Tarefas
Muitas vezes as estrias produzem sistemas simples que podem ser implementadas rapidamente. No entanto h estrias que podem consumir muito esforo de desenvolvimento, demorando dias ou at semanas. Para esses casos as estrias so reescritas em tarefas, as quais so divididas entre os desenvolvedores. Neste caso os desenvolvedores escolhem tarefas para implementar, ao invs de estrias.

5.3 - Estimando as estrias Estimando por Ponto

A estimativa feita usando como unidade de medida o Ponto. O ponto representa uma unidade de tempo que varia ao longo do desenvolvimento de acordo com a velocidade da equipe. Na prtica, muitas equipes usam como unidade de medida Horas, ou Dias dependendo da realidade de cada uma.

Estimando por Comparao

Esta estimativa deve ser usada sempre que possvel, utilizando de cartes de experincias passadas com caractersticas parecidas j vivenciadas pela equipe, usando os a quantidade de pontos realmente consumida(que normalmente fica registrada na parte superior direita), como sendo a nova estimativa do novo carto.

10

5.4 - Estimando a Equipe

O XP recomenda que as estimativas sejam feitas sempre me equipe, de modo que todos possam avaliar as estrias e identificar aspectos importantes. Estimativas geradas em quase sempre so mais precisas que aquelas geradas por uma nica pessoa. Durante a elaborao das estimativas, a presena do cliente imprescindvel para que as duvidas, sejam sancionadas e o processo fique mais gil e isto aumenta a qualidade das estimativas, e o que evita com que os desenvolvedores assumam a premissa de estimativas incorretas.

5.5 - Planejando os Releases

Os projetos em XP costumam ser divididos em releases, de modo que cada release implemente um conjunto de funcionalidades que possui um valor bem definido para o cliente.

5.6 - Planejando as Iteraes

Iteraes so pequenas partes de tempo dedicado a implementao de um conjunto de estrias. Normalmente no XP estas iteraes tm durao em media de duas semanas. Uma vez definido o tempo recomendado que este tempo seja mantido ate o fim. Isto facilita a gerencia e o planejamento ate o final do projeto.

5.7 - Encerrando uma Iterao

No ultimo dia faz se uma reunio para que o cliente teste o que foi descrito na iterao. O objetivo validar resultado da iterao, e podendo descobrir eventuais erros.

5.8 - Encerrando um Release

11

Um release finalizado quando a ultima iterao e finalizada, a equipe coloca o sistema em produo para que os usurios passem a ter acesso a ele.

6 - Reunies em P (Stand Up Meeting)

So reunies realizadas todos os dias pela equipe de XP. Essas reunies so realizadas em at 10 minutos e as pessoas devem permanecer de p. Dessa forma so induzidas a uma reunio rpida e objetiva. Um dos propsitos dessa reunio atualizar os membros da equipe sobre as ltimas tarefas realizadas no dia anterior. uma oportunidade que se tem de compartilhar problemas e solues encontradas, disseminando conhecimento equipe como um todo. Alm disso, com a troca de informaes, temos a chance de descobrir pontos fracos no sistema, aperfeioando a cada dia. A reunio tambm trata do que ser feito no dia que est se iniciando, e levanta as prioridades de cada um. Com todos os propsitos sendo compartilhados, temos uma noo geral de todas as fases do projeto.

7- Programao em Par
A implementao do cdigo feita em dupla, ou seja, dois desenvolvedores trabalham em um nico computador. O desenvolvedor que est com o controle do teclado e do mouse implementa o cdigo, enquanto o outro observa continuamente o trabalho que est sendo feito, procurando identificar erros sintticos e semnticos e pensando estrategicamente em como melhorar o cdigo que est sendo implementado. Esses papis podem e devem ser alterados continuamente. Uma grande vantagem da programao em dupla a possibilidade dos desenvolvedores estarem continuamente aprendendo um com o outro. E com isso permite que o cdigo seja revisado enquanto construdo. Embora parea estranho, uma pessoa digitar e outra ficar parada, ocorre um grande engano, pois ambas esto programando. O que acontece que o tempo de programao cai quase pela metade quando praticada em pares.

12

8 - Refatorao (Refactoring)

Focaliza o aperfeioamento do projeto do software e est presente em todo o desenvolvimento. A refatorao deve ser feita apenas quando necessrio, ou seja, quando um desenvolvedor da dupla, ou os dois, percebe que possvel simplificar o mdulo atual sem perder nenhuma funcionalidade. Trata da recodificao de cdigos mal escritos, mesmo que estejam funcionando. um risco em potencial permitir que um cdigo assim permanea inalterado sem saber exatamente o que ele est fazendo no sistema. Qualquer tentativa de manuteno futura estar comprometida, criando srios problemas para quem necessitar modifica-lo ou compreende-lo. Refactorizar melhora a clareza (leitura) do cdigo, divide-o em mdulos mais coesos e de maior reaproveitamento, evitando a duplicao de cdigo-fonte.

9 - Desenvolvimento Guiado Pelos Testes

Primeiro cria os testes unitrios (unit tests) e depois cria o cdigo para que os testes funcionem isso aprofunda o entendimento das necessidades do cliente, e das limitaes de cada funcionalidade. Esta abordagem complexa no incio, pois vai contra o processo de desenvolvimento de muitos anos. S que os testes unitrios so essenciais para que a qualidade do projeto seja mantida. Testes so essenciais para o bom funcionamento do software, quanto mais cedo s funcionalidades so testadas menos problemas sero encontrados no futuro. A quantidade de detalhes a situaes que devemos imaginar para produzir os testes enorme, mesmo assim no devemos encar-lo como uma coisa chata e desagradvel, e sim como algo intrnseco ao ato de programar. Os testes devem ser simples e no devem consumir muito tempo.

10 - Cdigo Coletivo
A propriedade coletiva encoraja a equipe inteira a trabalhar mais unida em busca de qualidade no cdigo fazendo melhorias e refatoramentos em qualquer parte do 13

cdigo a qualquer tempo. A princpio pode-se pensar que esta prtica possa gerar problemas, mas como todos devem respeitar um padro de codificao e devem realizar todos os testes para verificao de erros esta atividade feita de uma forma controlada e pode ser facilitada com o uso de uma ferramenta de controle de verso. O cdigo do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um cdigo, mesmo que ele prprio no o tenha desenvolvido, pode faz-lo, desde que faa a bateria de testes necessria. Isto possvel porque na XP todos so responsveis pelo software inteiro. Uma grande vantagem desta prtica que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto com poucas dificuldades, pois todos conhecem todas as partes do software, mesmo que no seja de forma detalhada.

11 - Padres de Codificao
Como XP prega a propriedade coletiva de cdigo, onde todos podem alterar e fazer refatoramento de qualquer parte do cdigo a qualquer momento, ento mais do que necessrio que se tenha padres de codificao. O objetivo que todos programem da mesma forma, facilitando o entendimento do cdigo e as alteraes. A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Dessa forma parecer que todo o cdigo fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. Sendo detalhes simples como a forma de identao, podem fazer grande diferena. Deve se procurar evitar muitos comentrios, e dentro da racionalidade podem-se usar nomes longos que comuniquem a idia que se quer expressar.

12 - Design Simples
Para que o cliente possa obter feedback logo, a equipe precisa ser gil no desenvolvimento, o que a leva a optar pela simplicidade do design. Ao invs de criar generalizaes dentro do cdigo, de modo a prepar-lo para possveis necessidades futuras, a equipe deve sempre optar por um cdigo que seja suficiente para atender s necessidades da funcionalidade que est implementando.

14

Os desenvolvedores se baseiam na premissa de que sero capazes de incorporar qualquer necessidade futura quando e se ela surgir. Para isso, eles contam com o refactoring, os testes e as demais prticas do XP para apoi-los.

13 - Metfora
Muitas vezes pessoas tentam explicar um assunto ou problema a outras pessoas por um perodo sem obter o xito necessrio na explicao dada, simplesmente as outras pessoas no conseguem entender a mensagem que est se tentando repassar. Ao criar comparaes e analogias com o assunto em questo, torna-se mais fcil a compreenso deste assunto. Este tipo de artifcio chamado de metfora na XP, e deve ser utilizado com intensidade durante o projeto, uma vez que facilita a comunicao e fixao dos assuntos entre as partes. Esta prtica anda em conjunto com o ritmo sustentvel, j que para o desenvolvedor criar boas metforas exige criatividade e desenvolvimento de idias, o que torna necessria uma boa condio fsica e bem estar por parte do desenvolvedor.

14 - Ritmo Sustentvel
Um grande problema nos projetos de software a falta de tempo para encerrar o mesmo, e uma das tcnicas mais adotadas para compensar a falta de tempo submeter os desenvolvedores (humanos) a trabalharem at mais tarde e muitas vezes sacrificarem seus finais de semana. Nos primeiros momentos, este tipo de atitude tem efeitos positivos, porm passados alguns dias o rendimento da equipe cai drasticamente, dando margens a erros pela falta de concentrao no desenvolvimento, justamente pelo cansao fsico do desenvolvedor. A XP probe que os desenvolvedores trabalhem at mais tarde, sugerindo um ritmo sustentvel de 40 horas semanais, respeitando assim a individualidade e a sade de cada desenvolvedor. Desta forma a equipe estar sempre concentrada e muito menos propensa a pequenas falhas na implementao.

15 - Integrao Contnua

15

No desenvolvimento tradicional, geralmente as equipes so organizadas de modo que uma parte (mdulo) fique sob responsabilidade de um desenvolvedor, cabendo a esta pessoa efetuar testes e codificao que dizem respeito sua parte. Esta estratgia reduz a complexidade e as preocupaes de um desenvolvedor. Interfaces de integrao so convencionadas para que futuramente estas partes possam se comunicar; este tipo de desenvolvimento est propenso a srios erros de integrao, uma vez que os perodos em que as partes so integradas e testadas so extremamente longos. A XP prope uma integrao contnua, se possvel devendo ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do cdigo recm-desenvolvido. Com esta prtica, o feedback sobre a alterao efetuada ser dado em menor espao de tempo.

16 Release Curto
Release um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente. Um projeto XP pode ter um ou mais releases no seu ciclo de desenvolvimento. No modelo tradicional o projeto dividido em fases, de modo que o cliente comear a ter benefcio com o sistema muito prximo de o mesmo estar finalizado. A maior parte do investimento do projeto feita antes mesmo de estar concludo, sem ter gerado qualquer tipo de valor econmico ao cliente. A XP recomenda que pequenos investimentos sejam efetuados de forma gradual e que busque grandes recompensas o mais rapidamente possvel. Com a prtica de releases curtos, a XP pretende dar o mximo de valor econmico ao cliente em curto espao de tempo.

17 A organizao do ambiente de trabalho

O ambiente de trabalho de uma equipe XP deve ser um reflexo do projeto. Algum que entre na sala da equipe deve conseguir obter, em poucos segundos, uma noo clara de como est o andamento do projeto.

16

Um dos primeiros passos na implantao do XP e talvez a mais visvel de todas as prticas foi aquisio de um quadro de avisos. Os cartes so colocados na parede, nesse mural, de modo que possam ser acompanhados facilmente por todos os participantes do projeto, incluindo desenvolvedores, gerentes, clientes, entre outros. Existem softwares que procuram ajudar no planejamento de projetos XP. Entretanto, eles no so to eficazes quanto os cartes em papel. Como o projeto no distribudo, optou-se pelo papel e caneta. Com o intuito de coordenar as atividades, estabelecer uma harmonizao das tarefas e tornar evidente os objetivos do perodo, o quadro foi dividido em quatro partes. Disponveis: tarefas a serem escolhidas por algum disponvel e realizadas; Atribudas: tarefas escolhidas por um membro e que esto em andamento; Concludas: tarefas completadas; Pendentes: tarefas que necessitam de outras para serem iniciadas ou que ainda devero ser discutidas.

Posteriormente, devido necessidade de membros da equipe que realizavam tarefas alheias ao projeto, surgiu mais uma diviso no quadro: * Externas: Foram preenchidos pequenos cartes para serem anexados nessas reas. Cada carto continha o nome da tarefa, uma descrio e a quantidade de tempo que se presumia levar para o trmino da mesma. A escolha de quais seriam as tarefas e o tempo geralmente eram definidos semanalmente aps reunies. Partindo-se dos princpios de que nenhuma tarefa leva menos de duas horas para ser completada, j que podem surgir dificuldades no caminho, e de que uma tarefa que leve mais de dois dias para ser concluda deve ser dividida em outras menores, a equipe adotou as seguintes metforas: - uma esfera vazia equivale a 2 horas; - uma esfera meia-lua equivale a 4 horas; - uma esfera cheia equivale a um dia; - duas esferas cheias equivalem a dois dias. 17

Os cartes com as tarefas eram anexados como disponveis, de acordo com a sua ordem de prioridade. O membro da equipe escolhe uma tarefa e atribu ao seu nome. Dessa forma possvel visualizar rapidamente quem est ocupado e com o que se est trabalhando no momento. Isso tambm evita que mais de uma pessoa esteja trabalhando sobre um mesmo arquivo. O desenvolvedor escolhe a tarefa com a qual possui maior familiaridade e que mais lhe agrade. Conseqentemente h uma melhora significativa na produtividade. Ao trmino da tarefa, atribuda ao carto uma data, o nome de quem a realizou e a quantidade real de tempo que ficou com o mesmo. Ele ento movido para a seo dos concludos.

18 - A equipe de desenvolvimento
Em uma equipe de XP existem papis a serem desempenhados por um ou mais desenvolvedores. So eles:

18.1 - Gerente de Projeto

Pessoa responsvel pelos assuntos administrativos do projeto, mantendo um forte relacionamento com o cliente para que o mesmo participe das atividades do desenvolvimento. O gerente de projeto responsvel por filtrar assuntos no relevantes aos desenvolvedores e aspectos que s devam ser implementados em iteraes futuras.

18.2 - Coach (Tcnico)

Pessoa responsvel pelas questes tcnicas do projeto. Recomenda-se que esta pessoa seja a que possua maior conhecimento do processo de desenvolvimento, dos valores e prticas da XP. de responsabilidade do coach verificar o comportamento da equipe frente ao processo XP, sinalizando os eventuais erros cometidos pela equipe.

18.3 - Analista de Teste

18

Pessoa responsvel em garantir a qualidade do sistema atravs dos testes escritos. Ele deve ajudar o cliente a escrever os casos de testes e no final de cada iterao verificar se o software atende todos os casos de testes. Recomenda-se que esta pessoa no seja um desenvolvedor, para evitar uma viso tendenciosa j que no conhece o cdigo desenvolvido. O analista de teste deve ter uma viso muito parecida com a do cliente e em muitos projetos esta pessoa acaba exercendo o papel de redator tcnico.

18.4 - Redator Tcnico

Pessoa responsvel em documentar o sistema, evitando um forte trabalho dos desenvolvedores neste tipo de atividade, permitindo uma maior dedicao ao trabalho de codificao. Esta pessoa deve estar em plena sintonia com os desenvolvedores e clientes para que a documentao reflita o cdigo escrito e as regras de negcio atendidas pelo sistema.

18.5 - Desenvolvedor
Pessoa responsvel em analisar, projetar e codificar o sistema. Na XP no existe diferena entre analista, projetista e programador, uma vez que em vrios momentos do projeto o desenvolvedor estar exercendo alguma destas atividades. Naturalmente existem nveis distintos de desenvolvedores dentro de uma equipe, mas com as prticas da XP, como a programao em par, a tendncia a equipe se tornar uniforme em suas habilidades.

19 - Documentao do Projeto
XP foi projetado para usar comunicao face a face humana no lugar de documentao escrita, sempre que possvel. Conversa eficaz mais rpido e mais eficaz do que a documentao escrita. Quando voc reunir as pessoas, elas precisam de menos burocracia.

19

19.1 - Requisitos documentar

XP na sua forma pura tem um cliente (tomador de decises de negcios que sabe o que necessrio e pode decidir as prioridades). XP utiliza discusso verbal para explicar para os programadores que se deseja. Como dissemos desde o projeto de volta C3 no final dos anos 90, essas discusses so normalmente apoiadas por tabelas de valores, planilhas, at mesmo extratos de documentos de requisitos vindo de algum lugar fora do projeto. Os requisitos so documentados de uma forma que muito mais definitiva do que um mero documento de requisitos: eles so documentados na forma de testes automatizados que verificar os resultados da utilizao do software. Combinamos um foco na comunicao verbal com testes automatizados para comunicar os requisitos. O resultado muito menor necessidade de requisitos escritos dentro da equipe Alguns projetos tm uma necessidade de comunicar os requisitos fora da equipe. Esta necessidade no abordada no processo XP Se h uma necessidade de negcios para um documento, o cliente deve solicitar o documento da mesma forma que ela iria solicitar um recurso: com um carto de histria. A equipe ir estimar o custo do documento, e o cliente pode program-lo em qualquer iterao ela deseja.

19.2 - Documentao de Design

Como muitos outros mtodos que remontam incremental, na medida do mtodo de Boehm Spiral, XP cresce o projeto em vez de sintetiz-la. Mais uma vez, porque no XP os programadores esto todos juntos, no h necessidade de passar muito papel e para trs. O sistema construdo em duas semanas de iteraes, e os recursos so normalmente construdos em questo de dias. Em tal ambiente, artefatos de design so geralmente efmeras. A equipe pode tirar algumas UML em um quadro branco ou um tablet, ento sentar-se para construir o recurso. comum para as equipes de XP para ter algumas fotos do design do sistema est na parede por perodos prolongados. Observo que estes parecem servir mais como decorao do que como documentao: as pessoas no olhar para eles com muita 20

freqncia. Eles perguntam uns aos outros, ou programa de par com algum que sabe a resposta. Por que eles fazem isso em vez de olhar as fotos na parede? Eu acredito que porque a comunicao verbal e trabalho de programao par melhor. Mas eu no tenho nenhuma prova - a nica experincia. XP ensinam que se a equipe precisa de um documento, seja ele um desenho, uma tabela, ou palavras em uma linha, elas devero produzir o documento. Tambm ensinamos que se voc produzir um documento e no us-lo, que poderia muito bem ser um indcio de que voc no precisa dele, afinal. Quando hora de entregar o software, seja para as pessoas de manuteno ou para usurios (talvez os programadores que iro utilizar o software para construir outras coisas, ou outros tipos de usurios finais), ento claro que voc precisa para construir a documentao adequada para ir com -lo. No caso de usurios, eu acho que isso seria como qualquer outro tipo de documentao do usurio. No caso dos programadores de manuteno, que normalmente sugerem um pequeno documento descrevendo a arquitetura do sistema ou metfora (talvez com alguns diagramas UML), os conceitoschave, as classes importantes, e assim por diante. Isto deve, sugerimos, ser pensado como uma introduo ao sistema, um ndice alto nvel se quiser.

19.3 - Documentando Cdigo

XP tem foco muito alta no desenvolvimento incremental. O ciclo de desenvolvimento comear com design simples, comunicada atravs de Pair Programming, apoiada por testes de unidade extensa, e evoluiu atravs Refactoring. Para que isso funcione, deve ser possvel refatorar o cdigo: o cdigo deve ser muito limpo e muito claro. Existem regras (ver em outro lugar uma discusso das regras da simplicidade relativa reutilizao) que ajudam programadores produzir cdigo claro. Em essncia, se h uma idia na nossa cabea quando escrevemos o cdigo, exigimos a ns mesmos para expressar essa idia diretamente no cdigo. Ns tratamos a necessidade de comentrios como "cdigo cheiros", sugerindo que o cdigo precisa ser melhorado, porque no clara o suficiente para ficar sozinho. Nossa primeira ao melhorar o cdigo para ser mais claro. Tudo o que no pode esclarecer, no cdigo, para depois comentar.

21

Testes de unidade so tambm a documentao. Os testes de unidade mostram como criar os objetos, como exercer os objetos, e que os objetos vo fazer. Esta documentao, como os testes de aceitao pertencentes ao cliente, tem a vantagem de que executvel. Os testes no dizem o que ns pensamos que o cdigo faz: eles mostram o que o cdigo realmente faz. Dentro da equipe, este tipicamente cdigo de documentao suficiente. Fora da equipe, de forma semelhante s sees acima, voc pode precisar de mais. Novamente, isto seria mais provvel em algum momento em que o cdigo deve ser transmitida para outra pessoa. Naquele tempo, se um documento necessrio, sugerimos que deveria ser escrita.

20 - Manuais
A melhor maneira de fazer manuais , provavelmente, ter os escritores trabalham lado a lado com os programadores, como parte da equipe.

21 - Outra documentao
Como XP intencionalmente uma metodologia mnima, no seguimos o caminho RUP (um caminho honrado, apenas um diferente) de listar todos os documentos que voc pode querer, a partir da qual voc seleciona aqueles que considerem adequado. Em vez disso, XP coloca as pessoas que esto interessados no projeto juntos, em um ambiente de feedback rpido. Algumas pessoas argumentam que isso arriscado, que as equipas "no se pode confiar" para descobrir o que necessrio. Ns achamos que em equipas fato de que configurar ciclos de feedback rpido aprender rapidamente e fazer muito bem.

22