Друзья, всем привет! 🙌
Недавно мы рассказывали вам про технику формирования требований к ПО в формате User stories.
Напоминаем, что шаблон User story выглядит следующим образом:
1. Как (роль),
2. я хочу (выполнять задачу),
3. чтобы (достичь цель).
Например:
Как пользователь приложения для доставки продуктов, я хочу, чтобы приложение определяло мою геопозицию самостоятельно, чтобы мне не пришлось вводить адрес доставки вручную.
Но недостаточно просто формулировать историю по шаблону, ведь она всё равно может оставаться сложной для понимания. Важно, чтобы проектной команде было удобно оценивать историю в часах, планировать её в работу, проектировать и сравнивать конечный результат с изначально заявленным.
Для того, чтобы передавать в разработку истории, с которыми удобно работать, проверяйте их на соответствие определённым правилам или критерям.
Поговорим об INVEST-критерях для User stories 🌚 #hardGetAnalyst
Недавно мы рассказывали вам про технику формирования требований к ПО в формате User stories.
Напоминаем, что шаблон User story выглядит следующим образом:
1. Как (роль),
2. я хочу (выполнять задачу),
3. чтобы (достичь цель).
Например:
Как пользователь приложения для доставки продуктов, я хочу, чтобы приложение определяло мою геопозицию самостоятельно, чтобы мне не пришлось вводить адрес доставки вручную.
Но недостаточно просто формулировать историю по шаблону, ведь она всё равно может оставаться сложной для понимания. Важно, чтобы проектной команде было удобно оценивать историю в часах, планировать её в работу, проектировать и сравнивать конечный результат с изначально заявленным.
Для того, чтобы передавать в разработку истории, с которыми удобно работать, проверяйте их на соответствие определённым правилам или критерям.
Поговорим об INVEST-критерях для User stories 🌚 #hardGetAnalyst