Comments 6
Мы попробовали этот подход реализовать на платформе совместного моделирования Онто и пользовательские истории ожили. Стали моделью. Подход действительно очень удобный когда ты можешь использовать пользовательские истории в архитектурных скетчах к примеру.
В классической версии процесса: мы сначала набрасываем юзер стори, можно не детализировать, а оставить просто заголовок, а уже потом, когда нужно описываем критерии приемки до достаточного состояния. Почему вам кажется, что нужно собрать полный документ сразу?
А когда наступает это самое нужно и кто это определяет?
Я не против классической версии, мы от нее не сильно отошли на самом деле, а модернизировали:
Проблема классического подхода в том, что список не детализированных юзер сторей в самом начале проекта не особо помогает команде и бизнесу понять зачем мы все это делаем и как. Это похоже на список покупок в магазине. Можно предположить какой салат у нас получится из этих ингридиентов, но не зная результата, можем забыть что-то важное без чего блюда не получится.
А еще юзер стори без уточнения просто невозможно объективно приоритезировать. Что самое важное, что сделать проще всего и это даст максимальный результат.
Поэтому вместо юзер сторей в самом начале мы всегда определяем цели и формулируем гипотезы по их достижению. Гипотезы тоже можно формулировать в виде юзер сторей, если вам так удобней. Но мне здесь больше нравится декларативный подход — сделать интерфейс создания тренировки. Он понятней, точнее и в виде задачи, которую надо решить.
На этом этапе мы приоритезируем — выделяем основные гипотезы, с которыми надо работать в первую очередь.
Потом эти гипотезы перевариваются в документ.
Документ это тоже набор сценариев. Сначала они в виде заголовка, например «Тренер создает тренировку».
Детализируем сценарии для того, чтобы:
1. Синхронизировать ожидания бизнеса и команды.
2. Разобраться как сценарии будут дружить друг с другом. Это, кстати, решает основную, на мой взгляд, проблему разработки через юзер стори без глубокой проработки — часто сценарии противоречат друг другу и мы в будущем можем очень много проблем из-за этого получить.
3. Определить риски, объем работ, получить новые идеи по реализации, новые гипотезы.
4. Понять какая архитектура продукта будет.
5. Оценить объем работ, выделить версии релизов и сроки, запланировать работу команды.
Ну а финальный USM, который мы собираем после этого — просто удобный способ визуализации всего, что мы проделали до этого.
Здесь важно уточнить еще, что наш подход хорошо ложится на запуск новых продуктов или глубокую модернизацию существующих. Если мы занимаемся развитием продукта и команда на проекте стабильная, то классическая версия проектирования через юзер стори очень хорошо работает и мы ею пользуемся.
Спасибо за подробный ответ!
2. Разобраться как сценарии будут дружить друг с другом. Это, кстати, решает основную, на мой взгляд, проблему разработки через юзер стори без глубокой проработки — часто сценарии противоречат друг другу и мы в будущем можем очень много проблем из-за этого получить.
Согласен - в тексте документа легче рассказать понятную стройную историю от лица конкретного пользователя.
Как использовать User Story mapping при создании цифрового продукта