Архитектурная полоса — рецепт технических инвестиций в SAFe®

Вольный перевод статьи Architectural Runway – Scaled Agile Framework.

Зная о том, что при проектировании и разработке системы возможна эмерджентность, с небольшим планированием можно избежать крупных потерь.

Джеймс Коплин, Lean Architecture

Архитектурная Полоса включает существующий код, компоненты и техническую инфраструктуру, необходимые для реализации ближайших планируемых Фич без чрезмерного перепроектирования и задержек.

Архитектурная Полоса поддерживает непрерывный поток ценности через Конвейер Непрерывной Поставки. Она же обеспечивает необходимый технический базис для разработки бизнес-инициатив, внедрения новых Фич или Возможностей.

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

Гибкая разработка отходит от большого предварительного проектирования BDUF (Big Design Up-Front). Вместо него используется простое убеждение: «лучшие архитектуры, требования и дизайн создаются самоорганизующимися командами». В результате возникает практика эмерджентного (спонтанного) дизайна – это процесс поиска и расширения архитектуры только по мере необходимости реализации и проверки следующего инкремента функциональности.

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

• Снижается скорость работы из-за чрезмерного редизайна и задержек.
• Затрудняются интеграция систем, проверка и обслуживание.
• Ухудшаются системные качества, известные как Нефункциональные Требования (Non-Functional Requirement, NFR).
• Ослабляется как взаимодействие между командами, так и их синхронизация.
• Общие компоненты почти не используются повторно, тогда как элементов решения в избытке.

Из-за этих проблем падает производительность решения, разработка становится дороже и тормозится вывод решения на рынок.

Целевая архитектура обеспечивает общую картину

При масштабировании эмерджентный дизайн неэффективен. Ни одна из команд, работающих в крупной организации или над крупным Решением, не может увидеть полной картины, или заблаговременно предугадать все изменения, которые им предстоит внести, так как многие из этих изменений происходят вне локального контроля команд. Поэтому командам нужны как целевая архитектура (intentional architecture), так и практики межкомандного проектирования во время совместной реализации. Целевая архитектура – это набор целенаправленных планомерных архитектурных руководств, следование которым улучшает дизайн решения, его производительность и удобство использования.

Когда целевая архитектура и эмерджентный дизайн применяются вместе, Agile Release Trains (ARTs) получают возможность создавать и поддерживать крупномасштабные решения. За счет эмерджентного дизайна обеспечивается быстрое локальное управление. Такое управление помогает команде реагировать на меняющиеся требования и поддерживать систему в актуальном состоянии без лишних движений. Целевая архитектура разъясняет, что необходимо для обеспечения концептуальной целостности всей системы и соответствия ее назначению. Достижение баланса между эмерджентным дизайном и продуманной архитектурой – это ключ к эффективной разработке крупномасштабных систем.

Обеспечение непрерывной поставки и Релиза по требованию с помощью архитектуры

Решающую роль при проектировании систем, которые могут обеспечить непрерывный поток ценности для пользователя, играют архитекторы. Корпоративные архитекторы определяют Enablers для портфолио, в то время как Архитекторы Системы и Решения обычно определяют их для ARTs и Solution Trains. Архитекторы не только описывают Enablers, но и помогают продвигать эти работы по Kanban-системам, предоставляя рекомендации, необходимые для их анализа, оценки и внедрения . Такая поддержка гарантирует, что в затронутых элементах — подсистемах, компонентах, функциях, протоколах, внутренних системных функциях — есть архитектура, нужная для поддержания краткосрочных Фич и Возможностей в Дорожной карте.

Чтобы избежать большого предварительного проектирования, предприятие обязуется разрабатывать архитектуру постепенно. Это означает, что Эпики должны быть разделены на Enabler-фичи и/или Enabler-возможности, которые в конечном итоге будут реализованы отдельными ARTs. Каждая конкретная Enabler-фича должна быть завершены в пределах Инкремента Программы (Program Increment, PI), гарантируя стабильную работу системы в том смысле, что она потенциально может быть развернута даже во время ее разработки.

Архитектура – это ключевой базис Конвейера Непрерывной Поставки (Continuous Delivery Pipeline, CDP), а архитектурная полоса тесно связана с созданием CDP. Благодаря Непрерывной Интеграции (Continuous Integration, CI) и Непрерывному Развертыванию (Continuous Deployment, CD), CDP становится эффективнее и дает командам оперативную и качественную обратную связь. С его помощью Непрерывное Изучение (Continuous Exploration, CE) и Релиз по Требованию (Release on Demand) пополняются прямыми откликами от пользователей и проверенным обучением. В результате получается продукт более высокого качества, который легко адаптируется и соответствует назначению.

Как создается архитектурная полоса

В некоторых случаях свежая инновация может начинаться со значительной инициативы, требующей больших архитектурных затрат или создания совершенно нового продукта. В таких ситуациях Архитектор Системы или Решения играет ключевую роль в формулировании и построении полосы. Изучение и новая инфраструктура изначально осуществляются несколькими Agile-командами — иногда Архитектор выполняет роль Владельца Продукта в течение первых нескольких итераций, как показано на рисунке 1.

При создании Архитектурной Полосы применяются простые и гибкие правила:

• Команды, которые создают эту полосу, повторяют итерации, как и любая другая Agile-команда в программе.
• Предпочтение отдается работающим решениям, а не моделям и проектам.
• Время не ждет. Внедрить и проверить новую технологию следует не более чем за несколько итераций.
• Фиче-команды проверяют новую архитектуру. Они дают обратную связь путем создания, развертывания и релиза фич поверх новой технологии, как показано на рисунке 2.

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

Менеджмент Продукта/Решения и Архитекторы, в сотрудничестве с причастными командами, определяют многие из этих Enablers. Но реализация – это уже ответственность ARTs. Поддерживая успешную реализацию в краткосрочной перспективе, архитектурная полоса не должна излишне ограничивать развитие из-за долгосрочных технических обязательствам. Полоса должна быть минимально-достаточной, поскольку:

• Избыточность приведет к тому, что работы над архитектурой перегрузят команды, а сама архитектура станет слишком оторванной от текущего контекста.
• Недостаток полосы вызовет у команд проблемы с принятием и выполнением своих краткосрочных обязательств.

Архитектурная полоса требует постоянных вложений

На развитие Архитектурной Полосы влияют следующие факторы:

• Agile-команды работают быстро: оперативно реализуют новые фичи, используя уже существующую полосу.
• Владельцы Продуктов и Менеджмент Продукта/Решения нетерпеливы: они вложили часть времени на внутренние системные возможности и потому быстро сместят приоритеты с задач из бэклога на фичи, за которые пользователи готовы платить.
• Архитектура требует инноваций и должна постоянно развиваться: в современном мире технологии быстро меняются и устаревают.
• Потребности меняются – бизнес должен быть в состоянии быстро реагировать на возможности, угрозы и новые требования клиентов.

Все это истощает инвестиции, вкладываемые в архитектуру, как показано на рисунке 3.

Следовательно, архитектурная полоса требует постоянных инвестиций, это не разовая акция. На каждой итерации команды берут на себя обязательства по разработке, анализу и внедрению Enablers. Архитекторам и Agile-командам необходимо будет научиться разделять Enablers на небольшие кусочки. Каждый кусочек может быть реализован в ходе отдельной итерации и PI. В результате ценность будет постоянно поставляться заказчику.

Архитектурная полоса в рамках крупных решений

При создании больших систем Архитектурная Полоса играет еще более важную роль, поскольку несколько ART-команд вносят свой вклад в одно и то же решение как часть Solution Train. В статье «Поставка Корпоративных Решений» описаны девять методов создания крупных решений. Некоторые из них тесно взаимодействуют с архитектурной полосой:

Постоянно дорабатывайте вариативную/фиксированную часть Solution Intent

Solution Intent определяет множество ограничений в форме Нефункциональных Требований (Non-Functional Requirement, NFR). Многие NFR представляют собой сквозные проблемы, которые можно решить и упростить, намеренно создавая архитектурную поддержку для их внедрения и тестирования. При создании архитектурной полосы изменения в Solution Intent могут привести к дополнительным работам или аннулировать существующую полосу.

Используйте несколько горизонтов планирования

Чтобы реализовать базовые возможности в рамках крупных решений, может потребоваться больше времени. Эти системы требуют более длинной архитектурной полосы, часто реализуемой с помощью дополнительных эпиков в Kanban Программы и/или Решения.

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

Достижение этих целей в крупных решениях требует целевой архитектуры – чтобы реализовать эффективный Непрерывный Конвейер Поставки – и гарантирует облегченные операции с глубокой обратной связью через дистанционное отслеживание приложений.

Постоянно обращайтесь к вопросам нормативно-правового контроля

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

Дорабатывайте развернутые системы

Быстрый и экономичный Конвейер Непрерывной Поставки подразумевает, что системы можно релизить на ранних этапах и улучшать их. Поэтому системы должны быть спроектированы таким образом, чтобы поддерживать Непрерывное Развертывание и Релиз по Требованию.

Предыстория архитектурной полосы

Термин «архитектурная полоса» возник как аналогия при наблюдении за графиками, показывающими объём оставшихся работ на уровне PI (burn-down). Часто, когда команда начинает PI, ей не хватает архитектурной полосы. И любые фичи, которые зависят от новой архитектуры, сопряжены с высоким риском.

ART не всегда может “приземлить такие PI” (довести объём оставшихся работ до нуля в конце PI). В этом случае они не достигают целей PI. PI, как и самолету, нужно достаточное количество взлетно-посадочной полосы для безопасной посадки.

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

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.