Qual é a diferença entre histórias e recursos do usuário?

25

Brincando com o icescrum , percebi que não entendia a diferença entre histórias e recursos do usuário.

Alguém pode explicar a diferença?

agile scrum features

— BЈовић
fonte

23

Um recurso é um elemento distinto da funcionalidade que pode fornecer recursos aos negócios.

Uma história é um pequeno aspecto de um recurso que você pode usar para obter feedback das partes interessadas e descobrir se está fazendo algo errado.

Por exemplo, um recurso pode ser "permitir que os usuários comentem artigos". As histórias associadas a esse recurso podem ser:

salvar comentários
filtrar comentários por palavras rudes
limitar comentários a 400 caracteres e enviar aos usuários
adicione captchas para impedir que os bots façam spam no site
permitir que os usuários façam login via ID do Google

etc.

Em cada estágio, podemos obter feedback sobre se a direção que estamos tomando é útil.

Algumas equipes não se preocupam em dividir os recursos em histórias. Isso está ok.

— Lunivore
fonte

13

Essas histórias associadas não são realmente tarefas de histórias do usuário? Eu diria que eles são. Uma história de usuário seria: Como usuário, gostaria de comentar artigos, para que nós, como usuários, possamos melhorar o conteúdo do artigo ou expressar preocupações. Esta história de usuário seria dividida em tarefas que você descreveu ...

— Robert Koritnik

4

Considero que uma tarefa é algo que precisa ser feito para obter feedback, mas sobre o qual você não pode obter feedback sozinho - por exemplo, criando uma tabela de banco de dados. Qualquer uma dessas histórias, exceto a primeira, poderia potencialmente ser removida, mantendo valor no envio. As tarefas geralmente são cortadas horizontalmente no meu mundo. Mas, se você tiver definições diferentes, tudo bem. A granularidade não é uma coisa completamente discreta, todo objetivo é uma subobjetiva de outro, e acho que você deve fazer o que for pragmático para você. Acho essa repartição útil, como muitas de minhas equipes.

— Lunivore

16

Características == Histórias de usuários.

A verborragia é ditada pela metodologia Agile fornecida .

As diferentes metodologias usam terminologia diferente para se referir aos recursos. Cabe à equipe decidir qual metodologia ou terminologia usar. Extreme Programming (XP) usa os termos Histórias de usuário ou Histórias para representar recursos; Scrum usa Product Backlog para descrever uma lista de recursos; O Desenvolvimento Orientado a Recursos usa Feature; e o DSDM usa o Requisito. Da mesma forma, existem várias versões leves do Processo Unificado, ou UP Agile, que usam Requisito e / ou Caso de Uso para definir a funcionalidade de entrega incremental. Por fim, o objetivo é o mesmo - fornecer valor comercial regularmente em pequenos incrementos e mais cedo ou mais tarde.

— Aaron McIver
fonte

+1, isso explica bem. Eu não diria necessariamente recurso == história do usuário, exceto quando você fala sobre valor comercial ou valor do cliente. Em outros casos, o termo respectivo pode não ter um significado.

— 22411 murrekatt

2

Eu não acho que você possa dizer que eles são iguais, mesmo que sejam termos relacionados. E os recursos que abrangem várias histórias de usuários?

— sleske

@sleske Uma história de usuário em uma abordagem pura do Scrum deve ser um valor agregado ao usuário e, portanto, um recurso. Se vamos catalogar recursos como épicos abrangentes, tudo bem, mas o resultado final são histórias de usuários que agregam valor.

— Aaron McIver

1

@AaronMcIver: Sim, isso é verdade. No entanto, às vezes a quantidade mínima de funcionalidades que é realmente útil para o usuário (= recurso) é demais para uma história de usuário (ou mesmo para uma iteração). Nesse caso, você deve dividir o recurso em várias histórias.

— sleske

BTW, pergunta relacionada & resposta: stackoverflow.com/questions/1714557/...

— sleske

7

Uma história do usuário é uma declaração informal no idioma do cliente que captura a intenção de algo que o cliente deseja alcançar. Você pode pensar em uma história de usuário como uma declaração de requisitos informais.

Um recurso de software é uma característica distinta do software que contribui para o design e a funcionalidade gerais do software.

Algumas considerações importantes:

A história pode descrever um recurso , mas uma característica não descreve uma história .
Uma história pode não descrever diretamente um recurso .
Uma história pode implicar a inclusão de vários recursos .
Um Recurso - individualmente ou como membro de uma coleção de Recursos - pode capturar a intenção de uma História .

Com tudo isso em mente, costumo pensar em Histórias como descrições. Requisitos basicamente informais que me dizem o que o cliente deseja. Recursos, por outro lado, costumo pensar mais em uma especificação que me diz como um sistema deve funcionar para atender aos requisitos dos clientes.

— S.Robins
fonte

3

Os dois termos estão intimamente relacionados, mas existem algumas diferenças.

Primeiro, eles vêm de domínios diferentes. O termo "recurso" é um termo bastante geral para parte da funcionalidade de um software, enquanto "história do usuário" foi inventada e é realmente usada apenas no contexto do desenvolvimento ágil de software.

Na prática, muitas vezes coincidem, pois a história de um usuário consiste em implementar um determinado recurso.

No entanto, em algumas situações, eles podem ser diferentes:

Muitas vezes, um recurso é muito trabalhoso para uma única história de usuário. As histórias de usuários não devem ser muito grandes (geralmente não mais do que alguns dias, no máximo 1-2 semanas de trabalho). Obviamente, muitos recursos são muito maiores. Nesse caso, um recurso será implementado em várias histórias de usuários. Algumas pessoas usam "épicos" para agrupar histórias de usuários. Nesse caso, você pode dizer que o recurso é épico.
Requisitos não funcionais (desempenho, segurança, compatibilidade etc.) também podem ser tratados como histórias de usuários (embora isso não seja universalmente aceito). Nesse caso, o resultado da história do usuário normalmente não seria chamado de recurso (a menos que você chame "nosso aplicativo raramente trava" um recurso).

— sleske
fonte