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

Como alguém que ainda é novo no Agile, não sei se entendi completamente o relacionamento ou a diferença entre a história do usuário, o recurso e o épico.

De acordo com essa pergunta , um recurso é uma coleção de histórias. Uma das respostas sugere que um recurso é realmente um épico. Então, recursos e épicos são considerados a mesma coisa, que é basicamente uma coleção de histórias de usuários relacionadas?

Nosso gerente de projeto insiste que há uma estrutura hierárquica:

Épico -> Recursos -> Histórias de usuários

E que basicamente todas as histórias de usuários devem estar dentro dessa estrutura. Portanto, todas as histórias de usuários devem se enquadrar em um recurso abrangente e todos os recursos devem se enquadrar em um épico.

Para mim, isso parece estranho. Alguém pode esclarecer como as histórias, os recursos e os épicos do usuário estão relacionados? Ou existe um artigo que descreve claramente as diferenças?

Eles são termo muito genérico, na verdade. 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.

Geralmente, uma Epopeia compreende uma funcionalidade muito global e não muito bem definida em seu software. É muito amplo. Geralmente, ele é dividido em menor história ou recurso do usuário quando você tenta entender o sentido e ajustá-lo a uma iteração ágil. Exemplo:

Épico
- Permite ao cliente gerenciar sua própria conta via Web

O recurso e a história do usuário são funcionalidades mais específicas, que você pode testar facilmente com testes de aceitação. Geralmente, recomenda-se que sejam granulares o suficiente para caber em uma única iteração.

Os recursos geralmente tendem a descrever o que o seu software faz:

Recurso
- Edição das 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,
desejo poder modificar as informações do cliente
para mantê-las atualizadas.

Eu não acho que exista realmente uma hierarquia entre os dois, mas você pode ter uma se quiser ou se encaixar em 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 de usuário. Ou eles podem denotar a mesma coisa. Você pode usar os dois: Histórias de usuários para definir o que agrega valor e recurso aos negócios para descrever as restrições do software.

História do usuário : como cliente, quero pagar com os cartões de crédito mais populares. Suporte a
recursos da API XML GOV-TAX-02 do governo.

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

Cenário : Retirada de dinheiro
Dado que tenho 2000 $ na minha conta bancária
Quando retiro 100 $
Depois recebo 100 $ em dinheiro
E meu saldo é 1900 $

É assim que definimos os termos em que 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 da equipe concordem com uma definição para que vocês possam se entender. Alguns métodos como o scrum tendem a defini-los de maneira mais formal, mas escolha o que funciona para você e deixe o resto. Afinal, não é ágil sobre indivíduos e interações em processos e ferramentas e software de trabalho em documentação abrangente ?

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

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

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

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

http://en.wikipedia.org/wiki/Software_feature

Aconselho você a não aplicar uma hierarquia muito rígida a esses termos. Tentamos fazer isso no meu trabalho anterior. Duas vezes. As duas tentativas foram diferentes e, nas duas vezes em que descobrimos, tínhamos nos limitado desnecessariamente. A única constante foi a definição de uma história de usuário . Do ponto de vista do planejamento, uma história é o alicerce básico de um projeto. Os termos maiores (épico, recurso 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ários épicos 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 também podem funcionar para você.

A maneira como trabalhamos com épicos, histórias e recursos é a seguinte

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

Nosso novo site permitirá que os clientes pesquisem produtos, visualizem disponibilidade e preços, façam pedidos e vejam o histórico de pedidos anteriores

Isso leva a épicos como

• Navegar no catálogo de produtos
• Ver disponibilidade
• Ver preços
• Faça a encomenda
• Exibir histórico de pedidos

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

Essas epopeias são posteriormente divididas em histórias de usuário . Essas são jornadas reais de usuário de ponta a ponta, com escopo muito limitado e definidas de uma maneira que pode ser estimada e planejada de forma independente, e desenvolvida , testada e lançada em um ciclo de liberação.

A história do usuário é a unidade de entrega. É a história do usuário que está completa ou não, entra no ar ou não.

Uma epopeia pode resultar em um grande número de histórias de usuários, nem todas serão desenvolvidas ou lançadas ao mesmo tempo.

Como exemplo, a epopeia Navegar no catálogo de produtos pode ser dividida em

• Navegar na hierarquia de categorias
• Pesquisa por palavra-chave
• Filtrar por atributos do produto (por exemplo, faixa de preço, marca, cor, tamanho etc.)

Novamente, cada um deles seria escrito no formato, por exemplo, como cliente, desejo navegar na hierarquia de categorias, para que eu possa navegar pelos produtos e detalhar o produto mais adequado às minhas necessidades.

Geralmente, na maioria dos nossos projetos, temos dezenas de épicos e centenas de histórias.

Agora, ao longo do ciclo de vida da história, marcamos essas histórias com os Recursos s. Por exemplo, todas as histórias de navegação, pesquisa, estoque e preços serão marcadas com, por exemplo, 'catálogo de produtos'. As histórias de pedidos de compras relacionadas ao pagamento com cartão de crédito podem ser marcadas com uma etiqueta 'cartão de crédito' e aquelas relacionadas a pagamento com PayPal serão marcadas com uma etiqueta 'paypal'.

Esses rótulos servem para agrupar histórias que pertencem umas às outras, não porque são tipos diferentes de executar a mesma atividade (por exemplo, todas as histórias de pedidos por local), mas porque elas devem ser liberadas juntas.

Por exemplo, a história "fazer um pedido com pagamento por cartão de crédito" pertence ao mesmo épico da história "fazer um pedido com pagamento por PayPal", mas eles não precisam ser liberados juntos.

Visto que a história "fazer um pedido com pagamento por cartão de crédito", a história "processando um reembolso devolvido em um cartão de crédito" e a história "permitindo que os clientes administrem seus cartões de crédito salvos em sua conta" parecem pertencer uma à outra . Todos teriam sido marcados com o rótulo do recurso "cartão de crédito". ou seja, todos eles pertenceriam ao recurso "Cartão de crédito". Não é muito útil liberar a capacidade de fazer um pedido com pagamento por cartão de crédito, se não for possível processar um reembolso no PayPal ou se não for possível gerenciar os cartões de crédito salvos em sua conta

Nota : Como regra geral, é isso. Esta é, no final, uma decisão de negócios. Se o tempo de colocação no mercado for importante, pode haver uma razão legítima para entrar no mercado com um desses e não com o outro.

Assim, as Epopeias servem para dividir em histórias (relacionadas, mas separadas) que podem ser desenvolvidas independentemente, enquanto os Recursos servem para agrupar histórias que devem ser liberadas.

Você poderia dizer que as Epopeias se decompõem em Histórias de Usuário, e as Histórias de Usuário são compostas em Recursos. As histórias que pertencem a um recurso geralmente são épicas. Portanto, Epopeias e Recursos são ortogonais, não em uma hierarquia estrita.

Em nossa maneira de trabalhar, uma vez que as Epopeias foram divididas em histórias, elas perdem seu propósito. Não estimamos ou planejamos épicos. Nós não acompanhamos o progresso nas Epopeias. Não lançamos Epics. Estimamos, planejamos e acompanhamos histórias de usuários. E lançamos Recursos.

Concordo, como muitas respostas, que realmente não há respostas corretas, uma vez que estes são apenas termos que podem variar dependendo do campo do Agile em que você se baseia e você pode definitivamente criar o seu próprio campo , desde que todos da sua equipe, incluindo as partes interessadas externas entender o que eles significam. É apenas uma maneira de organizar suas necessidades.

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

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• Épica é apenas uma grande história (hierárquica)
• O tema é apenas um grupo de histórias (praticamente como tag)

Na verdade, ele evita o termo "Recurso". Suponho que seja principalmente porque era um termo comum no mundo tradicional das cachoeiras. Muitos camp Agile tendem a usar termos diferentes para enfatizar as diferenças.

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

Aqui está minha informação gráfica desta definição no meu artigo na InfoQ http://www.infoq.com/articles/visualize-big-picture-agile ;-)

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 épica.
• Uma história de usuário pode conter muitos recursos.
• Um recurso pode atender de 1 a muitas histórias de usuário.

Nas fases de planejamento, as discussões resultam em Histórias de Usuário, normalmente 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 esta fase. Mas isso é apenas um subproduto da discussão. Os recursos são usados ​​para planejar um roteiro do produto, que é uma discussão separada.

As epopeias são tomadas e discutidas mais adiante, resultando em histórias de usuário para cada epopeia. Os Recursos e as Epopeias são usados ​​para conduzir discussões nas sessões de Refinamento de Backlog e Planejamento de Sprint . Nesse momento, as histórias de usuário que saem dessas discussões são refinadas , priorizadas e, no Sprint Planning , aceitas em sprints para implementação.

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

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

Nossa organização tem mais de 2.000 desenvolvedores; portanto, a resposta a esta pergunta é importante para uma comunicação clara e fluente entre as centenas de equipes Agile que trabalhamos 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 outras pessoas responderam). No entanto, para grandes organizações, definitivamente existe a necessidade de uma hierarquia organizada, dimensionada e consistente - e é aí que reside o problema de tentar tornar uma hierarquia fora de algo que não seja estritamente hierárquico.

Aliás, nos referimos a cada um desses níveis díspares como "itens de trabalho". Algumas organizações (incluindo alguns dos entrevistados acima) se referem a níveis díspares como Histórias ou Histórias de usuários (e também temos no passado), mas achamos isso ambíguo demais, portanto, agora nos referimos a elas genericamente como Itens de Trabalho.

O melhor que "oficialmente" fizemos até agora é seguir a estrutura SAFe de Dean Leffingwell, de Temas de Investimento e Épicas de Negócios, estando no topo (e o segundo do topo) da hierarquia, depois Recursos sob esse e, finalmente, Histórias sob Recursos. De acordo com o Agile, as tarefas estão sempre no Stories, por isso tomamos cuidado para não reutilizar esse termo mais alto. Optamos por seguir o SAFe para ter pelo menos ALGUMA consistência em todas as nossas equipes.

Mas isso ainda é insuficiente para 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 das próximas versões). 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. Agora também estamos começando a seguir a definição da SAFe de Tema de investimento e Épica comercial no nível do portfólio (e não abaixo deste nível). E estamos começando a não usar nossas definições antigas de "Tema" e "Épica".

Agora estamos evoluindo lentamente nessa direção, mas as rodas do progresso rangeram 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" menor que um recurso, mas maior que uma história. Os sub-recursos podem ser usados ​​para partes do trabalho realizado em um recurso por CADA equipe INDIVIDUAL, ou partes do trabalho realizado por uma equipe ÚNICA em momentos diferentes (em diferentes sprints ou 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 o resolvemos, a não ser chamá-los de "Temas" - que sabemos que não é o termo correto, pois é facilmente confundido com os Temas de investimento do SAFe. Para alguns grandes projetos (lançamentos), temos de 5 a 8 níveis hierárquicos diferentes, cada um dividindo o trabalho em partes cada vez menores. Você pode pensar nesses temas como sendo "grupos de recursos", mas esse também não é necessariamente o termo correto.

Eu acho que é importante tentar usar termos que ofereçam mais clareza do que ambiguidade. Portanto, qualquer pessoa que se refira a uma história significa a menor unidade de trabalho que pode ser executada em um único Sprint (exceto as tarefas da história), e Subfuncionalidade significa a menor unidade de trabalho em uma operação que pode ser executada por um único equipe. Da mesma forma, um grupo de recursos é um nível hierárquico acima do recurso. Acima disso, fica um pouco confuso, então geralmente os chamamos de Temas, e permitimos Temas como pais e filhos de outros Temas. Tentamos restringir os níveis de Recurso, Sub-Recurso e História a um único nível cada (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 de detalhamento do trabalho organizacional 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 ponto principal é que isso ainda é um trabalho em andamento para nós, e ainda estamos lutando com isso. Mas aderir às definições da SAFe de Tema, Épica, Característica e História nos leva à direção certa!

A hierarquia do backlog do produto depende bastante do tamanho do produto e de sua modularidade (número de áreas de produto definidas).

Para pequenos projetos: Epic> Story é mais que suficiente; e você chama o "recurso".
Projetos grandes podem se parecer com: Novela> Tema> Épica> Recurso> História

O melhor exemplo pode ser o seguinte:
Novela =
Tema do MS Office = MS Word / MS Excel ...
Épica = Tabelas / Diretório de fontes ...
Recursos = Tabela básica / Esquema de cores da tabela / Operações com células ...
Histórias (para ' Recurso de Tabelas Básicas na Epopéia de 'Tabelas') = Adicionar Tabela / Desenhar Tabela / Inserir Bruto / Inserir Coluna ...

O que eu acho que é benéfico ter em mente ao definir sua própria escala para backlog é:
1. História: a) sempre viável em um sprint; b) nem sempre pode ser testado para usuários finais
2. Épico / recurso: a) não se encaixa na duração de um sprint e precisa ser decomposto; b) sempre deve ser testável para usuários finais; c) sempre entregável, pode ser monetizado - obtenha o ROI calculado para isso
3. Ao considerar adicionar ou não a seção Epic> Feature ou seguir Epic> Story: eu recomendaria inserir o Feature entre Epic e Story apenas quando: A Epic não ' t cabe mesmo em 1 Release, portanto, você precisa definir o elemento que pode ser entregue para caber na duração de 1 Release .

Espero que isso seja útil.

Em nossa organização, temos o seguinte:

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

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

Recursos = Faz o que diz na lata, descreve um recurso do produto necessário

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