Desenvolvimento em "Repasses"

Taí, alguém conhece desenvolvimento em espiral? Basicamente é uma idéia velhinha de Engenharia de Software: vc faz um "protótipo" numa iteração e a cada nova iteração vai completando ele cada vez mais. Pena que isso é teoria dez e prática zero. Na prática o pessoal nunca planeja em espiral, é sempre o maldito cascata. E se não acredita em mim, olha para o seu cronograma, se ele tem "repasses" da mesma funcionalidade, vc é um sortudo. O outro problema é que ninguém nunca diz o que um protótipo deve ter ou não em cada versão... Sempre fica um "cada projeto é de um jeito" no ar e ninguém faz nada na prática. Depois de cozinhar um tanto a idéia na cabeça e rever minhas experiências ("Minha vida inteira passou pelos meus olhos... foi muito chato!" - Babs, A Fuga das Galinhas) cheguei ao seguinte esboço:

Tiro inicial (ou Primeira Iteração): "Esqueletão"

O esqueletão é mais para criar algumas partes essencias do sistema, frequentemente elas nem estão conectadas entre si.

Deixe de fora:

• Tratamento de exceções
• Objetos de negócios detalhados. Crie um Objeto de Negócio Genérico, provavelmente encapsulando um Dicionário (Map, Hash, Hashtable, vc entendeu!) e use ele para testar o esqueletão. Alguns campos mais essenciais ao negócio e algumas estruturas básicas já aparecem aqui.
• Preocupações com desempenho e consumo de memória.
• Interface de usuário.
• Se puder, descarte Banco de Dados por enquanto.

Inclua:

• Testes de Unidade

Primeiro Repasse (ou Segunda Iteração): "Carne entre os ossos"

Aqui vc começa a ligar as coisas.

Deixe de fora:

• Tratamento de exceções. Apenas faça uma distinção entre erros de negócio (coisas que o usuário fez errado) e erro de sistema (aqueles que o pobre usuário não tem culpa, como erro de conexão com banco). Siga essa distinção durante todos os outros passos, mas não tente tratar os erros (exceto os mais recuperáveis). O resto, só mande pra cima.
• Preocupações com desempelho e consumo de memória
• Interface de usuário

Inclua:

• Banco de dados.
• Objetos de negócio mais detalhados. Mas não se preocupe muito aqui, sempre antes do final do projeto aparecem mais dados (campos) ou somem outros. A idéia aqui não é ter todos os campos e valores, mas sim ter a ESTRUTURA (ênfase dupla na palavra, vou até repetir: "ESTRUTURA") dos objetos de negócio. Por estrutura eu digo: quem conhece quem, e quem contém quem.
• Testes de aceitação. Só uns rascunhos usando banco de dados.
• Mais testes de unidade.

Segundo Repasse (ou Terceira Iteração): "Vejo algo se mover"

Nesse o sistema já funciona de cabo a rabo, meio toscão, mas funciona.

Deixe de fora:

• Tratamento de exceções
• Preocupações com desempenho e consumo de memória.
• Testes de aceitação. Cuidado aqui. Vc só está adicionando o visual, o teste de aceitação roda "por baixo" dele, não devem aparecer muitos testes novos aqui. A menos que seus testes de aceitação rodem "por cima" da interface (exercitando ela).

Inclua:

• Interface com usuário.
• Um mané testando as telas, ou um designer gente boa.
• Testes de unidade, principalmente de "validadores", que não são exatamente parte da interface do usuário, mas tem o mal hábito de aparecerem quando vc contrói elas.

Okay, pare aqui. Esses passos de 1 a 3 devem ser feitos POR FUNCIONALIDADE. Como assim? Explico. Vc tem um sistema com Cadastro de Usuário, Cadastro de Filme e Locação de Filmes. Isso são FUNCIONALIDADES. Vc primeiro faz os 3 passos para Locação de Filmes, depois faz os mesmos 3 para Cadastro de Usuário e finalmente os mesmos 3 para Cadastro de Filme e assim vai. Por que isso? Por 2 motivos:    Vc vai conseguir mostrar coisas para o seu cliente mais cedo, ele vai ficar feliz    Se a funcionalidade estiver errada, vc vai descobrir logo (pq ou cliente vai ver) e não daqui 6 meses. No jargão de "Engenharia de Software" isso significa:    "Early Delivery"    Diminuição de risco Depois disso vc passa para as próximas etapas, novamente elas são divididas POR FUNCIONALIDADE.

Terceiro Repasse (ou Quarta Iteração): "Minha visão está clareando"

Deixe de fora:

• Tratamento de exceções.
• Preocupações com desempenho e consumo de memória.
• Testes de unidade. Só atualize os que vc precisar. Não devem aparecer muitas funcionalidades novas aqui, se aparecerem, óbvio, inclua testes.
• Testes de aceitação. Idem acima.

Inclua:

• Banco e Interface. Nesse ponto, os campos que vc precisa já devem estar bem defininidos, incluindo aqueles mais obscuros e usados somente por questões informativas (tradução: relatórios, cartas de cobrança).

Quarto Repasse (ou Quinta Iteração): "Toques finais"

Deixe de fora:

• Banco e Interface.
• Preocupações com desempenho e consumo de memória.

Inclua:

• Tratamento de Exceções. Finalmente! Antes vc só arremessava as exceções, agora vc pega elas, apresenta telinhas bonitinhas, manda email pro suporte se explodir erro que não é coisa de usuário, etc e tal.
• Testes de Unidade.
• Testes de Aceitação.

Quinto Repasse (ou Sexta Iteração): "Sorriso da Mona Lisa"

Deixe de fora:

• Banco e Interface.

Inclua:

• PREOCUPAÇÕES COM DESEMPENHO E MEMÓRIA. Primeiro, faça "profiling" para ver ONDE estão os gargalos. Crie testes de unidade e aceitação para demonstrar os gargalos e finalmente corrija-os. Muitas vezes esse repasse nem é necessário.

---

Bom, é isso. Lógico que isso são mais sugestões do que leis. Nem todo desenvolvimento é igual, mas essas são boas "thumb rules" pra se usar. Mas eu vou refinando essa estrutura com o tempo.