Як я можу розробляти історії користувачів як розробника?

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

{1} Я оцінюю спритну службу управління проектами TargetProcess , і кожна історія користувача повинна бути пов'язана з батьківською функцією. Система здається вдалою, тому ця невелика обмеженість - це те, з чим я б швидше працював, ніж працював.

Типовий шаблон історії дуже просто уявити:

As a [ROLE] I need to [WHAT] so that/because [WHY].

Цікавим є те, що важливість компонентів зворотна.

ЧОМУ важливіше, ніж ЩО, а це важливіше, ніж РОЛЬ

Приклад з використанням цього питання

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

Більше нічого не надто ускладнює наміри та реалізацію Історій користувачів.

Додаткові інструменти (Інтеграція найкраща)

Інструменти можуть бути використані для отримання додаткової детальної інформації про історії, яка відзнята при обговоренні їх для призначення балів / оцінок, але ця деталь не повинна бути частиною самої розповіді. Щось таке просте, як Вікі з 1 сторінкою на історію, щоб розмістити деталі / стенограми обговорень, є досить хорошим рішенням. Електронна таблиця Excel - жахливе рішення.

Зосередьтеся на тому, що і навіщо, і уникайте способів написання історій користувача.

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

Ви повинні зосередитись на загальній вимозі, наприклад "потрібно вміти робити один вибір із випадаючого списку об'єктів, щоб користувач міг активувати Foo", замість того, щоб використовувати комбінаційну скриньку або список списків або що інше, що запускає певну рутину .

Ще один спосіб наблизитись до цього - зробити вигляд, ніби основна база / рамка коду майже повна чорна скринька. Щоразу, коли ви опинитесь "використовувати об'єкт XYZ", ви можете самостійно перевірити, запитавши, чи знаєте ви про це в системі чорного поля.

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

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

Якщо ви багатомовний, використовуйте дві різні мови в якості лакмусового тесту. Наприклад, рядки в C - це, як правило, масиви char (acter), тоді як C ++, Java та C # (добре, і майже всі інші ...) мають власне об'єкт String, подібний до цього. Якщо ви виявите, що ваша специфікація визнана недійсною, використовуючи одну з цих мов, знаєте, що ви переоцінили.

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

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