ATDD na Prática - Revista Engenharia de Software Magazine 55

A engenharia de software vem passando por mudanças nos últimos anos. No início dos anos 70, tivemos o primeiro modelo de desenvolvimento de sistemas que foi o modelo clássico, mais conhecido como cascata, que é inspirado nos modelos das atividades da engenharia convencional e conhecido por uma abordagem “top-down” em que as atividades do processo de desenvolvimento tem como entrada o fim do processo anterior. Foi o principal modelo utilizado para construção de sistemas grandes por anos e passou a ser criticado por ser linear, rígido e monolítico (sem participação de usuários e clientes, somente ter o software implementado e entregue). Esse método de desenvolvimento acabava sendo falho pelo simples fato de que requisitos sofrem mudanças com o tempo. Muitas vezes aquilo que foi levantado inicialmente já não condiz com a realidade do negócio ao final de todo o processo de desenvolvimento, fazendo com que os sistemas implementados já viessem desatualizados.

Para sanar as necessidades não supridas pelo modelo cascata, nasceu a metodologia RUP (Rational Unified Process), que é um produto/processo iterativo, incremental e customizável de Engenharia de Software pertencente à IBM desde 2003. O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquitetura e iteração. Os casos de uso envolvem várias características por todo processo de concepção de um sistema, como, regras de negócio, requisitos não-funcionais dentre outros. Casos de uso são documentos e podem ter diferentes aplicações ao longo do processo de desenvolvimento e manutenção de software, podendo ser úteis em diferentes contextos.

O RUP ajudou a engenharia de software, porém começou a se deparar com um problema. As pessoas passavam meses fazendo páginas e mais páginas de documentação e entregam para desenvolvedores que precisavam ler tudo, interpretar os textos e traduzir tudo para código. Ocorriam problemas de interpretação e geralmente nem tudo era lido antes de começar o desenvolvimento. Depois vinha a frase conhecida do cliente “mas não era isso que eu queria”. Como é difícil manter a documentação pois os requisitos mudam, muitas vezes, o cliente descobre o que realmente queria só depois de começar a usar o software, gerando assim retrabalhos. Esses documentos, normalmente chamados de contrato, serão o alicerce de discussões entre clientes e prestadores e, muitas vezes se encontram tão desatualizadas que os casos de uso passam a ser referências para acordos por e-mail ou qualquer outra forma de comunicação entre analistas de requisitos e clientes.

O RUP é um framework e nada impede do RUP ser customizado para ser uma metodologia ágil. É fundamental para qualquer profissional envolvido em um desenvolvimento de sistema a presença de documentação, porém para o usuário final o mais importante é um software funcionando e atendendo as suas necessidades do que o detalhamento de todos os escopos em um documento. Melhor ainda se a documentação for executável para garantir que esteja refletida no código. Por esse motivo surgiu o Manifesto Ágil dando origem às metodologias ágeis e consequentemente ao Scrum.

O manifesto ágil foi criado por 17 pessoas que trabalhavam em um projeto nos EUA, entre eles Martin Fowler e Kent Beck, tem como principais valores:

· Indivíduos e interações mais que processos e ferramentas;

· Software em funcionamento mais que documentação abrangente;

· Colaboração com o cliente mais que negociação de contratos;