Продолжаю серию статей про историю работы с требованиями. На рубеже веков жизнь показала, что невозможно за счет тщательного планирования и проектирования системы проекта обеспечить разработку и успешное внедрение системы в предполагаемые сроки. Как ответ на это родились Agile-методы, которые организовывают разработку принципиально иным образом: короткими итерациями, с регулярным получением обратной связи от заказчика и пользователей, для чего необходимо им представлять работоспособную версию продукта, которую они смогут оценить. Я не буду рассматривать это подробно, а отсылаю интересующихся к своим статьям «Agile-методы и проектный подход — в чем разница?», «Agile — ответ IT на вызовы цифрового мира» и «Развитие и провал регулярного менеджмента в IT», которые входят в книгу «Менеджмент цифрового мира».

Естественно, изменение организации проекта принципиально изменило работу с требованиями и проектирование системы. Классический подход, который я описывал в статье «Какие нужны требования: развитие концепта», исходил из того, что мы сможем за счет их тщательной проработки гарантировать успех проекта. А если мы признаем высокую неопределенность проекта, влекущую активное изменение требований, тщательная работа с ними теряет смысл, превращается в лишнюю работу.

Был предложен легкий метод user story — описание требований к системе в виде коротких историй взаимодействия пользователя с системой, в результате которого пользователь получит ценный для него результат, сможет достичь каких-то своих целей. Историю пишут в коротком формате пожелания от имени пользователя, выполняющего определенную роль: «Как <роль> я хочу сделать <действия> для того, чтобы <цель>». Последняя часть про цель принципиально важна, так как понимание цели помогает принимать правильные решения в случае альтернативных вариантов реализации. Описание в виде user story было предложено Майком Коном в 1998 году, часть про цель добавили в 2001. Истории должны быть небольшие и в идеале — слабо зависимыми, и каждая из них должна быть ценной, чтобы при планировании можно было достаточно легко выбирать набор для спринта. Первые варианты Scrum Guide прямо рекомендовали user story как способ ведения бэклога, позднее рекомендация была убрана.

User story — легкий способ описания системы как черного ящика, ориентированный на инкрементальную разработку

В случае продуктовой разработки вместо ролей пользователей используется техника персон — синтетических портретов пользователей, олицетворяющих различные группы целевой аудитории. Для работы с большим количеством user story, описывающими пожелания пользователей к продукту, используется техника story mapping. Позднее для этих целей была развита техника построения Customer Journey Map.

Отмечу, что дискуссия о том, должны ли разработчики понимать язык заказчиков и пользователей, или аналитики должны переводить требования на технический язык в Agile, решена в пользу понимания разработчиками пользователей. User story пишутся именно на языке пользователей, и разработчик должен понимать цели, для которых они используют систему. Таким образом, концепция единого языка проекта, понимаемого всеми участниками, предложенная в рамках DDD, сейчас является общепринятой, хотя это может не акцентироваться. Без этого активная коммуникация в проекте, которую предполагает Agile-манифест, является невозможной: люди не поймут друг друга.

Разработчик должен понимать язык заказчиков и пользователей без перевода

Для быстрого погружения разработчиков в специфику проекта предложена техника event storming, в ходе которой идет быстрая передача знаний о бизнес-процессах и месте системы в них всей команде. Это — развитие способа моделирования предметной области, только не в виде объектной модели и бизнес-процессов, а через события. И это лучше соответствует современной архитектуре систем из асинхронно взаимодействующих микросервисов. Так что такую модель легче отражать в код в соответствии с принципами DDD, которым была посвящена моя предыдущая статья «Domain Driven Design: модели вместо требований».

Замечу, что все эти форматы — story mapping, customer journey map, event storming — не форматы документов, как было бы в классическом подходе, а формат коммуникации, проведения встреч для получения информации и проектирования решений. В полном соответствии с ценностями Agile, подчеркивающими важность взаимодействия людей.

Agile делает фокус на форматы эффективных коммуникаций, а не на документы

Дизайн системы при итерационной разработке тоже делают инкрементально. Реализацию каждой user story проектируют отдельно. Часто это делает разработчик перед реализацией, и лишь для сложных user story проводят дизайн-сессии. Впрочем, тут есть много деталей, которые присутствуют в процессе неявно. В частности, для решения о включении в спринт должно быть не только понятно, что user story реализуема, — важна примерная оценка трудоемкости реализации. А это означает, что общее представление о дизайне уже должно быть, и для этого еще на этапе подготовки бэклога к планированию привлекается кто-то из опытных разработчиков. Кроме того, для оценки принимаемых решений часто используют практику design review: даже если дизайн делает сам разработчик, он должен сначала представить будущее решение, получить одобрение и лишь потом сделать. Впрочем, для действительно сложных, экспериментальных вещей это плохо работает: там реализуемость идеи решения часто не видна, пока код не заработал.

User story часто дополняют макетом интерфейса. Цель макета двойная: мы не только намечаем будущую реализацию, но еще и представляем ее пользователям, чтобы те оценили, действительно ли это решит их проблему, будет ли им это удобно. На этом этапе часто выясняется, что решение не слишком пригодно. Например, то дополнительное поле, которое они хотят видеть на договоре с клиентом, не всегда может быть заполнено при начальном заполнении договора. И это надо предусмотреть. Часто — в самой первой реализации, иначе четверть договоров просто не смогут сразу заводить в системе.

Фрагментарность user story содержит проблему. Для первой реализации выбирается наиболее простой сценарий, и часто его реализация содержит принципиальные ограничения на структуры данных, которые потом мешают реализации дополнительных сценариев. Например, предполагают, что покупатель на кассе всегда оплачивает свою покупку одним платежом и реквизиты оплаты сохраняются вместе с корзиной покупателя. При этом в дополнительных историях есть оплата несколькими способами, просто как далеко не первоочередная задача. И часто оказывается, что целесообразно было с самого начала заложить в структуры данных возможность множественной оплаты, а не делать тяжелый реинжиниринг позднее, когда дошел черед до реализации истории с несколькими оплатами. Этот риск конкурирует с другим: сразу заложить в структуры данных очень общие случаи, которые никогда не будут реализованы, и тем самым усложнить и сделать более долгой разработку простых.

Есть компромиссное решение: на этапе дизайна разработчикам надо держать в фокусе внимания не только реализуемую историю, но и все связанные. И принимать решение о дизайне, учитывая и требуемый реинжиниринг, и накладные расходы на сложный дизайн для реализации простых историй. Развитие Use Case 2.0, о котором я писал в первой статье, — это способ адаптировать use case к итеративной разработке: мы описываем use case целиком, но реализовывать будем поэтапно, разрезав на кусочки (slice).

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

В целом практика показала, что в Agile-мире сохраняется многообразие работы с методами и проектом системы, обусловленное многообразием самих проектов и используемых технологий. Какого-либо лучшего метода, который пытались изобрести классики работы с требованиями, не существует. Как и не существует единого способа синтеза архитектуры и дизайна системы и воплощения ее в коде. Есть лишь принципы, которые полезно использовать для проверки, и шаблоны для решения конкретных типовых задач. Но разработка конкретной системы — всегда творчество. На этом я завершаю разговор про те способы работы с требованиями, которые появились благодаря Agile.

В этой и предыдущих статьях я рассмотрел три основных подхода работы с проектированием систем: классические требования, работу с моделями и легкие варианты в Agile-методах. За рамками остались способы описания постановок на создание информационных сайтов, подробное рассмотрение развития ветки UI-design — usability — UX и многие другие вопросы. Да и затронутые темы освящены только обзорно, это показывает обсуждение с Денисом Бесковым в комментариях к статье про модели. Так что, возможно, продолжение следует…