Agile systems engineering по ISO/IEC/IEEE 24748-10:2026: как быть гибким и не потерять жизненный цикл

Agile и системная инженерия часто описывают так, будто это два несовместимых подхода.

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

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

Именно поэтому выход ISO/IEC/IEEE 24748-10:2026 выглядит важным событием. Это первая редакция стандарта из серии 24748, полностью посвященная systems engineering agility. Документ не предлагает «внедрить Scrum в системную инженерию», а задает стратегические аспекты гибкости и рекомендации по их выбору и применению.

Главная мысль стандарта, на мой взгляд, звучит так: agility в системной инженерии — это не набор ритуалов, а стратегическая рамка, делающая жизненный цикл отзывчивым к неполному знанию и изменяющейся операционной среде.

Что именно задает стандарт

Во введении ISO/IEC/IEEE 24748-10 systems engineering agility определяется как strategy-based method для проектирования, создания, поддержки и развития систем в условиях uncertain knowledge и dynamic environments.

Здесь важно не схлопнуть несколько уровней рассуждения в одно слово.

Сам стандарт задает стратегические аспекты и помогает ответить на вопрос, на что именно должен быть способен проект в условиях неопределенности. Проект на этой основе выбирает локальные методы реализации: например, формат итераций, тип review, набор артефактов, toolchain, правила эскалации, способ интеграции и принятия решений. А команда уже исполняет конкретные работы: проводит испытание, обновляет requirement baseline, фиксирует решение в ADR (Architecture Decision Record), пересматривает риск или добавляет verification case.

Именно в этом смысле стандарт говорит, что agility — это what, not how. Он задает не готовую операционную процедуру, а рамку выбора: что проект должен обеспечить и по каким признакам это видно. В статье далее под agility понимается именно стратегическая рамка проекта; конкретные циклы, церемонии, шаблоны артефактов и toolchain — это локальная реализация в контексте конкретной системы.

Это важная поправка для инженерной практики. Можно проводить daily standup и оставаться негибкой организацией. И наоборот, можно работать в достаточно формальной среде, но быть гибкими, если проект быстро переводит наблюдения и результаты проверок в изменения связанных артефактов жизненного цикла.

Почему здесь важен 15288

Стандарт прямо адресован тем, кто использует или планирует использовать ISO/IEC/IEEE 15288, отвечает за техническое управление проектом или исполняет процессы жизненного цикла на уровне проекта.

Это полезно еще и потому, что 24748-10 отдельно разбирает типичное заблуждение: будто 15288 автоматически означает waterfall. В таблице common misunderstandings about agile прямо сказано, что ISO/IEC/IEEE 15288 не предписывает конкретную lifecycle model, methodology, modelling approach или technique. Процессы 15288 могут применяться вместе с agile-техниками — с адаптацией или без нее.

Отсюда следует практический вывод: проблема обычно не в самом 15288, а в том, как организация его интерпретирует и применяет. Один и тот же набор lifecycle processes можно превратить либо в тяжёлую бюрократию, либо в управляемый жизненный цикл, который быстро обрабатывает новые факты и согласованно обновляет требования, архитектурные решения, риски и верификацию.

Из чего состоит systems engineering agility

В разделе 5 стандарт выделяет восемь стратегических аспектов systems engineering agility:

• adaptable modular architecture;

• iterative incremental development;

• attentive situational awareness;

• attentive decision making;

• common-mission teaming;

• shared-knowledge management;

• continual integration and test;

• being agile.

При этом стандарт отдельно оговаривает: не обязательно внедрять все аспекты сразу. Степень agility определяется и тем, сколько аспектов реально работает, и тем, насколько каждый из них соответствует характеристикам системы, mission needs и организационному контексту.

1. Adaptable modular architecture

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

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

2. Iterative incremental development

Стандарт связывает iterative incremental development с уменьшением rework, повышением качества и поддержкой innovation. При этом он различает iteration как повторение процесса и increment как проверяемую поставляемую версию, дающую новую или измененную capability.

Это полезное различение. Команда может работать ритмично, но не производить проверяемых результатов. Поэтому важен не только календарный ритм, но и то, что именно появляется на выходе: прототип, функция, сценарий, подтвержденная capability, новый verified configuration.

3. Attentive situational awareness

Здесь стандарт особенно точен: нужно внимательно поддерживать awareness и о внутренней ситуации, то есть doing things right, и о внешней, то есть doing the right things. В примерах перечислены демонстрации work in progress, автоматизированные проверки соответствия требованиям, периодические оценки процесса, мониторинг технологий, угроз и устаревания COTS-компонентов.

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

4. Attentive decision making

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

Это особенно важно для инженерных проектов, где разные изменения имеют разный масштаб последствий. Одно дело — изменить формат отчета или порог в песочнице. Другое — изменить внешний интерфейс, safety requirement, криптографический механизм или решение, затрагивающее эксплуатационный риск. Гибкость здесь не означает, что все меняется одинаково быстро; она означает, что границы изменения заданы явно и не маскируются лозунгом «мы работаем agile».

5. Common-mission teaming

Стандарт различает collaboration, cooperation и teaming. Это не синонимы: обмен информацией, согласование действий и совместная работа на общую цель — разные режимы взаимодействия.

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

6. Shared-knowledge management

Стандарт говорит не о «магическом едином документе», а о shared-knowledge management как об ускорении mutual learning и поддержке authoritative sources of truth для внутренних и внешних участников. При этом он различает краткосрочное операционное знание — что произошло, что происходит и что запланировано — и долгосрочное курируемое знание: цифровые артефакты, lessons learned, proven practices.

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

7. Continual integration and test

Этот аспект нужен для раннего обнаружения интеграционных проблем до того, как они превратятся в дорогую переделку на поздней стадии или уже в эксплуатации. Стандарт говорит о синхронизации нескольких инженерных доменов, а в примерах упоминает digital engineering, physical mock-up и среды, где вместе существуют реальные и симулированные компоненты.

Для cyber-physical и embedded-систем это особенно практично. Реальные проблемы часто проявляются не внутри отдельного компонента, а на стыке: hardware и software, алгоритма и данных, timing и communication, эксплуатации и архитектурных предположений. Поздняя интеграция почти всегда означает позднее обнаружение системных дефектов.

8. Being agile

Последний аспект сформулирован как being agile. Стандарт подчеркивает, что agility — это поведение, а не процедура: sensing, responding and evolving.

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

Что полезно в разделе о заблуждениях

Одна из самых сильных частей стандарта — таблица common misunderstandings about agile. Она полезна тем, что не романтизирует agile и не сводит его к свободе от дисциплины.

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

Он не говорит, что agile автоматически делает проект быстрее. Он говорит, что working product можно поставлять раньше и меньшими партиями, но это не гарантирует более быстрого завершения проекта целиком.

Он не ограничивает agile software-разработкой. В документе прямо сказано, что подход применим и за пределами software, а Annex A приводит case story по agile development and evolution of an uncrewed, off-road vehicle.

Наконец, стандарт не поддерживает идею, будто short feedback loops отменяют formal validation или долгосрочную работу с рисками. Напротив, в таблице отдельно указано, что final validation в intended operating environment остается необходимой, а long-term strategic risk management должно продолжаться на всем жизненном цикле.

Почему это особенно важно для AI, IoT и embedded

Именно в этих проектах особенно быстро выясняется, что исходные представления о системе неполны.

В AI-системах после пилота могут измениться качество входных данных, характер ошибок модели, условия human review, требования к latency или правила обработки недостоверных источников. В IoT и embedded быстро выясняется, что лабораторная картина не совпадает с полевой: влияют монтаж, температура, вибрации, ориентация устройства, энергобюджет, качество связи и режимы эксплуатации.

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

Если после такого входа команда действительно работает в логике agile SE, обновляются не только устные договоренности и слайды статуса. Должны обновляться requirement baseline, architectural decision record, risk register, verification case и decision log. Без этого проект получает локальное впечатление, но не оформляет его в проверяемый и трассируемый инженерный результат.

Что хорошо видно в Annex A

В приложении A стандарт приводит case story по agile development and evolution of an uncrewed, off-road vehicle. Этот кейс полезен не только тем, что относится не к чистому software, но и тем, что показывает гибкость через наблюдаемые механизмы.

В проекте использовались шестимесячные перекрывающиеся increments, внутри которых было не меньше двух итераций. Подрядчиков поощряли приносить work in progress на раннюю интеграцию, а в конце каждой волны проводились workshops с пользователями и table-top exercises, которые выявляли реальные operational needs.

В кейсе используется сильный термин collective consciousness. В обзорной статье его лучше не оставлять как метафору без пояснения. В инженерном смысле здесь речь идет о наборе наблюдаемых механизмов: общей видимости статуса, общей событийной ленте изменений, едином реестре решений, ранней интеграции work-in-progress, открытой коммуникации и общем ритме review и escalation. Именно эта организационная конструкция позволяет команде быстро замечать рассогласования и реагировать на них не локально, а на уровне проекта.

Отдельно показательно, что shared knowledge repository — CIE — в кейсе рассматривается как необходимое условие успеха. Но и здесь важен не образ «одного файла со всей истиной», а то, что через CIE были связаны статусы, решения, новые данные, результаты испытаний и представления для разных ролей.

Практический вывод

Чтобы эта логика не оставалась на уровне общих слов, полезно дать рабочее определение ключевого термина.

Learning loop в контексте статьи — это цикл, в котором для конкретной гипотезы, риска или архитектурного вопроса заранее заданы:

• входные данные или источник факта;

• метод проверки;

• критерий завершения;

• перечень обновляемых артефактов.

Тогда learning loop становится не красивой метафорой, а объектом управления. У него есть границы, ответственный, ожидаемый результат и условия закрытия вопроса.

Именно поэтому learning loop не равен sprint. Спринт — это единица планирования. Learning loop — это единица снижения неопределенности по конкретному вопросу. Иногда они совпадают, но часто нет: проверка гипотезы о данных, полевое испытание датчика, анализ интеграционного сбоя и накопление reliability evidence живут в разных временных масштабах.

Практический критерий здесь очень простой. Если после цикла проверки обновились связанные артефакты — например, requirement baseline, ADR, risk register, verification case и decision log — значит проект действительно уменьшил неопределенность в управляемой форме. Если обновился только статус-отчет, значит наблюдение произошло, но жизненный цикл его еще не обработал.

Чек-лист для команды

Ниже короткий self-check, который можно использовать прямо на проекте.

• [ ] Архитектура системы допускает локальные изменения без каскадной переделки соседних частей.

• [ ] Инкременты дают проверяемую capability, а не только видимость движения.

• [ ] Для важных вопросов проект собирает наблюдаемые основания: результаты испытаний, полевые наблюдения, инциденты, телеметрию, результаты обзоров и анализы.

• [ ] Понятно, какие решения можно принимать быстро, а какие требуют review и другого уровня ответственности.

• [ ] Hardware, software, data, test, ops и другие дисциплины работают в общей рамке решения, а не как очередь передач.

• [ ] У проекта есть авторитетный, версионируемый набор связанных артефактов с явной трассировкой и ролевыми представлениями по требованиям, решениям, рискам и тестам.

• [ ] Интеграция и тестирование начинаются рано, а не откладываются на финал.

• [ ] Для каждого существенного learning loop заранее определены вход, метод проверки, критерий завершения и перечень артефактов, которые должны обновиться.

Если по нескольким пунктам ответ отрицательный, проблема обычно не в нехватке agile-ритуалов. Чаще это означает, что жизненный цикл пока плохо приспособлен к работе с неопределенностью как с нормальным инженерным материалом.

Практическое значение

ISO/IEC/IEEE 24748-10:2026 ценен не тем, что предлагает новую моду на agile. Он ценен тем, что возвращает разговор о гибкости в инженерный контекст.

Гибкость здесь — это не отказ от требований, архитектуры, верификации и lifecycle discipline. И не право менять все в любой момент. Речь о другом: проект должен уметь получать факты из наблюдений и проверок, переводить их в решения и согласованно обновлять связанные артефакты системы описаний.

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