Pesquisando na web, o Agile Sages considera casos de uso e histórias de usuários como duas coisas diferentes:

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

A abordagem orientada a casos de uso foi uma das técnicas mais populares para captura de requisitos e algumas pessoas agora consideram que é um tipo de técnica de estilo antigo e desatualizada associada a muitos problemas que fazem com que sua equipe NÃO seja “ágil” devido aos problemas de caso de uso :

• Requisito inicial – tentar definir os detalhes de todos os aspectos iniciais resultará em muito esforço e tempo desperdiçados, pois grande parte do trabalho precisará ser refeito.
• Decomposição Funcional: A natureza funcional dos casos de uso naturalmente leva à decomposição funcional de um sistema em termos de casos de uso concretos e abstratos que são relacionados por extensões e incluem associações de casos de uso.

Se você pesquisar na Web com as palavras-chave “caso de uso vs história do usuário”, encontrará uma longa lista de artigos que sugerem as desvantagens, problemas ou armadilhas da abordagem do caso de uso, enquanto há uma lista ainda maior dos benefícios relacionados à história do usuário . Interessante, as coisas mudam tão rapidamente no setor de TI, e ainda mais rápido para as pessoas que estão mudando das coisas que costumavam ser “modernas” no passado para as coisas “mais modernas” de agora.

Curiosamente, algumas pessoas gostam de perceber as coisas em um padrão binário e perseguir as coisas da moda associando-as simbolicamente ao invés de realmente praticá-las genuinamente. Algumas pessoas até não querem que outras pessoas saibam que ainda estão usando casos de uso, ou podem ser consideradas desatualizadas e com estilo antigo.

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

• Agile = história do usuário ou Agile = história do usuário + Scrum
• História do usuário = suficiente e just-in-time
• História do usuário = atendendo às expectativas do usuário e satisfatória
• Caso de uso = Captura de requisitos detalhada inicial
• Caso de uso = <<include>> + <<extends>> = decomposição funcional
• O caso de uso é “entrada do usuário” -> estilo apenas “resposta do sistema”
• Caso de uso = estilo antigo e desatualizado

Como fornecedor de ferramentas, somos bastante neutros em métodos, ferramentas e técnicas. Pessoalmente, quero deixar claro que sou um grande fã de desenvolvimento ágil, história de usuário e processo scrum. Em particular, os princípios e as melhores práticas subjacentes a conceitos como:

 

• Descoberta de requisitos em vez de entrega de requisitos
• Sob o princípio acima, isso produz duas propriedades importantes no processo de desenvolvimento ágil
  • Na hora certa
  • Apenas o suficiente

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

Agora, vamos voltar aos tópicos “caso de uso vs história do usuário”. Bem, o peso pesado Agile Sages já votou nisso, será que eu sou tão teimoso tentando derrubar seus “votos argumentando que eles são semelhantes ou até mesmo iguais?

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

Exemplo

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

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

Como [papel], quero [fazer alguma coisa], 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 representa a discussão entre os usuários finais, o proprietário do projeto e a equipe de desenvolvimento. Nesta conversão, registra a discussão verbal, ou muitas outras informações úteis como, e-mails, wireframes ou qualquer outro conteúdo relacionado ao projeto.

O “C” final de uma história de usuário é a confirmação que é o critério de aceitação usado para confirmar que a história de usuário foi implementada corrigida e entregue com sucesso.

Deixe-me elaborar 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 guiar a escrita de testes de aceitação para uma História de Usuário:

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

Ferramentas como os frameworks de teste Cucumber e Jbehave incentivam o uso do modelo Given/When/Then para conduzir testes automatizados, embora também possa ser usado puramente como uma heurística, independentemente de ser uma ferramenta a ser usada.

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

Adotei o formato 3 Cs comumente usado para representar a história do usuário “registrar curso”. Da mesma forma, também adotei o formato mais usado para descrever para 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 do usuário que está associada ao número da etapa que coloquei na descrição do caso de uso. Eles são os mesmos “nove passos” do cenário a ser colocado em cada uma das abordagens com ordem diferente. Acredito que ambas as representações do modelo são aceitáveis ​​para seus sábios e seguidores correspondentes. Então, a pergunta novamente, a história do usuário é muito semelhante ao caso do usuário e ainda assim eles são diferentes ou a ordem das etapas causando todo tipo de crítica à abordagem do caso de uso?

Semanticamente equivalente com significado diferente?

Vamos investigar se existe um caso semelhante no domínio da modelagem, para comparar com a situação aqui, ou pode nos ajudar a votar em “história de usuário versus casos de uso”, mas não seguir cegamente a multidão ou repetir o que o sábios diziam como um papagaio.

Exemplo: Semanticamente Equivalente

Em UML podemos descrever um cenário de caso de uso com um diagrama de sequência, mas normalmente não usamos um diagrama de colaboração para o mesmo propósito; mesmo através de ambos os diagramas são 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 pelo mesmo conjunto de objetos para executar uma tarefa de um cenário. No entanto, o primeiro é o foco no tempo e o último é o foco no espaço. O diagrama de sequência é mais intuitivo ao ser usado com modelagem de cenário, enquanto o diagrama de colaboração é apropriado para modelar o relacionamento estrutural entre objetos. ou seja, você deseja representar o cenário do objeto participado estruturalmente no framework MVC (modelo/visualização e camadas de controle).

Pessoalmente, não acho que usar a história do usuário fará com que minha equipe se torne ágil, e o caso de uso fará com que minha equipe seja “adiantada”. O mais importante é como aplicamos e usamos essas ferramentas com que tipo de mentalidade e práticas recomendadas estão por trás. Não me preocupo muito com as pessoas que me consideram “antiquado” ou desatualizado quando na verdade ajo de maneira ágil.

Ainda me lembro nos dias de análise estruturada e design, talvez possamos usar o Abstract Data Type no ADA para aplicar os princípios de análise e design orientados a objetos sem ter o suporte de OOP em 198x, certo? Infelizmente, você pode nem mesmo se deparar com os conceitos do Tipo de Dados Abstrato! Oh! Meu Deus eu divulgo acidentalmente – eu sou velho? Ou, devo pensar positivo – experiente?

O que você acha? Qual é o seu voto sobre isso? Avise-me ou corrija-me se estiver errado.