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

Artigo do tipo Teórico
Recursos especiais neste artigo:
Conteúdo sobre Agilidade.
ATDD na Prática
Este artigo aborda o desenvolvimento de software guiado por critérios de aceitação. Sabemos que as estórias dos usuários são necessidades do cliente e o que o mesmo espera do sistema para atender as suas expectativas. Para que possamos finalizar uma estória temos requisitos mínimos a cumprir e podemos ter nosso desenvolvimento baseado nesses requisitos, que no fundo são seus critérios de aceitação.


Em que situação o tema é útil
Descrever bem uma estória do usuário colocando os critérios de aceitação para finalizar a mesma e em cima disso construir seus testes automatizados pode ser uma boa prática para a qualidade do seu software e a integração contínua do seu projeto. O conteúdo apresentado no artigo foca no valor do que está sendo gerado no seu projeto e procura atingir ao objetivo final que é se ter um software de qualidade e atingindo aos objetivos do usuário final.

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.

...
Quer ler esse conteúdo completo? Tenha acesso completo