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;

· Responder a mudanças mais que seguir um plano.

O primeiro dos itens acima indica que a ênfase das abordagens ágeis está em uma interação mais efetiva entre os membros da equipe sem que para isso seja necessário um processo formal. Enquanto isso, o terceiro item retrata a necessidade de se ter o cliente o mais próximo possível da equipe de forma que ele perceba os avanças e também entenda as dificuldades enfrentadas pela equipe de desenvolvimento mais claramente. Já o quarto item indica que em abordagens ágeis existe uma predisposição a mudanças em detrimento de um planejamento formal e a longo do projeto.

Quanto ao segundo item, existe nas metodologias ágeis uma clara preocupação em entregar produtos que agreguem valor ao negócio do cliente mais rapidamente ao invés de direcionar muito esforço para atividades de documentação. A partir da próxima seção iremos entender um pouco mais sobre este tópico.