Які розповіді користувачів слід писати на початкових етапах проекту?

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

Це не відповідає моєму поняттю "завдання": для мене я б хотів щось подібне до "завдань":

• Показуйте фіктивні дані для foos користувача у HTML, отримані від об’єктів JavaScript.
• Налаштуйте логічний шар презентації та підключіть до нього об’єкти JavaScript.
• Налаштуйте логічний шар домену та підключіть до нього логічний шар презентації.
• Налаштуйте рівень доступу до даних та підключіть до нього логічний рівень домену.

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

Це гарне запитання, і напевно на нього є кілька хороших відповідей. Моя думка така:

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

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

На початкових етапах проекту, коли у вас немає відповідних рамок для швидкого та легкого розвитку CRUD ( C reate, R ead, U pdate, D elete), ваші історії повинні бути набагато меншими, поступовими шматки.

Замість "Користувач повинен мати можливість переглядати його foo" , приблизно так:

1. Користувач повинен мати можливість бачити сторінку із зразковими даними
2. Користувач повинен мати можливість бачити сторінку з інтерактивними зразками даних
3. Користувач повинен мати можливість бачити сторінку з інтерактивними прикладними даними

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

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

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

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

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

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

Вам потрібно представити це назад і домовитись про згоду.

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

Деякі з них розкажуть на дошці, а потім представлять і пояснять.

Деякі будуть писати суворі та ретельно проаналізовані документи.

Кожна техніка має свої переваги та недоліки.

Про єдину пораду, яку я б дав, це: стрибнути в кодування рішення занадто рано, як правило, це поганий крок. Розуміння того, що робити для ХТО і ЧОМУ, перш ніж це зробити, як правило, призводить до меншої кількості перероблень та швидшого розвитку.

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

Не скупіться на аналіз і документацію на передній частині.

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

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