XP1: Um Processo de Desenvolvimento

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

Versão 1.7, 21/03/2007: Adaptação e complementação do processo com ênfase em papel do cliente (uso de proxy do cliente na equipe), atividades de documentação e cálculo da estimativa de tempo para realização de User Stories.

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 (traceability, 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:

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;
Descrever os requisitos não funcionais do software;
Definir o plano de release de software;
Descrever os testes de aceitação para cada User Story;
Escolher User Stories para cada iteração;

Caso o cliente não esteja sempre disponível (pode não estar na UFCG, por exemplo), uma pessoa da equipe assumirá este papel durante todo o projeto, sendo um proxy do cliente na equipe. Durante as reuniões de acompanhamento ele deve apresentar a visão do cliente. Para isso, ele deverá interagir continuamente com o cliente a fim de validar:

requisitos levantados e suas prioridades;
plano de release, definindo quais User Stories estarão em cada iteração;
testes de aceitaçã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. A estimativa deve ser feita em “horas ideais”. Essas horas são convertidas para “horas reais” levando em consideração a última velocidade do desenvolvedor ao qual a tarefa foi alocada;

· Escolher Tarefas para desenvolver;

5. Elaborar o esquema lógico dos dados, se necessário;

6. Escrever o código das tarefas, baseado nos Testes de Aceitação automáticos recebidos. A existência de testes automáticos permite que desenvolvedores façam constante refatoramento para manter o código "limpo". Outros tipos de testes (de unidade, por exemplo), podem ser mantidos pelo desenvolvedor mas apenas os testes de aceitação automáticos são obrigatórios (e são de responsabilidade do cliente ou de seu proxy);

7. Executar atividades de integração de tarefas realizadas à base central de código do projeto;

8. Conversar com o cliente antes do desenvolvimento da User Story para detalhar o que deverá sem implementado.

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. Apenas o cliente sabe o que tem menos business value e pode ser cortado.

Gerente de projeto

1. Conduzir as atividades de planejamento;

2. Avaliar riscos e lidar com os riscos descobertos;

3. Manter o progresso do projeto;

4. Auxiliar na coleta de informações auxiliares;

Atividades

Atividades de análise

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. O tempo estimado pode variar de algumas horas a alguns dias; qualquer coisa menor indica que 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 um teste de aceitação automatizado deve existir para verificar que uma User Story foi implementada corretamente. Os testes em si devem ser escritos pelo cliente ou por seu proxy. Desenvolvedores podem escrever testes de unidade, mas não devem escrever testes de aceitação.

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.

Atividades de planejamento

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 dois releases em cada semestre.
Podem-se planejar releases por tempo ou por escopo. O cliente decide. Tipicamente, é mais fácil planejar por escopo, pelo menos no início, pois sem uma funcionalidade mínima, o software não é útil. Porém, se for possível, planeje por tempo. Neste caso, 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 (se for possível, 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 uma semana, sempre (cada equipe poderá alterar a duração, desde que seja mantida fixa). 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. Para tanto, usam-se as horas reais (=horas ideais divididas pela velocidade da equipe). Observe que apenas User Stories para as quais se têm testes de aceitação prontos poderão ser alocadas a uma iteração
Os desenvolvedores devem pedir detalhes ao cliente sobre cada Story e quebrar as User Stories em Tarefas. Observe que User Stories empregam o 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 ideais)
Os desenvolvedores escolhem as tarefas que desejam fazer, estimam o tempo de cada tarefa, até acumularem 1 semana de trabalho cada. Neste momento, a conversão de tempo é feita pela última velocidade de cada desenvolvedor.

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 automáticos (de aceitação e de unidade). Portanto, não descuide disso!

Atividades de testes

Elaboração de Testes de Aceitação: Pelo menos um teste de aceitação deve existir para cada User Story. Eles são especificados pelo cliente e devem conter um texto descritivo da User Story, explicitando o que será testado. O código necessário para fazer os testes passarem é implementado pelos desenvolvedores e os testes são executados automaticamente. Uma User Story só pode ser declarada terminada quando seus testes de aceitação executarem completamente. Para facilitar a vida do desenvolvedor, sugere-se usar uma arquitetura MVC e testar a lógica de negócio usando o EasyAccept.

Atividades de documentação

· Documentação do código fonte: Documentar (código fonte) significa descrever em linguagem natural a funcionalidade do programa para que os desenvolvedores (inclusive você) possam entendê-lo sem ter de (re)ler o código. É realizado para manter o código compreensível e de fácil manutenção, permitindo fácil adaptação de novos programadores à equipe.

· Documentação dos testes de aceitação: Escrever testes de aceitação é uma atividade do cliente, mas que pode ser auxiliada pelos desenvolvedores. Deve existir pelo menos um script automático de teste de aceitação testando a funcionalidade de cada User Story. É fundamental que a descrição da Story esteja descrita no script de teste. Dessa forma, a documentação das funcionalidades do programa segue junto com os testes facilitando atividades de manutenção do programa. O uso de scripts automáticos de testes de aceitação (exemplo: EasyAccept) é fundamental para sucesso deste tipo de atividade.

· Projeto Arquitetural: Produzido durante a fase de análise este documento deve apresentar a organização geral do sistema, descrevendo:

o camada de lógica da aplicação;

o camada de dados persistentes;

o camada de interface;

o entidades externas ao sistema;

Grandes alterações na arquitetura do sistema refletem mudanças neste documento. Mais detalhes sobre este documento ver aqui.

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) ou Subversion (SVN).
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 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 aqui 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, inicia-se com a visão do cliente. Caso o cliente não esteja presente, o proxy do cliente na equipe deve ter a visão cliente;
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:

Descrição do risco

Data em que foi identificado

Gravidade (baixo, médio, alto)

Ordem

(1 = pior risco)

Ordem semana passada

Número de semanas na lista

Responsável por fazer o risco sumir

Observações

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 do número (e %) de User Stories realizadas versus tempo (onde 100% é tudo que é planejado para o próximo release)
Gráfico do 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.
Outras métricas interessantes poderão ser definidas pelo gerente de projeto.

Quando...

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

Tipo de Atividade	Atividade	Quando realizar
Análise	Escrita de User Stories	No início do projeto, e sempre que o cliente pensar em novas stories
Análise	Levantamento de requisitos não funcionais	No início do projeto, em paralelo com o levantamento de User Stories
Planejamento	Planejamento de releases	Logo depois que o projeto arquitetural estiver pronto
Planejamento	Planejamento de iteração	Iterações individuais são planejadas em detalhe imediatamente antes do início da iteração e não antecipadamente. Há uma iteração a cada semana.
Projeto	Projeto arquitetural	Imediatamente após o levantamento de User Stories e requisitos não funcionais
	Projeto do esquema lógico dos dados	No início de um release, planeja-se o modelo de dados para todas as User Stories do release. Mudanças poderão ocorrer durante iterações.
	Refatoramento constante	Ao longo das iterações.
Testes	Elaboração de Testes de Aceitação	O cliente (ou o proxy servindo de analista) deve se antecipar e ter testes de aceitação prontos o quanto antes. Os testes de aceitação de uma User Story devem necessariamente estar prontos para que a User Story seja alocada.
Documentação	Documentação do código fonte	Realizada durante a implementação do código. Também é realizada nas tarefas de refatoramento.
	Documentação dos testes de aceitação	Durante a escrita dos testes de aceitação. O cliente escreve um texto descritivo detalhado da User Story junto com seu teste de aceitação.
	Projeto Arquitetural	Imediatamente após o levantamento de User Stories e requisitos não funcionais. Também deve ser realizado após grandes alterações arquiteturais no sistema.
Integração	Iniciar controle de versão	Na criação de qualquer documento, arquivo, etc. que necessite estar sob controle de versão.
	Realizar check-out	No início de uma tarefa. Também é feito no final de uma tarefa para realizar a integração (operação de update).
	Realizar check-in	No final de uma tarefa.
Gerência	Gerenciar riscos	Todo dia, em papos informais no corredor. Também é feito na reunião semanal de acompanhamento.
	Manter o progresso	A coleta de informação para o Big Chart deve ser feita pelo menos semanalmente, mais freqüentemente se a coleta for automática.
	Publicação	A publicação de resultados de acompanhamento (tabela de riscos, Big Chart) deve ser feita pelo menos 1 vez por semana Big Chart: antes da reunião de acompanhamento Tabela de riscos: depois da reunião de acompanhamento Plano de releases: sempre que houver mudança

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. Neste caso uma pessoa da equipe (o proxy do cliente) assumirá este papel durante todo o projeto, sendo responsável por todas as atividades do cliente. Para isso, ele deverá interagir continuamente com o cliente a fim de validar:

requisitos levantados com suas prioridades;
plano de releases, definindo quais User Stories estarão em cada iteração;
testes de aceitação;

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árias 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, 2 horas sendo um bom tempo limite. Ela sempre deve ser realizada antes do planejamento da iteração. São 4 etapas na reunião:

A reunião inicia com a visão do cliente. Caso o cliente não esteja presente, seu proxy na equipe deverá apresentar a visão do cliente. Para isso, uma reunião com o cliente deverá ter sido realizada antes da reunião de acompanhamento.
Planejamento de releases e Avaliação de riscos: cada membro da equipe relata a existência ou não de riscos de não cumprir o prometido.
Discussão do progresso do projeto (usando o Big Chart).
Discussão do plano de releases, para posicionar a equipe sobre a situação global do projeto.
Resumir a situação global do projeto: um nível de risco global (baixo/médio/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;

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)

Muitas coisas podem levar ao furo de estimativas iniciais de tempo de realização de tarefas, por exemplo: tarefa desconhecida, curva de aprendizagem mais acentuada do que o esperado, feriados e férias esquecidos, viagens, tarefas prioritárias que “pintam” (ex. tirar bugs), treinamento esquecido, reuniões, tarefas "burocráticas" como check-in/check-out de código na ferramenta de controle de versão, etc., integração mais difícil do que se pensava, etc.

Em vez de se preocupar com tudo isso, usamos uma técnica mais simples. As tarefas são estimativas em horas-ideais como se o mundo não fosse cruel J. No final de uma iteração, calculamos a velocidade de cada desenvolvedor (horas reais/horas ideais). Esta velocidade é usada para estimar quantas horas reais serão utilizadas para as tarefas cujas horas ideais estimadas conhecemos.

Contudo, não faz mal incluir um buffer de contingência (digamos 50%) em cada atividade realmente nova (atividades com conteúdo tecnológico novo e aparentemente complexo).

É importante observar que uma velocidade mais baixa não significa que um desenvolvedor não esteja trabalhando bem; significa apenas que a hora ideal dele(a) é diferente da hora real. Se este desenvolvedor mantiver consistência nas estimativas (a velocidade não altera muito), então o planejamento funcionará muito bem!

Produção dos 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 artefatos, numa tentativa de minimizar esforços de sincronização. Os artefatos de XP1 são:

Artefatos sob responsabilidade do cliente:

User Stories;
Requisitos não funcionais;
Testes de aceitação com descrição da User Story;
O plano de releases (cronograma);

Artefatos de desenvolvimento:

O projeto arquitetural;
Código com sua documentação;
Testes de unidade automáticos;

Artefatos de gerência (isso é guardado como artefatos permanentes para adquirir informação histórica e ajudar a fazer relatórios quando necessários):

Os planos de iteração;
Tabela de risco;
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 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.

Como manter User Stories

Uma sugestão:

User Story	4
Título	Gerar carta
Business Value	Alto (ou prioridade: 0, 1, 2, ...)
Status	Concluída
Descrição	Um usuário seleciona um cliente para o qual deseja enviar uma carta e um gabarito que define o formato da carta. O Jato produz uma carta para cada cliente, usando a informação do gabarito para gera a carta, substituindo a informação "plugável" (chamada tag) que estiver no gabarito pela informação relacionada ao cliente. Há informação plugável não relacionada ao cliente, a data de hoje, por exemplo. O usuário recebe uma visão da expansão da carta para cada cliente para verificação.
Observações	Embora tenhamos que eventualmente gerar cartas em formatos mais complexos como HTML ou PDF, nessa User Story, basta usar texto simples.
Dependências	1,2
Tempo ideal estimado	12 hrs
Tempo Real consumido	21 hrs

Nessa tabela, o business value pode ser "alto, médio, baixo". As dependências indicam os User Stories que deveriam estar prontas antes de atacar essa User Story. Tempo ideal estimado serve para o cliente ter uma idéia do esforço necessário para realizar a User Story. O tempo real, é o tempo gasto para a realização da User Story e serve principalmente para cálculo da velocidade do desenvolvedor.

Note que a informação acima poderá ser mantida em HTML, usando uma ferramenta como Xplanner, etc.

Como fazer um plano de release

Obtenha as User Stories do cliente;
Estime o tempo de desenvolvimento de cada User Story;
O cliente prioriza as User Stories em função de quanto ele quer cada uma (seu business value) e quanto tempo cada uma vai levar;
Com as User Stories priorizadas, o cliente "passa a faca" onde ele quer um release. Isso pode ser feito por tempo fixo no release ou pelo escopo desejado no release;
O plano de release é simplesmente essa lista ordenada de User Stories, com as marcas onde cada release termina;

Aqui está um plano de releases típico:

Plano de Releases
Observações gerais (isso existe mais para ajudar o professor a corrigir o plano) Time com 4 desenvolvedores 88 horas reais disponíveis por iteração (2 semanas * (12+12+12+8)) Horas reais são usadas nesse plano. Usamos velocidade de 75%. Portanto, 66 horas de horas estimadas serão alocadas em cada iteração
Release 1
Data inicial: 17/05/2004 Data final: 28/06/2004 Número de iterações: 3
User Story	Título	Prioridade	Número de horas
66	Tamanho janela	11	8
141	Exibição de vários gráficos de um objeto	9	16
151	Melhoras na interface gráfica - gráficos/zoom	10	8
155	Saúde de host e respectivo plugin	5	4
159	Calculador de SLA	1	24
160	Saúde de host para windows 2000	6	16
79	Dashboard de SLA	4	30
80	SLA com histórico de falhas	7	8
163	Calculador de Business Metrics	3	40
165	Empacotar o BL	8	24
166	Saúde de componentes	2	20
Total			198
Release 2
etc...
Total			198

Se você usar pair programming, cuidado com as estimativas de horas: duas pessoas estão envolvidas e o número de horas disponíveis é menor.

Inicialmente, uma velocidade chutada pode ser usada para fazer o plano de releases (digamos 50% ou o valor “conhecido” para a equipe em projetos passados).

Como fazer um plano de iteração

Senta com o cliente e priorize User Stories, escolhendo as próximas a fazer na iteração;
Divida cada User Story em tarefas;
Estime o tempo de cada tarefa (horas ideais);
Junte tarefas o suficiente para encher o tempo disponível da iteração, levando em conta a última velocidade da equipe.
Para distribuir as tarefas entre desenvolvedores, eles fazem sign-up (cada um escolhe as tarefas que ele quer fazer);
Entre com esses dados na ferramenta de acompanhamento (XPlanner, ...);
Se não usar XPlanner, seu plano de iteração tem que indicar:

User Stories;
Tarefas de cada User Story;
Estimativa de tempo;
A quem foi alocada;
Percentual concluído (com isso, o plano de iteração também serve de acompanhamento de progresso);

Aqui está um plano de iteração típico:

Plano de Iteração
Data inicial: 17/05/2004 Data final: 25/05/2004 Número de User Stories: 3 Desenvolvedores: Anderson, Tiago e Carlos;
User Story 4
Tarefas	Descrição	Desenvolvedor	Número de horas	Concluída
TA 4.1	Página para seleção de clientes	Anderson	2	100%
TA 4.2	Seleção de clientes por critério	Anderson	4	100%
TA 4.3	Apresentação de template	Carlos	8	100%
TA 4.4	Substituição de informações	Tiago	8	70%

User Story 5
Tarefas	Descrição	Desenvolvedor	Número de horas	Concluída
TA 5.1	Calculador de SLA	Anderson	4	100%
TA 5.2	Calculador de Business Metrics	Anderson	6	100%
TA 5.3	Dashboard de SLA	Carlos	8	100%
TA 5.4	SLA com histórico de falhas	Tiago	8	100%

User Story 6
Tarefas	Descrição	Desenvolvedor	Número de horas	Concluída
etc

Como obter requisitos não funcionais

Para obter os requisitos não funcionais devemos investigar cada um dos tópicos listados abaixo:

Tipo de interface desejada
Quem utilizará o produto
Facilidade de uso necessária
Volume de utilização (número de usuários, número de transações, ...)
Hardware e software alvo para o produto
Qualidade/robustez
Tolerância a falha
Desempenho
Segurança
Compatibilidade com outros produtos/versões e necessidades de migração
Necessidades de internacionalização do produto
Necessidades de customização do produto pelo cliente
Suporte
Preço da solução
Documentação necessária
Uso de padrões
Aspectos legais
Integração com outros produtos
Packaging
Requisitos de instalação
Riscos aceitáveis

Exemplos:

Atributo	Detalhes ou condição limite
Tempo de resposta	(Condição limite) Ao registrar um item sendo vendido, a descrição e preço devem aparecer em 2 segundos
Tipo de interface	(Detalhe) Usar formulários para entrada de dados e dialog boxes (Detalhe) Maximizar a facilidade de uso via teclado e não via mouse
Tolerância a falhas	(Condição limite) Deve fazer log dos pagamentos autorizados via cartão de crédito em 24 horas, mesmo com falhas de energia ou de dispositivo
Plataformas operacionais	(Detalhe) Microsoft Windows 95, Windows, 98, Windows NT e Windows 2000

Como fazer um projeto arquitetural

Para construir um projeto arquitetural devemos responder as seguintes perguntas:

Sobre entidades externas ao sistema

Quais sistemas externos devem ser acessados?
Como serão acessados?
Há integração com o legado a ser feita? Como?

Determinação de oportunidades para o reuso de software

Há interesse/conveniência/tempo em aproveitar tais oportunidades?
Como isso pode ser feito?

Com componentes?
Construindo um framework?

Sobre a organização geral do sistema

O sistema é centralizado ou distribuído?
Como modularizar em subsistemas?
Como minimizar acoplamento entre os pedaços?
Lembrando que um sistema pode ser visto como sendo composto de três grandes camadas lógicas...
Tais camadas serão lógicas ou terão existência física separada?
Onde colocar o business logic (como dividir entre as camadas)?
Qual é o nível de acoplamento, freqüência de interações, volumes de dados trocados entre as camadas?
Qual seria a estrutura de comunicação e controle entre os subsistemas (como ligar as camadas)?

Usando o Observer Pattern?
Usando o Model-View-Controller Pattern?

Quais são as interfaces importantes entre os pedaços?

Qual é o formato das mensagens (xml,...)?
Como é feita a comunicação remota? CORBA? RPC? RMI? Message Queue?

A programação será feita com qual paradigma? OO?
Que linguagens e ferramentas serão usadas?

Sobre a camada de interface

O sistema será acessado usando que tipos de clientes?

Browser?
Uso de applet?
Uso de script cliente?

Como fazer a interface gráfica?

Com que ferramentas?
Com que componentes visuais?

Serão desenvolvidos? comprados?

Javascript ou outra linguagem de script do lado cliente será usada?

Que modelo de componentes visuais será usado?

Activex?
Javabeans?

Se a interface usar um browser, como será feita a geração de HTML dinâmico?

Servlets?
JSP?
ASP?

Que ferramentas usar para a formatação de relatórios?
Há packages a desenvolver que poderiam ser comuns a várias partes da interface?

Sobre a camada de lógica da aplicação

Escolha de middleware: qual modelo de componentes de servidor será usado?

.Net?
J2EE/EJB?

Quais são os componentes principais a fazer?
Serão componentes persistentes?
Serão componentes com ou sem estado?
De que forma atender aos requisitos para uso multi usuário?

Soluções para resolver a concorrência

Que APIs serão usadas para acesso a:

Dados persistentes?
Serviço de mail?
Serviço de nomes?

Há packages a desenvolver que poderiam ser comuns a várias partes da lógica da aplicação?
Qual é a organização interna dos modulos executáveis?

Determinar sub-camadas e partições

Quais são as interfaces importantes entre os pedaços?
Onde verificar os business rules?

No SGBD?
No middleware?

Como implementar aspectos de segurança?
Como implementar os requisitos de auditoria?

Sobre a camada de dados persistentes

Quais são as fontes de dados? externas? internas? existentes? novas?
Como acessa-las?
Que estratégia de persistência será usada:

Na memória (com recursos especiais como pilha)?
Em arquivos?
Usando um SGBD?

Qual paradigma de SGBD usar?

Relacional?
O-R?
O-O?

Onde usar stored procedures para implementar os business rules ou garantir a integridade dos dados?
Qual será a estratégia de interação entre a aplicação e os dados?
De que forma atender aos requisitos para uso multiusuário (concorrência)?
Como resolver o impedance mismatch entre a camada de lógica de aplicação e o esquema de persistência?
Para grandes escalas, como oferecer connection pooling?
Como implementar a segurança no SGBD?
Como será feita a população dos bancos de dados?

Sobre requisitos de desempenho

Há necessidade de bolar formas especiais de atender aos requisitos de desempenho?

Como prover escala?
Como prover failover?

O que deve ser produzido?

Quais são os módulos executáveis a produzir?

Executáveis, DLLs, ...

Quais são os arquivos importantes (de configuração, etc.) e seu formato (xml, ...)?
Como será resolvida a instalação do produto?
O que será comprado, feito, modificado?
O que será gerado automaticamente com uma ferramenta especial?

Exemplo: geração de esquema através de ferramentas CASE, ...

Sobre a integração futura

Que interfaces devem ser expostas para facilitar a futura integração de aplicações (Enterprise Application Integration - EAI)?

Pode-se usar uma camada de API para expor a camada de business logic, colocar uma camada de script acima disso e ainda camada(s) de interface para ativar a business logic através de scripts.
Vantagens:

Fácil criação de macros e outras formas de automação
Fácil criação de testes de regressão
Clara separação de business logic da interface para o usuário

Como será feita a exposição?

Com XML?
Através de uma API?

Perguntas adicionais

Que ferramentas de desenvovimento serão geradas?
Como será o atendimento a outros requisitos (custo, mobilidade, uso de padrões, etc.)
Há considerações especiais de administração a levar em conta?

Como será a troca de versões?
Como será a distribuição do software?

Via Internet/Intranet?
Via mídia?

Pergunta final

Você já verificou que a arquitetura bolada pode atender a todos os requisitos levantados?

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.
Se puder usar Pair Programming, será melhor, pois facilita a comunicação. Pair Programming estressa cooperação e treinamento em vez de crítica.

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

Já que existe posse coletiva de código, as pessoas estarão olhando o código umas das outras o tempo todo. Quando refatoramento parece ser necessário, deve ser feito.

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

Projeto arquitetural. Prática introduzida porque estamos convencidos que a turma de XP errou (ou não se explicou bem).
Projeto do esquema lógico de dados. Prática 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.

"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, um glossário pode ser montado, etc. Só não sã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 define 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.

"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 seqüência, e outros diagramas UML (ou diagramas de outro tipo)?"

Primeiro, lembre que ferramentas como Eclipse, 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?"

Normalmente, você usa Eclipse, não usa comandos na mã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