В прошлой статье мы разобрались, из чего состоит User Story и как её записывать. Но одной формулировки мало — важно довести историю до состояния, когда её можно передавать разработчикам. Для этого используется процесс формирования истории. Его можно запомнить как три «П»: 1️⃣ Прописать историю 2️⃣ Проговорить историю 3️⃣ Подтвердить историю 🔹 Шаг 1. Прописать историю Историю можно оформить на стикере или в электронных инструментах (Miro, Notion, draw.io). На карточке обычно фиксируют: Название (краткое и уникальное: «Оплатить заказ баллами», «Посмотреть баланс», «Вернуть заказ») Шаблон истории (Connextra: «Как … я хочу … чтобы …») Примечания (детали для уточнения: вопросы, предложения, напоминания) Критерии приёмки Сценарии приёмки 🔹 Шаг 2. Проговорить историю Историю обсуждают в команде: бизнес-аналитик, заказчик, разработчики, тестировщики. 💡 Задача этого шага — убедиться, что все одинаково понимают, что именно нужно реализовать и зачем. 🔹 Шаг 3. Подтвердить историю История утверждается, если: есть чёткие критерии приёмки; команда понимает ценность для пользователя; понятны границы реализации. ✅ Критерии приёмки Это условия, которые должны быть выполнены, чтобы история считалась реализованной. Формулируются коротко, например: «Система автоматически показывает оставшуюся сумму после оплаты баллами». Критерии отвечают на вопрос: «Что именно ожидает пользователь?» 🎬 Сценарии приёмки Сценарий — это шаги пользователя для проверки, что ПО работает так, как задумано. Примеры: Если сумма заказа больше баллов → пользователь доплачивает разницу, заказ уходит на сборку. Если сумма заказа ≤ баллов → заказ подтверждается без доплаты. 📌 Чтобы не писать длинные тексты, часто используют формат Gherkin (Given-When-Then): Дано: у пользователя есть 100 баллов, заказ на 150₽. Когда: он выбирает оплату баллами. Тогда: система показывает 50₽ к доплате, заказ доступен к сборке. ⚡️ Итог: правильно сформированная User Story — это не просто фраза «Как пользователь, я хочу…», а целый пакет артефактов (название, шаблон, критерии, сценарии), который гарантирует, что команда сделает именно то, что нужно пользователю. 🦆И ещё К сожалению, учесть все возможные ситуации, которые могут возникнуть в процессе реализации истории, на этапе аналитики очень сложно. Но не стоит переживать — это стандартный процесс. История будет обрастать деталями в процессе её обсуждения с командой и даже на этапе проектирования и тестирования. Важная задача аналитика — постараться учесть самые популярные кейсы (или сценарии), а после — своевременно дополнять историю информацией, которую «подсветят» другие участники проектной команды. #Приоритизация #Requirements #BusinessAnalysis #ProductManagement #Agile #UserStories #BA #UserStory #ПользовательскаяИстория #База