Qual é a diferença entre um usuário história e um recurso na terminologia Agile? [fechadas]

Question

Eu acho que um recurso poderia ser algo como "autorização de cartão de crédito", enquanto uma história de usuário pode ser "autorizar o cartão de crédito para paypal".

Então, é uma história de usuário um subconjunto de um recurso?

Answer 1

Sim, algo como um subconjunto. Este artigo é uma boa leitura:
Características vs Stories

Trecho:

Eu percebi hoje que eu não tinha feito explícita a diferença em minha mente entre as características e histórias e é uma diferença importante. Essencialmente, uma característica é um grupo de histórias que estão relacionados e entregar um pacote de funcionalidade que os usuários finais faria geralmente esperar para obter tudo de uma vez. Por exemplo, a tabela embutida é redimensionamento um recurso (nota: isto é a capacidade a arraste para redimensionar tabelas, linhas e colunas - experimentá-lo em Word). No primeira passagem, você provavelmente tem um história única para redimensionamento em linha de mesas, mas seria grande demais para estimativa. Então você dividi-la em três histórias, colunas de redimensionamento, redimensionamento linhas e redimensionar a tabela em si.

Answer 2

De acordo com a Kent Beck e Martin Fowler histórias e apresenta são sinônimos:

A história de usuário é um pedaço de funcionalidade (algumas pessoas usam o palavra recurso ) que é de valor para o cliente.

O que você chama um recurso é normalmente referido como tema ou épica . Temas e épicos são usados ??para histórias de usuários grupo para maiores conjuntos de recursos, que fazem sentido por conta própria.

Do ponto de vista mais semântico: recurso é uma parte do sistema que você está tentando construir, história de usuário é uma maneira de descrever essa parte.

---

Correção:

Como Pascal tem as pontas - talvez eu perdi o verdadeiro significado de "recurso" em que a citação ( "recurso" obviamente se refere à funcionalidade) Além disso, eu ainda acho que se pode usar essas palavras (característica e história do usuário) como sinônimos em muitos contextos ( "Eu estou trabalhando sobre esta história" versus "Eu estou trabalhando sobre este recurso"), uma vez que, como disse Pascal, uma história de usuário é uma maneira de capturar uma característica. Que significa que há uma relação de 1: 1 entre os dois. E, como pode ser visto da minha observação sobre a semântica, isto é como eu realmente entendê-la.

Answer 3

Nem um pouco ..

A história de usuário representa pequenas partes de valor do negócio. Por isso, é realmente difícil dizer quando uma história de usuário é um subconjunto de um recurso ou um recurso é um subconjunto de uma história de usuário (também ter em mente que as histórias de usuário são geralmente escrito pelas partes interessadas, que tendem a não saber exatamente o que eles querem ... :))

Então, se você seguir a recomendação do ágil para manter os contos você iria cair na "melhor" cenário que é a história do usuário ser um subconjunto do recurso.

No entanto, se os seus write partes interessadas histórias longas, cada história teria um par de características (se houver uma boa comunicação entre a equipe e os stakeholders isso não vai acontecer desde que a equipe vai quebrar as histórias em pequenos)

Answer 4

As características são o que um sistema está fazendo. histórias de usuários são apenas uma maneira entre outros para recursos de captura.

Answer 5

Eu deparei com este assunto quando eu estava à procura de ideias diferentes sobre "usando múltiplos papéis para exigências semelhantes".

Eu acho que, uma característica como um recipiente para histórias relacionadas ajuda a priorizar os requisitos pois as partes interessadas geralmente dizer suas necessidades como histórias dependentes. Em um projeto recente, o cliente me disse o seguinte

Um membro pode enviar mensagens para o administrador Admin pode enviar mensagens a todos os membros Os membros podem enviar mensagens uns aos outros

Quando vejo esses requisitos, eu sei disso, devemos implementar um sistema para permitir que as pessoas para enviar uma mensagem e devemos adicionar verificações para permitir que quem faz o que.

E também sei que esses requisitos podem ter alguns outros requisitos implícitos, como ler as mensagens que vieram, organizando-os, pode ser a criação como spam e etc.

Então, eu tento reformular estes requisitos como

Como um membro ou admin, eu posso enviar mensagens para outras pessoas. Como membro ou admin, eu posso ler as mensagens que foram enviadas para mim.

E, como os critérios de aceitação, estado i em detalhe quem pode enviar para quem.

Então eu chamo todas estas coisas como recurso "Mensagens Privadas", de modo que, em algum momento posterior, se o cliente decide que é um custo extra, ele pode dizer "Basta soltar a coisa mensagens particulares" e posso remover todos eles a partir do backlog.