Solution Intent — Замысел Решения

Вольный перевод статьи Solution Intent — Scaled Agile Framewok 6.0.

Качество начинается с замысла. —У. Эдвардс Деминг

Solution Intent — это репозиторий для хранения, управления и передачи знаний о текущем и предполагаемом поведении Решения (Solution).

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

Причина появления замысла решения очевидна. Разработка крупных программных продуктов и создание киберфизических систем являются одними из наиболее сложных задач в отрасли. Они требуют согласования двух основных вопросов:

• Что именно разрабатывается?
• Как мы будем его разрабатывать?

Более того, эти два вопроса взаимосвязаны и влияют друг на друга. Если непонятно, «как» разработать что-то за разумные деньги или технически осуществимым способом, то придется пересмотреть «что» разрабатывать с учетом контекста и ограничений «как». В SAFe этот важнейший пул знаний называется «Замыслом Решения» — базовым пониманием текущих и развивающихся требований, дизайна и намерений, то есть, более широким пониманием назначения решения.

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

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

Сложные с инженерной точки зрения и высоконадежные решения требуют и порождают большие объемы технической информации. Многие из них отражают требования к решению и проектные решения в виде набора Фич (Features) и Возможностей (Capabilities), Историй (Stories), Нефункциональных Требований (Non-Functional Requirements, NFR), системной архитектуры, моделей и проектов в терминах предметной области (например, электрических, математических и механических), системных интерфейсов, спецификаций заказчика, тестов и результатов тестирования, а также трассировок (возможности отследить влияние изменений в одном элементе на изменения в других). Дополнительно записываются некоторые из основных проектных решений и выводов относительно системы. К ним может относиться информация из маркетинговых исследований, результаты экспериментов, обоснование проектных решений и другие элементы. Во многих случаях эта информация должна стать частью официальных документов, будь то по необходимости или по закону.

Собирайте знания в замысле решения

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

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

Собирайте как текущий, так и будущий замысел решения

Рисунок 1 показывает сложную природу замысла решения:

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

Рис. 1. Анатомия замысла решения

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

Конкретные элементы замысла решения могут быть представлены в различных формах: от документов, электронных таблиц и сеансов интерактивной доски до формальных требований и моделей, созданных при помощи специальных инструментов моделирования, как описано в Model-Based Systems Engineering (MBSE). Но замысел решения — это только средство для завершения разработки решения, поэтому методы сбора и фиксации не должны создавать ненужных расходов и трат (см. обсуждение достаточности ниже).

Замысел решения меняется со временем

Традиционно набор подробных, предварительно согласованных, фиксированных требований служил в качестве замысла решения. Но принцип SAFe №3: «Предполагайте изменчивость; сохраняйте варианты» — говорит нам о том, что слишком четкое определение требований и проектных решений приводит к менее успешным результатам. Нужен другой подход, который поддерживает понимание того, что уже известно, однако позволяет по ходу разработки появляться тому, что ещё неизвестно.

Замысел решения — это не статичная одноразовая декларация: он должен поддерживать весь процесс разработки и продолжать развиваться. На рисунке 2 традиционная ранняя декомпозиция фиксированных требований сравнивается с подходом Lean-Agile, в котором требования детализируются с помощью Фич, Историй и, в конечном итоге, личных обсуждений.

Рис. 2. Сравнение традиционных и гибких требований

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

Держите варианты открытыми с фиксированными и переменными целями решения

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

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

• Определенные рабочие характеристики («форма сигнала кардиостимулятора всегда должна быть следующей»).
• Соблюдение стандартов («соблюдение всех требований к кредитным картам, отвечающим требованиям PCI»).
• Основные возможности, определяющие решение («максимальный вес груза автономного транспортного средства доставки составляет 200 килограммов»).

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

Переход от переменного к фиксированному состоянию требует получения знаний для принятия решений. Enablers (специальные виды работ-активаторов для обеспечения возможности продвижения разработки) — это инструмент SAFe для исследования неизвестного и записи полученных знаний и сделанного выбора в замысле решения. Следуя практике вариативного проектирования (Set-Based Design), команды изучают альтернативы, чтобы выбрать оптимальный экономический вариант. Выбранные варианты позволяют разрабатывать следующие функции, следуя дорожной карте (рисунок 3).

Рис. 3. Движение от переменного к фиксированному замыслу решения

В каждом Инкременте Программы (Program Increment, PI) команды одновременно создают то, что они знают, и исследуют то, чего еще не знают.

Вырабатывайте замысел решения совместно

Замысел решения — это совместная работа команд и руководителей программы. Продуктовый Менеджмент и Менеджмент Решения совместно с Архитекторами/Инженерами уровня Системы и Решения несут ответственность за общесистемный выбор вариантов реализации самого высокого уровня (декомпозиция системы, интерфейсы и распределение требований к различным подсистемам и возможностям). Они также устанавливают организационную структуру замысла решения для поддержки будущих потребностей в анализе и соблюдении нормативных требований. Замысел решения помогает принимать локальные решения в бэклогах команд, как показано на рисунке 4.

Рис. 4. Замысел решения развивается благодаря сотрудничеству

Замысел решения определяет Дорожную Карту решения и, в конечном счете, элементы бэклога для реализации. Замысел решения начинается с Концепции, в которой описываются цель и ключевые возможности решения, а также нефункциональные требования к системе. Эти знания и появляющаяся дорожная карта, а также критически важные вехи, помогают командам создавать бэклог и планировать свою работу. Как дорожная карта, так и замысел решения содержат различные неопределенности, предположения, гипотезы. Их следует корректировать с учетом знаний, полученных в результате реализации (рисунок 5). Эта форма взаимодействия заменяет традиционный подход, когда стараются снизить неопределенности за счет подробных спецификаций и планов.

Рис. 5. Разработка замысла решения

Руководство SAFe по непрерывной поставке предусматривает проверку предположений с помощью минимально-жизнеспособных продуктов (Minimum Viable Product, MVP), которые позволяют приобрести подтвержденные знания посредством частых, количественно измеримых экспериментов. Подтвержденные знания в замысле решения носят преимущественно технический характер, но также применяются и бизнес-ориентированные принципы бережливого стартапа (Lean Startup).

Соедините замыслы решений по всей цепочке поставок

При масштабировании замысел решения не обязательно должен быть единственным. Поскольку системы состоят из нескольких подсистем, замысел решения распространяется на эти подсистемы, включая поставщиков. У поставщиков часто бывают отдельные и независимые требования, проекты и другие спецификации для их подсистем или крупных функций. С их точки зрения это и есть замысел решения. Конечный (верхнеуровневый) замысел решения должен включать всю необходимую информацию по всей иерархии подсистем для передачи выбранных вариантов реализации, облегчения исследования, согласования между командами и соблюдения нормативных требований (рисунок 6).

Рис. 6. Иерархия замысла решения

Создайте минимальную, но достаточную документацию

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

• Модели предпочтительнее документов – в условиях постоянных изменений подход, опирающийся на документы для организации и управления замыслом решения, становится чрезмерно сложным. Модели, включая те, которые созданы с использованием современных практик, таких как дизайн-мышление и проектирование, ориентированное на пользователя, при правильном применении могут обеспечить более удобные способы управления, о чем подробнее говорится в MBSE.
• Обсуждайте замысел решения совместно – не существует монополии на инновации, и замысел решения не является исключительной прерогативой продуктовых менеджеров, руководителей решений, архитекторов и ведущих инженеров. В создании, получении обратной связи и уточнении информации о замысле решения участвуют многие члены команды.
• Держите варианты открытыми – отложите принятие окончательных решений до решения локальных проблем и принимайте их как можно позже. Адаптивный подход к требованиям и проектированию сохраняет перспективные варианты открытыми до тех пор, пока это экономически оправданно. Практика вариативного проектирования помогает избежать слишком раннего принятия окончательных решений в отношении дизайна и требований.
• Документируйте всё в одном месте – записывайте любые требования и проектные решения в одном месте, в едином «источнике правды», который служит хранилищем записей для всех и вся.
• Поддерживайте высокий уровень – общайтесь на как можно более высоком уровне абстракции и не пишите слишком подробно. Задавайте диапазон допустимых значений вместо фиксированных чисел, чтобы обеспечить возможность вариативного проектирования. Описывайте поведение решения при помощи намерений, а не конкретики. Децентрализуйте полномочия в отношении требований и принятия проектных решений.
• Сохраняйте простоту – Замысел решения – это метод создания продукта с соблюдением нормативных требований и договорных обязательств. Записывайте только то, что реально необходимо. Не забывайте принцип «чем короче, тем мудрее» («Το λακωνίζειν εστί φιλοσοφείν», Хилон, 6 век до н.э.).

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