XP1: Um Processo de Desenvolvimento

Jacques P. Sauvé, Airon F. da Silva, Francisco R. de A. Neto, Francisco W. L. Cabral

Versão 1.3, 22/11/2002

Introdução

Este documento descreve um processo de desenvolvimento de software. O processo pretende ser útil para alunos de Projeto em Computação I ou outras pessoas que estejam usando um processo de desenvolvimento pela primeira vez, em ambiente universitário. O processo descrito aqui tem as seguintes características:

• É baseado nas práticas de Extreme Programming (XP), mas com algumas mudanças e simplificações. Cuidado! O processo não é XP, pois só inclui algumas das idéias de XP. Por isso, chamamos o processo de "XP1".
• Pretende abraçar as tarefas imprescindíveis: aquelas que precisam ser feitas em qualquer processo de desenvolvimento de software, por mais simples que seja. XP1 é um processo magro.
• Pretende ser tão simples que as chances de sucesso em aplicá-lo por alunos da disciplina Projeto I sejam muito altas. Portanto, vários aspectos que constam de um processo de software completo estão propositadamente ausentes aqui (tracking, por exemplo). Na disciplina Projeto II, um processo mais completo poderá ser usado.
• Foi especialmente elaborado para levar em consideração características especiais do ambiente universitário em que alunos não trabalham no projeto 40 horas por semana e nem sempre terão muitas horas compartilhadas para realizar o trabalho.

Por ser baseado em XP, este processo é particularmente indicado quando os requisitos funcionais do software a ser desenvolvido não estiverem muito bem definidos, pois permite fazer mudanças a um custo menor.

Um processo de desenvolvimento de software diz "Quem faz o quê, quando e como". É assim que organizamos este documento.

Quem faz ...

Os papeis assumidos por pessoas no processo são os seguintes:

• Cliente
• Desenvolvedor
• Gerente de projeto

O quê ...

Responsabilidades

Os participantes do processo têm as seguintes responsabilidades básicas:

Cliente

Responsável pelas seguintes atividades:

1. Descrever a funcionalidade desejada (ver User Stories), estando disponível para pequenas interrupções a qualquer momento para refinar as Stories e tirar dúvidas que surgirem durante o desenvolvimento
2. Descrever os requisitos não funcionais do software
3. Definir o plano de release de software
4. Descrever os testes de aceitação para cada User Story
5. Escolher User Stories para cada iteração

Em XP1, gente técnica toma decisões técnicas e gente de negócio toma decisões de negócio. Portanto, o cliente não deve fazer o seguinte:

• Ditar em quanto tempo as User Stories devem ser feitas. Apenas os desenvolvedores estimam isso.

Desenvolvedor

Responsável pelas seguintes atividades:

1. Ajudar a levantar User Stories e requisitos não funcionais junto ao cliente
2. Durante a fase de planejamento de releases, elaborar um projeto arquitetural
3. Durante o planejamento de releases, estimar, aproximadamente, o tempo de desenvolvimento de User Stories
4. Durante o planejamento de iteração:

• Dividir as User Stories em Tarefas
• Estimar, com precisão, o tempo de desenvolvimento de Tarefas
• Escolher Tarefas para desenvolver

5. Elaborar o esquema lógico dos dados, se necessário.
6. Escrever o código das tarefas, sempre incluindo Testes de Unidade. A existência de testes de unidade e de aceitação permite que desenvolvedores façam constante refatoramento para manter o código "limpo".
7. Executar atividades de integração de tarefas realizadas à base central de código do projeto.
8. Executar Test Review a pedido do gerente de projeto.
9. Implementar a automação de Testes de Aceitação (alguns desenvolvedores, não necessariamente todos).

Gente técnica toma decisões técnicas e gente de negócio toma decisões de negócio. Portanto, os desenvolvedores não devem fazer o seguinte:

• Inventar "coisas legais" para colocar no software. Quem sabe o que é "legal" é o cliente. Ele(a) decide.
• Decidir em que ordem as User Stories são implementadas. O cliente escolhe isso. Os desenvolvedores podem alertar o cliente quanto a dependências entre User Stories que podem afetar a ordem e podem pedir para colocar User Stories de mais alto risco na frente para "pegar o boi pelos chifres". Neste sentido, XP1 é risk-confronting, como RUP.
• Decidir que funcionalidade cortar quando prazos podem estourar. Quem sabe o que tem menos Business Value e pode ser cortado é o cliente.

Gerente de projeto

1. Conduzir as atividades de planejamento
2. Alocar reviewers de testes
3. Avaliar riscos e lidar com os riscos descobertos
4. Manter o progresso do projeto

Atividades

Atividades de planejamento

• Escrita de User Stories: O levantamento de requisitos funcionais é feito através da escrita de User Stories. User Stories:
• São descritas pelo cliente;
• Devem ter pouco detalhe (digamos até 2 sentenças), o suficiente para que os desenvolvedores possam dar uma estimativa de tempo de desenvolvimento. Detalhes só são obtidos verbalmente pelos desenvolvedores no momento em que uma User Story é implementada.
  • As estimativas de tempos são usadas para o planejamento de releases.
  • O tempo de desenvolvimento de User Stories deve ser estimado pelos desenvolvedores. Uma Story com mais de 3 semanas de duração estimada deve ser quebrada. Se o tempo estimado for menor que alguns dias, o nível de detalhe é grande demais.
• Não se limitam a descrever o que aparece na interface do usuário.
• São instrumentais em escrever testes de aceitação. Pelo menos 1 teste de aceitação automatizado deve existir para verificar que uma User Story foi implementada corretamente.
• Levantamento de requisitos não funcionais: O cliente deve descrever os requisitos não funcionais aplicáveis ao projeto. Exemplos de requisitos não funcionais podem ser vistos aqui. Não há necessidade de elaborar testes de aceitação para requisitos não funcionais.
• Planejamento de releases: Um release é a liberação e instalação do software em ambiente externo à equipe de desenvolvimento. Usuários reais usarão o software. Para planejar a liberação de releases (isto é, planejar o projeto de desenvolvimento como um todo em alto nível):
  • Os desenvolvedores elaboram um projeto arquitetural para o sistema.
  • Os desenvolvedores estimam, aproximadamente, o tempo para cada User Story.
  • As dependências entre User Stories são evidenciadas, quando houver.
  • O cliente sabe que business value é obtido de cada User Story, e é portanto o cliente que decide em que ordem as User Stories serão implementadas, baseando-se, claro, nas estimativas de tempo fornecidas pelos desenvolvedores e nas dependências entre as User Stories.
  • No final do planejamento de releases, tem-se um plano para desenvolver um sistema usável, testável, que ofereça business value, o quanto antes.
  • É preferível fazer muitos pequenos releases. Para alunos das disciplinas Projeto I e II, tentem fazer pelo menos 2 releases em cada semestre.
  • Planeje os releases por tempo e não por escopo. Em outras palavras, determine a data de cada release antecipadamente e depois controle o escopo para ver que Stories vão caber dentro do tempo dado. Motivos para esta forma de controle podem ser vistos aqui.
  • A cada poucas iterações (3-5), é possível que o plano de releases tenha que ser alterado (no escopo, não na data).
  • O plano de releases também é chamado de "cronograma".

• Planejamento de iteração: Em XP1, a iteração é a unidade de planejamento detalhado. Uma iteração dura exatamente 2 semanas, sempre. O tempo é fixo, o escopo do que será feito na iteração é variável. No planejamento de uma iteração, as seguintes atividades são feitas:
  • O cliente deve escolher exatamente que User Stories serão feitas, em que ordem, de forma a preencher o tempo cumulativo disponível dos desenvolvedores.
  • Os desenvolvedores devem pedir detalhes ao cliente sobre cada Story e quebrar as User Stories em Tarefas. Observe que User Stories empregam linguajar do cliente ("Exibir os fregueses que estão devendo dinheiro à empresa e o valor devido"), enquanto Tarefas empregam linguagem de desenvolvimento ("Criar e popular o banco de dados de testes").
  • Tarefas devem ser de curta duração (4 a 20 horas, incluindo buffers de contingência)
  • Os desenvolvedores escolhem as tarefas que desejam fazer, estimam o tempo de cada tarefa, até acumularem 2 semanas de trabalho cada.

Atividades de projeto (design)

• Projeto arquitetural: A arquitetura do sistema é a sua organização em grandes módulos. Detalhes podem ser vistos aqui sobre o projeto arquitetural.
• Projeto do esquema lógico dos dados: Se houver um banco de dados envolvido, o esquema lógico dos dados deve ser elaborado. Essa atividade normal de design detalhado é destacada aqui de forma especial, pois deve ser planejada com cuidado. O motivo é que mudanças no esquema lógico freqüentemente acarretam atividades trabalhosas e demoradas de migração de dados que devem ser evitadas. Portanto, há mais planejamento aqui do que é normalmente o caso para outras atividades de design detalhado. Mudanças certamente serão necessárias ao longo das iterações, mas como o modelo de dados tende a ser mais estável do que requisitos funcionais e código, vale a pena investir aqui.
• Refatoramento constante: Refatorar significa alterar o código de um programa sem alterar sua funcionalidade. É realizado para manter o código limpo e flexível, permitindo implementar nova funcionalidade com mais facilidade. É uma das partes-chave de XP1, junto com testes de unidade e de aceitação. Portanto, não descuide disso!

Atividades de testes

• Elaboração de Testes de Aceitação: Pelo menos 1 teste de aceitação deve existir para cada User Story. Eles são especificados pelo cliente e implementados, com execução automática, pelos desenvolvedores. Uma User Story só pode ser declarada terminada quando seus testes de aceitação executarem completamente.
• Elaboração de Testes de Unidade: Testes de unidade testam classes individuais, ou poucas classes acopladas. Eles são sempre automatizados. Em XP1, testes de unidade são obrigatórios. Eles devem sempre estar executando 100% corretamente.
• Realização de Test Review: Para assegurar a qualidade do código e dos testes escritos, um Test Review deve ser realizado no final de uma tarefa. O review é realizado por um desenvolvedor diferente daquele que desenvolveu o código e os testes. Testes de unidade e de aceitação devem ser verificados. O reviewer tem duas responsabilidades: verificar a execução correta dos testes de unidade e de aceitação, e verificar se os testes são suficientemente fortes e completos. A segunda parte deve ser feita examinando o código dos testes. Caso os testes pareçam fracos ou incompletos, deverão ser fortalecidos pelo desenvolvedor original. Se achar desejável, o reviewer pode aproveitar o momento e realizar um Design Review e Code Review. Porém, apenas o Test Review é obrigatório. Para ser aceita como terminada, uma tarefa deve ter sofrido um Test Review, ter 100% dos testes de aceitação executando corretamente. Os testes de unidade devem sempre estar rodando 100%.

Atividades de integração

Já que equipes diferentes poderão trabalhar em paralelo, há possibilidade de alterarem o mesmo código, resultando em conflitos. Para lidar com a situação, atividades especiais de integração devem ser seguidas.

• Iniciar controle de versão: Todos os artefatos do projeto (incluindo código, scripts, e tudo que for necessário à construção do software a partir do zero) são colocados sob controle de versão usando uma ferramenta tal como Concurrent Versions System (CVS).
• Realizar check-out: No início de uma tarefa, o responsável (ou responsáveis) pela tarefa fazem uma operação de check-out de todo o código do projeto. Esta é a versão mais atualizada que sofreu integração e testes totais. Vários desenvolvedores poderão fazer check-out do código inteiro em paralelo.
• Realizar check-in: No fim da tarefa, o desenvolvedor deve realizar o check-in de sua tarefa. Como vários desenvolvedores estarão fazendo check-out e check-in em paralelo, é possível que algum check-in de outro desenvolvedor tenha sido feito entre seu check-out e seu check-in. Portanto, a possibilidade de conflito existe e deve ser tratada com cuidado, pois é fonte de bugs (chamados bugs de integração). Portanto, ao completar uma tarefa, obtenha novamente a última versão do código e verifique se há conflito com seu código. As ferramentas de controle de versão informam da existência de conflitos. Por exemplo, CVS tem o comando "update" para este fim. Integre as várias versões de código onde existe conflito, até conseguir fazer todos os testes de unidade e aceitação executarem. Finalmente, faça check-in (commit) do resultado.
  • É importante observar que apenas uma integração poderá estar ocorrendo de cada vez. Integrações devem necessariamente ser seqüenciais.
  • Durante a integração, é possível que testes de aceitação que funcionavam anteriormente passem a não funcionar. Como a iteração é de tempo fixo, e como a integração é seqüencial, você não pode demorar muito na integração. Se as coisas complicarem, libere a vez de integrar para outro, e faça a integração "por fora", reiniciando todo o processo quando os testes estiverem passando. Essa demora pode ser indicação de que você precisa integrar mais freqüentemente (1 vez por dia, ou mais).
  • Para minimizar dores de integração, integre com freqüência. Uma vez por dia ou mais é ideal. Daí a importância de ter tanta automação nos testes.

Atividades de gerência

Numa empresa, um gerente de projeto tem muitas atividades que não serão consideradas aqui (gerência de RH, gerência de custos, gerência de aquisições, etc.) Só consideramos as atividades de gerência relacionadas com o acompanhamento do projeto (escopo, tempo, qualidade).

• Gerenciar riscos: Um risco é uma possibilidade de não conseguir cumprir o prometido (o plano de releases). Nesta atividade, o gerente de projeto monta a tabela de riscos, através de pequenas conversas diárias com a equipe e uma reunião semanal de acompanhamento.
  • Na reunião semanal de acompanhamento, avaliam-se os riscos para o projeto
  • A reunião trata dos problemas prioritários que podem impactar uma data prevista no plano de releases
  • O gerente apresenta as áreas de alto risco logo no início da reunião
    • Apresentação em ordem de efeito negativo provável
  • Discussão de soluções
  • Em seguida, novos riscos são levantados junto à equipe
  • Cada problema de médio/alto risco deve ter um dono
  • O problema deve ser acompanhado separadamente com uma tabela de riscos, contendo:

• Se um problema de alto risco permanecer na tabela muito tempo, é sinal de que não está recebendo a atenção devida
  • Outros recursos devem ser mobilizados para remover o problema.
    
• Manter o progresso: Primeiro, para que haja progresso máximo, o gerente de projeto deve se assegurar de que todos os membros da equipe sempre tenham tarefas alocadas para preencher seu tempo. Segundo, o progresso deve ser monitorado. O progresso do projeto é avaliado através de métricas simples publicadas num "Big Chart". É útil publicar o Big Chart em papel numa área física freqüentada pela equipe. As métricas podem ser publicadas instantaneamente em página Web se sua coleta for automática (desejável). Caso a montagem do Big Chart seja realizada manualmente, deve haver atualização pelo menos semanalmente. O Big Chart deve conter as métricas mostradas abaixo, calculadas a partir da última versão integrada do software. É importante que as métricas estejam consistentemente "indo para cima". O progresso do projeto é mantido com o Big Chart mas também através do plano de iteração que deve indicar a tarefa, o responsável, o número de horas previstas, o número de horas usadas até agora e o percentual da tarefa concluída.
  • Métricas do Big Chart
    • Gráfico de % de User Stories realizadas versus tempo (onde 100% é tudo que é planejado para o próximo release)
    • Gráfico de número total de testes de unidade (100% rodando, sempre)
    • Gráfico de número (e %) de testes de aceitação rodando (onde 100% inclui todos os testes de aceitação para o próximo release)
    • Gráfico de número de módulos implementados (classes, páginas HTML/JSP, ...). Um módulo é algo construído por uma pessoa humana.

Quando ...

A tabela abaixo resume quando as atividades deste processo devem ser realizadas.

Outras regras importantes na dimensão "quando"

• No processo XP1, o cliente deve estar "sempre" disponível. Idealmente, o cliente faz parte da equipe de desenvolvimento em tempo integral. Como isso raramente poderá ser o caso em ambiente universitário, é absolutamente imprescindível que o cliente esteja "facilmente" acessível. Os desenvolvedores devem poder tirar uma dúvida com o cliente a qualquer momento. Embora isso possa parecer difícil e chato para o cliente, o processo depende deste fato, já que atividades antecipadas de planejamento detalhado são evitadas em XP1.

Como ...

Já falamos vários coisas sobre o "como" acima. Completamos a informação aqui.

Como realizar uma reunião de acompanhamento

A reunião dura o tempo mínimo, 1 hora sendo um bom tempo limite. São 4 etapas na reunião:

1. Avaliação de riscos: cada membro da equipe relata a existência ou não de riscos de não cumprir o prometido.
2. Discussão do progresso do projeto (usando o Big Chart)
3. Discussão do plano de releases, para posicionar a equipe sobre a situação global do projeto.
4. Resumir a situação global do projeto: um nível de risco global (baixo/medio/alto) é atribuído ao projeto, com respeito ao fim do próximo release
   • Baixo: o risco de afetar as datas, funcionalidade, custo ou qualidade é baixo;
   • Médio: um plano de recuperação deve ser estabelecido
     • Este plano deve ter um dono e vira uma Tarefa
   • Alto: um plano de contingência deve ser preparado e fatores que desencadearão sua ativação devem ser estabelecidos
     • Este plano deve ter um dono e vira uma Tarefa

A cada duas semanas, depois da reunião de acompanhamento, tem uma reunião de planejamento de iteração para a próxima iteração. Iterações iniciam e terminam na reunião de acompanhamento. Essa reunião é obrigatória.

Como fazer estimativas de tempo (cronograma)

Seguem algumas dicas a respeito de estimativas de tempo:

• Você já fez algo semelhante antes? Use o que ocorreu no passado como ajuda para estimar
• Discuta suas estimativas com outras pessoas experientes
• Não planeje em usar horas extras
• Levante os feriados e férias que ocorrerão durante as atividades
• Levante as viagens que ocorrerão durante as atividades
• Especifique a duração em horas de trabalho (fora da universidade, poderá usar dias em vez de horas)
• Lembre que a produtividade de pessoas menos experientes é menor
• Inclua tempo de treinamento para a aquisição de conceitos novos
• Lembre que certas atividades paralelas levam tempo e deverão ser feitas pelas pessoas da equipe (reviews de testes, reuniões de acompanhamento)
• Lembre que certas tarefas "burocráticas" precisam ser feitas (check-in/check-out de código na ferramenta de controle de versão, etc.)
• Inclua tempo de interrupção para suporte pós-venda deste ou de outros produtos
• Inclua um buffer de contingência em cada atividade
  • Sugere-se 20% para atividades normais e 50% ou mais para atividades com conteúdo tecnológico novo e aparentemente complexo.

Artefatos usados no processo

Neste processo, "artefatos" representam informação que deve ser guardada sob controle de versão de forma permanente e em sincronia. XP1 é "light" em termos de artefato, numa tentativa de minimizar esforços de sincronização. Os artefatos de XP1 são:

• Artefatos sob responsabilidade do cliente
  1. User Stories
  2. Requisitos não funcionais
  3. Testes de aceitação
  4. O plano de releases (cronograma)
• Artefatos de desenvolvimento
  1. O projeto arquitetural
  2. Código
  3. Testes de unidade
• Artefatos de gerência (isso é guardado como artefatos permanentes para adquirir informação histórica)
  1. Os planos de iteração
  2. Tabela de risco
  3. Big Chart de progresso

Observe que vários outros tipos de "artefatos" opcionais e descartáveis (que não entram em controle de versão) podem ser usados. Exemplos incluem diagramas de Entidade-Relacionamento e outros modelos conceituais, diagramas UML, etc. Pode-se usar papel ou quadro branco e jogar fora os diagramas quando não são mais necessários.

Frequently Asked Questions

"XP1 não inclui todas as regras e práticas de XP. Por que não?"

• Tem dois motivos: primeiro, tentamos criar um processo absolutamente mínimo, removendo tudo que pudesse sê-lo no sentido de facilitar a adoção do processo. Tentar fazer um aluno adotar um processo com 5 práticas é mais fácil do que fazê-lo adotar um processo com 10 práticas.
• Algumas práticas de XP não se aplicam bem a nosso ambiente. Por exemplo, Pair Programming requer que todo mundo esteja trabalhando sempre no mesmo lugar o tempo todo para poder formar pares. Na maioria das vezes, não é nosso caso. Como Pair Programming é opcional no processo, o Review de Testes foi colocado no seu lugar para não perder de todo os benefícios de Pair Programming.

"Posso usar XP1 com Pair Programming?"

• Sim! Qualquer tarefa individual pode ser feita com Pair Programming.
• A regra básica é: se uma tarefa foi feita completamente com Pair Programming, não faça Test Review nela. Em outras palavras, se alguém programou sozinho em alguma parte de uma tarefa, faça Test Review.
• Se puder usar Pair Programming, será melhor, pois facilita a comunicação. Além do mais, remove o stress de "ver minhas coisas passar por um review". Pair Programming estressa cooperação e treinamento em vez de crítica.

"Por que não tem design review e code review em XP1"

• Sempre vai haver testes a implementar e achamos que test review seja suficiente. A pessoa que faz o review, ao desconfiar da qualidade do que ela está vendo, pode mergulhar mais fundo e fazer um review de design e código.

"Que práticas de XP1 não são XP e por que foram introduzidas?"

• Projeto arquitetural. Introduzida porque estamos convencidos que a turma de XP errou.
• Projeto do esquema lógico de dados. Introduzida como atividade destacada haja vista a dificuldade de alterar esquemas lógicos em bancos de dados populados. Achamos que pensar um pouco mais sobre isso vale a pena.
• Test Review. Introduzida para não perder todos os benefícios de Pair Programming (outra pessoa tem que ver o que cada desenvolvedor faz).

"Cadê atividades de análise deste processo? Cadê o modelo conceitual?"

• Levantar requisitos, entender as User Stories e entender os testes de aceitação é a fase de análise.
• O fato de ter um cliente sempre à mão para conversar e ter User Stories e testes de aceitação descritos elimina parte da necessidade de desenhar um modelo conceitual. Porém, se você achar conveniente, o modelo conceitual sempre pode ser desenhado. Só não é um artefato que entra em controle de versão.

"Posso usar XP1 como processo de desenvolvimento para sempre, mesmo fora da Universidade?"

• A grande maioria das empresas do mundo simplesmente não usa processo algum de desenvolvimento e é por isso que há tanto fracasso em fazer software no mundo. Portanto, como alternativa a usar nada, você pode usar XP1 fora da universidade com grande sucesso. Vá em frente.
• Algumas coisas estão ausente de XP1, por motivos explicados nesta FAQ. Uma versão mais completa (XP2) para uso em equipes mais maduras será desenvolvido oportunamente.

"XP usa algo chamado Progress Velocity que XP1 não usa. O que substitui isso?"

• Buffers de contingência nas estimativas de tempo são o substituto a Progress Velocity. No futuro, vamos avaliar o uso de Progress Velocity. Se for mais eficaz do que buffers de contingência, adotaremos Progress Velocity.

"Por que planejar releases e iterações por tempo e não por escopo?"

• Pergunta muito importante, meu caro!
• Primeiro, temos que dizer que XP recomenda o planejamento por tempo também, embora para nós, tenha a vantagem adicional de se encaixar nas restrições universitárias em que o semestre tem um fim fixo.
• XP (e XP1) acredita em planejamento com tempo fixo porque:
  • É muito mais fácil controlar o botão "escopo" do que controlar o botão "tempo". Então deixe o tempo fixo e controle o que é feito neste tempo.
  • É muito legal você sacar que nunca mais vai atrasar! Você não vai mais ter que sofrer o atrito com seu cliente de atrasar a entrega das coisas. Em vez de atrasar, você vai negociar com seu cliente quanto vai ser entregue na data prometida. A data prometida não muda.
  • Claro que há um pouco de exagero no que falamos acima, porque o plano de release pode sofrer atrasos se a funcionalidade mínima não puder ser entregue. Mas é impressionante ver quantas vezes podemos tirar um pouco de funcionalidade, sem atrasar e ainda satisfazer o cliente!
  • Lendo o que está acima, você pode achar que está havendo engodo. Não! A chave é que o cliente decide que funcionalidade retirar. Como desenvolvedor, nunca faça essa escolha. Deixe o cliente escolher e ele quase sempre vai dar um jeito de retirar algo não essencial e ainda manter a data. Todo mundo fica motivado de ver que atrasos deixam de acontecer. Maravilha.

"O que acontece com design detalhado (design de baixo nível) com diagramas de classes, etc.?"

• Design sempre ocorre. Mas em XP1, não é uma atividade feita antes de codificar com muito planejamento.
• A diferença reside no fato de que fazemos refatoramento em XP1. Portanto, não há necessidade de planejar com muita antecedência com toneladas de diagramas.
• O planejamento ocorre, mas em paralelo com a codificação. Diagramas UML de classes, etc. podem ser usados, mas em quadro branco, em papel, etc. para discutir e não em Rational Rose como artefato permanente.
• Se você planejar seus testes de unidade antes de codificar, verá que, em grande parte, é aí que a atividade de design de baixo nível vai ocorrer.

"O que ocorre se meu cliente exigir diagramas de classes, de sequência, e outros diagramas UML (ou diagramas de outro tipo)?"

• Primeiro, lembre que ferramentas como JBuilder, Rose, etc. podem fazer engenharia reversa e produzir alguns diagramas a partir do código. Portanto, os diagramas podem ser retirados do código no final e entregues ao usuário. Você não é obrigado a mantê-los como artefatos para seu uso, certo?
• Segundo, se certos diagramas não puderem ser gerados com ferramenta reversa, então fazer o diagrama vira uma User Story como qualquer outra!

"Por que XP1 dá tão pouco valor a diagramas UML?"

• Os dois artefatos mais importantes em XP1 são código e testes. Diagramas UML podem ser importantes numa discussão usando um quadro branco mas não são bons artefatos permanentes. O motivo?
  • Diagramas como artefatos precisariam permanecer sincronizados com o código e simplesmente não acreditamos que este esforço seja compensador. Refatorar é a chave de XP1 e para refatorar freqüentemente, o custo do refatoramento deve ser baixo. Portanto, refatoramos apenas o imprescindível: código e testes.

"Em outros processo, ouço falar de Work Breakdown Structure - WBS. Onde está isso em XP1?"

• A lista de User Stories, suas dependências e sua quebra em tarefas (feita no planejamento de iteração) corresponde ao WBS.

"Há lugar para usar Gantt charts com uma ferramenta como Microsoft Project em XP1?"

• Se o WBS e o plano de releases ficarem complicados de manter, claro que pode-se usar Gantt charts para manter o plano de releases.
• Por outro lado, é provável que os projetos das disciplinas Projeto I e Projeto II não necessitem de uma ferramenta dessas.

"Por que não há métricas de produtividade em XP1?"

• De fato XP1 só usa métricas de progresso, não de produtividade. O motivo é de manter as coisas mais simples no início. Pode ser uma boa idéia experimentar com métricas de produtividade em Projeto II. Porém em Projeto I, seria mais uma coisa para olhar, e só desviaria a atenção enquanto o aluno deve estar aprendendo o básico de processos de desenvolvimento. Decidimos portanto não incluir nada de produtividade.

"Quais são os maiores riscos associados a XP1 num ambiente universitário?"

• O maior risco: o cliente não assume seu papel e freia o desenvolvimento, forçando os alunos (desenvolvedores) a tomarem decisões que não deveriam ser deles
• O segundo maior: devido à rotação de Project Manager usada nas disciplinas Projeto I e II, há o risco de ter project managers ruins durante certos períodos.
  

"Como faço para completar minha tarefa se eu dependo de João fazer alterações nas classes sob sua responsabilidade?"

• Em XP1, a posse de código é coletiva. Não existe essa de "classe de João, onde só João mexe". Você vai mexer onde for necessário para terminar sua tarefa. Se você não entender algo numa classe, verifique os testes, converse com os colegas, refatore, mas, no fim das contas, é você que faz a alteração.
• Em outros processos de desenvolvimento, há posse individualizada de código para evitar conflitos e simplificar a integração. Isso deixa o desenvolvimento mais lento e burocrático (você tem que pedir mudanças a classes fora do seu controle e esperar que sejam feitas). Em XP1, resolvemos isso com integração contínua, minimizando os problemas de integração.

"A palavra iteração é empregada no mesmo sentido do processo RUP?"

• Não. Em XP1, uma iteração significa um período fixo em que o planejamento deve ser minucioso. Em RUP, uma iteração é o que XP1 chama de release

"Como faço para usar CVS nas atividades de integração?"

• Não dá para fazer um manual de CVS aqui, mas os comandos básicos são:
  • cvs init
    • para inicilizar seu repositório
  • cvs import
    • para colocar seu projeto sob controle de CVS
  • cvs checkout
    • para obter uma versão do software no início de uma tarefa
  • cvs update
    • para verificar conflitos e iniciar a integração
  • cvs commit
    • para realizar o check-in final

"Como faço para construir o Big Chart automaticamente?"

• Há uma ferramenta que pode ajudar: xp1pm (XP1 Progress Metrics)

"Onde posso obter mais informação sobre XP?"

• http://www.extremeprogramming.org
  • O link explica a filosofia XP e explica bem as regras e práticas
  • Neste site, também há referência aos excelentes livros existentes sobre XP. "Extreme Programming Explained" de Beck vende bem o peixe. "Extreme Programming Installed" e "Extreme Programming in Practice" explicam bem como funciona na prática.
• http://www.xispe.com.br/index.html
• http://www.agilemodeling.com/essays.htm