#8. Как писать пользовательские истории (user stories)
В этой статье мы рассмотрим как пишутся пользовательские истории (user story). Мы узнаем приемлемый уровень их детализации, а также что необходимо учитывать при их составлении.
Как уже говорилось ранее, История вмещает в себе требования к разрабатываемому компоненту.
В идеале, История составляется Владельцем Продукта (Product Owner, PO), однако, в некоторых случаях делегирование этой задачи одному человеку может быть ущербным. К примеру, PO может не обладать нужной компетенцией (например, в Истории нужно описать механизм работы транзакций процессинговой системы пластиковых карт, а PO никогда не работал в банковской сфере).
В идеале, История составляется Владельцем Продукта (Product Owner, PO), однако, в некоторых случаях делегирование этой задачи одному человеку может быть ущербным. К примеру, PO может не обладать нужной компетенцией (например, в Истории нужно описать механизм работы транзакций процессинговой системы пластиковых карт, а PO никогда не работал в банковской сфере).
Помимо этого, PO - тоже человек, и он может банально ошибиться после долгого рабочего дня. Подобная ошибка может незаметно проскользнуть в Бэклог и привести к неверной имплементации описанной функции. По этим причинам, к PO при составлении Истории могут подключиться Бизнес Аналитик (редко), Менеджер Продукта или Менеджер Проекта (PM).
Пользовательская История. Составление
Пользовательская История называется так потому, что ее формат подразумевает описание в виде истории от первого лица, того что хочет "видеть" пользователь разрабатываемого приложения.
Обычно, истории составляются на основании готового дизайна, или, в редких случаях, на основании прототипа, при уверенности, что дизайн больше не изменится. В случае изменений в дизайне, истории переписываются, что влечет за собой определенные риски. В частности, снижается читабельность, повышается вероятность упустить мелкие детали, и так далее.
Итак, предположим, что мы с вами – команда. Я новый Владелец Продукта, а вы – опытный Бизнес Аналитик, с которым я советуюсь.
Предположим, наш клиент – владелец онлайн платформы цифрового издательства “JPUB”. Пользователи нашего клиента создают на ней свои журналы, а мы занимаемся технической поддержкой этой платформы и разрабатываем для нее функции.
В один прекрасный день Я получаю запрос от JPUB:
«Я хочу чтобы наши издатели могли ограничивать досуп к своим журналам для разных стран. Нам нужна эта функция послезавтра».
«Я хочу чтобы наши издатели могли ограничивать досуп к своим журналам для разных стран. Нам нужна эта функция послезавтра».
Дедлайны ужасные. Это возмутительно и все такое, но что поделать, жизнь – боль.
С другой стороны, вроде бы, ничего сложного, нужно добавить опцию, где издатели смогут указывать страны, из которых можно будет получить доступ к публикациям и все.
Я иду к дизайнеру и прошу по-быстрому набросать мокап. Получаем что-то такое:
С другой стороны, вроде бы, ничего сложного, нужно добавить опцию, где издатели смогут указывать страны, из которых можно будет получить доступ к публикациям и все.
Я иду к дизайнеру и прошу по-быстрому набросать мокап. Получаем что-то такое:
Окей, теперь у нас есть набросок дизайна страницы, где издатели могут включить функцию ограничения доступа по странам, и указывать страны, которым разрешен вход. Я подхожу к вам и прошу высказать мнение.
Вы с недоумением смотрите на мой набросок и спрашиваете «А почему не добавить возможность блокировки отдельно взятых стран? Ведь если речь идет об ограничении доступа, тогда же очевидно, что издатели гораздо чаще будут ограничивать доступ для нескольких стран, нежели открывать доступ для нескольких сотен – это же тупо!».
Да, действительно. Я беру еще немного времени на размышления, и добавляю возможность блокировки.
Да, действительно. Я беру еще немного времени на размышления, и добавляю возможность блокировки.
Возвращаюсь к вам, показываю обновленную версию. Теперь издатель может выбрать один из двух пунктов – Allow, для разрешения, либо Deny – для блокировки. Одновременно может быть активен только один из списков.
Вы снова грустно смотрите на меня, и задаете вопрос «А мы действительно можем гарантировать, что никто из указанных стран не будет иметь доступ?». Поразмыслив, я отвечаю «Ну, как...мы используем IP адрес для ограничения доступа. Если пользователь использует VPN, или какие-нибудь технологии смены IP-адреса, тогда, очевидно, доступ он получить сможет», на что вы задаете весьма резонный вопрос «А может быть мы в рамках этой же функции, объясним это издателю, чтобы у него в будущем не возникало претензий, что кто-то таки смог добраться и прочесть их журнал, хоть он и уверен, что этот кто-то живет в стране, доступ для которой заблокирован?».
Взгрустнув, я возвращаюсь к наброскам и добавляю соответствующую надпись под опцией:
Боясь произвести на вас впечатление полного идиота, я трачу чуть больше времени на размышления, и вспоминаю лицензионное соглашение нашего клиента, в котором четко указано, что пользователь, который купил доступ к онлайн журналу на платформе JPUB, должен иметь к нему доступ постоянно.
Это приводит меня к выводу, что если мы в вышеуказанном виде разработаем и запустим функцию ограничения по странам, то целый ряд читателей, которые купили онлайн журналы, окажись «не в той» стране, могут потерять доступ к своему приобретенному товару! Грусть и печаль, друзья. Поэтому я добавляю в свой макет еще одно примечание.
И возвращаюсь к вам. Я подробно рассказываю, к каким я там выводам пришел и какую еще умную работу совершил, на что вы отвечаете «Молодец, все правильно» и идете в сторону двери, попутно добавляя «Я бы, возможно, добавил описание к каждому из пунктов – Allow и Deny, чтобы в корне исключить вероятность какой-либо путаницы пользователями. Ты же понимаешь, у нашего клиента миллионы пользователей по всему миру, а люди разные..».
Я благодарю вас за подсказку, бегу к дизайнеру, прошу его добавить пару деталей. Дизайнер приводит все в нужный вид, и прощается, оставляя меня в офисе одного.
Итак, у меня есть дизайн и я знаю, что максимум, что может измениться – это цвет, тогда как по функционалу я вроде бы представляю, как все должно работать. Я сажусь за свое рабочее место, логинюсь в JIRA и в колонке Бэклог Продукта, в самом верху (ведь это нужно послезавтра), создаю новую Историю.
Далее я представляю вашему вниманию пользовательскую историю для этой задачи. БОльшая ее часть скопирована из настоящей пользовательской истории этой задачи.
Название истории: "Ограничение доступа к публикации по странам".
Описание:
Описание:
Как издатель, пользователь платформы JPUB, на странице управления моими журналами я бы хотел видеть иконку глобуса, при клике на которую появлялись бы опции ограничения доступа по странам.
В открывшемся окне я хочу видеть переключатель, который позволит мне включить/выключить опцию ограничения по странам.
Я хочу видеть опции «Разрешить» и «Запретить», с вопросительными знаками рядом с ними, при наведении на которые должны появиться соответствующие подсказки:
(Для «Разрешить»): Публикация будет доступна только для указанных стран
(Для «Запретить»): Публикация не будет доступна для указанных стран
При включении опции ограничения доступа, опция «Разрешить» должна быть активирована по-умолчанию.
Я хочу видеть опции «Разрешить» и «Запретить», с вопросительными знаками рядом с ними, при наведении на которые должны появиться соответствующие подсказки:
(Для «Разрешить»): Публикация будет доступна только для указанных стран
(Для «Запретить»): Публикация не будет доступна для указанных стран
При включении опции ограничения доступа, опция «Разрешить» должна быть активирована по-умолчанию.
Как только я кликну на поле ввода, я хочу, чтобы система подсказала мне, что я должен ввести по меньшей мере два символа, чтобы получить список доступных стран.
Я хочу иметь возможность добавлять неограниченное кол-во стран в любой из списков, и удалять их из списка по клику на «Х» в названии страны, либо через клавишу Backspace при выбранном поле ввода.
Если я выбрал опцию «Разрешить» и ввел названия стран, я хочу, чтобы система разрешила доступ к моему журналу только для тех пользователей, чей IP-адрес принадлежит к стране/странам указанным в списке разрешенных.
Если я выбрал кнопку «Запретить» и ввел названия стран, я хочу, чтобы система запретила доступ к моему журналу для тех пользователей, чей IP—адрес принадлежит к стране/странам указанным в списке запрещенных.
Я хочу, чтобы списки стран, которые я составил, были сохранены под опциями так, чтобы при переключении между «Разрешить/Запретить» списки не стирались, и я мог продолжать их редактировать.
Под полем ввода я хочу видеть две подсказки системы:
*Для определения страны мы используем IP-адрес посетителя.
Пользователи по-прежнему могут получить доступ к этой публикации, если они получили его из страны, где публикация была доступна, либо специальным предложением по почте.
Как только я ввел нужные страны, я хочу иметь возможность сохранить настройки через кнопку «Сохранить настройки», либо, если я передумал, закрыть окно нажав на кнопку «Отменить».
Если я выбрал кнопку «Запретить» и ввел названия стран, я хочу, чтобы система запретила доступ к моему журналу для тех пользователей, чей IP—адрес принадлежит к стране/странам указанным в списке запрещенных.
Я хочу, чтобы списки стран, которые я составил, были сохранены под опциями так, чтобы при переключении между «Разрешить/Запретить» списки не стирались, и я мог продолжать их редактировать.
Под полем ввода я хочу видеть две подсказки системы:
*Для определения страны мы используем IP-адрес посетителя.
Пользователи по-прежнему могут получить доступ к этой публикации, если они получили его из страны, где публикация была доступна, либо специальным предложением по почте.
Как только я ввел нужные страны, я хочу иметь возможность сохранить настройки через кнопку «Сохранить настройки», либо, если я передумал, закрыть окно нажав на кнопку «Отменить».
Все
Теперь, когда дизайнер утром придет на работу, он может прикрепить дизайн-файлы к нашей Истории, и она будет готова к разработке. Я закрыл лаптоп у поехал домой, отсыпаться.
С утра, во время планирования работ на день, команда, в соответствии с пожеланием нашего клиента, в особом порядке возьмется за разработку этой истории, и вроде бы все хорошо, но так ли это?
С утра, во время планирования работ на день, команда, в соответствии с пожеланием нашего клиента, в особом порядке возьмется за разработку этой истории, и вроде бы все хорошо, но так ли это?
Вроде бы мы описали как работает новая функция. Мы очень скрупулезно описали кнопки, тексты, переключатели, мы даже вдались в детали того, что происходит во время переключения между списками. Мы указали минимальное кол-во символов, необходимое для ввода, чтобы система авто-заполнением выдала нам список стран. На первый взгляд, все в порядке. И да, девелоперы могут не вдаваясь в детали начать разрабатывать историю, а тестировщики могут изучать историю и составлять тест-кейсы.
Проблема лишь в том, что мы не указали что именно происходит, если пользователь переходит по ссылке в браузере на журнал, который ограничен в его стране. Мы забыли это указать, и мы можем только гадать, что будет, если История будет имплементирована именно так, как мы написали. Вероятнее всего, пользователь увидет какую-то грубую страницу с системной ошибкой (в лучшем случае), либо, увидит пустую страницу с какой-то короткой строкой системной ошибки:
Если бы проектом был наш блог, то может быть, это было бы еще кое-как простительно, но наш клиент - JPUB – крупная онлайн платформа с миллионами пользователей.
Если бы мы не заметили этого упущения и имплементировали историю как есть, то как только несколько издателей платформы воспользовались бы этой функцией, несколько тысяч, а то и десятков тысяч пользователей могли бы увидеть очень грубую страницу ошибки. Очевидно, что это ударит по репутации проекта (заметьте – не издателей, а именно платформы JPUB).
Если бы мы не заметили этого упущения и имплементировали историю как есть, то как только несколько издателей платформы воспользовались бы этой функцией, несколько тысяч, а то и десятков тысяч пользователей могли бы увидеть очень грубую страницу ошибки. Очевидно, что это ударит по репутации проекта (заметьте – не издателей, а именно платформы JPUB).
И вот, я снова бегу к дизайнеру и прошу его все бросить и по-быстрому нарисовать недостающие страницы ограничения доступа, чтобы прикрепить все к Истории. Затем я бегу к разработчикам и долго-долго извиняюсь перед ними за то, что забыли о странице, ну и так далее. Драма, грусть, печаль, но страница готова.
Вот такая вот, казалось бы, небольшая опция стала большой проблемой из-за невнимательности Владельца Продукта.
Надеюсь что процесс, который я проиллюстрировал оказался полезен. В заключение хотел бы подчеркнуть три крайне важных правила по составлению историй:
- Правильный формат истории – это тот, который согласован с проектной командой. Это может быть повествование от первого лица, это может быть формат «текст – картинка», это может быть что-угодно, и единственно верным здесь является то, что устраивает всю команду.
- Правильная детализация истории - это та, которая согласована с командой. По мере того, как команда все дольше и дольше работает над проектом, уровень детализации Истории снижается, потому-что множество вещей со временем становится очевидным. Однако, если команда новая, либо если в ней появился новенький, детализация вновь должна повышаться, чтобы избежать разночтений;
- Правильный размер истории – это тот, который дает достаточно информации всем участникам команды, работающим с историей.
Пользовательская История. Состав
Искусство писать Истории заключается в том, чтобы найти ту самую грань минимальной информации, обладание которой позволит команде разработать в точности то, что нужно.
Для этого, у Владельца Продукта есть целый ряд инструментов, которые он смело может использовать в Истории (согласовав с командой, конечно же):
- Скриншоты
- Скриншоты с заметками (типа тех, которые были выше в этой статье)
- Скринкасты (видео)
- Эскизы, Макеты, Дизайн файлы
- Презентационные файлы (редко)
И вообще все что угодно.
У Владельца Продукта не должно быть какого-то «единственного стиля» составления Историй, так как в этом случае он будет недостаточно гибким. Если команде нужны скриншоты – PO их делает. Если команде нужны видео, или эскизы набросанные на стикерах – PO их составляет.
Нельзя брезговать ничем, даже таким:
Владельцу Продукта на заметку:
- Если хочешь выполнить работу быстро – не спеши;
- Если хочешь просидеть в офисе до глубокого вечера, чтобы закончить что-то так, чтобы это было готово к утру, когда придет команда – прекрати, и иди домой. Если ты все-же все доделал - приди с утра по раньше и тщательно проверь все свои записи;
- Если тебе уже дважды приходилось изменять Историю, и ты все еще ее не закончил, выпей чаю, прогуляйся на свежем воздухе, вернись на рабочее место, и пройдись по ней еще раз;
- Если, проверяя Историю ты пропускаешь какие-то абзацы «потому что там все и так понятно, я это читал сто раз», тогда выпей чаю, прогуляйся на свежем воздухе, вернись, и прочти все абзацы еще раз;
- Если эти заметки вызывают на твоем лице легкую улыбку, либо в голове у тебя мерещется слово «очевидно», значит ты молодец.
В завершение этой статьи, я хочу показать как вышеуказанная «История» была составлена мной в формате PRD (Product Requirements Documentation) в Joomag:
Теперь мы знаем, как выглядят и как составляются Истории, столь необходимые для имплементации проекта.
В следующей статье мы рассмотрим ключевые технические компоненты любого проекта.