Exorcisando o RUP II - Executáveis e Iterações

As vezes, quando conhecemos algo, esquecemos de repetir as coisas básicas sobre ele porque são óbvias para nós. Mas nessa semana realizei algo que me deixou embasbacado: tem gente que ainda acha que as Iterações à lá RUP não terminam em software funcionando.

Vou ser direto (acho esse o grande defeito do RUP, tem muita coisa lá): segundo o RUP, o objetivo de TODA iteração é obter um release TESTÁVEL do software em desenvolvimento .

Agora vamos aos detalhes:
1. Esse release pode ser interno: a equipe vai realizar testes com ou sem a presença do usuário, ou
2. Externo: o software será efetivamente implantado "em produção" para o usuário começar a usar.
3. Existe uma única exceção para essa regra: as iterações da fase de Concepção podem não resultar em executável testável.

A razão para os itens 1 e 2 é que o RUP é um processo centrado em arquitetura e a arquitetura deve ser VALIDADA o mais cedo possível. Perguntas como: "o software vai suportar as X mil transações por segundo?" ou "nossa idéia vai acomodar a inclusão de novos produtos financeiros ao longo do projeto sem necessidade de 'grandes reformas'?", devem ser respondidas logo no início do projeto (fase de Elaboração). E quando digo que a arquitetura deve ser validada, isso significa software FUNCIONANDO e sendo trucidado por testes de carga e desempenho. Arquitetura não é desenho. Não é modelo. Não é framework. É software! Mas é a parte do software que garante o atendimento dos requisitos não funcionais e portanto não tem valor para o usuário. Por isso não é entregue, mas pode ser mostrado, para que o Stakeholder valide se o tempo de resposta está adequado, por exemplo.

Ao ler o Item 3, os "agileiros" de plantão devem ter pensado "A-ha! Sabia que o RUP não obrigava a produção de um software testável a cada iteração!". Lembrem-se, eu disse (e repito) que a regra é software funcionando ao final de cada Iteração. Porém, o RUP suporta o desenvolvimento do software desde antes da decisão de construi-lo. Imagine uma empresa que está examinando seus processos e decidindo quais devem/podem ser automatizados (por software): neste momento, coisas como ROI (Retorno Sobre Investimento) e Time-to-Market (a janela de tempo até que a primeira versão do software esteja funcionando e comece a dar retorno) devem ser avaliadas para decidir se vale a pena construido. Acontece que a maioria dos projetos começam depois dessa decisão (esse estudo já foi feito) e os requisitos já vão começar a ser definidos. Pois bem, neste caso não tem exceção: a iteração só termina com software funcionando sendo testado ao final de cada iteração.

Muita gente me pergunta: mas e se não terminar assim? A resposta é simples: então a iteração não terminou. "Ah! Mas segundo o cronograma, terminou." Neste caso você só está se enganando, porque a Iteração só termina com software funcionando sendo testado.

E é batendo o resultado dos testes contra os requisitos que o gerente do projeto vai aferir progresso e qualidade. Não olhando a pilha de documentos crescer. Nem olhando a percentagem da tarefa no Gantt Chart. Esse é um bom tópico para outro post.

É isso. Espero que não demore tanto pra falar mais (caso estejam gostando, comentem pois isso é um baita estimulo!)

Forte abraço!