O artigo anterior apresentou as Funções – os trabalhos que alguém precisa executar. Hoje veremos as opções que temos para registrar esse tipo de requisito. Conceitos básicos sobre como contar um tipo muito especial de história.

O ato de contar histórias é quase tão antigo quanto andar para frente. Contando histórias nós informamos, ensinamos ou divertimos. Há uma estrutura clássica para histórias que pretendem informar. Elas devem responder a uma sequência pré-determinada de questões: o quê? quem? quando? onde? como? por quê? Este padrão, parte do que é conhecido como pirâmide invertida, foi lançado pelo jornal New York Times em 1861. É utilizado por jornalistas desde então. Variações da sequência surgiram como ferramentas no mundo dos negócios na segunda metade do século passado. Elas ficaram conhecidas por siglas como 5W2H e 6W, por exemplo. Mais recentemente, em The Back of the Napkin (Portfolio, 2008), Dan Roam utilizou a neurociência para justificar sua versão das questões. Em relação à pirâmide invertida original ele apenas trocou a posição das perguntas quando e onde. Se há uma estrutura relativamente bem consolidada para a narração de histórias, por que precisaríamos de algo diferente para o registro de requisitos – das necessidades, desejos e restrições de clientes e usuários?

Diz a lenda¹ que no final dos anos 1960 Ivar Jacobson, trabalhando em uma empresa de telecomunicações sueca, deu à luz uma ferramenta que apoia os trabalhos de descoberta e descrição dos requisitos funcionais de um sistema. A ferramenta se chama Especificação de Casos de Uso – Casos de Uso para os íntimos. Causo para todos que já frequentaram uma turma do FAN. O termo, bem caipira, serve para a rápida vinculação com histórias curtas narradas em linguagem coloquial. Um caso de uso típico apresenta a seguinte estrutura:

Comparado à pirâmide invertida, o caso de uso carece de duas informações que ajudariam a entender melhor o contexto: quando e onde. Apesar deste e de alguns outros pesares, esta é a melhor ferramenta para os trabalhos de descoberta e descrição de funções. É uma pena que nosso incurável gosto por coisas “sofisticadas” a tenha complicado demais. Inventamos n nomes para os fluxos (os comos), casos de uso de negócio (uma aberração²) e outras tantas coisas que só bagunçaram o coreto. Não por acaso, são muitos os profissionais que nutrem verdadeiro ódio pela ferramenta. Devo fazer um mea culpa: o modelo que utilizo poderia ser um pouco menos rebuscado. Mas, como explico em sua apresentação, a principal finalidade é didática. E ele tem funcionado bem assim.

Com a intenção de contrapor as intermináveis “especificações funcionais” inventamos as Histórias de Usuários (User Stories). Sua mensagem é clara: trocamos trocentas páginas de documentos por maior proximidade e mais conversas com clientes e usuários. As histórias são formadas por três componentes: um cartão (onde a história é descrita); as conversas (motivadas pela história); e a confirmação (testes que devem verificar a realização da história). Uma história padrão é contada da seguinte maneira:

Além das mesmas omissões que vemos em casos de uso, as histórias também abrem mão do como. Talvez seja importante dizer que isso não é uma falha e sim uma característica intencional. O desenvolvedor que deve realizar uma história tem total liberdade para experimentar. Para funcionar bem as histórias de usuários apresentam um pré-requisito fundamental: a proximidade e intensa participação de clientes e usuários. Quando isso não é possível, o número de idas e vindas (ou seja, de experimentações) pode ser muito maior do que o desejável.

O bode que as histórias de usuários tiraram da sala, a sua maior diferença em relação aos casos de uso, é a descrição do como: como um ator (perfil/usuário) utilizará determinada função. Esta é de fato a parte mais complexa de qualquer história. É também a porção dos casos de uso que mais sofreu nas mãos de “inventores”. Cabe um pequeno exemplo. Por diversas vezes questionaram o pequeno espaço que dedico para o “caminho feliz” (o fluxo principal de um caso de uso). Citando Coplien e Cockburn³, insisto que o fluxo principal não deveria ter mais que sete ou nove passos. Algumas pessoas acham isso arbitrário demais e seguem questionando. O que me obriga a apelar: se não estamos desenvolvendo um videogame (único caso em que faz sentido dificultar a vida do usuário em seu caminho para realizar determinado objetivo), devemos sempre buscar o caminho mais curto possível. Já pensou se você tivesse que dar doze cliques para comprar um livro na Amazon? Até quem construiu os quase sempre disfuncionais caixas automáticos e bancos eletrônicos não ousou ultrapassar o limite de nove passos para a realização de uma transação. Por que você o faria?

Epílogo

Organizações são únicas, assim como projetos e histórias. Acreditar em um padrão universal para o registro destas é como crer em Papai Noel. Me contradigo? Afinal, escrevi ali em cima que “a especificação de casos de uso é a melhor ferramenta para a descoberta e descrição dos requisitos funcionais de um sistema”. Sustento minha colocação em duas características dos casos de uso: 1) Não somos obrigados a escrever muito nem muito pouco. Distância e constância da participação de clientes e usuários são os únicos fatores que determinam quanto devemos escrever; 2) Podemos criar um modelo que atenda necessidades específicas de uma organização, equipe ou projeto.

E o que dizer da deficiência apontada acima, da falta de um lugar para registrar onde e quando? Oras, nada o impede de criar este espaço e chamá-lo de Contexto. Tanto melhor se você referenciar o processo de negócio suportado no causo. Melhor ainda se você combinar presente (as-is – processo de negócio) e futuro (to-be – requisitos) em uma visualização única (PUCS – Process-Use Case Support). Há muito tempo aprendemos que uma história que pretende informar obrigatoriamente responde a seis perguntas básicas. Por mais que gostemos de reinventar a roda, devemos respeitar o óbvio: a roda é redonda; Uma história tem seis respostas.

Notas

1. A lenda fala em final dos anos 1960. Na história devidamente documentada, a especificação de casos de uso foi formalmente apresentada por Ivar Jacobson em 1986.
2. Casos de uso de negócio são uma aberração. Porque a ferramenta caso de uso trata o sistema (negócio) em discussão como uma caixa preta – não queremos nem precisamos ver seu interior, não precisamos entender como o sistema (negócio) realizará determinada função. Nos interessam apenas as interações entre usuário e sistema (negócio). Quando estudamos um negócio, queremos e precisamos entender como ele funciona. Por isso não faz o menor sentido tratá-lo como uma caixa preta.
3. Em Lean Architecture (Wiley, 2010) e Escrevendo Casos de Uso Eficazes (Bookman, 2006), respectivamente.