User story вместо диаграмм: как проще разрабатывать фичи

Это статья из серии в формате записи из дневника разработчика, который решил стать соло-предпринимателем. Прошлая заметка тут.

Когда я решил стать не просто кодером, а разработчиком «по-взрослому», я, как и положено, начал с паттернов, архитектуры и, конечно же, документации. Особенно — с тех самых загадочных спецификаций, которые должны все объяснять, но часто только путают. Именно о них и хочу рассказать.

В какой-то момент мне попалась книга с интригующим названием — «UML для простых смертных». Название подкупало: мол, если ты не архитектор из Enterprise-монолита 2007 года, то и тебе найдётся место в этом UML-мире.

Так я узнал о разных видах диаграмм:

Полный список видов диаграмм можно посмотреть здесь, однако, в этой статье хочу обратить внимание на формат use case или «сценариев использования»:

И действительно, по началу когда я начал использовать UML все было структурно, формально, логично. Но чем глубже я погружался, тем сильнее ощущал — эта штука не даёт мне ускорения. Напротив, она будто тормозит весь процесс.

Наверное, не зря книгу так назвали — «для простых смертных».

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

Use case — вещь полезная. Особенно если вы работаете над большим продуктом, где участвуют аналитики, архитекторы, разработчики, тестировщики и менеджеры. Каждому нужен общий язык, и формальные сценарии взаимодействия пользователя с системой прекрасно решают эту задачу.

Но в соло-разработке всё иначе.

Ты — и аналитик, и разработчик, и тестировщик, и злой заказчик, который пишет себе в TODO «Срочно починить!».

Когда всё это — один человек, коммуникация превращается в разговор с самим собой. И формальности здесь скорее мешают, чем помогают.

В какой-то момент я просто устал рисовать диаграммы. Вместо того, чтобы рисовать очередную диаграмму, я открыл текстовый и написал:

«Пользователь должен иметь возможность создавать и редактировать проекты»

«Система сама должна придумать название проекта из описания, представленного пользователем»

и так далее, и так далее…

Это заняло буквально несколько минут, и у меня уже был черновик функциональных требований к системе. Так я изобрел велосипед под названием «пользовательские истории».

Никаких человечков, которые обозначают акторов, никаких стрелочек. Просто суть, оформленная в виде коротких тезисов. С этого момента я начал писать user stories.

Помимо скорости это дает ещё одно важное преимущество: легче посмотреть на проект глазами пользователя.

На самом деле, у user story есть четкий формат:

Как [пользователь], я хочу, чтобы я мог [совершить действие] для того, чтобы [достичь результата].

Подводя итог, нужно сказать, что эти два инструмента не взаимоисключают друг друга. Просто это разные инструменты для достижения разных целей.

Когда ты один или у вас маленькая команда, не стоит пытаться внедрять тяжелые процессы, которые будут вас замедлять. Особенно на ранних этапах проекта, когда проверяется множество гипотез.

Лично мне такой подход позволяет избежать так называемый «страх белого листа». Я могу быстро накидать несколько предложений в виде идей и уже дальше двигаться от этого.

Также такой подход позволяет реализовать ещё одну крутую штуку: перенести требования в свободном формате (например, пожелания пользователя после интервью) в более конкретное представление, которое затем уже можно формализовать и перевести в код.

Честно говоря, в этом, наверное, основная ценность user story для меня.

Что касается UML — я по прежнему активно использую некоторые виды диаграмм, в частности activity diagram, которая позволяет наглядно представить взаимодействия систем во времени.

Но об этом, возможно, в другой раз :)

Если тебе интересна тема разработки, без лишнего, но с умом — заглядывай в мой блог «Код без тайн», где я пишу о разработке, своих проектах и технологиях, которые меня вдохновляют: