Nota prévia: Muito dos conceitos aqui descritos baseiam-se num livro muito interessante escrito por Mike Cohn e editado pela Addisson-Wesley com o título "User Stories Applied - for Agile Software Development". Os conceitos não são originais, mas este livro faz um muito bom trabalho na sua descrição.
Um dos maiores... desafios (a palavra é muito maltratada, mas enfim) do desenvolvimento de software é a especificação de requisitos. É uma tarefa muito complicada devido a múltiplos factores.
Do meu ponto de vista, e na opinião de gente muito mais brilhante do que eu, o maior problema é que é tremendamente difícil, impossível mesmo, para o cliente descrever o que pretende, de for objectiva e não ambígua, apenas com o esforço da imaginação. A linguagem natural é naturalmente (pun intended) ambígua. O cliente, ou um seu representante como um gestor de produto, muda de ideias a meio do percurso, como é natural e desejável. Num ambiente em constante mudança, temos de entrar na onda e não contra ela.
Se a isto juntarmos uma relação contratual entre cliente e fornecedor, baseada na especificação de requisitos de uma coisa tão volátil como o software, temos meio caminho andado para o desastre: uma luta feroz na interpretação de umas folhas de papel. Não é por acaso que as empresas de software não costumam ser demasiado bem vistas...
Bom, mas então não temos solução? Como é que vamos conseguir manter o rumo com tantas nebulosas pelo caminho? Como vamos saber o que temos de construir, como acompanhamos a construção, como estimamos a data de entrega? Para quem conhece a filosofia que eu sigo, a solução provém de algumas práticas das metodologias ágeis, especialmente Extremme Programming.
User Stories
A primeira peça do puzzle são as user stories. Uma história não é mais do que a descrição de uma pequena funcionalidade que o cliente pretende ver desenvolvida no sistema. Estas são a unidade atómica da especificação de requisitos, no sentido em que não é possível partir as user stories em conceitos mais pequenos e é a partir delas que se define todo o planeamento.
Uma user story é constituída por:
- Um pequena descrição da história, utilizada como lembrete e para as actividades de planeamento.
- Conversações sobre a história, entre clientes e programadores, de modo a detalhar a história e esclarecer dúvidas.
- Um conjunto de testes de aceitação.
Um ponto muito importante, e comum a todos os métodos de especificação de requisitos, é que as histórias devem ser escritas pelo cliente ou por um seu representante e nunca pela equipa de desenvolvimento. As histórias devem apresentar claramente algo de valor para o cliente.
Analisemos cada um dos pontos com base numa funcionalidade muito comum: "Um potencial cliente do nosso site deve poder registar-se de modo a receber notícias, ofertas, entre outros tipos de contactos." A possibilidade de se registar como utilizador de um site é uma característica cujo desenvolvimento pode ser muito complexo, pelo que convêm dividir a tarefa em algo mais pequeno, em várias user stories.
Pequena descrição
A primeira parte de uma história é uma pequena descrição, de uma ou duas frases, de modo a que nos possamos referir à história de forma simples sempre que necessário, nomeadamente no planeamento. Para o nosso exemplo, é possível encontrar muitas histórias, cujas descrições podiam ser:
- "Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica."
- "O cliente deve receber um e-mail de confirmação do registo."
- "O cliente só fica devidamente registado depois de responder ao e-mail de confirmação."
- "O cliente deve poder fornecer dados adicionais, como morada, telefone ou idade."
De certeza que vocês podem encontrar muitas outras, mas acho que dá para perceber a ideia. A história deve ser uma coisa simples, passível de completar em pouco tempo, idealmente de 1 a 5 dias.
Conversações sobre a história
Como é natural, não é possível construir a funcionalidade apenas com as mini-descrições. Bom, possível será sempre, mas o mais provável é que o resultado final seja bastante diferente do pretendido pelo cliente. Sendo assim, é fundamental que cliente e equipa desenvolvimento discutam entre si a história de modo a esclarecer tanto quanto possível o pretendido.
Peguemos na história "O cliente deve receber um e-mail de confirmação do registo.". Existem um conjunto de questões que saltam imediatamente à vista. O cliente (o nosso, não o do site) deve poder alterar o conteúdo do e-mail sem intervenção da equipa de desenvolvimento? O e-mail deve ser personalizado? Deve ser enviado em texto puro, RTF, HTML? Todas estas questões devem ser debatidas e esclarecidas entre cliente e equipa de desenvolvimento antes e durante a construção da história.
Estas conversações também têm por objectivo permitir à equipa de desenvolvimento estimar o tempo de construção da história, um ponto importante mas que vou deixar para outra altura. ;)
Testes de aceitação
Os testes de aceitação têm uma finalidade semelhante à dos testes funcionais, confirmar que o sistema funciona de acordo com a especificação. No entanto, seguem uma filosofia muito diferente. A cada história estão associados um conjunto de testes de aceitação, que devem ser definidos pelo cliente, antes da construção da história. Apesar de ser o cliente o primeiro responsável pela definição dos testes, a equipa de desenvolvimento, especialmente se tiver experiência no tipo de sistema a ser desenvolvido, também pode contribuir com a definição de alguns testes.
O nome, testes de aceitação, tem como objectivo indicar que estes são os testes que o cliente definiu como sendo necessários o sistema passar de modo a que a história possa ser dada como concluída. Assim, temos uma forma clara e objectiva de saber se temos o trabalho pronto ou não, uma vantagem importantíssima.
Imaginemos a história "Um cliente deve-se registar indicando como código de utilizador o e-mail e escolhendo uma palavra-chave alfa-numérica.". Que testes de aceitação podemos definir? Não é difícil de imaginar alguns:
- "O código de utilizador deve ser validado que tem o formato de um email, tanto quanto possível. Por exemplo, o código de utilizador joao.hugo.miranda@pardaisaoninho.com deve ser válido mas o código de utilizador joao não."
- "Uma palavra-chave não deve aceitar caracteres que não os A-Z, a-z e 0-9."
- "Depois de registado, o cliente deve receber uma confirmação provisória do registo."
- "Se o código de utilizador estiver errado, o cliente deve ser informado do motivo."
O mais bonito, é que muitos destes testes podem ser automatizados. A framework mais famosa é o Fit\Fitnesse.
Em resumo, as histórias são o ponto de partida para resolver muitos dos problemas associados ao planeamento e à especificaçãod e requisitos. São simples, estabelecem critérios bastante objectivos de conclusão, são facilmente entendíveis por todos os envolvidos.
Há muito mais para dizer sobre histórias, mas... não é para já. Se estiverem interessados, leiam o livro que indiquei acima ou outro sobre Extreme Programming. Entretanto, espero escrever mais algumas coisas sobre isto mas não tenho sido muito regular nos últimos... meses!!! ;P
Posted
19-1-2006 23:27
por
João Hugo Miranda