Как писать понятные и ёмкие user stories для команды. Пользовательская история — это потребность пользователя, написанная продактом с точки зрения этого самого пользователя. Простейший шаблон: «Как __(тип пользователя)__, я хочу __(действие)__, чтобы получить ____(цель)_____». Простейший пример: "Как пользователь приложения X, я хочу ввести свой адрес электронной почты адрес и придуманный пароль, чтобы зарегистрироваться и войти в свой аккаунт". Пользовательская истории состоит из: 1. Описания. 2. Критерий приемлемости. 3. Бизнес-правила. 1. Описание. Здесь вы описываете функцию с точки зрения конечного пользователя как написано выше. Просто, ясно и лаконично в рамках конкретной потребности и действия. 2. Критерии приемки. Это условие или набор условий, которые должны быть соблюдены, прежде чем функция/функция может считаться выполненной. Это будущее определение готовности для описыываемой функции. Примеры критериев принятия с использованием истории реги и входа в X: – Пароль чувствителен к регистру. – Поле электронной почты НЕ чувствительно к регистру. – Пароль должен состоять из 5+ символов и буквенно-цифровых символов. – Требования к паролю должны быть отображены в UI. – Должна присутствовать проверка требований и вывод ошибок при их несовпадении. – И т.п. Критерии приемки помогают всей команде: 1) PM - быстро и доходчиво объяснить себе и команде, какие потребности пользователя должны быть удовлетворены. 2) Разработчикам – знать, что именно для этого нужно сделать и с какими условиями. 3) QА – увидеть, понять и прогнать тесты по данным условиям. 4) Дизам – воплотить всё это в виде интерфейса для пользователя. 3. Бизнес-правила. Это набор политик или правил, обычно налагаемых компанией в качестве средства формирования поведения на более широком уровне. Примером бизнес-правила могут быть юридические (18+) или иные ограничения, например регистрация только аккаунта юридического лица на различных B2B-платформах.