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."

[...] continue lendo...

Trabalhando com requisitos �geis

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.

Artigos relacionados