Como “especificar” um projeto usando XP?

Tivemos que enfrentar um grande problema na atual fase do projeto. Esse problema veio do fato desse ser um projeto de formatura.

Normalmente disciplinas de projeto de formatura baseiam suas avaliações fortemente no acompanhamento das documentações desenvolvidas pelos grupos. O problema é que isso é incompatível com o uso das metodologias agéis de desenvolvimento de software. Essas metodologias preferem obter um software funcionando a ter uma documentação extensa sobre o sistema.

Nesse mês, teríamos que entregar a especificação do nosso projeto para a avaliação final da disciplina. Nosso problema era como fazer uma “especificação ágil”? Coloco entre aspas porque qualquer agilista me mataria ao me ouvir falar em especificação de software…

Nossa primeira atitude foi procurar na bibliografia existente sobre o assunto alguma resposta para esse grande dilema. Achamos bons artigos com relatos sobre o uso de metodologias agéis em projetos de formatura. Porém, apesar de úteis para nosso projeto, não resolviam a nossa questão inicial, pois eram relatos de professores que decidiram introduzir o XP nas disciplinas de projeto de formatura. Inclusive, em um desses artigos, o autor comenta que teve que alterar o critério de avaliação da disciplina de modo a avaliar coerentemente o andamento dos projetos, já que não havia mais uma documentação para ser avaliada.

O problema no nosso caso é que não são os professores que querem introduzir o XP no projeto de formatura e sim os alunos de um projeto em específico que querem usá-lo, e que sabem que o critério de avaliação leva em conta principalmente a documentação produzida.

Já que a bibliografia não nos ajudou a resolver nosso problema, então decidimos apelar para algum professor especialista na área. Porém, na Escola Politécnica não há nenhum professor da área de Engenharia de Software que trabalhe com metodologias agéis, todos trabalham com RUP. Enfim, entramos em contato com o professor Fabio Kon do IME que é especialista na área.

Foi relatado que eles já haviam tentado em uma disciplina de Engenharia de Software (na qual estavam usando XP como metodologia de desenvolvimento) gerar também documentação e o resultado foi um fracasso.  O que eles fizeram foi criar um adaptador entre o professor e o time. O professor explicava o que queria (diagramas, relatórios e etc) e o time transforma em cartões e tentava não só gerar documentos, mas também gerar código junto. Isso não deu certo, porque no final, a sequência de coisas era muito mais parecida com cascata do que com ágil, e para manter os documentos atualizados a sobrecarga era grande.

Percebemos que estávamos tentando unir dois mundos que pareciam não se conversar muito bem. Como não achamos respostas na bibliografia e nem com especialistas percebemos que nós mesmos teríamos que definir o que seria o nosso documento de especificação de acordo com o “bom senso”.

Tínhamos duas alternativas. A primeira era usar a documentação usada pelo RUP com seu levantamento de requisitos, modelo de casos de uso, modelo de classes e de seqüência, modelo de banco de dados, arquitetura de software e plano de testes. Se usássemos essa documentação estaríamos fadados aos problemas que o professor do IME nos havia dito, sendo que um de nossos principais objetivos do projeto de formatura não seria atingido (explorar o XP para o desenvolvimento de um projeto de formatura).

A segunda alternativa era criar uma especificação mais leve e geral que não nos amarrasse e em que fosse possível que os requisitos mudassem sem que criasse uma grande sobrecarga para alterar toda a documentação feita. E foi isso que decidimos fazer. A nossa especificação foi definida como contendo as seguintes seções:

• Compilação das histórias iniciais levantadas através do jogo do planejamento com o cliente;
• Definição da 1a. iteração do sistema (quais dessas histórias seriam as primeiras a serem implementadas);
• Tecnologias a serem utilizadas e
• Arquitetura do software (mostrando seus módulos principais).

Com essa especificação a idéia não é fechar os requisitos para que estes não mudem mais, mas sim dar uma idéia melhor do que é a proposta do projeto. Por isso, colocamos as histórias iniciais, o que não quer dizer que não haja outras histórias que possam ser descobertas ao longo da implementação.

Acho até que resolvemos bem o dilema em que nos encontrávamos… Se alguém quiser ver a “especificação de software”, basta acessar aqui.