Relação entre história do usuário, recurso e épico?

Eles são, na verdade, termos muito genéricos. Há muitas maneiras de interpretá-las, variando na literatura e como as pessoas as veem. Pegue tudo o que digo com um enorme grão de sal.

Normalmente, um Epic inclui uma funcionalidade muito global e não muito bem definida no seu software. É muito amplo. Em geral, ele será dividido em uma história ou recurso de usuário menor quando você tentar dar sentido a isso e torná-los adequados a uma iteração ágil. Exemplo:

Épico
- Permitir que o cliente gerencie sua própria conta através da Web

Recurso e História do Usuário são funcionalidades mais específicas, que você pode testar facilmente com testes de aceitação. Geralmente, é recomendável que eles sejam granulares o suficiente para caber em uma única iteração.

Os recursos costumam descrever o que seu software faz:

Recurso
- Editando as informações do cliente através do portal da web

As histórias de usuários tendem a expressar o que o usuário deseja fazer:

História do usuário
Como funcionário do banco,
Eu quero ser capaz de modificar as informações do cliente
para que eu possa mantê-lo atualizado.

Eu não acho que há realmente uma hierarquia entre os dois, mas você pode ter um, se quiser ou se encaixar como você trabalha. Uma história de usuário pode ser uma justificativa específica para um recurso ou uma maneira específica de fazê-lo. Ou pode ser o contrário. Um recurso pode ser uma maneira de realizar uma história do usuário. Ou eles podem denotar a mesma coisa. Você pode usar os dois: Histórias do usuário para definir o que agrega valor comercial e recurso para descrever a restrição do software.

História do usuário : como cliente, quero pagar com os cartões de créditos mais populares no Recurso para apoiar a API XML GOV-TAX-02 do governo .

Há também a questão do cenário, que geralmente é uma maneira de uma história de recurso / usuário ser executada. Eles geralmente mapeiam de forma limpa para um teste de aceitação específico. Por exemplo

Cenário : Retirando dinheiro
Dado que tenho $ 2000 na minha conta bancária
Quando eu retirar 100 $
Então recebo 100 $ em dinheiro. E meu saldo é 1900 $

É assim que definimos esses termos onde trabalho . Essas definições estão longe de ser uma definição matemática ou um termo padronizado. É como a diferença entre um político de direita ou um político de esquerda. Depende de onde você mora. No Canadá, o que é considerado de direita pode ser considerado de esquerda nos Estados Unidos. É muito variável.

Sério, eu não me preocuparia muito com isso. O importante é que todos na equipe concordem com uma definição para que você possa entender um ao outro. Alguns métodos como o scrum tendem a defini-los mais formalmente, mas escolhem o trabalho para você e deixam o resto. Afinal, não é ágil sobre indivíduos e interações sobre processos e ferramentas e software de trabalho sobre documentação abrangente ?

Épico : uma história de usuário muito grande que é eventualmente dividida em histórias menores.

História do usuário: Uma definição de alto nível de um requisito, contendo apenas informações suficientes para que os desenvolvedores possam produzir uma estimativa razoável do esforço para implementá-lo.

link

Recurso : uma característica distintiva ou capacidade de um aplicativo ou biblioteca de software (por exemplo, desempenho, portabilidade ou funcionalidade).

link

Aconselho você a não aplicar uma hierarquia muito rígida a esses termos. Nós tentamos fazer isso no meu trabalho anterior. Duas vezes. Ambas as tentativas foram diferentes e ambas as vezes descobrimos que nos limitamos desnecessariamente. A única constante era a definição de uma User Story . De uma perspectiva de planejamento, uma história é o bloco de construção básico de um projeto. Os termos maiores (epic, feature, etc.) são efetivamente apenas tags . As tags são uma maneira fácil de permitir que uma história exista como parte de várias epopeias e vários recursos ao mesmo tempo. Não vale a pena o esforço mental para ser mais rigoroso do que isso.

As tags funcionam no Stack Exchange e podem funcionar para você também.

A maneira como trabalhamos com Épicos, Histórias e Recursos é a seguinte

No início do ciclo do projeto, criamos Épicas . São pontos de funcionalidade de alto nível, quase centrados em marketing. O tipo de coisa que você pode usar em um resumo executivo, como

Our new web site will allow customers to browse products, view availability and pricing, place orders and see their past order history

Isso leva a épicos como

• Navegue pelo Catálogo de produtos
• Visualizar disponibilidade
• Visualizar preço
• Fazer pedido
• Visualizar histórico de pedidos

Estes são escritos como histórias de usuário (por exemplo, como cliente, eu quero navegar no catálogo de produtos, para que eu possa tomar uma decisão de compra informada), mas servem apenas como entrada para dez para o que será realmente desenvolvido lançado.

Essas epopéias são divididas em histórias de usuários . Essas são jornadas reais do usuário de ponta a ponta, muito limitadas no escopo e definidas de uma maneira que pode ser estimada e planejada independentemente e desenvolvida , testado e liberado em um ciclo de lançamento.

A história do usuário é a unidade de entrega. É a história do usuário que está completa ou incompleta, entra em operação ou não é publicada.

A resposta que eu gosto é do acampamento de Mike Cohn e é bastante simples.

link

• Epic é apenas uma grande história (hierárquica)
• O tema é apenas um grupo de histórias (muito parecido com tag)

Ele realmente evita o termo "Recurso". Eu suponho que é principalmente porque era um termo comum no mundo da cachoeira tradicional. Muitos Agile camp tendem a usar diferentes termos para enfatizar as diferenças.

Assim, na definição do seu PM, o recurso está em algum lugar no meio da hierarquia da história épica.

Aqui está meu info-gráfico desta definição do meu artigo da InfoQ link ;-)

Recursos e épicos não são a mesma coisa.

• Um recurso não é uma história de usuário.
• Uma epopeia é uma história de usuário.
• Uma história de usuário pode ser uma epopéia.
• Uma história do usuário pode conter muitos recursos.
• Um recurso pode atender 1 a muitas histórias de usuário.

Nas fases de planejamento, as discussões resultam em Estórias de usuário , que normalmente são identificadas como Épicas porque o esforço para implementar soluções para elas é grande demais para ser realizado em poucos dias. Os recursos do produto são identificados durante essa fase. Mas isso é apenas um subproduto da discussão. Os recursos são usados para planejar um roteiro do produto, que é uma discussão à parte.

As Épicas são analisadas e discutidas, resultando em Estórias de Usuário para cada Épico. Os recursos e épicos são usados para orientar discussões nas sessões de refinamento do registro posterior e planejamento de sprint . Nesse momento, as Estórias de usuário que saem dessas discussões são refinadas , priorizadas e, no Sprint Planning , aceito em sprints para implementação.

É apenas decomposição do problema. São apenas histórias, exceto em tamanhos diferentes.

Eu pessoalmente prefiro não rotular seus tamanhos, mas se você fizer isso, tudo bem. Pergunte a você qual é a definição em seu espaço de trabalho.

A Hierarquia do Backlog do Produto depende bastante do tamanho do produto e de sua modularidade (número de áreas de produto definidas).

Para projetos pequenos: Epic > A história é mais que suficiente; e você chama o "recurso". Grandes projetos podem se tornar semelhantes a: Novel > Tema > Épico > Recurso > História

O melhor exemplo pode ser o seguinte:
Novel = MS Office
Tema = MS Word / MS Excel ...
Épico = Tabelas / Diretório de fontes ...
Recursos = Esquema de cores de tabela / tabela básica com células ...
Histórias (para o recurso 'Tabelas básicas' dentro da epopéia 'Tabelas') = Adicionar Tabela / Desenhar Tabela / Inserir Coluna Bruta / Inserir ...

O que acredito ser benéfico ter em mente ao definir seu próprio escalonamento de backlog é: 1. História: a) sempre viável dentro de um sprint; b) nem sempre testável para usuários finais
2. Épico / Recurso: a) não se encaixa em uma duração de sprint e precisa ser decomposta; b) sempre deve ser testável para os usuários finais; c) sempre vendável, pode ser rentabilizado - obtenha o ROI calculado para si. 3. Ao considerar adicionar ou não Epic > seção Recurso ou escolha Epic > História: Eu recomendaria inserir Feature entre Epic e Story somente quando: Epic não couber em 1 Release, então você precisa definir o elemento shippable que irá caber em 1 Release duration .

Espero que isso seja útil.

Na nossa organização, temos o seguinte:

Tema = usado para agrupar uma coleção de histórias

Epic = Descreve uma grande história de usuário (na verdade, um requisito) que precisa ser dividida em histórias de usuário

Recursos = Faz o que diz na lata, descreve uma característica do produto necessário

História do usuário = Este é o nível mais baixo de detalhe do qual as tarefas são derivadas.

Nossa organização tem mais de 2.000 desenvolvedores, portanto, a resposta a essa pergunta é importante para uma comunicação fluente e clara entre as centenas de equipes ágeis que temos trabalhando juntas em nosso produto comum. Para uma organização muito pequena, você pode ter uma estrutura muito simples que nem precisa ser hierárquica (como outros já responderam). No entanto, para grandes organizações, há definitivamente a necessidade de alguma hierarquia organizada, escalonada e consistente - e aí reside o problema em se esforçar para fazer uma hierarquia de algo que não é estritamente hierárquico.

A propósito, nos referimos a cada um desses níveis díspares como "itens de trabalho". Algumas organizações (incluindo alguns dos entrevistados acima) referem-se a níveis díspares como Histórias ou Estórias de Usuário (e também no passado), mas achamos isso muito ambíguo, então agora nos referimos a eles genericamente como Itens de Trabalho.

O melhor que temos "oficialmente" feito até agora é seguir a estrutura SAFe de Temas de Investimento e Épicos nos Negócios de Dean Leffingwell no topo (e segundo no topo) da hierarquia, depois em Recursos e, finalmente, em Histórias sob Características. De acordo com o Agile, as Tarefas estão sempre em Histórias, portanto, temos o cuidado de não reutilizar esse termo mais acima. Escolhemos seguir o SAFe para pelo menos ter ALGUM consistência em todas as nossas equipes.

Mas isso ainda é insuficiente para as nossas necessidades. Definimos um Recurso como uma entrega claramente valiosa para um consumidor de nosso produto de software (ou seja, listamos esses Recursos em nossos anúncios de futuros lançamentos). E definimos uma História como uma quantidade menor de escopo e trabalho que pode ser entregue em um único Sprint por uma única equipe de desenvolvimento Ágil. Também estamos agora COMEÇANDO a seguir a definição SAFe de Tema de Investimento e Épico Comercial no nível do Portfólio (e não abaixo deste nível). E estamos começando a não usar nossas antigas definições de "Theme" e "Epic".

Estamos agora lentamente evoluindo nessa direção, mas as engrenagens do progresso se movem lentamente. Ainda estamos lutando para dividir o trabalho em partes menores para que possamos definir o trabalho e executá-lo sem problemas por várias equipes. Para fazer isso, vemos a necessidade de um "Sub-recurso" que seja menor que um recurso, mas maior que uma história. Os sub-recursos podem ser usados para trechos de trabalho feitos em uma equipe de recurso por CADA INDIVÍDUO ou em partes de trabalho feitas por uma equipe ÚNICA em momentos diferentes (em Sprints diferentes ou até mesmo em versões diferentes).

Também precisamos de vários níveis hierárquicos entre o Feature e o Business Epic, mas ainda não resolvemos esse problema, além de apenas chamá-los de "Temas" - que sabemos que não é o termo correto, pois é facilmente confundido com SAFe. Temas de Investimento. Para alguns grandes projetos (lançamentos), temos até 5-8 diferentes níveis hierárquicos, cada um dividindo o trabalho em partes cada vez menores. Você pode pensar nesses temas como "Grupos de recursos", mas esse não é necessariamente o termo correto.

Acho importante tentar usar termos que ofereçam clareza em vez de ambigüidade. Assim, qualquer um que se refira a uma História significa a menor unidade de trabalho que pode ser feita em uma única Sprint (exceto para as Tarefas na História) e Sub-Recurso significa a menor unidade de trabalho em um Recurso que pode ser feito por uma única. equipe. Da mesma forma, um grupo de recursos é um nível hierárquico acima do recurso. Acima disso, fica um pouco confuso, por isso normalmente só os chamamos de Temas e permitimos que os Temas sejam pais e filhos de outros Temas. Tentamos restringir os níveis de recurso, sub-recurso e história a um único nível cada (os recursos não devem ser filhos de outros recursos), mas ainda não temos 100% de êxito em restringir isso.

Eu sei que poderíamos usar "Tags" para organizar parte disso, mas as tags não nos fornecem a estrutura organizacional de divisão de trabalho que precisamos para categorizar o trabalho entre todas as nossas equipes. Por definição, as tags são ambíguas (relacionamentos muitos-para-muitos), mas uma hierarquia é estritamente um-para-muitos.

O resultado é que este ainda é um trabalho em andamento para nós, e ainda estamos lutando contra isso. Mas aderir às definições SAFe de Tema, Épico, Característica e História nos leva na direção certa!