Trabalhando com requisitos ágeis

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.