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

Ответ 1

Да, что-то вроде подмножества. Эта статья хорошо читается:
Особенности vs Истории

Выдержка:

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

Ответ 2

Согласно Кент Бек и Мартин Фаулер Истории и особенности - синонимы:

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

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

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

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

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

Ответ 3

Совсем не..

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Итак, я пытаюсь перефразировать эти требования как

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

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

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