Alovak thoughts

Мы используем User Story (US) для описания требований к разрабатываемой системе. Формат US такой:

As a <role>, I want <feature> so that <value>

Перед тем, как “собирать” US для нашего приложения мы должны определить типы пользователей (роли) в нашей системе. Как их определить?

Майк Кон предлагает следующие шаги для определения ролей:

• методом “мозгового штурма” найти как можно больше ролей
• категоризировать и объединить полученные роли
• удалить ненужные роли

Т.к. у нас есть опыт разработки подобной системы, то роли мы описали достаточно быстро. У нас получились:

• Продавец
• Покупатель
• Администратор
• Бухгалтер

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

Иногда случаются ситуации, когда мы знаем, что нужно сделать и как это будет работать, но понимаем, что воспользоваться этим сможет лишь часть пользователей у которых есть определенные навыки/возможности и т.п. Здесь и возникает необходимость создания новых ролей и их детального описания. У нас, к примеру, возникла необходимость создать несколько ролей продавцов. Каждой из этих ролей мы дали имя, помогающее понять её особенности. А также добавили детальное описание.

К примеру, продавец (merchant) - общая роль. Когда мы начали прорабатывать воможности интеграции с нашей системой, мы поняли, что у нас есть две категории продавцов, которым мы дали соответствующие имена:

• nulchant - продавец, у которого нет программистов, своего магазина и т.д. Ему нужен максимально простой и быстрый способ интеграции для того, чтобы начать продажи. Например он может: ввести данные в форму -> нажать на кнопку -> получить html-код -> разместить его где угодно.
• richant - продавец, у которого есть программисты, свой магазин и т.д. Ему нужна гибкость при интеграции и возможность “заточить” все под себя.

После определения ролей, мы принялись собирать US. Нашей целью было максимально быстро “выпустить” в продакшн систему с минимально-полезным набором функций, для проверки ряда предположений.

Всей командой, включая Product Owner’а, мы нарисовали прототип системы для каждой роли. Пример для продавца:

Каждый прямоугольник представляет из себя часть приложения, где пользователь может выполнить какие-либо действия. Рисование начинается с прямоугольника, в котором пользователь начинает работу с приложением. Кажый участник высказывает свои предположения о том, что пользователь может делать/увидеть, находясь в этой точке. Если функциональность не подходит для этой части, рисуем новый прямоугольник и т.д.

Прототипы для каждой роли оказались очень простыми и понятными. Все собранные требования были записаны, а прототипы, после первой итерации, выброшены, т.к. они выполнили свое предназначение: помогли определить начальный набор US.