Користувацькі історії та критерії приймання: як чітко формулювати вимоги

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

Докладніше: Довгі специфікації часто не читають. Гнучкі команди пишуть вимоги як короткі історії, що показують користь і мету та конкретизуються в розмові.

Подробиці

Формат

Як <роль> я хочу <функція>, щоб <користь>. Приклад: «Як клієнт я хочу отримувати підтвердження замовлення електронною поштою, щоб знати, що воно дійшло.» Три частини відповідають на запитання Хто? Що? Навіщо? «Щоб» запобігає функціям без мети. Історія — не повний договір, а привід для розмови.

Хороші історії: INVEST

• Independent (незалежна)
• Negotiable (обговорювана)
• Valuable (цінна для користувача/клієнта)
• Estimable (оцінювана)
• Small (достатньо мала для спринту)
• Testable (тестована) Надто великі історії («епіки») ділять на менші.

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

Вони конкретно описують, коли історія готова, в ідеалі у форматі given – when – then:

• Given кошик не порожній, when я плачу, then я отримую лист із підтвердженням і номером замовлення.
• Лист надходить протягом 5 хвилин; містить товари, підсумок, адресу доставки.
• За недопустимої адреси електронної пошти показується повідомлення про помилку. Вони тестовані (так/ні), достатньо повні й становлять основу тестів (див. BDD) та приймання.

Вбудовування в проєкт

Історії перебувають у беклоге продукту, пріоритизуються й реалізуються в спринті. Визначення готовності (DoD) діє для всіх історій (код перевірено, тести зелені, задокументовано, розгорнуто), критерії приймання — для однієї історії. У документації IHK можна подавати вимоги як користувацькі історії з критеріями та доповнювати документами вимог/технічного завдання. Додатково: діаграми варіантів використання, прототипи, ескізи.

Див. також: Гнучкі методи, Документи вимог і технічного завдання, BDD, Приймання та передача