User story
User stories представляют собой короткие, простые и понятные описания функциональности системы с точки зрения конечного пользователя или заинтересованной стороны. Они фокусируются на описании потребностей и целей пользователей, а не на технических деталях. Каждая user story содержит название, описание и критерии приемки.
Формат записи User story
Я, как [Роль пользователя] Хочу [решить задачу/выполнение какого-либо действия] Когда [при каких условиях/обстоятельствах] Чтобы [достичь цель]
Пример
Я, как [юзер кофе-машины] Xочу [взбить молоко] Когда [открываю кран подачи пара] Чтобы [получилась густая молочная пенка]
Я, как [юзер кофе-машины] хочу [иметь возможность наливать воду в кофе-машину] Когда [открываю крышку резервуара с водой] Чтобы [кофе-машина могла функционировать]
INVEST
Написанную User Story можно оценить по шести критериям INVEST, которые сформулировал консультант и директор по развитию продукта Билл Уэйк.
Independent (независимый). В пользовательской истории лучше описывать одну или несколько независимых функций. Они должны решить проблему пользователя без помощи других инструментов.
Negotiable (подлежащий обсуждению). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется. Без обсуждения есть риск, что команда разработки получит неполное представление о задаче.
Valuable (ценный). В функции, которую описывает User Story, должна быть реальная ценность для пользователя.
Estimable (поддающийся оценке). Хорошую User Story можно оценить — понять, сколько времени, ресурсов и денег займёт разработка функции.
Small (маленький). История должна быть краткой и ёмкой. Объёмные истории сложнее оценить, и они могут потребовать больше ресурсов на разработку.
Testable (поддающийся тестированию). С критериями приёмки команде разработки будет проще создать нужную функцию. Тестировать историю лучше за один раз — это ещё одна причина, почему в истории не должно быть много деталей.
Источники:
Last updated