A História do Usuário é compatível com o caso de uso?

Pesquisando pela internet, os Sábios Ágeis consideram que casos de uso e histórias de usuário são coisas diferentes:

• Mike Cohn:Histórias de usuário não são casos de uso
• Alistair Cockburn:Uma história de usuário é para um caso de uso como uma gazela é para um gazebo
• Extreme Programming.org:Histórias de usuário servem para o mesmo propósito que os casos de uso, mas não são iguais.

A abordagem orientada por casos de uso foi uma das técnicas mais quentes para captura de requisitos e algumas pessoas hoje consideram que é uma espécie de técnica ultrapassada, antiga, associada a muitos problemas que fazem com que sua equipe NÃO seja “Ágil” devido aos problemas dos casos de uso:

• Requisitos iniciais – tentar definir o detalhe de todos os aspectos do início resultará em muitos esforços e tempo desperdiçados, pois grande parte do trabalho precisará ser refeito.
• Decomposição funcional: a natureza funcional dos casos de uso leva naturalmente à decomposição funcional de um sistema em casos de uso concretos e abstratos, relacionados por associações de casos de uso extends e include.

Se você pesquisar na internet com as palavras-chave “caso de uso vs história de usuário”, encontrará uma longa lista de artigos que sugerem os pontos fracos, problemas ou armadilhas da abordagem de casos de uso, enquanto há uma lista ainda maior dos benefícios relacionados às histórias de usuário. Interessante, as coisas mudam tão rapidamente na indústria de TI, e ainda mais rápido para as pessoas que mudam das coisas que eram “modas” no passado para as “novas modas” do presente.

Curiosamente, algumas pessoas gostam de perceber as coisas em um padrão binário e perseguir coisas modernas associando-se a elas simbolicamente, em vez de praticá-las de forma genuína. Algumas pessoas nem sequer querem que outras saibam que ainda estão usando casos de uso, ou podem ser consideradas ultrapassadas e de estilo antigo.

Agora algumas pessoas colocam um sinal de igual relacionado à história de usuário e ao caso de uso:

• Ágil = história de usuário ou Ágil = história de usuário + Scrum
• História de usuário = o suficiente e no momento certo
• História de usuário = atender às expectativas do usuário e satisfatória
• Caso de uso = captura detalhada de requisitos iniciais
• Caso de uso = <<inclui>> + <<estende>> = decomposição funcional
• O caso de uso é apenas o estilo “entrada do usuário” -> “resposta do sistema”
• Caso de uso = estilo antigo e ultrapassado

Como fornecedor de ferramentas, somos bastante neutros em métodos, ferramentas e técnicas. Pessoalmente, quero enfatizar claramente que sou grande fã do desenvolvimento Ágil, das histórias de usuário e do processo Scrum. Particularmente, os princípios subjacentes e as melhores práticas relacionadas a conceitos como:

• Descoberta de requisitos em vez de entrega de requisitos
• Sob o princípio acima, resultam duas propriedades importantes no processo de desenvolvimento Ágil
  • No momento certo
  • O suficiente

(Vou escrever mais posts relacionados aos princípios acima com minhas próprias opiniões, que estão diretamente relacionados à minha área de pesquisa de doutorado entre 1992-1995 – metamodelos e transformações de esquemas)

Agora, vamos voltar aos tópicos “caso de uso vs história de usuário”. Bem, os Sábios Ágeis de peso já votaram nisso, será que sou tão teimoso em tentar anular seus “votos” argumentando que são semelhantes ou até iguais?

Deixe-me mostrar um exemplo para ilustrar se a história de usuário é “tão diferente” do caso de uso:

Exemplo

Boas histórias de usuário são muito mais do que apenas afirmações. Uma história de usuário padrão consiste em três partes, comumente conhecidas como os três C’s.

O primeiro “C” de cada história de usuário deve seguir o formato padronizado de:

Como [papel], quero [fazer algo], para que [benefícios]

que é o conteúdo mínimo de uma história de usuário a ser colocado no cartão.

As Conversas são o conteúdo do segundo “C” de uma história de usuário, que representam a discussão entre os usuários finais, o proprietário do projeto e a equipe de desenvolvimento. Nesses diálogos, registra-se a discussão verbal ou muitas outras informações úteis, como e-mails, wireframes ou quaisquer outros conteúdos relacionados ao projeto.

O último “C” de uma história de usuário é a confirmação, que são os critérios de aceitação usados para confirmar que a história de usuário foi implementada corretamente e entregue com sucesso.

Deixe-me explicar um pouco mais sobre como desenvolver a parte de confirmação de uma história de usuário. Aqui usamos o modelo mais conhecido chamado Gherkin, que adota a fórmula Dado-Quando-Então para orientar a escrita dos testes de aceitação para uma História de Usuário:

• (Dado.. e) algum contexto
• (Quando.. e) alguma ação é realizada
• (Então.. e) Realizar algumas ações

Ferramentas como Cucumber e Jbehave frameworks incentivam o uso do modelo Dado-Quando-Então para realizar testes automatizados, embora também possa ser usado puramente como um heurístico, independentemente de se usar uma ferramenta.

Vamos reunir todas as informações para a história de usuário “registrar curso” e colocá-las no formato 3C:

Adotei o formato 3 C comumente usado para representar a história de usuário “registrar curso”. Da mesma forma, também adotei o formato mais amplamente utilizado para descrever o mesmo caso de uso “registrar curso”, elaborado por uma descrição de caso de uso. Numerei as etapas da seção de confirmação (o último C) da história de usuário, que estão associadas ao número da etapa que coloquei na descrição do caso de uso. São as mesmas “nove etapas” do cenário a serem colocadas em cada abordagem, com ordem diferente. Acredito que ambas as representações de modelo são aceitáveis para seus respectivos sábios e seguidores. Então, a pergunta novamente: a história de usuário é muito semelhante ao caso de uso, mas ainda assim é diferente, ou será que a ordem das etapas está causando toda essa crítica à abordagem de caso de uso?

Semanticamente equivalentes com significados diferentes?

Vamos investigar se há um caso semelhante no domínio de modelagem, para que possamos comparar com a situação aqui, ou talvez isso nos ajude a formar nossa própria opinião sobre “história de usuário versus casos de uso”, mas sem seguir cegamente a multidão ou repetir o que os sábios disseram como um papagaio.

Exemplo: Semanticamente equivalentes

No UML, podemos descrever um cenário de caso de uso com um diagrama de sequência, mas geralmente não usamos um diagrama de colaboração para o mesmo propósito; embora ambos os diagramas sejam semanticamente equivalentes. Em outras palavras, tanto o diagrama de sequência quanto o diagrama de colaboração têm o mesmo número de objetos participando de um cenário, com o mesmo número de mensagens passando entre o mesmo conjunto de objetos para realizar uma tarefa de um cenário. No entanto, o primeiro é focado no tempo e o segundo é focado no espaço. O diagrama de sequência é mais intuitivo ao ser usado com modelagem de cenários, enquanto o diagrama de colaboração é adequado para modelar relações estruturais entre objetos. Por exemplo, você deseja representar estruturalmente o cenário dos objetos participantes no framework MVC (camadas de modelo, visualização e controle).

Pessoalmente, não acho que usar histórias de usuário fará minha equipe se tornar ágil, e casos de uso farão minha equipe ser “proativa”. O mais importante é como aplicamos e usamos essas ferramentas com que tipo de mentalidade e melhores práticas por trás. Não me preocupo muito com as pessoas me considerarem “de estilo antigo” ou ultrapassado, quando na verdade agiro de forma ágil.

Ainda me lembro dos tempos da análise e design estruturados, talvez pudéssemos usar Tipo de Dados Abstrato em ADA para aplicar os princípios de análise e design orientados a objetos sem o suporte de POO em 198x, certo? Infelizmente, você talvez nem sequer encontre os conceitos de Tipo de Dados Abstrato! Oh! Meu Deus, eu acidentalmente revelei – sou velho? Ou, deveria pensar positivamente – experiente?