У чому різниця між історіями користувачів та функціями?

25

Граючи з icescrum , я зрозумів, що не розумію різниці між історіями користувачів та особливостями користувачів.

Чи може хтось пояснити різницю?

agile scrum features

23

Особливістю є чіткий елемент функціональності, який може надати можливості бізнесу.

Історія - це невеликий аспект функції, який ви можете використовувати, щоб отримати зворотний зв'язок із своїми зацікавленими сторонами та з’ясувати, чи робите ви щось не так.

Наприклад, функцією може бути "дозволити користувачам коментувати статті". Історії, пов’язані з цією функцією, можуть бути:

зберегти коментарі
фільтрувати коментарі для грубих слів
обмежити коментарі до 400 символів і повернутись користувачам
додайте капчу, щоб зупинити боти, які спамують сайт
дозволяти користувачам входити через ідентифікатор Google

тощо.

Тоді на кожному етапі ми можемо отримати зворотній зв'язок щодо корисного напрямку, яким ми займаємось.

Деякі команди не переймаються розбиванням функцій на історії. Все добре.

— Лужник
джерело

13

Чи не є ці пов'язані історії насправді завданнями розповідей користувачів? Я б сказав, що вони є. Історія користувача буде такою: Я, як користувач, хотів би коментувати статті, щоб ми як користувачі могли покращувати вміст статті або висловлювати занепокоєння. Ця історія користувача буде розбита на завдання, які ви описали ...

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

4

Я вважаю, що завдання є чимось, що потрібно зробити для отримання зворотного зв’язку, але про яке ви не можете отримати зворотній зв'язок самостійно - наприклад, створення таблиці бази даних. Будь-яка з цих історій, крім першої, потенційно може бути видалена, залишаючи при цьому вартість. Завдання зазвичай горизонтально нарізані в моєму світі. Але якщо у вас різні визначення, це нормально. Гранульованість - це не зовсім дискретна річ, кожна мета - це підряд іншого, і я думаю, ви повинні робити все, що для вас є прагматичним. Я вважаю цю розрив корисною, як і багато моїх команд.

— Lunivore

16

Особливості == Історії користувачів.

Багатослівність продиктована застосовуваною методикою Agile .

Різні методології використовують різні термінології для позначення особливостей. Команда повинна вирішити, яку методологію чи термінологію використовувати. Екстремальне програмування (XP) використовує терміни Історії користувачів або Історії для представлення функцій; Scrum використовує Блокування продукту для опису списку функцій; Функція, керована функціями, використовує функцію; і DSDM використовує вимогу. Аналогічно, існують різні полегшені версії Уніфікованого процесу або Agile UP, які використовують Вимогу та / або Використовують випадок для визначення функціональних можливостей, що забезпечуються поступово. Зрештою, мета одна і та ж - регулярно надавати вартість бізнесу невеликими кроками, і швидше, ніж пізніше.

— Аарон Маківер
джерело

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

— murrekatt

2

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

— sleske

@sleske Історія користувача в чистому підході Scrum повинна бути додатковою для користувача, а отже, функцією. Якщо ми будемо каталогізувати функції як всеохоплюючі епоси, це добре, але кінцевим результатом є історії користувачів, які надають цінність.

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

1

@AaronMcIver: Так, це правда. Однак іноді кількість функціональних можливостей, які справді корисні користувачеві (= функція), занадто багато для історії користувача (або навіть для ітерації). У такому випадку ви повинні розбити функцію на кілька історій.

— sleske

До речі, пов'язаний з цим питання і відповідь: stackoverflow.com/questions/1714557 / ...

— sleske

7

Історія користувача є неформальним заявою на мові клієнта , який фіксує намір що - то , що бажання клієнта досягти. Ви можете розглядати історію користувача як неофіційну заяву про вимоги.

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

Кілька основних міркувань:

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

Маючи на увазі все це, я схильний вважати Історії описом. В основному неформальні вимоги, які говорять мені про те, що хоче клієнт. Особливості, з іншого боку, я схильний розглядати це як специфікацію, яка підказує мені, як система повинна працювати для задоволення потреб клієнтів.

— С. Робінз
джерело

3

Два терміни тісно пов'язані, але є деякі відмінності.

По-перше, вони походять з різних областей. Термін "функція" є досить загальним терміном для певної частини функціональності програмного забезпечення, тоді як "історія користувачів" була придумана і справді використовується лише в контексті спритної розробки програмного забезпечення.

На практиці вони дуже часто збігаються, оскільки одна історія користувача складається з реалізації певної функції.

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

Часто функцією є занадто багато роботи для однієї історії користувача. Історії користувачів не повинні бути занадто великими (як правило, не більше кількох днів, максимум 1-2 тижні роботи). Очевидно, що багато особливостей набагато більше. У цьому випадку функція буде реалізована в багатьох історіях користувачів. Деякі люди використовують "епоси", щоб групувати історії користувачів разом, у цьому випадку можна сказати, що ця функція є епопеєю.
Нефункціональні вимоги (продуктивність, безпека, сумісність тощо) можуть також розглядатися як історії користувачів (хоча це не є загальновизнаним). У такому випадку результат користувацької історії зазвичай не називатиметься функцією (якщо тільки ви не називаєте функцію "наш додаток рідко виходить з ладу").

— sleske
джерело