В чем разница между пользовательскими историями и функциями?

25

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

Может кто-нибудь объяснить разницу?

agile scrum features

23

Функция - это отдельный элемент функциональности, который может предоставить возможности для бизнеса.

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

Например, функция может быть «позволить пользователям комментировать статьи». Истории, связанные с этой функцией, могут быть:

сохранить комментарии
фильтровать комментарии для грубых слов
ограничение комментариев до 400 символов и обратная связь с пользователями
добавить капчу, чтобы боты не спамили сайт
разрешить пользователям входить через Google ID

и т.п.

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

Некоторые команды не заботятся о разделении функций на истории. Ничего страшного.

— Lunivore
источник

13

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

— Роберт Коритник,

4

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

— Лунивор

16

Особенности == Пользовательские истории.

Разговор продиктован данной Agile методологией .

Различные методологии используют разные термины для обозначения функций. Команда должна решить, какую методологию или терминологию использовать. Extreme Programming (XP) использует термины «Пользовательские истории» или «Истории» для представления функций; Scrum использует Product Backlog для описания списка функций; Feature-Driven Development использует функцию; и DSDM использует требование. Точно так же существуют различные облегченные версии Unified Process или Agile UP, которые используют Requirement и / или Use Case для определения пошагово предоставляемых функциональных возможностей. В конечном счете, цель одна и та же - приносить ценность для бизнеса регулярно, небольшими шагами и раньше, а не позже.

— Аарон Макивер
источник

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

— Муррекатт

2

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

— Слеське

@sleske Пользовательская история в чистом Scrum-подходе должна быть добавленной ценностью для пользователя и, следовательно, функцией. Если мы собираемся каталогизировать функции в качестве всеобъемлющих эпосов, это хорошо, но конечный результат - это пользовательские истории, которые приносят пользу.

— Аарон Макивер

1

@AaronMcIver: Да, это правда. Однако иногда минимальное количество функциональности, которая действительно полезна для пользователя (= функция), слишком много для пользовательской истории (или даже для итерации). В этом случае вы должны разбить функцию на несколько историй.

— Слеське

Кстати, связанный вопрос и ответ: stackoverflow.com/questions/1714557/…

— sleske

7

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

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

Пара ключевых соображений:

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

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

— S.Robins
источник

3

Эти два термина тесно связаны, но есть некоторые различия.

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

На практике они очень часто совпадают в том, что одна пользовательская история состоит из реализации определенной функции.

Однако в некоторых ситуациях они могут быть разными:

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

— sleske
источник