Отношение между пользовательской историей, особенностью и эпопеей?


111

Как человек, который еще новичок в гибкой разработке, я не уверен, что полностью понимаю взаимосвязь или разницу между пользовательской историей, функцией и эпопеей.

Согласно этому вопросу , особенность представляет собой сборник рассказов. Один из ответов предполагает, что особенность на самом деле эпическая. Значит, черты и эпические сюжеты считаются одним и тем же, то есть в основном это коллекция связанных пользовательских историй?

Наш руководитель проекта настаивает на том, что существует иерархическая структура:

Epic -> Особенности -> Пользовательские истории

И это в основном все пользовательские истории должны попадать в эту структуру. Поэтому все пользовательские истории должны попадать под зонтичную функцию, а все функции должны попадать под эпопею.

Для меня это звучит неловко. Может кто-нибудь объяснить, как связаны пользовательские истории, функции и эпопеи? Или есть статья, которая четко обрисовывает различия?


15
Единственный реальный ответ на это - «нет окончательного ответа». Интерпретация каждого человека / компании немного отличается. Для меня особенности и пользовательские истории одинаковы, другие люди могут делать различия (что мне кажется глупым), но ни то, ни другое не является правильным или неправильным. Я не думаю, что кто-то на земле может сказать вам окончательно: «Это эпопея, это история, это особенность» ... хотя многие попробуют!
MattDavey

Я не согласен. Функция НЕ является историей пользователя, а эпопея - историей пользователя. Примером того, как выглядит функция, является «оплата через PayPal». В качестве примера пользовательской истории, как клиент на iPhone, я хочу купить молоток и расплатиться своей учетной записью PayPal, чтобы мне не приходилось вводить информацию о моей кредитной карте. Более того, я бы посчитал эту историю эпической, потому что для ее реализации потребуется больше дня.
Джои Герра

3
@JoeyGuerra Как мы используем эти термины, вы только что написали 1 пользовательскую историю, которая приведет к 1 функции. Мы вообще не используем «эпос», но наше общее слово - «проект», что, в качестве примера, будет включать корзину для покупок и все формы оплаты (и, возможно, более взаимосвязанные части).
Изката

Ответы:


93

На самом деле это очень общий термин. Существует много способов их интерпретации, в зависимости от литературы и от того, как люди их видят. Возьми все, что я скажу, с огромным зерном соли.

Обычно Epic содержат очень глобальные и не очень четко определенные функциональные возможности в вашем программном обеспечении. Это очень широко. Обычно он разбивается на более мелкие пользовательские истории или функции, когда вы пытаетесь разобраться в них и привести их в соответствие с гибкой итерацией. Пример :

Epic
- позволяет клиенту управлять своей учетной записью через Интернет

Feature и User Story - это более специфичные функции, которые вы можете легко протестировать с помощью приемочных тестов. Часто рекомендуется, чтобы они были достаточно гранулированными, чтобы поместиться в одну итерацию.

Функции обычно имеют тенденцию описывать то, что делает ваше программное обеспечение:

Особенность
- Редактирование информации о клиенте через веб-портал

Пользовательские истории имеют тенденцию выражать то, что пользователь хочет сделать:

Пользовательская история
Как банковский служащий,
я хочу иметь возможность изменять информацию о клиентах,
чтобы я мог постоянно обновлять ее.

Я не думаю, что на самом деле существует иерархия между ними, но вы можете иметь такую, если хотите, или если она подходит вам. Пользовательская история может быть конкретным обоснованием для функции или конкретным способом сделать это. Или это может быть наоборот. Функция может быть способом реализации пользовательской истории. Или они могут обозначать одно и то же. Вы можете использовать и: Пользовательские истории, чтобы определить, что приносит бизнес-ценность, и функцию, описывающую ограничения программного обеспечения.

История пользователя : как клиент, я хочу расплачиваться наиболее популярными кредитными картами.
Функция поддержки GOV-TAX-02 XML API правительства.

Существует также вопрос сценария, который, как правило, представляет собой сюжет «Особенность / Пользователь». Они обычно соответствуют чисто приемочным испытаниям. Например

Сценарий : снятие денег
Учитывая, что у меня есть 2000 $ на моем банковском счете,
когда я снимаю 100 $,
тогда я получаю 100 $ наличными
И мой баланс составляет 1900 $

Вот как мы определяем те термины, где я работаю . Эти определения далеки от математического определения или стандартизированного термина. Это как различие между политиком правого крыла или политиком левого толка. Это зависит от того, где вы живете. В Канаде то, что считается правым, в Соединенных Штатах может считаться левым. Это очень изменчиво.

Серьезно, я бы не слишком волновался об этом. Важно, чтобы все в команде согласились с определением, чтобы вы могли понять друг друга. Некоторые методы, такие как scrum, имеют тенденцию определять их более формально, но выбирайте, какая работа для вас, и оставьте все остальное. В конце концов, разве не гибко в отношении отдельных лиц и взаимодействий над процессами и инструментами и рабочим программным обеспечением над всеобъемлющей документацией ?


17
+1 за «Важно, чтобы все в команде согласились с определением»
MattDavey

Где вариант использования вписывается в эту иерархию?
Ренегрин

Это будет зависеть от того, как вы определите вариант использования в своей команде. Предположим, это стиль использования RUP. В этом случае сценарий использования будет играть роль сценария и сюжета, смешивая их, и, таким образом, в RUP требования к программному обеспечению указаны только в сценарии использования. Спросите себя: какой должна быть история ? А какой должен быть вариант использования ? Вам нужны оба? Почему? Лично я бы использовал либо историю, либо вариант использования, но не оба, потому что у них одна цель. Тем не менее, это всегда зависит. Если у вас есть роль для каждого, используйте каждого из них; если нет, используйте тот, который вы знаете :).
Лоран Бургало-Рой

1
Единственное дополнение, над которым я работал, заключается в том, что вы вряд ли когда-либо завершите все, что вы идентифицируете в эпосе. Некоторые пользовательские истории просто не смогут попасть в верхнюю часть журнала.
августа

2
Это всего лишь описания проблемы, которая должна быть решена на разных высотах. Эпос имеет смысл для высшего руководства. Особенности - то, что маркетологи хотят, чтобы эпопея предоставила. Эта точка зрения работает для менеджеров среднего звена. Пользовательские истории разбивают работу для людей, которые должны создать решение, для разработчиков и низкоуровневого управления.
rfportilla

36

Эпопея : очень большая пользовательская история, которая в итоге разбивается на более мелкие истории.

История пользователя: определение требования очень высокого уровня, содержащее достаточно информации, чтобы разработчики могли получить разумную оценку усилий по ее реализации.

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

Характеристика : Отличительная характеристика или возможности программного приложения или библиотеки (например, производительность, портативность или функциональность).

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


26

Я предостерегаю вас от применения слишком жесткой иерархии к этим терминам. Мы пытались сделать это на моей предыдущей работе. Дважды. Обе попытки были разными, и оба раза мы обнаружили, что излишне ограничивали себя. Единственной константой было определение пользовательской истории . С точки зрения планирования история является основным строительным блоком проекта. Большие термины (эпические, художественные и т. Д.) - это просто теги . Теги - это простой способ позволить истории существовать как часть нескольких эпосов и нескольких функций одновременно. Не стоит умственных усилий быть более строгими, чем это.

Теги работают на Stack Exchange, и они могут работать на вас тоже.


1
Именно так. Я нажал на этот вопрос, надеясь найти ответ, подобный этому.
Зимано

23

То, как мы работаем с Epics, Stories и Features, выглядит следующим образом

В начале проектного цикла мы придумали Epics . Это высокоуровневые, почти маркетинговые, функциональные точки. То, что вы можете использовать в резюме, например,

Наш новый веб-сайт позволит клиентам просматривать продукты, просматривать их наличие и цены, размещать заказы и просматривать историю своих прошлых заказов.

Это приводит к эпосам, таким как

  • Просмотреть каталог продукции
  • Посмотреть доступность
  • Посмотреть цены
  • Разместить заказ
  • Посмотреть историю заказов

Они написаны в виде пользовательских историй (например, как клиент, я хочу просмотреть каталог продуктов, чтобы я мог принять обоснованное решение о покупке), но они служат лишь отправной точкой для десяти того, что будет фактически разработано и выпущено.

Эти эпосы затем разбиваются на истории пользователей . Это фактические сквозные поездки пользователей, очень ограниченные по объему и определяемые таким образом, чтобы их можно было оценивать и планировать независимо, а также разрабатывать , тестировать и выпускать за один цикл выпуска.

Пользовательская история - это единица доставки. Это пользовательская история, которая завершена или не завершена, запускается или не запускается.

Epic может привести к большому количеству пользовательских историй, не все будут разработаны или выпущены одновременно.

Например, эпопея «Обзор продуктов» может быть разбита на

  • Навигация по иерархии категорий
  • Поиск по ключевым словам
  • Фильтр по атрибутам товара (например, диапазон цен, марка, цвет, размер и т. Д.)

Опять же, каждый из них будет записан в формате, например, как клиент, я хочу перемещаться по иерархии категорий, чтобы я мог просматривать продукты и переходить к продукту, наиболее подходящему для моих нужд.

Как правило, для большинства наших проектов у нас есть десятки эпосов и сотни историй.

Теперь, когда мы проходим жизненный цикл истории, мы помечаем эти истории с помощью функции s. Например, все истории о поиске и поиске, а также об акциях и ценах будут отмечены, скажем, «каталогом продукции». Рассказы о размещении заказов, связанные с оплатой кредитной картой, могут быть помечены ярлыком «кредитная карта», а те, что связаны с оплатой PayPal, будут помечены ярлыком «paypal».

Эти ярлыки служат для группирования историй, которые принадлежат друг другу, не потому, что они представляют собой разные типы выполнения одного и того же действия (например, все истории с размещением заказов), а потому, что они должны быть выпущены вместе.

Например, история «размещения заказа с помощью кредитной карты» относится к той же эпопее, что и история «размещения заказа с помощью PayPal», но их не нужно выпускать вместе.

Принимая во внимание, что история «размещения заказа с помощью кредитной карты», история «обработки возврата денег на кредитную карту» и история «позволить клиентам управлять своими сохраненными кредитными картами на своем счете», похоже, принадлежат друг другу , Все они были бы помечены меткой «кредитная карта». т.е. все они будут принадлежать функции «Кредитная карта». Не очень полезно высвобождать возможность размещать заказ с оплатой кредитной картой, если невозможно обработать возврат возврата средств в PayPal или если невозможно управлять своими сохраненными кредитными картами в своей учетной записи.

Примечание : как правило, это так. Это, в конце концов, деловое решение. Если важно выходить на рынок, может существовать законная причина, чтобы жить с одним из них, а не с другим.

Таким образом, «Эпики» служат для разбивки на (связанные, но отдельные) истории, которые можно разрабатывать независимо, а «Функции» служат для группировки историй, которые должны быть выпущены вместе.

Можно сказать, что Epics разлагаются на пользовательские истории, а пользовательские истории объединяются в функции. Истории, которые принадлежат какой-либо функции, обычно встречаются в эпосах. Таким образом, эпосы и особенности ортогональны, а не в строгой иерархии.

В нашем способе работы, когда эпопеи разбиты на истории, они теряют свою цель. Мы не оцениваем и не планируем Эпос. Мы не отслеживаем прогресс на Epics. Мы не выпускаем Epics. Мы оцениваем, планируем и отслеживаем истории пользователей. И мы выпускаем Особенности.


4
«... Таким образом, Epics служат для разделения на (связанные, но отдельные) истории, которые можно разрабатывать независимо, в то время как функции служат для группировки историй, которые должны быть выпущены вместе ...» Момент Эврика!
Генри Родригес

Этот пост заслуживает большего! Престижность!
Gooshan

10

Я согласен, как и многие ответы, что на самом деле нет правильных ответов, поскольку это просто термины, которые могут варьироваться в зависимости от того, на каком лагере Agile вы находитесь, и вы определенно можете создать свой собственный лагерь, если все в вашей команде, включая внешних заинтересованных лиц понять, что они имеют в виду. Это просто способ организовать ваше требование.

Мне нравится ответ из лагеря Майка Кона, и он довольно прост.

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

  • Эпос это просто большая история (иерархическая)
  • Тема - это просто группа рассказов (очень похоже на тег)

Он на самом деле избегает термина «особенность». Я предполагаю, что это главным образом потому, что это был общий термин в традиционном мире водопада. Многие Agile лагеря, как правило, используют разные термины, чтобы подчеркнуть различия.

Таким образом, в определении вашего PM, Feature находится где-то посередине иерархии Epic-Story.

Вот моя инфо-графика этого определения из моей статьи InfoQ http://www.infoq.com/articles/visualize-big-picture-agile ;-)

введите описание изображения здесь


6

Особенности и эпосы не одно и то же.

  • Функция не является историей пользователя.
  • Эпос - это история пользователя.
  • Пользовательская история может быть эпической.
  • Пользовательская история может содержать много функций.
  • Функция может выполнять от 1 до многих пользовательских историй.

На этапах планирования обсуждения приводят к созданию пользовательских историй, которые обычно обозначаются как Epics, поскольку усилия по внедрению решений для них слишком велики, чтобы их можно было выполнить за несколько дней. Особенности продукта определяются на этом этапе. Но это всего лишь побочный продукт обсуждения. Особенности затем используются для планирования продукта дорожной карты, которая является отдельной дискуссии.

В Эпос принимаются и обсуждаются далее, в результате чего Истории пользователей для каждого Epic. В особенности и эпос используются для привода обсуждения в Отставание утонченности и Sprint планирования сессий. В это время пользовательские истории, полученные в результате этих обсуждений, уточняются , расставляются по приоритетам и в Sprint Planning принимаются в виде спринтов для реализации.


4

Это просто проблема разложения. Это просто истории, за исключением разных размеров.

Лично я предпочитаю не маркировать их размеры, но если вы это сделаете, то это тоже хорошо. Спросите у своего ПМ, какое определение у вас на рабочем месте.


1

В нашей организации более 2000 разработчиков, поэтому ответ на этот вопрос важен для свободного и ясного общения между сотнями команд Agile, которые работают вместе над нашим общим продуктом. Для очень маленькой организации у вас может быть очень простая структура, которая даже не должна быть иерархической (как ответили другие). Однако для крупных организаций, безусловно, существует необходимость в некоторой организованной, масштабированной, последовательной иерархии - и в этом заключается проблема в стремлении создать иерархию из чего-то, что не является строго иерархическим.

Кстати, мы называем каждый из этих разнородных уровней «рабочими элементами». Некоторые организации (в том числе некоторые из респондентов выше) называют разные уровни «Истории» или «Пользовательские истории» (и у нас тоже в прошлом), но мы сочли это слишком двусмысленным, поэтому теперь мы называем их в общем как «Рабочие элементы».

Лучшее, что мы «официально» сделали до сих пор, - это следуем структуре SAFe Дина Леффингвелла «Инвестиционные темы и бизнес-эпосы», находящейся на вершине (и второй сверху) иерархии, затем «Функции» и, наконец, «Истории» «Функции». По словам Agile, Задачи всегда находятся под историями, поэтому мы стараемся не использовать этот термин выше. Мы решили следовать SAFe, чтобы, по крайней мере, иметь НЕКОТОРЫЕ согласованность во всех наших командах.

Но этого все еще недостаточно для наших нужд. Мы определяем Функцию как явно ценную поставку для потребителя нашего программного продукта (т.е. мы перечисляем эти Функции в наших объявлениях о будущих версиях). И мы определяем Story как меньшее количество объема и работы, которые могут быть выполнены в одном Sprint одной командой разработчиков Agile. Мы также начинаем следовать БЕЗОПАСНОМУ определению инвестиционной темы и бизнес-эпоса на уровне портфеля (и не ниже этого уровня). И мы НАЧИНАЕМ НЕ использовать наши старые определения «Theme» и «Epic».

Сейчас мы медленно развиваемся в этом направлении, но колеса прогресса медленно вращаются. Мы все еще боремся с тем, как разделить работу на куски размером в куски, чтобы мы могли определить работу и выполнить ее гладко несколькими командами. Для этого мы видим необходимость в «подфункции», которая меньше, чем функция, но больше, чем история. Подфункции могут использоваться для фрагментов работы, выполняемой над Элементом КАЖДОЙ ИНДИВИДУАЛЬНОЙ командой, или для фрагментов работы, выполняемой одной командой в разное время (в разных Спринтах или даже в разных Релизах).

Нам также необходимо несколько иерархических уровней между Feature и Business Epic, но мы еще не решили этот, кроме как просто назвать их «Темы» - что, как мы знаем, не является правильным термином, поскольку его легко спутать с Инвестиционными темами SAFe. Для некоторых крупных проектов (выпусков) у нас есть 5-8 различных иерархических уровней, каждый из которых разбивает работу на все более мелкие куски. Вы можете думать об этих темах как о «группах функций», но это не обязательно правильный термин.

Я думаю, что важно попытаться использовать термины, которые предлагают ясность, а не двусмысленность. Таким образом, любой, кто ссылается на Историю, означает наименьшую единицу работы, которую можно выполнить за один Спринт (кроме Задач в рамках Истории), а Подфункция означает наименьшую единицу работы над Функцией, которую может выполнить одна команда. Аналогично, группа объектов находится на один иерархический уровень выше функции. Кроме того, это становится немного размытым, поэтому мы обычно называем их Темами, и мы разрешаем Темы как родителям и детям других Тем. Мы пытаемся ограничить уровни Feature, Sub-Feature и Story до одного уровня каждый (функции не должны быть дочерними по отношению к другим функциям), но пока мы не на 100% успешны в ограничении этого.

Я знаю, что мы могли бы использовать «Теги», чтобы организовать кое-что из этого, но теги не дают нам организационную структуру разбивки работ, в которой мы должны классифицировать работу между всеми нашими командами. По определению, теги неоднозначны (отношения «многие ко многим»), но иерархия строго «один ко многим».

Суть в том, что это все еще в стадии разработки для нас, и мы все еще боремся с этим. Но соблюдение БЕЗОПАСНЫХ определений «Тема», «Эпический», «Особенность» и «История» заставляет нас двигаться в правильном направлении!


1

Иерархия невыполненных заказов продукта в значительной степени зависит от размера продукта и его модульности (количество определенных областей продукта).

Для небольших проектов: Epic> Story более чем достаточно; и вы называете либо «особенность».
Крупные проекты могут стать похожими на: Роман> Тема> Эпический> Особенность> История

Лучшим примером может быть следующее:
Novel = MS Office
Theme = MS Word / MS Excel ...
Epic = Таблицы / Каталог шрифтов ...
Возможности = Базовая таблица / Цветовая схема таблицы / Операции с ячейками ...
Рассказы (для ' Элемент Basic Tables в Epic «Tables» = Добавить таблицу / Нарисовать таблицу / Вставить необработанный / Вставить столбец ...

Я считаю, что полезно иметь в виду, когда вы определяете свое собственное масштабирование отставания:
1. История: а) всегда выполнимая в течение одного спринта; б) не всегда проверяемые для конечных пользователей
2. Эпик / Feature: а) не подходит один длительности спринта и должны быть разложено; б) всегда должен быть тестируемым для конечных пользователей; c) всегда могут быть отправлены, могут быть монетизированы - рассчитать рентабельность инвестиций для него
3. При рассмотрении вопроса добавить или нет раздел Epic> Feature или придерживаться Epic> Story: я рекомендую вставлять Feature между Epic и Story только в том случае, если: Epic notn ' t fit даже 1 Release, поэтому вам нужно определить отправляемый элемент, который будет соответствовать 1 Release .

Надеюсь, это полезно.


-1

В нашей организации у нас есть следующее:

Тема = Используется для группировки коллекции историй

Epic = Описывает большую пользовательскую историю (по правде говоря, требование), которую нужно разбить на пользовательские истории

Особенности = делает то, что написано на банке, описывает особенность требуемого продукта

Пользовательская история = Это самый низкий уровень детализации, из которого получены задачи.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.