Пользовательские истории – это один из способов документации требований к разработке продукта, раскрывающий то, что он должен сделать для пользователя.
Нередко у команд возникает вопрос о необходимости работы над документацией при условии, что можно просто создать задачи в трекере и начать вводить новый функционал. Однако главная задача документации – это, прежде всего, понять и описать потребности. Она призвана не объяснить, что должен делать продукт, а удостовериться в его соответствии тому, что нужно потребителю.
Пользовательские истории, гибкая разработка которых должна быть результатом обсуждения бизнес-пользователей и разработчиков, необходимо фиксировать в максимально простой форме. Обсуждения помогут разобраться в том, зачем создается новый функционал и кто его основной юзер, а также заранее рассчитать тестирование и ограничение системы.
Составляющие истории следующие:
- Текст
- Критерии приемки, по которым мы сможем понять, что она закончена.
- Тестирование. В историях могут быть включены тест кейсы.
- Технические детали и заметки. Например, информация об ограничениях.
Рекомендации по написанию и типичные ошибки
В идеале текст должен написать внешний или внутренний бизнес-пользователь, желающий получить новый продукт или функционал, а после ее необходимо обсудить с командой разработки.
Важно помнить, что текст – это объяснение действия и потребностей пользователя, а также предполагаемого результата.
Шаблоны пользовательских историй могут строиться по схеме:
как <роль/персона юзера> я <что-то хочу получить> <с такой-то целью>.
Предлагаем список правил, следуя которым у вас получится хорошая история:
- Обязательное присутствие ценности. Завершающая часть схемы «я хочу что-то получить с такой-то целью» содержит главную осмысленную цель.
- Простота оценки. Чтобы добиться этого, чересчур большую или размытую формулировку можно разбить на несколько частей.
- Процесс разработки должен занимать не больше недели, в противном случае ее нужно разделить на составляющие.
- Критерии приемки должны быть настолько четкими, что по ним можно протестировать продукт.
- Независимая разработка. Спланировать историю с множеством ограничений и программных зависимостей намного сложнее.
Рассмотрим пользовательские истории, пример которых иллюстрирует самые частые ошибки в написании.
Например, текст выглядит так:
Как пользователь я хочу контролировать отображение спецпредложений, чтобы удалять устаревшие и неактуальные».
Какие ошибки здесь допущены? Все важные составляющие присутствуют, однако при ближайшем рассмотрении очевидно, что мы не знаем, для кого ее создаем. Юзер может быть администратором системы, которому необходимо показать спецпредложения от рекламодателей, или рекламодателем, желающим управлять их показом. Ожидания от продукта у таких людей разные, поэтому главная ошибка здесь – это пренебрежение к роли в ней пользователя.
Приведем пример истории для разработчика:
«Как разработчик я хочу обновить программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х».
Она не несет никакой ценности для пользователя. Чтобы исправить это, нужно обратить внимание на то, что способна сделать библиотека X для него. Допустим, с помощью библиотеки можно быстрее создавать спецпредложения и убрать задержку после их создания. Тогда новый вариант выглядит следующим образом:
«Как рекламодатель я хочу, чтобы система не делала задержек после создания спецпредложений, чтобы я мог оперативнее работать с большим объемом спецпредложений».
А если переписать историю с точки зрения пользователя, то она будет выглядеть так:
«Как рекламодатель я хочу, чтобы система позволяла мне создавать папки, чтобы я мог оперативнее работать с большими списками объявлений»
В таком случае становится гораздо легче написать критерий приемки:
«Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».
Еще один вариант типичной ошибки – это отсутствие бизнес-ценности. Например:
«Как администратор системы я хочу иметь возможность сортировать спецпредложения».
Все части на своих местах, но возникает вопрос: зачем администратору необходимо сортировать спецпредложения? При отсутствии четкой цели теряется смысл.
Чек-лист написания хороших пользовательских историй
- Разбейте историю на несколько мелких оставляющих.
- Не увлекайтесь техническим жаргоном.
- Не обсуждайте конкретные UI элементы. Даже если визуальная реализация изменилась, актуальность должна сохраняться.
- Оценивайте и анализируйте усилия по разработке.
- В конечном итоге, убедитесь в наличии осмысленного ценного результата.
Неверные стратегии:
Формализм
Нередко случается, что бизнес-пользователи пишут большие подробные тексты. Все детали кажутся освещенными, и команда рискует пропустить обсуждения. В результате, часть требований может потеряться, потому что одному человеку трудно охватить все детали.
Отсутствие обсуждений
Лучше потратить время еще до написания кода, чем в процессе упустить важные детали или иметь неверное представление об основной задаче.
Преобладание технических историй
Очень важно сохранять равновесие между техническими историями для внутренних и для конечных пользователей продукта. В противном случае, может случиться так, что в реализованных историях будет мало продуктовой ценности.
Наш блог на сайте: https://olprime.ru/blog/
Мы в других соцсетях:
Telegram: t.me/olprime
Instagram: https://www.instagram.com/olprime_ltd/
Vkontakte: https://vk.com/olprime
Twitter: https://twitter.com/Olprime