ti-enxame.com

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 isso questão , 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?

117
nivlam

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, é recomendado 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
- Editando as informações do cliente através do portal da web

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

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

Eu não acho que exista realmente uma hierarquia entre os dois, mas você pode ter uma se quiser ou se ela se encaixa no modo 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 traz valor e recurso de 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
Recurso suporta a 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
Como tenho 2000 $ na minha conta bancária
Quando retiro 100 $
Então recebo 100 $ em dinheiro
E meu saldo é 1900 $

É assim que definimos esses termos onde eu 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 sobre processos e ferramentas e software de trabalho em documentação abrangente?

99
Laurent Bourgault-Roy

É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

38
Robert Harvey

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 um ser Story . 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ê.

28
Michael Kristofik

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

Elas são escritas 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 então divididas em ser Stories. 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 planejado independentemente e desenvolvido , testado e liberado 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.)

Mais uma vez, cada um deles seria escrito no formato, por exemplo Como cliente, quero navegar na hierarquia de categorias, para poder pesquisar produtos e detalhar o produto mais adequado às minhas necessidades.

Geralmente, para a 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 Recurso 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 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 se dividir em histórias (relacionadas, mas separadas) que podem ser desenvolvidas independentemente, enquanto os Recursos servem para agrupar histórias que devem ser lançadas.

Você pode 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 as Histórias de usuários. E lançamos Recursos.

27
Vihung

Concordo, como muitas respostas, que realmente não há respostas corretas, pois esses são apenas termos que podem variar, dependendo do campo do Agile em que você se baseia e , você pode definitivamente criar seu próprio campo desde que todos na sua equipe, incluindo as partes interessadas externas, entendam 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 do meu artigo na InfoQ http://www.infoq.com/articles/visualize-big-picture-agile ;-)

enter image description here

10
Kulawat The Eidos

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 ser Stories, que normalmente são identificadas como Epics porque o esforço para implementar soluções para eles é grande demais para ser realizado em poucos dias. Produto Recursos são identificados durante esta fase. Mas isso é apenas um subproduto da discussão. Recursos são usados ​​para planejar um roteiro do produto, que é uma discussão separada.

Os Epics são usados ​​e discutidos mais adiante, resultando em ser Stories para cada Epic. Os Recursos e Epics são usados ​​para conduzir discussões em sessões Refinamento da lista de pendências e Sprint Planning. Nesse momento, as histórias de usuário saindo dessas discussões são refinadas, priorizadas e, em Sprint Planning , aceito em sprints para implementação.

6
Joey Guerra

É 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 a você PM qual é a definição em sua área de trabalho.

5
Martin Wickman

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, existe definitivamente a necessidade de uma hierarquia organizada, dimensionada e consistente - e é aí que reside o problema de tentar fazer uma hierarquia 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 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" 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 de 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!

2
Kirk Bryde

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".
Os grandes projetos podem se parecer com: Romance> Tema> Épico> Recurso> História

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

O que eu acredito que é benéfico ter em mente ao definir seu próprio dimensionamento para backlog é:
1. História: a) sempre viável dentro de um sprint; b) nem sempre testável para usuários finais
2. Épico/Característica: 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 ele
. Ao considerar adicionar ou não a seção Epic> Feature ou use Epic> Story: eu recomendaria inserir o Feature entre Epic e Story apenas when: A Epic não se encaixa nem mesmo em uma versão, portanto, você precisa definir o elemento que pode ser transportado que se encaixará na duração de uma versão .

Espero que isso seja útil.

1
Dmitriy Bibikov