Artigos Engenharia de Software Trabalhando com requisitos ágeis

Requisitos Ágeis: O desenvolvimento de projetos de software continua passando por adaptações significativas. Nos últimos anos tem-se observado ao crescimento da aplicação de conceitos de agilidade em atividades do desenvolvimento. Talvez o principal objetivo desses conceitos possa ser resumido no fato de entregar rapidamente as necessidades de maior valor agregado para o cliente. Para isso, o paradigma ágil foca naquilo que é essencial no desenvolvimento do projeto, evitando assim o uso muitas vezes excessivo de documento durante o projeto.

O Behaviour-Driven Development (Desenvolvimento Guiado por Comportamento) tem por objetivo ajudar o desenvolvimento na entrega priorizada, com valor de negócio verificável, fornecendo um vocabulário comum que abrange as áreas de negócio e de tecnologia. Reuni ideias do Test-Driven Development (o qual auxilia o desenvolvedor a criar código de alta qualidade, por meio de testes de unidade escritos antes da implementação do código), Acceptance Test Driven Planning (escrever testes durante a reunião de planejamento da iteração) e Domain-Driven Design (DDD).

O test-driven development se refere a uma técnica de desenvolvimento de software que se baseia em ciclos curtos de desenvolvimento onde para cada ciclo o desenvolvedor escreve um caso de teste automatizado. Feito isso, o código da funcionalidade é elaborado e é apenas aprovado quando passar com sucesso no caso de teste definido anteriormente. Normalmente, um ciclo de desenvolvimento utilizando o TDD considera as seguintes atividades: definir um teste, executar os testes, escrever o código, executar novamente os testes, refatorar o código e repetir o processo até que todo código seja aprovado pelos casos de teste escritos.

Neste contexto, este artigo retrata a forma de documentar requisitos com foco em testes de aceitação e com uma linguagem comum entre especialistas de domínio e equipe de desenvolvimento. A abordagem utilizada é baseada em integração entre o Behaviour-Driven Development e o Scrum. Este último define uma maneira simples e repetível de gestão do trabalho que pode ser utilizada para o desenvolvimento de novos projetos ou produtos.

Em que situação o tema útil: Para quem tem como objetivo trabalhar com os requisitos em um ambiente ágil, com a documentação na medida certa para cada fase do processo de desenvolvimento de software, com foco na modelagem colaborativa.

Eric Evans, em seu livro Domain-Driven Design, destaca que muitas coisas podem fazer um projeto perder seu rumo: a burocracia, objetivos pouco claros e a falta de recursos, para citar alguns. Mas é a abordagem dada ao projeto que, em grande parte, determina até que ponto os softwares podem se tornar complexos. Quando a complexidade foge do controle, os desenvolvedores já não podem entender o software bem o suficiente para alterá-lo ou expandi-lo com facilidade e segurança.

Cada software está relacionado a alguma atividade ou interesse do seu usuário. Essa área de interesse do usuário é o domínio do software. Os domínios dos softwares geralmente têm pouco a ver com computadores. Por isso, para criar softwares que tenham valor para as atividades desempenhadas pelos usuários, a equipe de desenvolvimento deve trazer consigo um conjunto de conhecimentos relacionados a essas atividades. Mas a quantidade de conhecimento necessária pode ser estarrecedora. O volume e a complexidade de informação podem ser imensos. Modelos são ferramentas para atacar essa sobrecarga. Um modelo é uma forma de conhecimento seletivamente simplificada e conscientemente estruturada. Um modelo adequado faz com que as informações tenham sentido e se concentra em um problema.

Outro aspecto relevante é a linguagem utilizada. Especialistas de um domínio possuem um entendimento limitado do vocabulário técnico usado no desenvolvimento. Já os desenvolvedores, por outro lado, podem entender e discutir o sistema em termos descritivos e funcionais, desprovidos do significado transmitido pela linguagem dos especialistas.

Em meio a essa divisão linguística, os especialistas de um domínio descrevem vagamente o que querem. Os desenvolvedores, lutando para entender um domínio novo para eles, entendem tudo vagamente.

Por este motivo, um processo sem uma linguagem comum, faz com que desenvolvedores tenham que traduzir para os especialistas do domínio. Esses especialistas traduzem entre cada desenvolvedor e também com outros especialistas do domínio. Até mesmo os desenvolvedores traduzem uns para os outros. A tradução confunde os conceitos do modelo, o que leva a uma refatoração destrutiva do código.

O custo de toda a tradução, além do risco de entendimento errado, é simplesmente muito alto. Por este motivo, um projeto precisa de uma linguagem em comum. Essa linguagem deve ser baseada no modelo e deve ser usada entre os desenvolvedores para descrever não só artefatos do sistema, mas tarefas e funcionalidades.

Existem maneiras sistemáticas de pensar que podem ser empregadas pelos desenvolvedores na busca por novas visões e pela geração de modelos eficazes. Uma destas maneiras é o Behaviour-Driven Development (BDD) – Desenvolvimento Guiado por Comportamento –, que tem por objetivo ajudar o desenvolvimento na entrega priorizada, com valor de negócio verificável, fornecendo um vocabulário comum, ou linguagem ubíqua, que abrange a área de negócio e a área de tecnologia. Reunindo ideias do Test-Driven Development (TDD), do Acceptance Test Driven Planning (ATDP) e do Domain-Driven Design (DDD) em um todo integrado, tornando a relação entre estas duas abordagens mais evidentes.

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