В чем разница между Историей пользователя и Функцией в терминологии Agile?[закрыто]

Question

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

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

Answer 1

Да, что-то вроде подмножества.Эту статью полезно прочитать:
Особенности против Историй

Отрывок:

Сегодня я понял, что не сделал явной разницы в моем сознании между функциями и историями, и это важная разница.По сути, функция - это группа историй, которые связаны и предоставляют пакет функциональных возможностей, которые конечные пользователи обычно ожидают получить все сразу.Например, изменение размера встроенной таблицы - это функция (примечание:это возможность перетаскивать для изменения размера таблиц, строк и столбцов – попробуйте это в Word).На первом этапе у вас, вероятно, была бы единственная история для встроенного изменения размеров таблиц, но она была бы слишком большой для оценки.Итак, вы разбиваете его на три истории, изменяете размеры столбцов, изменяете размер строк и изменяете размер самой таблицы.

Answer 2

Согласно Кент Бек и Мартин Фаулер Истории и возможности являются синонимами:

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

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

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

---

Исправление:

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

Answer 3

Нисколько..

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

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

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

Answer 4

Функции — это то, что делает система.Пользовательские истории — это лишь один из способов зафиксировать функции.

Answer 5

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

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

Участник может отправлять сообщения администратору Администратор может отправлять сообщения всем участникам Участники могут отправлять сообщения друг другу

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

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

Поэтому я пытаюсь перефразировать эти требования следующим образом

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

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

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