історію

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

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

Як написати якісну історію користувача

Історія користувача

Основна мета написання історії користувача - відповісти на запитання:
1) до кого стосується потреба
2) що йому конкретно потрібно
3) навіщо це потрібно

Цей простий запис є ефективним способом передавати інформацію про те, що ви очікуєте (що програмне забезпечення має вміти робити).

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

Одним з мнемонічних допоміжних засобів, що допомагає у практичному позначенні якісної історії користувача, є абревіатура INVEST, яка представляє набір атрибутів:

  • Я - незалежний
  • N - договірна
  • V - цінний
  • E - оцінюваний
  • S - малий
  • Т - перевіряється

Історія користувача - це конструкція, виконання якої може бути (веселою) (N); при її доставці я намагаюся звести до мінімуму інші залежності (I), вона приносить користь бізнесу для клієнта (V), переважно, щоб функціональність у питання якомога менше (S), щоб його можна було оцінити якомога точніше (E) і його можна було перевірити (T).

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

Критерії приймання

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

Якщо критерій прийняття смердить надмірно складним, необхідно врахувати, чи не можна передане ним значення витягнути в окрему історію користувача (розділення, застосування I, V та S від скорочення INVEST).

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

В Інтернеті існує багато теорії про INVEST, базову структуру історії користувача, ролі (людей) або критерії прийняття. Я хотів би додати кілька своїх перевірених відгуків, які я звик додавати до історії користувача. 🙂

Статус кво

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

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

Апетит/таймбокс

Мій апетит до вирішення цієї вимоги або часового поля допомагає визначити, наскільки я готовий прийняти обхідні шляхи (тобто я наразі не хочу ідеального рішення, це тимчасове рішення).

Довідкові матеріали

Запис якоїсь дикої конкретної формули, згідно з якою я очікую, що додаток оцінить бізнес-правило (наприклад, розрахунок кількості днів зберігання або очікуваної суми амортизації до кінця календарного періоду), є більш ефективним для ілюстрації у допоміжному Excel, ніж критерії).

Відкриті питання

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

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

Каркасний

Одне зображення краще, ніж тисяча слів. Рекомендація полягає в тому, що каркасний каркас просто обрамляє те, що я маю на увазі. Потрібно свідомо мінімізувати пошук деталей. Я повинен залишити деталь рішення рішення дизайнеру/користувачеві (якщо у мене є такі офіційні або неофіційні).

Історія користувача є ефективним способом документування бізнес-вимог. Індекс історій користувачів (user story index) може ефективно відповідати на питання навіть після того, як програмне забезпечення вже обслуговує своїх користувачів - це стає зручною документацією.

Іван Криштоф

допомога менеджерам програмних проектів задовольнити очікування бізнесу (ROI)

Відставання від дієти

Як приборкати цифрових монстрів, і де вони нас чекають? Маленька історія про ...

Прийняття програмного забезпечення не є безкоштовним

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