Что такое хорошая User Story?♦️🙂
Давайте разберем этот вопрос. Системные аналитики и команды разработки используют User Stories как основной инструмент, который отвечает на три критически важных вопроса: КТО получит пользу, ЧТО он сможет сделать, и, самое главное, ЗАЧЕМ ему это нужно.
➡️ Формула, которая работает
Идеальная User Story всегда следует простой структуре:
КАК [Роль/Тип Пользователя], Я ХОЧУ [Действие], ЧТОБЫ [Получить ценность/выгоду].
Как использовать?
❌ Вместо: "Нужно, чтобы список продуктов фильтровался по цене."
✔️ Пишем: “КАК ПОКУПАТЕЛЬ, я хочу быстро отсортировать товары от самых дешевых к дорогим, ЧТОБЫ быстрее найти бюджетный вариант в рамках лимита.”
Секрет успеха: мы фокусируемся не на том, что мы строим, а на том, какую проблему мы решаем для человека.
Если вы не можете логично закончить фразу "ЧТОБЫ…", значит, вы, скорее всего, описываете как это должно работать, а не зачем это нужно.
➡️ Что делать?
Методика INVEST
Чтобы история была работоспособна для команды, она должна соответствовать принципам INVEST (Независимая, Обсуждаемая, Ценная, Оцениваемая, Маленькая (на 1 спринт), Тестируемая).
Пока что, сосредоточьтесь на последних двух: если историю можно оценить и протестировать — значит, она достаточно ясна.
✅А дальше?
Мы выяснили, ЧТО мы строим и ЗАЧЕМ. Но как нам убедиться, что разработчик сделал ИМЕННО ТО, что мы задумали?
Об этом мы поговорим в следующем посте! Мы раскроем тему Критериев Приемки (Acceptance Criteria) — того самого списка проверок, который гарантирует, что Story действительно готова.
#статьи_WBS #userstory
