Углубленный сравнительный анализ моделей зрелости процесса разработки программного обеспечения: От истоков до современных тенденций

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

Данное исследование призвано провести углубленный сравнительный анализ ключевых моделей оценки зрелости процесса разработки программного обеспечения, таких как CMMI (Capability Maturity Model Integration), ISO/IEC 15504 (SPICE) и современные Agile-модели. Мы не просто представим их структуру, но и проследим их историческую эволюцию, выявим фундаментальные сходства и различия, рассмотрим практические аспекты внедрения и оценим их вклад в повышение качества ПО и эффективности работы команд. Особое внимание будет уделено актуальным тенденциям и вызовам, стоящим перед индустрией, включая последние обновления CMMI 2.0 и их интеграцию с гибкими методологиями. Цель работы — предоставить читателю, будь то студент технического или экономического вуза, исчерпывающее и актуальное руководство по миру моделей зрелости, вооружая его знаниями для принятия обоснованных решений в области управления проектами и инженерии ПО.

Теоретические основы и исторический контекст моделей зрелости

Залог успешного проекта в IT-индустрии, будь то разработка нового приложения или сложной корпоративной системы, кроется не только в таланте индивидуальных инженеров, но и в качестве самого процесса, по которому они работают. Это понимание привело к возникновению и развитию моделей зрелости — инструментов, которые помогают организациям систематизировать, измерять и постоянно совершенствовать свои методы работы. Как же эти инструменты преобразили подход к управлению качеством в IT?

Понятие зрелости процесса и модели зрелости

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

История возникновения и эволюция моделей зрелости

История моделей зрелости — это увлекательный рассказ о поиске путей упорядочивания хаоса в сложной и быстро развивающейся отрасли. Первоначальная концепция системы зрелости процессов зародилась в недрах IBM в начале 1980-х годов благодаря усилиям Уоттса Хамфри и его коллег. Хамфри, будучи дальновидным исследователем, заметил прямую корреляцию между качеством продукта ПО и качеством процесса его разработки, стремясь адаптировать классический цикл усовершенствования Шухарта-Деминга (Plan-Do-Check-Act) к специфике программной инженерии. Его ключевой инсайт заключался в том, что для достижения постоянного улучшения организациям необходимо решать проблемы в определенной, поэтапной последовательности.

Однако идеи поэтапной структуры зрелости не были совершенно новыми. Ещё в 1979 году Филипп Кросби в своей знаковой книге «Quality Is Free» опубликовал концепцию «Quality Process Maturity Grid», описав пять эволюционных этапов внедрения методик качества в организацию. Эти этапы включали:

• Неопределённость (Uncertainty): Состояние, при котором качество воспринимается как нечто само собой разумеющееся или как источник проблем.
• Пробуждение (Awakening): Осознание необходимости управления качеством и поиск решений.
• Просвещение (Enlightenment): Понимание того, что для улучшения качества требуются изменения в культуре и процессах.
• Мудрость (Wisdom): Интеграция качества в повседневные операции и принятие его как нормы.
• Уверенность (Certainty): Достижение стабильного, предсказуемого качества, когда улучшения становятся частью непрерывного цикла.

Эти идеи Кросби послужили основой. Рон Радис и его команда под руководством Хамфри в 1985 году адаптировали структуру Кросби конкретно к процессу разработки программного обеспечения, опубликовав её в IBM Corporation. Параллельно с этим, в 1983 году Ричард Нолан предложил свою модель «Ступени роста» для IT-организаций, что также подчёркивало растущую потребность в структурировании развития.

Кульминацией этих усилий стало создание в 1986 году в Институте программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги-Меллона модели зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software, CMM). Задача разработки CMM была возложена на SEI с целью оценки зрелости процессов в программной инженерии, особенно для поставщиков Министерства обороны США. В 1987 году Уоттс Хамфри изобрёл модель Software Acquisition Capability Maturity Model, а к концу 1980-х она вернулась в сферу ПО под аббревиатурой Sw-CMM. Первый публичный драфт CMM – CMM v0.2 – появился в январе 1990 года, быстро став де-факто стандартом уровня зрелости процесса разработки в индустрии производства программного обеспечения.

Модель зрелости, как было сформулировано в CMM, состоит из следующих ключевых компонентов:

• Уровни зрелости: Иерархическая структура, описывающая стадии формализации и совершенствования процессов, от хаотичных до оптимизированных.
• Области процессов: Группы связанных практик, которые при совместной реализации приводят к достижению определённого набора целей.
• Цели: Конкретные результаты, которые должны быть достигнуты при реализации практик в данной области процесса.
• Практики: Конкретные действия или активности, которые необходимо выполнять для достижения целей.

Под уровнями зрелости понимается шкала, которая характеризует степень формализации и совершенствования процессов, начиная от нерегламентированных, ситуативных (ad-hoc) процессов до таких, которые состоят из формализованных и определённых шагов, у которых есть метрики результатов, и которые были оптимизированы для постоянного совершенствования. Таким образом, история моделей зрелости — это история осознания того, что путь к качеству и эффективности лежит через систематическое управление и непрерывное улучшение процессов, подтверждая неразрывную связь между структурой и результатом.

Модель CMMI (Capability Maturity Model Integration): Структура, уровни и области применения

В начале 21 века индустрия программного обеспечения столкнулась с потребностью в более комплексном и унифицированном подходе к совершенствованию процессов. Так на смену CMM пришла её интегрированная версия — CMMI, которая не только вобрала в себя лучшие практики предшественницы, но и расширила горизонты применимости, став мощным инструментом для организаций, стремящихся к операционному совершенству.

Обзор CMMI: От CMM к CMMI

CMMI (Capability Maturity Model Integration) — это не просто модель, а целая система совершенствования процессов, предоставляющая организациям детальную дорожную карту для постоянного улучшения. Она представляет собой набор методологий и рекомендаций, предназначенных для повышения эффективности процессов в организациях различных размеров и видов деятельности. Основная предпосылка CMMI заключается в том, что систематизированный процесс помогает уловить и использовать лучшие достижения прошлых проектов для успеха в будущих.

CMMI возникла как эволюционное развитие своей предшественницы, CMM (Capability Maturity Model). В то время как CMM была ориентирована преимущественно на программную инженерию, CMMI, созданная в 2002 году, объединила в себе несколько ранее существовавших моделей зрелости, охватывая системную инженерию, разработку ПО, а затем и услуги, и приобретение. Последняя версия CMM 1.3 появилась в 2009 году, но уже тогда CMMI зарекомендовала себя как более современный и универсальный подход. CMMI предназначена для институционализации набора предопределённых практик и обеспечения их последовательного выполнения, чтобы увеличить вероятность успешного завершения проектов — в срок и в рамках бюджета. Важно отметить, что CMMI, как и CMM, не предписывает, как выполнять ту или иную работу, а лишь указывает, что нужно делать, оставляя решения о способах выполнения на усмотрение исполнителей, что обеспечивает гибкость в адаптации к специфике конкретной организации. Именно эта гибкость позволяет CMMI оставаться актуальной в меняющихся условиях рынка.

Уровни зрелости CMMI

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

• Уровень 1: Начальный (Initial). На этом уровне процессы характеризуются хаотичностью, реактивностью и непредсказуемостью. Процессы, если они вообще существуют, не регламентируются, среда нестабильна, а успех проекта часто зависит от героических усилий отдельных личностей, а не от систематической работы. Результаты часто непредсказуемы, и при возникновении проблем организация реагирует на них, а не предупреждает.
• Уровень 2: Управляемый (Managed). На этом этапе организация начинает осознанно управлять проектами. Часть основных процессов описана и может использоваться многократно. Процессы становятся более дисциплинированными и реактивными, но их применение может быть не универсальным по всей организации. Устанавливаются базовые практики управления проектами, такие как планирование, мониторинг и контроль.
• Уровень 3: Определённый (Defined). Этот уровень означает, что все процессы в организации определены и задокументированы, стандартизированы и интегрированы в единую систему. Они понятны и используются всеми сотрудниками. Процессы могут быть адаптированы под конкретные проекты, но в рамках установленных организационных стандартов. Акцент делается на проактивном управлении и предотвращении проблем.
• Уровень 4: Количественно управляемый (Quantitatively Managed). На этом уровне процессы измеряются и контролируются с использованием статистических и других количественных методов. Управление осуществляется на основании объективно полученных данных. Создаются метрики процессов разработки для контроля качества, производительности и других ключевых показателей, что позволяет предсказывать результаты и принимать решения на основе фактов.
• Уровень 5: Оптимизирующийся (Optimizing). Высший уровень зрелости, ориентированный на постоянное улучшение и оптимизацию бизнес-процессов. Организация активно ищет способы совершенствования своих процессов путём внедрения новых методов, технологий и подходов, основываясь на данных, полученных на 4-м уровне. Здесь акцент делается на предотвращении дефектов, инновациях и адаптации к изменяющимся потребностям рынка.

Процессные категории и области CMMI

Формальная иерархия процессов в концептуальной модели CMMI организована в четыре основные процессные категории, каждая из которых, в свою очередь, включает несколько процессных областей. Эти категории обеспечивают всесторонний охват деятельности организации:

1. Управление процессами: Фокусируется на определении, внедрении, оценке и улучшении процессов в организации.
2. Управление проектами: Связано с планированием, мониторингом, контролем и управлением рисками отдельных проектов.
3. Разработка: Охватывает весь цикл разработки продукта, от требований до тестирования и развёртывания.
4. Сопровождение: Касается поддержки продукта после его выпуска, включая устранение дефектов и улучшение функциональности.

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

• Категория «Управление проектами» может включать области процессов, такие как «Планирование проекта», «Мониторинг и контроль проекта», «Управление рисками» и «Управление поставщиками».
• Категория «Разработка» может включать «Разработку требований», «Техническое решение», «Интеграцию продукта» и «Верификацию» (тестирование на соответствие требованиям).
• Категория «Управление процессами» содержит области, связанные с «Определением процессов организации», «Фокусом на процессах организации» и «Инновациями и внедрением организации».

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

Для различных видов деятельности были разработаны специализированные модели CMMI:

• CMMI for Development (CMMI-DEV): Ориентирована на организации, занимающиеся разработкой программного обеспечения и систем.
• CMMI for Services (CMMI-SVC): Предназначена для компаний, оказывающих услуги, например, IT-аутсорсинг или поддержку.
• CMMI for Acquisition (CMMI-ACQ): Разработана для организаций, которые приобретают продукты или услуги у поставщиков, помогая им управлять процессом закупок.

Таким образом, CMMI предлагает всеобъемлющий, но гибкий фреймворк, который позволяет организациям систематически повышать свою зрелость, улучшать предсказуемость результатов и, в конечном итоге, достигать поставленных бизнес-целей.

Модель ISO/IEC 15504 (SPICE): Принципы, уровни и методология оценки

Наряду с американскими разработками, мировое сообщество активно работало над созданием международного стандарта для оценки и улучшения процессов разработки программного обеспечения. Результатом этих усилий стала серия стандартов ISO/IEC 15504, более известная как SPICE, которая предложила свой уникальный взгляд на измерение зрелости и возможностей процессов.

Сущность и история SPICE

ISO/IEC 15504, или SPICE (Software Process Improvement and Capability Determination), является эталонной моделью, которая определяет методологию измерения процесса и измерения его возможностей. Это международно признанный стандарт качества процессов программного обеспечения, целью которого является не только улучшение этих процессов, но и точное определение уровней возможностей каждого из них.

Разработка SPICE началась ещё в 1993 году в рамках проекта, направленного на создание универсального подхода к оценке процессов. Этот масштабный труд завершился получением статуса международного стандарта в 2006 году. В отличие от CMMI, которая исторически развивалась из оборонного сектора США, SPICE изначально задумывалась как глобальный стандарт, применимый в любой стране и для любой организации, занимающейся разработкой программного обеспечения. Её универсальность и ориентация на международное признание стали одними из ключевых факторов её широкого распространения.

Категории процессов и уровни возможностей SPICE

Модель SPICE структурирована таким образом, чтобы охватить все ключевые аспекты жизненного цикла программного обеспечения и управления им. Она разделена на процессы из пяти категорий, каждая из которых объединяет связанные между собой активности:

1. Поставщик-потребитель (Customer-Supplier): Процессы, связанные с взаимодействием между организацией-разработчиком и её клиентами, включая установление требований, приёмку и поставку.
2. Инжиниринг (Engineering): Непосредственно процессы разработки программного обеспечения, от анализа требований до проектирования, кодирования, тестирования и интеграции.
3. Поддержка (Support): Процессы, обеспечивающие эффективное выполнение других процессов, такие как управление конфигурацией, документирование, управление проблемами и обеспечение качества.
4. Управление (Management): Процессы планирования, мониторинга и контроля проектов и ресурсов.
5. Организация (Organization): Процессы, касающиеся общей организационной инфраструктуры и её развития, включая управление персоналом, инфраструктурой и улучшениями процессов.

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

• Уровень 0: Неполный процесс (Not Achieved, 0-15%): Процесс не реализован или не достигает своих целей. Существуют лишь отдельные элементы процесса, которые не скоординированы и не дают предсказуемых результатов.
• Уровень 1: Выполняемый процесс (Partially Achieved, >15%-50%): Процесс реализован, и его основные цели достигаются. Однако выполнение процесса может быть неполным, не систематическим и зависеть от индивидуальных усилий. Управление процессом ещё недостаточно развито.
• Уровень 2: Управляемый процесс (Largely Achieved, >50%-85%): Процесс реализован и управляется. Существуют планы, ресурсы выделены, ответственность определена, а результаты мониторятся и контролируются. Это позволяет получать более стабильные и предсказуемые результаты.
• Уровень 3: Установленный процесс (Fully Achieved, >85%-100%): Процесс не только управляется, но и установлен в организации. Он описан, стандартизирован и применяется последовательно по всей организации. Определены роли, ответственности, входные и выходные данные, критерии успешности.
• Уровень 4: Предсказуемый процесс (Predictable): На этом уровне процесс выполняется в заданных пределах, измеряется и контролируется с использованием количественных методов. Это обеспечивает высокую степень предсказуемости результатов, позволяя управлять вариациями процесса и прогнозировать его производительность.
• Уровень 5: Оптимизированный процесс (Optimizing): Высший уровень, на котором процесс постоянно улучшается и адаптируется к изменяющимся потребностям организации и рынка. Инновации внедряются для повышения эффективности, производительности и качества. Организация активно ищет новые технологии и подходы для совершенствования своих процессов.

Атрибуты измерения возможностей и шкала оценки SPICE

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

• Производительность процесса (Process Performance): Насколько эффективно процесс достигает своих целей.
• Управление производительностью (Performance Management): Способность планировать и управлять достижением целей процесса.
• Управление продуктом (Product Management): Насколько хорошо процесс управляет продуктами своей деятельности.
• Определение процесса (Process Definition): Степень формализации и стандартизации процесса.
• Развертывание процесса (Process Deployment): Насколько широко процесс внедрён и используется в организации.
• Измерение процесса (Process Measurement): Способность собирать и анализировать данные о процессе.
• Контроль процесса (Process Control): Способность управлять процессом и корректировать его выполнение.
• Нововведения в процесс (Process Innovation): Способность внедрять улучшения и инновации в процесс.
• Оптимизация процесса (Process Optimization): Способность постоянно совершенствовать процесс.

Каждый из этих атрибутов может быть измерен по рейтинговой шкале из четырёх пунктов (NPLF):

• N (Not Achieved): Не достигнуто (0-15%)
• P (Partially Achieved): Частично достигнуто (>15%-50%)
• L (Largely Achieved): В значительной степени достигнуто (>50%-85%)
• F (Fully Achieved): Полностью достигнуто (>85%-100%)

Эта детальная шкала позволяет проводить более точную и объективную оценку, чем простое присвоение уровня. Стандарт ISO/IEC 15504 также включает рекомендации по проведению оценки, сам процесс оценки, модель для оценки и используемые инструменты, что делает его комплексным решением.

Важно отметить, что первые стандарты ISO/IEC 15504 были заменены более новыми и уточнёнными версиями, такими как ISO/IEC 33001 «Информационные технологии. Оценка процесса. Понятия и термины» и ISO/IEC 33002 «Информационные технологии. Оценка процесса. Требования к выполнению оценки процесса». Эти обновления отражают постоянное развитие и совершенствование методологий оценки процессов в условиях стремительно меняющейся IT-индустрии, подтверждая их способность адаптироваться к новым вызовам.

Agile-модели зрелости и современные подходы

С появлением и широким распространением гибких методологий разработки (Agile), таких как Scrum и Kanban, традиционные модели зрелости, разработанные для более предсказуемых и последовательных процессов, столкнулись с необходимостью адаптации. Так возникла новая категория инструментов — Agile-модели зрелости, призванные помочь организациям оценить и улучшить свою способность к быстрой адаптации и эффективной поставке ценности.

Концепция и цели Agile-моделей зрелости

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

Она предоставляет дорожную карту для организаций, переходящих на Agile-разработку, и помогает измерять их прогресс. Конечная цель зрелости Agile — помочь командам эффективно создавать ценность, быстро реагировать на потребности клиентов и изменения рынка. Высокая зрелость Agile способствует снижению затрат, улучшению качества и сокращению времени между планированием и выпуском на рынок. Например, исследования показывают, что компании с высоким уровнем зрелости Agile могут сократить время вывода продукта на рынок на 37%, улучшить качество программного обеспечения на 25% и повысить удовлетворённость клиентов на 21%. Это подчёркивает не только теоретическую, но и значительную практическую ценность внедрения Agile-принципов. Но действительно ли организации полностью осознают весь потенциал этих преимуществ?

Уровни зрелости Agile и их преимущества

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

• Начальный (Initial): На этой стадии организация или команда только начинает свой путь в Agile. Процесс разработки ПО является ситуативным (ad-hoc), нет стандартизации практик, а понимание Agile-принципов поверхностно. Характерны сопротивление изменениям и сохранение старых привычек.
• Определённый (Defined): Команда осознанно применяет некоторые Agile-практики (например, Scrum-собрания, бэклог продукта). Определены основные роли и артефакты, но их применение может быть непоследовательным, а понимание принципов ещё неглубоко.
• Управляемый (Managed): Agile-практики последовательно применяются, процессы становятся более стабильными и предсказуемыми. Команды активно используют инструменты для мониторинга прогресса, начинают собирать метрики. Появляется фокус на постоянном улучшении через ретроспективы.
• Количественно управляемый (Quantitatively Managed): На этом уровне ключевые области результатов и процессы хорошо проработаны, повышается предсказуемость и качество результатов. Делается сильный акцент на постоянное улучшение, и команда начинает исследовать продвинутые практики, такие как масштабированные Agile-фреймворки (например, SAFe — Scaled Agile Framework). Решения принимаются на основе данных, а производительность команд измеряется и анализируется.
• Оптимизирующийся (Optimizing): Высший уровень зрелости, характеризующийся глубоким внедрением Agile-мышления в культуру организации. Команды высокопроизводительны и имеют полномочия, идеи определяются потребностями клиентов, происходит постоянное улучшение и обучение. Организация постоянно адаптируется и развивается, поощряя инновации. Agile-мышление является частью ДНК компании.

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

Процесс оценки зрелости Agile и другие фреймворки

Оценка зрелости Agile выходит за рамки простой проверки использования фреймворков (Scrum, Kanban), углубляясь в культуру, процессы и общее мышление организации. Этот процесс обычно включает несколько этапов:

1. Определение целей: Чёткое понимание, что именно организация хочет улучшить и зачем.
2. Выбор фреймворка: Подбор наиболее подходящей модели зрелости Agile или создание собственной.
3. Использование опросов и интервью: Сбор данных от всех членов команды и стейкхолдеров.
4. Оценка и анализ результатов: Идентификация сильных сторон и областей для улучшения.
5. Проведение семинаров: Обсуждение результатов и выработка решений.
6. Создание плана действий: Формирование конкретных шагов по улучшению с ответственными лицами и сроками.

Оценка обычно охватывает множество измерений, включая:

• Динамика команды и сотрудничество.
• Практики постоянного улучшения (ретроспективы, демонстрации).
• Техническое превосходство и качество (автоматизация тестирования, непрерывная интеграция/развёртывание).
• Ориентация на клиента и предоставление ценности.
• Организационная культура и поддержка руководства.
• Agile-практики и процессы (Scrum, Kanban).
• Инструменты и инфраструктура.

Помимо традиционных Agile-моделей зрелости, существуют и другие фреймворки. Например, Agile Fluency Model, разработанная Джеймсом Шором и Дайаной Ларсен, предлагает альтернативный взгляд. Она не является моделью зрелости в традиционном понимании, а скорее инструментом для команд, помогающим внутренне оценивать необходимые возможности для достижения конкретных бизнес-целей, а не сравнивать себя с внешним эталоном. Команды могут начинать с любого из четырёх направлений: фокусировка, доставка, оптимизация, усиление, в зависимости от своих приоритетов и потребностей. Это подчёркивает эволюцию подходов к оценке, где акцент смещается от жёсткого соответствия стандарту к адаптивности и практической ценности для бизнеса.

Сравнительный анализ ведущих моделей зрелости

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

Сходства и различия в методологии и структуре

Если взглянуть на CMMI, ISO/IEC 15504 (SPICE) и Agile-модели зрелости, сразу бросаются в глаза как общие черты, так и фундаментальные различия. Общим для всех является стремление к улучшению процессов, повышению предсказуемости и качества результатов. Однако методология, структура и философия у них разные.

Критерий сравнения	CMMI (Capability Maturity Model Integration)	ISO/IEC 15504 (SPICE)	Agile Maturity Models
Основной фокус	Совершенствование процессов для предсказуемости и эффективности.	Измерение процессов и их возможностей для улучшения.	Оценка и улучшение гибкости, адаптивности и ценности.
Тип модели	Уровневая (Staged) или Непрерывная (Continuous).	Уровневая (Staged) — 6 уровней возможностей.	Чаще уровневая (5 уровней), но есть и другие подходы (Agile Fluency Model).
Количество уровней	5 уровней зрелости.	6 уровней возможностей.	Обычно 5 уровней зрелости.
Подход к оценке	Формальные оценки SCAMPI, ориентированные на соответствие практикам.	Детальная оценка атрибутов процессов по шкале NPLF.	Самооценка, опросы, интервью, семинары. Менее формализована.
Степень предписываемости	Высокая. Определяет «что» нужно делать, оставляя «как» на усмотрение.	Средняя. Эталонная модель, даёт рекомендации, но не предписывает.	Низкая. Фокус на принципах, ценностях и адаптации.
Исторические корни	Оборонный сектор США, инженерные практики.	Международный стандарт, общепромышленные практики.	Гибкая разработка, реакция на быстро меняющийся рынок.
Главная цель	Институционализация практик, снижение рисков, повышение предсказуемости.	Объективная оценка процессов, сопоставимость результатов.	Повышение адаптивности, скорости реакции, удовлетворённости клиента.
Интеграция	Интегрирует программную и системную инженерию, услуги, закупки.	Совместима с ISO 9001, 12207, 15288.	Интегрируется с фреймворками Scrum, Kanban, SAFe.

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

ISO/IEC 15504 (SPICE) — это эталонная модель, которая акцентируется на измерении процесса и его возможностей. Она имеет шестиуровневую структуру и детально проработанные атрибуты измерения, что делает её мощным инструментом для объективной оценки. SPICE менее предписывающая, чем CMMI, и её философия заключается в предоставлении основы для оценки, а не в диктовке конкретных реализаций.

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

Применимость и охват моделей

Выбор модели зрелости во многом зависит от контекста и специфики организации:

• CMMI наиболее применима для крупных организаций, особенно тех, кто работает с государственными заказами или в отраслях с высокими требованиями к надёжности и предсказуемости (например, аэрокосмическая, оборонная промышленность). Её комплексный характер и фокусировка на институционализации практик делают её идеальной для создания стабильных, повторяемых процессов, где точность и соответствие стандартам критически важны. Модели CMM/CMMI могут быть использованы как руководство для разработки и улучшения производственных процессов в широком спектре индустрий.
• ISO/IEC 15504 (SPICE) широко используется в Европе и других регионах как международный стандарт. Она особенно полезна для аудита и сертификации процессов, а также для сравнительной оценки различных поставщиков программного обеспечения. SPICE подходит для организаций, которым требуется внешнее подтверждение качества процессов или для тех, кто хочет иметь универсальный фреймворк для оценки, совместимый с другими стандартами ISO.
• Agile-модели зрелости оптимальны для компаний, работающих в быстро меняющихся условиях, где гибкость, скорость вывода продукта на рынок и постоянная обратная связь с клиентом являются ключевыми. Это стартапы, IT-компании, разрабатывающие потребительские продукты, а также организации, стремящиеся трансформировать свою культуру в сторону большей адаптивности и инновационности. Они помогают командам в первую очередь понять, насколько они действительно «гибкие», а не просто используют Agile-терминологию.

Взаимодействие и интеграция с гибкими методологиями

Вопрос взаимодействия традиционных моделей зрелости с Agile и DevOps становится всё более актуальным. Изначально CMMI и SPICE разрабатывались в парадигме «водопадной» разработки, что создавало определённые сложности при их применении в Agile-среде. Однако с течением времени эти модели также эволюционируют.

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

Интеграция CMMI и SPICE с Agile и DevOps часто подразумевает адаптацию традиционных практик к гибким принципам. Например, практики управления требованиями CMMI могут быть реализованы через бэклог продукта в Scrum, а контроль качества может быть усилен через практики непрерывной интеграции и автоматизированного тестирования в DevOps.

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

Практические аспекты внедрения моделей зрелости: Преимущества, недостатки и факторы успеха

Внедрение моделей зрелости — это не просто теоретическое упражнение, а серьёзный стратегический шаг, который требует значительных ресурсов и усилий. Однако, как показывает практика, при правильном подходе он способен принести ощутимые выгоды.

Преимущества внедрения моделей зрелости

Внедрение моделей зрелости, будь то CMMI, SPICE или Agile-модели, открывает перед организациями целый ряд преимуществ, формируя потенциал для роста результативности всей компании:

1. Повышение качества программного обеспечения: Одно из наиболее очевидных преимуществ. Зрелые организации обладают широкими возможностями по управлению процессами, что приводит к созданию более стабильных, надёжных и безошибочных продуктов.
2. Сокращение издержек: Лучше определённые и управляемые процессы уменьшают количество переделок, ошибок и отходов, что ведёт к экономии ресурсов и времени.
3. Повышение предсказуемости проектов: На более высоких уровнях зрелости проекты выполняются в соответствии с регламентами, сроки и бюджеты соблюдаются с большей точностью. Создаются метрики процессов разработки для контроля качества, что позволяет принимать обоснованные решения.
4. Улучшение коммуникации и сотрудничества: Чётко прописанные процессы и роли способствуют лучшей координации внутри команды и между отделами.
5. Формирование потенциала для роста: Технология оценки зрелости бизнес-процесса отражает как полноту бизнес-процесса организации, так и его постоянство. Это создаёт основу для дальнейшего масштабирования и инноваций.
6. Конкурентные преимущества: Сертификация по CMMI или SPICE может стать значимым преимуществом при участии в тендерах и заключении контрактов, особенно в государственном секторе или с крупными корпорациями.
7. Улучшение удовлетворённости клиентов: Поставка качественных продуктов клиентам вовремя и по ожидаемой цене — общая цель компаний-разработчиков ПО, желающих добиться успеха. Зрелые процессы напрямую способствуют её достижению.

Количественные подтверждения преимуществ: Внедрение CMMI, согласно исследованиям, может привести к сокращению затрат на разработку на 10-20%, уменьшению количества дефектов на 20-40% и сокращению времени вывода продукта на рынок на 15-30%. Что касается Agile, компании с высоким уровнем зрелости могут сократить время вывода продукта на рынок на 37%, улучшить качество программного обеспечения на 25% и повысить удовлетворённость клиентов на 21%. Эти цифры наглядно демонстрируют ощутимую отдачу от инвестиций в повышение зрелости процессов.

Недостатки и вызовы при внедрении

Несмотря на очевидные преимущества, процесс внедрения моделей зрелости сопряжён с рядом сложностей и потенциальных недостатков:

1. Высокие затраты и ресурсы: Проведение оценок, обучение персонала, изменение процессов и инструментов требуют значительных финансовых, временных и человеческих ресурсов.
2. Бюрократизация: Чрезмерное увлечение документацией и соблюдением процедур может привести к бюрократизации, замедляя инновации и делая процессы менее гибкими, что особенно критично для Agile.
3. Сопротивление изменениям: Сотрудники могут сопротивляться новым процессам, воспринимая их как дополнительную нагрузку или ограничение свободы.
4. Нелинейность роста: Одной из проблем Agile Maturity Models является то, что рост не всегда линеен. Организация может достичь высокого уровня в одной области, но отставать в другой, что создаёт дисбаланс.
5. Сложность выбора: Множество моделей и фреймворков может привести к путанице при выборе наиболее подходящего для конкретной организации.
6. Фокус на соответствии, а не на результате: Существует риск, что организации будут стремиться к формальному соответствию требованиям модели, не достигая реального улучшения бизнес-результатов.

Факторы успеха и практические рекомендации

Для успешного внедрения и извлечения максимальной пользы из моделей зрелости необходимо учитывать ряд критически важных факторов:

1. Поддержка высшего руководства: Без явной и последовательной поддержки со стороны руководства инициативы по улучшению процессов обречены на провал.
2. Наличие квалифицированных экспертов: Для проведения оценки, разработки планов улучшений и внедрения изменений необходимы специалисты, хорошо разбирающиеся в выбранной модели и в процессах разработки ПО.
3. Вовлечённость и обучение команд: Команды должны быть не просто информированы, но и активно вовлечены в процесс. Чётко прописанная модель зрелости помогает быстро синхронизироваться и находить зоны роста команд, выравнивая глубину проникновения и полноту технологий и процессов.
4. Постепенное внедрение: Не стоит пытаться изменить всё и сразу. Лучше начать с пилотных проектов и постепенно масштабировать успешные практики.
5. Контроль и прозрачность процесса: Регулярный мониторинг прогресса, сбор метрик и открытое обсуждение результатов помогают поддерживать темп и корректировать курс. Для работы модели зрелости необходимы мягкие коммиты от команд, контроль и прозрачность процесса.
6. Актуализация регламентов и процессов: Модели зрелости не являются статичными. Необходимо эпизодически пересматривать секции и повышать базовый уровень, а также актуализировать регламенты по мере необходимости, чтобы они соответствовали изменяющимся потребностям бизнеса и технологиям.
7. Назначение ответственного за модель: Должен быть чётко определённый человек или группа, отвечающие за внедрение, поддержание и развитие модели зрелости в организации.

Процесс работы с моделью зрелости часто включает следующие этапы:

• Самооценка команды: Каждая команда самостоятельно оценивает свой уровень зрелости по определённым критериям (например, по шкале от 1 до 3). Оценка зрелости инженерных команд может проводиться по шести основным блокам: Информационная безопасность, Обеспечение качества, Производительность, Фронтенд, Бэкенд, Продакт-деливери.
• Встреча с экспертами: Результаты самооценки обсуждаются с внешними или внутренними экспертами, которые корректируют и подтверждают оценки, выявляя расхождения и предоставляя обратную связь.
• Обучение команд: На основе выявленных зон роста разрабатываются и проводятся обучающие мероприятия, тренинги и мастер-классы для повышения квалификации команд и улучшения их процессов.
• Создание плана улучшений: Формируется конкретный план действий с измеримыми целями и сроками.

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

Актуальные тенденции и перспективы развития в области оценки зрелости ПО

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

CMMI 2.0: Обновления и новый подход к оценке

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

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

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

Этот обновлённый подход отражает стремление CMMI оставаться релевантной в условиях, где Agile и DevOps стали нормой, и где требуется не просто формальное соответствие, а реальное улучшение производительности и бизнес-ценности.

Масштабирование Agile и другие стандарты

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

Параллельно с развитием CMMI и Agile-моделей зрелости, продолжают развиваться и близкие по духу стандарты ISO, такие как:

• ISO 9001: Стандарт систем менеджмента качества, который обеспечивает общие требования к системам управления в любой организации.
• ISO/IEC 12207: Стандарт жизненного цикла программного обеспечения, описывающий процессы, которые должны быть выполнены в течение жизненного цикла ПО.
• ISO/IEC 15288: Стандарт жизненного цикла систем, охватывающий более широкий спектр системных проектов.
• ISO/IEC 15504 (SPICE): Как уже упоминалось, SPICE сам по себе является эталонной моделью, которая постоянно обновляется (например, замена на ISO/IEC 33001 и 33002), отражая лучшие практики в оценке процессов.

Все эти стандарты и модели взаимодействуют, создавая комплексную экосистему для управления качеством и процессами в IT-индустрии.

Перспективы развития

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

• Интеграция с DevOps и AI/MLOps: По мере того как DevOps становится стандартом, модели зрелости будут всё больше фокусироваться на оценке непрерывной интеграции, непрерывной поставки и операционной зрелости. Появление MLOps (Machine Learning Operations) потребует новых аспектов оценки зрелости в контексте разработки и развёртывания систем машинного обучения.
• Усиление акцента на данные и аналитику: Модели зрелости будут всё более ориентированы на количественные метрики и предиктивную аналитику, чтобы не просто оценивать процессы, но и прогнозировать их эффективность, используя большие данные и искусственный интеллект.
• Адаптивность и контекстуализация: Модели будут становиться ещё более гибкими, позволяя организациям настраивать их под свои уникальные нужды, размер и отрасль, отходя от «одноразмерного» подхода.
• Оценка зрелости кибербезопасности и устойчивости: В условиях растущих киберугроз и требований к устойчивости бизнеса, модели зрелости будут расширять свой охват, включая аспекты безопасности, надёжности и отказоустойчивости систем.
• Фокус на человеческом факторе и культуре: Признание того, что технологии — это лишь часть уравнения, приведёт к большему вниманию к организационной культуре, лидерству, компетенциям команд и благополучию сотрудников как ключевым факторам зрелости.

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

Заключение

Проведение углубленного сравнительного анализа моделей зрелости процесса разработки программного обеспечения позволило нам проследить их эволюцию от первых концепций до современных адаптированных фреймворков. Мы увидели, как идеи Уоттса Хамфри и Филиппа Кросби трансформировались в детализированные иерархические структуры CMMI и международные стандарты ISO/IEC 15504 (SPICE), а затем адаптировались под нужды гибкой разработки в Agile-моделях зрелости.

Каждая из рассмотренных моделей — CMMI, ISO/IEC 15504 и Agile Maturity Models — имеет свою уникальную философию, структуру и области применения. CMMI предлагает комплексный, структурированный подход к институционализации процессов, обеспечивая предсказуемость и надёжность, что особенно ценно в проектах с высокими требованиями к безопасности и качеству. SPICE, будучи эталонной моделью, предоставляет универсальный фреймворк для объективной оценки возможностей процессов, способствуя международному признанию и сравнимости. Agile-модели зрелости, в свою очередь, акцентируются на адаптивности, скорости и клиентоориентированности, помогая организациям процветать в быстро меняющейся рыночной среде.

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

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

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

Список использованной литературы

1. Модель зрелости процессов разработки программного обеспечения / Паулк Марк, Куртис Билл, Хриссис Мэри Бет, Вебер Чарльз В., Гарсия Сьюзен М., Буш Мерилин. (Книга переведена на русский язык).
2. Райсс М. Границы «безграничных» предприятий: перспективы сетевых организаций // Проблемы теории и практики управления. 1997. №1.
3. Патюрель Р. Создание сетевых организационных структур // Проблемы теории и практики управления. 1997. №3.
4. Вютрих Х.А., Филипп А.Ф. Виртуализация как возможный путь развития управления // Проблемы теории и практики управления. 1999. №5.
5. Модели зрелости процесса тестирования ПО. URL: https://software-testing.ru/library/testing/maturity-models/161-maturity-models-for-software-testing (дата обращения: 13.10.2025).
6. Модель CMMI // Хабр. URL: https://habr.com/ru/articles/75940/ (дата обращения: 13.10.2025).
7. CMMI (Capability Maturity Model Integrated): определение, уровни CMMI // SimpleOne. URL: https://simpleone.ru/glossary/cmmi-capability-maturity-model-integrated-opredelenie-urovni-cmmi/ (дата обращения: 13.10.2025).
8. ISO 15504 или SPICE (Software Process Improvement and Capability Determination), ISO/ IEC 19770-1, ISO 38500 — Обзор решений моделирования бизнес-процессов управления ИT сервисами // Studbooks.net. URL: https://studbooks.net/1359051/informatika/iso_15504_spice_software_process_improvement_capability_determination_iso_iec_19770_iso_38500_obzor_resheniy_modelirovaniya_biznes_protsessov_upravleniya_servisami (дата обращения: 13.10.2025).
9. CMM/CMMI — модель оценки зрелости процессов разработки / Артамошкин Максим. URL: https://artamoshkin.ru/blog/cmm-cmmi-model-ozenki-zrelosti-processov-razrabotki/ (дата обращения: 13.10.2025).
10. Как оценить уровень управленческой зрелости: CMMI и другие модели // Babok School. URL: https://babok.school/article/cmmi-i-drugie-modeli/ (дата обращения: 13.10.2025).
11. CMMI: Интеграция модели зрелости возможностей (полное руководство) // Visure Solutions. URL: https://www.visuresolutions.com/blog/cmmi-maturity-model-integration-requirements-engineering/ (дата обращения: 13.10.2025).
12. Модель зрелости возможностей (CMM — Capability Maturity Model) // QA_Bible. URL: https://qa_bible.ru/model-zrelosti-vozmozhnostej-cmm/ (дата обращения: 13.10.2025).
13. Модели зрелости // Диалог. URL: https://di.ru/articles/models-of-maturity (дата обращения: 13.10.2025).
14. Сертификация ISO / IEC 15504 SPICE // Belgelendirme. URL: https://belgelendirme.com/ru/iso-iec-15504-spice-sertifikatsiyasi/ (дата обращения: 13.10.2025).
15. Модель зрелости способностей к разработке программных продуктов. URL: https://www.unn.ru/pages/issues/vestnik/99999999_Base/2012/3/IT-21-2012-3.pdf (дата обращения: 13.10.2025).
16. Сертификация ISO/IEC 15504 (SPICE) // DQS. URL: https://dqs.ru/products/iso-iec-15504-spice/ (дата обращения: 13.10.2025).
17. Модель зрелости: как оценивать и растить инженерные команды // Habr. URL: https://habr.com/ru/companies/avito/articles/580136/ (дата обращения: 13.10.2025).
18. МОДЕЛИ ЗРЕЛОСТИ И ИХ ПРИМЕНЕНИЕ В ОБЛАСТИ УПРАВЛЕНИЯ ПРОИЗВОДСТВЕННЫМИ АКТИВАМИ И ИХ НАДЕЖНОСТЬЮ // ТОИР ПРО. 2021. 13 апреля. URL: https://toir.pro/blog/2021/04/13/modeli-zrelosti-i-ih-primenenie-v-oblasti-upravleniya-proizvodstvennymi-aktivami-i-ih-nadezhnostyu/ (дата обращения: 13.10.2025).
19. Глава 1. Исторический срез моделей зрелости // IPR Smart. URL: https://www.iprbookshop.ru/71842.html (дата обращения: 13.10.2025).
20. Процессы управления информационными технологиями. Лекция 9: Концептуальная модель CMMI // Интуит. URL: https://www.intuit.ru/studies/courses/2301/605/lecture/13936 (дата обращения: 13.10.2025).
21. Зрелость процесса или как «вырастить» бизнес-процесс? // BPMS.ru. URL: https://www.bpms.ru/articles/process_maturity_growing/ (дата обращения: 13.10.2025).
22. Что такое модели зрелости управления проектами? // PM-Way. URL: https://www.pm-way.com/glossary/chto-takoe-modeli-zrelosti-upravleniya-proektami/ (дата обращения: 13.10.2025).
23. Зрелость процесса разработки. URL: https://dl.susu.ru/pluginfile.php/127163/mod_resource/content/1/%D0%9B%D0%B5%D0%BA%D1%86%D0%B8%D1%8F%204.%20%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%20%D0%B7%D1%80%D0%B5%D0%BB%D0%BE%D1%81%D1%82%D0%B8%20%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B8%D0%B8%20%D0%9F%D0%9E%20%D0%A1%D0%9C%D0%9C.pdf (дата обращения: 13.10.2025).
24. The Agile Maturity Model // Shorter Loop. URL: https://shorterloop.com/agile-maturity-model/ (дата обращения: 13.10.2025).
25. Measure and Improve Your Agile Implementation With Maturity Models // Growing Scrum Masters. URL: https://growingscrummasters.com/agile-maturity-models/ (дата обращения: 13.10.2025).
26. The Agile Maturity Model // Thoughtworks. URL: https://www.thoughtworks.com/insights/articles/agile-maturity-model (дата обращения: 13.10.2025).
27. Agile Maturity Model: Levels, Assessment, and Benefits // KnowledgeHut. URL: https://www.knowledgehut.com/blog/agile/agile-maturity-model (дата обращения: 13.10.2025).
28. Agile Maturity Models and Assessments // Smartsheet. URL: https://www.smartsheet.com/content/agile-maturity-models (дата обращения: 13.10.2025).
29. What Is Agile Maturity Assessment? // Monitask. URL: https://monitask.com/blog/what-is-agile-maturity-assessment/ (дата обращения: 13.10.2025).