Как писать User Story

Tags

Top Highlights

• User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

• User Story — это не требования.

• являются короткими и легко читаемыми, понятными разработчикам, стейкхолдерам и пользователям

• легко поддаются эстимированию

• небольшие инкременты ценной функциональности

• не детализированы в самом начале проекта, а уже более детально разрабатываются «точно в срок»

• Как, <роль/персонаж юзера>, я <что-то хочу получить>, <с такой-то целью>

• Важно описывать историю на уровне “ЧТО?” делает, а не “КАК?” Это главное в истории. Опишите проблему, а не ее решение

• Лучше написать много историй поменьше, чем несколько громоздких.

• Истории должны быть написаны таким образом, чтобы их можно было протестировать

• Тесты должны быть написаны до кода.

• Каждая история должна содержать оценку.

• История должна иметь концовку — т.е. приводить к конкретному результату.

• История должна вмещаться в итерацию.

• прелесть пользовательской истории в том, что она формулирует не только бизнес-ценность, но и требования для разработки и тестирования.

• добавить критерии приемки, технические заметки, описание обработки ошибок, которые суммируют все задачи, которые вам нужно сделать.

• «Я как пользователь хочу сортировать товары по цене, чтобы выбрать лучшее из одной ценовой категории»

• «Я как пользователь хочу сохранять музыку в кэш, чтобы слушать без интернета»

• Детали историй — это больше не неизменная часть требований, которые продумываются заказчиками во время написания требований и предъявляются команде в готовом виде. Вместо этого заказчик и команда во время обсуждений историй совместно приходят к понимаю уровня детализации, который необходим на текущей фазе, и принимают совместные решения, пополняя истории все большим количеством информации.