Чи є документація історією користувача? [зачинено]

Нам потрібно зробити документацію користувача для продукту, над яким ми працювали протягом останніх кількох спринтів. Зараз ми розпочинаємо новий проект у наступному спринті, і PO виробляє документацію для виробленого раніше продукту. Історія користувача для цього спринту.

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

EDIT: Дякую за вашу думку, хлопці. У мене в голові, що спринт повинен реалізувати приріст робочого програмного забезпечення, але ваші погляди змінили мій кругозір. Дякую за всі ваші відповіді.

"Як користувач X, мені потрібно знати, як працює X", мені здається законною історією користувача. Це може призвести до письмової документації або онлайн-довідки.

Суть не просто в коді - це задоволення вимог користувачів.

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

Ви маєте рацію, це не створює жодного коду. Але це задовольняє вимоги користувача та має надавати пріоритет перед іншими вимогами користувачів.

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

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

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

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

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

Щоб відповісти на ваше запитання конкретно, я б запитав, чи вважає команда, що документація є частиною "Визначення завершеного" чи ні.

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

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