User stories популярный инструмент для формирования описания фичей не разработчика для разработчика. Имеет свои плюсы и минусы, к чему-то подходит, к чему-то не подходит. Попробуем разобраться, куда его использовать, а куда не стоит.
Что из себя представляет пользовательская история?
Если коротко - она описывает действие (перечень функций) с которыми взаимодействует пользователь в ходе выполнения своей конкретной задачи. Самый частый пример любой статьи по User Story (US далее) - оплата заказа в интернет магазине. Как правило такой подход не имеет ничего общего с архитектурой продукта и взаимосвязи на уровне сущностей: есть пользователь, есть его баланс, есть товар, есть оплата. Это всё разные сервисы и сущности, которые между собой связаны тонкой нитью US. Если взглянуть на это под углом компонентов1СБитрикслюбой CMS, включающей в себя некие готовые решения, всегда есть модуль с товарами, модуль с заказами, пользовательский модуль, платёжный шлюз. При этом вся US затрагивает по N функций каждого модуля. Плавно переходим к следующему заголовкуКак US описывает функционал системы, с точки зрения самой системы?
Да никак. Совсем. Она вообще не даёт понимания, что осталось за бортом, что ещё можно сделать в твоём приложении, какие ещё кнопки будут на экране и от чего зависеть. С точки зрения самой системы мы можем только логически додумать все эти вещи, опираясь на экспертное знание системы и дедуктивный метод. Сможет-ли заказчик описать это в рамках одной US? Да, конечно! Вот пример: Я, как интернет-магазин, должен дать возможность зарегистрироваться и авторизовываться пользователям, показать им рекламу, показать тултип при регистрации о запрещённых символах, показать перечень товаров в интернет-магазине, запоминать их действия и отсылать в яндекс.метрику... Замечаем, что даже здесь я пошёл каким-то логичным "человеческим" путём, однако уже видно, что возникает много "как?", "зачем?", "а что будет?" и прочего-прочего.. Если продолжать писать US для системы, получится очень плохо и больно. US написанные для пользователя на практике воспринимаются программистом не всегда хорошо и могут вести к реализации пачки конкретных кейсов, не пересекающихся на первых порах. Проблемы начнутся когда они пересекутся в виде "изначально так не планировалось" и костыляние функционала на старые функции.И зачем нам User Story в принципе?
User Story помогает (и только помогает!) составить техническое задание, которое в дальнейшем будет являться описанием того или иного сервиса (их совокупности), используемого в вашем приложении. Помогает оно тем, что из пары-тройки таких историй мы сможем вычленить компоненты системы и начать описывать их и именно это должно являться нашей целью. Сама по себе user story ни в коем случае не должна являться тем, что попадает в беклог программиста. Именно в этот момент происходит недооценка такой роли как "Системный аналитик": тот, кто пережуёт US в корректное описание сущностей и связей между ними, функцию каждого, что позволит в конечном итоге собрать нормальный масштабируемый продукт.Всё так плохо?
Нет, всё не плохо, когда мы говорим про тестирование гипотез или про формирование MVP продукта. Также US могут быть полезны при тестировании и вполне могут сойти за основные мануальные тесты в рамках итогового решения или в рамках построения общего понимания цели текущей разработки. В таких случаях пользовательские истории могут сыграть позитивную роль при построении "быстро на коленке", чтобы работало, быстро поставить ценность пользователю. Что делать после того, как сделали на коленке? Видел отличный материал здесь.
Итоги
User Story описывает поведение пользователя, а не системы, соответственно помогает составить ТЗ но не заменяет его.
Полезно для формирования MVP и быстрой проверки гипотезы. US помогают процессу разработки, но не являются его незаменимой и главной частью.
При получении рабочего прототипа не списывайте на "ну всё, работает, погнали развивать продукт", перейдите по ссылке.
Может навредить итоговой архитектуре продукта, сделав его не масштабируемым