Histórias de usuário vs casos de uso

Question

Os casos de uso são apenas várias histórias de usuário ??

Quais são os benefícios do uso de histórias de usuários sobre casos de uso .. e vice-versa ... Quando usar um em outro ... Todas as metodologias ágeis usam histórias de usuários?

Answer 1

Na verdade, os casos de uso originais (ver Oose de Jacobson) eram bastante leves, assim como as histórias de usuários são agora. Com o tempo, eles evoluíram até que um formato comum para "casos de uso" agora seja um documento complicado com entradas, saídas, herança, usa relacionamentos, pseudocódigo, etc. Programadores, em geral, tentam converter tudo em programação.

De qualquer forma, a tentativa de definir o que distingue um "caso de uso" de uma "história do usuário" de um "cenário" é bastante inútil, pois é difícil encontrar duas autoridades que concordam.

Pessoalmente, acho o padrão [ator] [verbos] [substantivo] para obter [valor comercial] útil. Se superar um parágrafo de texto, pode ser muito grande.

Answer 2

Quando se trata disso, "Agile" é apenas um rótulo, e as pessoas discordam sobre exatamente o que isso significa. Da mesma forma, as pessoas chamam coisas muito diferentes de "casos de uso".

Na minha experiência, a principal diferença entre os dois é que uma história do usuário está focada no usuário e geralmente é mais curta e menos formal - idealmente, deve se encaixar facilmente em um cartão postal. Provavelmente não fornece detalhes do manuseio de erros etc.

Casos de uso posso Seja muito mais formal (embora algumas pessoas também as escrevam informalmente) - elas se concentram em todas as interações com o sistema e podem muito bem entrar em mais detalhes sobre vários sistemas/atores diferentes/etc no mesmo caso de uso.

Essa é apenas a minha experiência - é provável que todos tenham usado essas ferramentas de maneiras diferentes. Eu não ficaria muito pendurado em rótulos - basta usar o que funciona para o seu projeto.

Answer 3

Casos de uso não são compilações de histórias de usuários.

As histórias de usuários geralmente são muito mais simples que os casos de uso. Acho que os casos de uso tentam cobrir absolutamente tudo a ver com o comportamento de algum aspecto do sistema. Ou seja, todos os comportamentos, todos os caminhos de erro e todo o manuseio de exceção.

O modelo recomendado para um usuário é:

Como (função) eu quero (algo) para que (benefício)

(Obrigado Mike Cohn por fornecer este modelo simples)

Descrições de comportamento expressas assim são mais ágeis.

Esse tipo de modelo permite descrever o comportamento usando diferentes níveis de detalhe. Por exemplo:

1. Para essas histórias que estão sendo implementadas em um sprint muito posterior, você pode descrever o comportamento de uma maneira de alto nível, por exemplo, como membro da equipe de OPS, quero monitorar o sistema remotamente para poder determinar a saúde do sistema enquanto estava na estrada.
2. Para essas histórias que estão sendo implementadas no próximo sprint, você pode descrever o comportamento é uma maneira um pouco mais detalhada, por exemplo, como membro da equipe de OPS, quero ter apenas um login de OPs dedicado para que eu possa verificar a saúde do sistema.
3. Para essas histórias que estão sendo implementadas no Sprint atual, você pode descrever o comportamento de uma maneira altamente detalhada, por exemplo, como membro da equipe de OPS, quero ter uma interface da Web para que eu possa verificar o status atual do ingerir servidor FTP.

Os casos de uso do IMHO são muito mais esculpidos em pedra! E, portanto, pode ser um problema a ser atualizado após a versão inicial.

Hth

Felicidades,

Roubar

Answer 4

Em uma palavra, não.

Os casos de uso são normalmente especificações detalhadas, que estabelecem como uma peça de funcionalidade específica funcionará ou como um usuário específico utilizará o sistema. Normalmente, ele está na voz de um usuário (ou ator) específico e é bastante independente.

Uma história do usuário, por outro lado, é "um convite para discussão". Normalmente é uma ou duas frases. Aqui é um bom recurso para isso. E Mike Cohn's Histórias de usuário aplicadas vale a pena.

A sintaxe típica é "como umu003Cuser> Eu preciso deu003Cfunctionality> alcançaru003Cbusiness value> ", ou" para alcançaru003Cbusiness value> como umu003Cuser> Eu preciso deu003Cfunctionality> "O que leva para casa o valor da história.

Histórias de usuário são não destinado a ser independente, mas pretendia convidar a discussão da história entre o desenvolvedor e o cliente (ou proxy do cliente).

Answer 5

Você pode pensar em uma história de USE como uma história de usuário, mas não o contrário. Uma USECASE cobrirá vários "finais" para a história, os requisitos especiais (por exemplo, os campos do formulário devem ser inseridos no formato XYZ e mostrar a mensagem de erro 123 se o usuário entrar em um campo no formato errado). Além disso, uma USECASE pode incluir referências adicionais a documentos externos, como diretrizes de segurança.

Answer 6

Histórias de usuário é uma ferramenta usada no desenvolvimento ágil para garantir que você crie o produto que seu usuário realmente precisa.

• Descreve mais Por quê você deve fazer esse ou aquele recurso em vez de COMO AS ou Que recurso.
• Pela minha experiência pessoal, é uma ótima maneira de equilibrar a visão do cliente e do desenvolvedor para criar um produto melhor.

Ao contrário de nós aCaso de uso concentra -se em quem usa seu produto. Aqui está a diferença.

Eu diria que não há outro instrumento para um desenvolvedor ágil como histórias de usuários. Se você quiser aprender a escrevê -los com sucesso, confira isto publicar.