tgoop.com/proagile/43
Last Update:
В бизнесе и продукте, как и в любом другом сложном домене нашей жизни, могут быть различные ограничения, правила и особенности. Как раз об этом варианте декомпозиции пользовательской истории мы и поговорим сегодня.
Вспомните, когда последний раз вы где-то регистрировались. Вспоминаете те ограничения, которым должен был соответствовать ваш пароль? Длина не менее 8 символов, строчные и прописные буквы, спецсимволы. Вот это как раз и есть один из примеров использования бизнес правил.
Рассмотрим процесс регистрации в нашем продукте. «Я, как пользователь, хочу зарегистрироваться в системе, чтобы не потерять историю своих заказов». Первый этап это регистрация. В зависимости от вашего продукта варианты могут быть следующие: регистрация с использованием электронной почты, номера телефона, использование логина. Так же наверняка у вас есть требования к паролю.
Вводя правила в процесс регистрации, вы накладываете ограничения: проверка пароля на соответствие условиям, номер телефона должен соответствовать формату номера, почта должна содержать символ @ и принадлежность к домену (.com, .ru, .uk и т.д.).
Такие ограничения и проверку сделать необходимо, даже не обсуждается. Но появляется другой вопрос — а так ли нам необходимо сделать их для запуска продукта, можем ли пока не проводить проверку, а вынести её в отдельную задачу по пользовательской истории и тем самым ускорить процесс выпуска пользовательской истории, либо зафиксировать общий объём работ.
Давайте поразмышляем. Пользовательская история: «Как пользователь, я хочу иметь возможность оставлять отзывы о товарах на сайте». Чтобы было проще начать, приведу пример первого возможного правила: Пользователь должен авторизоваться на сайте, чтобы оставить комментарий. Напишите в комментариях, какие ещё бизнес условия и правила вы можете предложить для данной истории?
@agileincubator
BY ProAgile
Share with your friend now:
tgoop.com/proagile/43