Как человек, который еще новичок в гибкой разработке, я не уверен, что полностью понимаю взаимосвязь или разницу между пользовательской историей, функцией и эпопеей.
Согласно этому вопросу , особенность представляет собой сборник рассказов. Один из ответов предполагает, что особенность на самом деле эпическая. Значит, черты и эпические сюжеты считаются одним и тем же, то есть в основном это коллекция связанных пользовательских историй?
Наш руководитель проекта настаивает на том, что существует иерархическая структура:
Epic -> Особенности -> Пользовательские истории
И это в основном все пользовательские истории должны попадать в эту структуру. Поэтому все пользовательские истории должны попадать под зонтичную функцию, а все функции должны попадать под эпопею.
Для меня это звучит неловко. Может кто-нибудь объяснить, как связаны пользовательские истории, функции и эпопеи? Или есть статья, которая четко обрисовывает различия?
источник
Ответы:
На самом деле это очень общий термин. Существует много способов их интерпретации, в зависимости от литературы и от того, как люди их видят. Возьми все, что я скажу, с огромным зерном соли.
Обычно Epic содержат очень глобальные и не очень четко определенные функциональные возможности в вашем программном обеспечении. Это очень широко. Обычно он разбивается на более мелкие пользовательские истории или функции, когда вы пытаетесь разобраться в них и привести их в соответствие с гибкой итерацией. Пример :
Epic
- позволяет клиенту управлять своей учетной записью через Интернет
Feature и User Story - это более специфичные функции, которые вы можете легко протестировать с помощью приемочных тестов. Часто рекомендуется, чтобы они были достаточно гранулированными, чтобы поместиться в одну итерацию.
Функции обычно имеют тенденцию описывать то, что делает ваше программное обеспечение:
Особенность
- Редактирование информации о клиенте через веб-портал
Пользовательские истории имеют тенденцию выражать то, что пользователь хочет сделать:
Пользовательская история
Как банковский служащий,
я хочу иметь возможность изменять информацию о клиентах,
чтобы я мог постоянно обновлять ее.
Я не думаю, что на самом деле существует иерархия между ними, но вы можете иметь такую, если хотите, или если она подходит вам. Пользовательская история может быть конкретным обоснованием для функции или конкретным способом сделать это. Или это может быть наоборот. Функция может быть способом реализации пользовательской истории. Или они могут обозначать одно и то же. Вы можете использовать и: Пользовательские истории, чтобы определить, что приносит бизнес-ценность, и функцию, описывающую ограничения программного обеспечения.
История пользователя : как клиент, я хочу расплачиваться наиболее популярными кредитными картами.
Функция поддержки GOV-TAX-02 XML API правительства.
Существует также вопрос сценария, который, как правило, представляет собой сюжет «Особенность / Пользователь». Они обычно соответствуют чисто приемочным испытаниям. Например
Сценарий : снятие денег
Учитывая, что у меня есть 2000 $ на моем банковском счете,
когда я снимаю 100 $,
тогда я получаю 100 $ наличными
И мой баланс составляет 1900 $
Вот как мы определяем те термины, где я работаю . Эти определения далеки от математического определения или стандартизированного термина. Это как различие между политиком правого крыла или политиком левого толка. Это зависит от того, где вы живете. В Канаде то, что считается правым, в Соединенных Штатах может считаться левым. Это очень изменчиво.
Серьезно, я бы не слишком волновался об этом. Важно, чтобы все в команде согласились с определением, чтобы вы могли понять друг друга. Некоторые методы, такие как scrum, имеют тенденцию определять их более формально, но выбирайте, какая работа для вас, и оставьте все остальное. В конце концов, разве не гибко в отношении отдельных лиц и взаимодействий над процессами и инструментами и рабочим программным обеспечением над всеобъемлющей документацией ?
источник
Эпопея : очень большая пользовательская история, которая в итоге разбивается на более мелкие истории.
История пользователя: определение требования очень высокого уровня, содержащее достаточно информации, чтобы разработчики могли получить разумную оценку усилий по ее реализации.
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
Характеристика : Отличительная характеристика или возможности программного приложения или библиотеки (например, производительность, портативность или функциональность).
http://en.wikipedia.org/wiki/Software_feature
источник
Я предостерегаю вас от применения слишком жесткой иерархии к этим терминам. Мы пытались сделать это на моей предыдущей работе. Дважды. Обе попытки были разными, и оба раза мы обнаружили, что излишне ограничивали себя. Единственной константой было определение пользовательской истории . С точки зрения планирования история является основным строительным блоком проекта. Большие термины (эпические, художественные и т. Д.) - это просто теги . Теги - это простой способ позволить истории существовать как часть нескольких эпосов и нескольких функций одновременно. Не стоит умственных усилий быть более строгими, чем это.
Теги работают на Stack Exchange, и они могут работать на вас тоже.
источник
То, как мы работаем с Epics, Stories и Features, выглядит следующим образом
В начале проектного цикла мы придумали Epics . Это высокоуровневые, почти маркетинговые, функциональные точки. То, что вы можете использовать в резюме, например,
Это приводит к эпосам, таким как
Они написаны в виде пользовательских историй (например, как клиент, я хочу просмотреть каталог продуктов, чтобы я мог принять обоснованное решение о покупке), но они служат лишь отправной точкой для десяти того, что будет фактически разработано и выпущено.
Эти эпосы затем разбиваются на истории пользователей . Это фактические сквозные поездки пользователей, очень ограниченные по объему и определяемые таким образом, чтобы их можно было оценивать и планировать независимо, а также разрабатывать , тестировать и выпускать за один цикл выпуска.
Пользовательская история - это единица доставки. Это пользовательская история, которая завершена или не завершена, запускается или не запускается.
Epic может привести к большому количеству пользовательских историй, не все будут разработаны или выпущены одновременно.
Например, эпопея «Обзор продуктов» может быть разбита на
Опять же, каждый из них будет записан в формате, например, как клиент, я хочу перемещаться по иерархии категорий, чтобы я мог просматривать продукты и переходить к продукту, наиболее подходящему для моих нужд.
Как правило, для большинства наших проектов у нас есть десятки эпосов и сотни историй.
Теперь, когда мы проходим жизненный цикл истории, мы помечаем эти истории с помощью функции s. Например, все истории о поиске и поиске, а также об акциях и ценах будут отмечены, скажем, «каталогом продукции». Рассказы о размещении заказов, связанные с оплатой кредитной картой, могут быть помечены ярлыком «кредитная карта», а те, что связаны с оплатой PayPal, будут помечены ярлыком «paypal».
Эти ярлыки служат для группирования историй, которые принадлежат друг другу, не потому, что они представляют собой разные типы выполнения одного и того же действия (например, все истории с размещением заказов), а потому, что они должны быть выпущены вместе.
Например, история «размещения заказа с помощью кредитной карты» относится к той же эпопее, что и история «размещения заказа с помощью PayPal», но их не нужно выпускать вместе.
Принимая во внимание, что история «размещения заказа с помощью кредитной карты», история «обработки возврата денег на кредитную карту» и история «позволить клиентам управлять своими сохраненными кредитными картами на своем счете», похоже, принадлежат друг другу , Все они были бы помечены меткой «кредитная карта». т.е. все они будут принадлежать функции «Кредитная карта». Не очень полезно высвобождать возможность размещать заказ с оплатой кредитной картой, если невозможно обработать возврат возврата средств в PayPal или если невозможно управлять своими сохраненными кредитными картами в своей учетной записи.
Примечание : как правило, это так. Это, в конце концов, деловое решение. Если важно выходить на рынок, может существовать законная причина, чтобы жить с одним из них, а не с другим.
Таким образом, «Эпики» служат для разбивки на (связанные, но отдельные) истории, которые можно разрабатывать независимо, а «Функции» служат для группировки историй, которые должны быть выпущены вместе.
Можно сказать, что Epics разлагаются на пользовательские истории, а пользовательские истории объединяются в функции. Истории, которые принадлежат какой-либо функции, обычно встречаются в эпосах. Таким образом, эпосы и особенности ортогональны, а не в строгой иерархии.
В нашем способе работы, когда эпопеи разбиты на истории, они теряют свою цель. Мы не оцениваем и не планируем Эпос. Мы не отслеживаем прогресс на Epics. Мы не выпускаем Epics. Мы оцениваем, планируем и отслеживаем истории пользователей. И мы выпускаем Особенности.
источник
Я согласен, как и многие ответы, что на самом деле нет правильных ответов, поскольку это просто термины, которые могут варьироваться в зависимости от того, на каком лагере 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 ;-)
источник
Особенности и эпосы не одно и то же.
На этапах планирования обсуждения приводят к созданию пользовательских историй, которые обычно обозначаются как Epics, поскольку усилия по внедрению решений для них слишком велики, чтобы их можно было выполнить за несколько дней. Особенности продукта определяются на этом этапе. Но это всего лишь побочный продукт обсуждения. Особенности затем используются для планирования продукта дорожной карты, которая является отдельной дискуссии.
В Эпос принимаются и обсуждаются далее, в результате чего Истории пользователей для каждого Epic. В особенности и эпос используются для привода обсуждения в Отставание утонченности и Sprint планирования сессий. В это время пользовательские истории, полученные в результате этих обсуждений, уточняются , расставляются по приоритетам и в Sprint Planning принимаются в виде спринтов для реализации.
источник
Это просто проблема разложения. Это просто истории, за исключением разных размеров.
Лично я предпочитаю не маркировать их размеры, но если вы это сделаете, то это тоже хорошо. Спросите у своего ПМ, какое определение у вас на рабочем месте.
источник
В нашей организации более 2000 разработчиков, поэтому ответ на этот вопрос важен для свободного и ясного общения между сотнями команд Agile, которые работают вместе над нашим общим продуктом. Для очень маленькой организации у вас может быть очень простая структура, которая даже не должна быть иерархической (как ответили другие). Однако для крупных организаций, безусловно, существует необходимость в некоторой организованной, масштабированной, последовательной иерархии - и в этом заключается проблема в стремлении создать иерархию из чего-то, что не является строго иерархическим.
Кстати, мы называем каждый из этих разнородных уровней «рабочими элементами». Некоторые организации (в том числе некоторые из респондентов выше) называют разные уровни «Истории» или «Пользовательские истории» (и у нас тоже в прошлом), но мы сочли это слишком двусмысленным, поэтому теперь мы называем их в общем как «Рабочие элементы».
Лучшее, что мы «официально» сделали до сих пор, - это следуем структуре SAFe Дина Леффингвелла «Инвестиционные темы и бизнес-эпосы», находящейся на вершине (и второй сверху) иерархии, затем «Функции» и, наконец, «Истории» «Функции». По словам Agile, Задачи всегда находятся под историями, поэтому мы стараемся не использовать этот термин выше. Мы решили следовать SAFe, чтобы, по крайней мере, иметь НЕКОТОРЫЕ согласованность во всех наших командах.
Но этого все еще недостаточно для наших нужд. Мы определяем Функцию как явно ценную поставку для потребителя нашего программного продукта (т.е. мы перечисляем эти Функции в наших объявлениях о будущих версиях). И мы определяем Story как меньшее количество объема и работы, которые могут быть выполнены в одном Sprint одной командой разработчиков Agile. Мы также начинаем следовать БЕЗОПАСНОМУ определению инвестиционной темы и бизнес-эпоса на уровне портфеля (и не ниже этого уровня). И мы НАЧИНАЕМ НЕ использовать наши старые определения «Theme» и «Epic».
Сейчас мы медленно развиваемся в этом направлении, но колеса прогресса медленно вращаются. Мы все еще боремся с тем, как разделить работу на куски размером в куски, чтобы мы могли определить работу и выполнить ее гладко несколькими командами. Для этого мы видим необходимость в «подфункции», которая меньше, чем функция, но больше, чем история. Подфункции могут использоваться для фрагментов работы, выполняемой над Элементом КАЖДОЙ ИНДИВИДУАЛЬНОЙ командой, или для фрагментов работы, выполняемой одной командой в разное время (в разных Спринтах или даже в разных Релизах).
Нам также необходимо несколько иерархических уровней между Feature и Business Epic, но мы еще не решили этот, кроме как просто назвать их «Темы» - что, как мы знаем, не является правильным термином, поскольку его легко спутать с Инвестиционными темами SAFe. Для некоторых крупных проектов (выпусков) у нас есть 5-8 различных иерархических уровней, каждый из которых разбивает работу на все более мелкие куски. Вы можете думать об этих темах как о «группах функций», но это не обязательно правильный термин.
Я думаю, что важно попытаться использовать термины, которые предлагают ясность, а не двусмысленность. Таким образом, любой, кто ссылается на Историю, означает наименьшую единицу работы, которую можно выполнить за один Спринт (кроме Задач в рамках Истории), а Подфункция означает наименьшую единицу работы над Функцией, которую может выполнить одна команда. Аналогично, группа объектов находится на один иерархический уровень выше функции. Кроме того, это становится немного размытым, поэтому мы обычно называем их Темами, и мы разрешаем Темы как родителям и детям других Тем. Мы пытаемся ограничить уровни Feature, Sub-Feature и Story до одного уровня каждый (функции не должны быть дочерними по отношению к другим функциям), но пока мы не на 100% успешны в ограничении этого.
Я знаю, что мы могли бы использовать «Теги», чтобы организовать кое-что из этого, но теги не дают нам организационную структуру разбивки работ, в которой мы должны классифицировать работу между всеми нашими командами. По определению, теги неоднозначны (отношения «многие ко многим»), но иерархия строго «один ко многим».
Суть в том, что это все еще в стадии разработки для нас, и мы все еще боремся с этим. Но соблюдение БЕЗОПАСНЫХ определений «Тема», «Эпический», «Особенность» и «История» заставляет нас двигаться в правильном направлении!
источник
Иерархия невыполненных заказов продукта в значительной степени зависит от размера продукта и его модульности (количество определенных областей продукта).
Для небольших проектов: 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 .
Надеюсь, это полезно.
источник
В нашей организации у нас есть следующее:
Тема = Используется для группировки коллекции историй
Epic = Описывает большую пользовательскую историю (по правде говоря, требование), которую нужно разбить на пользовательские истории
Особенности = делает то, что написано на банке, описывает особенность требуемого продукта
Пользовательская история = Это самый низкий уровень детализации, из которого получены задачи.
источник