В середине 2025 года вышел отчет по состоянию инженерной зрелости —
The State Of Software Engineering Excellence 2025 от компаний Harness, разрабатывающей платформу для автоматизации процессов поставки программного обеспечения. Отчет составлен на основе ответов 650 технических руководителей, которые прошли
Engineering Excellence Maturity Assessment. Результаты оценки показывают, что многие организации находятся на ранних этапах движения к инженерной зрелости и совершенству. Несмотря на широкое внедрение лучших практик, их применение часто является несистемным: практики используются фрагментарно или ограничены отдельными сценариями и стадиями конвейера.
В отчете анализируются следующие направления:
1. Developer Experience, включает оптимизацию каждого этапа рабочего процесса, от быстрого предоставления окружений до доступной документации, упрощенного планирования и эффективных практик контроля качества кода;
2. DevOps Modernization, включает оптимизацию процессов — от конвейеров сборки (Build pipelines) и автоматизации развертывания (Deployment automation) до современных стратегий поставки и механизмов безопасности;
3. Optimization, включает оптимизацию использования ресурсов — систем, затрат и усилий разработчиков;
4. Quality and Resilience, включает процессы тестирования приложений, проактивное формирование систем, способных выдерживать экстремальные условия, а также наличие устойчивых процессов управления инцидентами и процедур обучения на них;
5. Secure Software Development, включает интеграцию политик безопасности и управления (Governance) на ранних этапах, поддержание прозрачности состава программного обеспечения с помощью таких инструментов, как Software Bill of Materials (SBOM), а также обеспечение того, чтобы разработчики были обучены передовым практикам безопасности.
Для каждого направления в отчете приводятся результаты опроса, рекомендации, а также формулы расчета ROI. Основные выводы из отчета:
- Планирование и работа с требованиями (Planning and requirements process). 70% руководителей отмечают, что более 70% требований не имеют четко определенных критериев приемки (Acceptance criteria). Более половины руководителей зафиксировали рост изменения объема задач (Scope creep) более чем на 20% за последние 12 спринтов. Эффективное планирование и четкие требования являются фундаментом для Developer Experience. Разработчики сталкиваются с трудностями, дополнительной работой и снижением ощущения завершенности, когда требования неоднозначны или часто изменяются. Четко определенный процесс планирования, включая точные критерии приемки (Acceptance criteria), снижает трение (Friction), повышает уверенность и позволяет командам разработки сосредоточиться на создании ценности, а не на попытках интерпретировать неопределенные цели;
- Доступность информации и документация (Discoverability and documentation). Инженерным командам необходим мгновенный доступ к точной информации о сервисах над которыми они работают. Каталог сервисов с метаданными, статусы владения (Ownership) и состояния (Service status) — снижают трение (Friction) и позволяет инженерам сосредоточиться на решении технических задач. Только 21% инженерных команд имеют каталог сервисов (Service Catalog), который обновляется автоматически. Почти треть команд не имеют каталога сервисов вовсе. Для повышения зрелости авторы рекомендуют внедрять каталог сервисов с помощью Internal Developer Portal (IDP), собирая метаданные и статусы сервисов без ручных действий разработчиков;
- Окружения разработчика (Developer environments). Только 34% инженерных команд могут быстро поднимать предварительно собранные облачные окружения. 67% руководителей отмечают, что их разработчики не могут собрать и протестировать окружения менее чем за 15 минут. Задержки при предоставлении окружений или их несогласованность напрямую влияют на продуктивность, замедляют итерации и создают трение (Friction) в рабочем процессе. Для повышения зрелости необходимо обеспечить разработчиков инструментами самообслуживания (Self-service tools) для быстрого создания и стандартизации окружений;
- Процесс разработки и инженерная гигиена (Development process and hygiene). Данные показывают проблемы: 61% руководителей отмечают, что ревью кода занимает более одного дня. 35% инженерных команд не соблюдают стратегии ветвления (Branching strategy). Надежные процессы разработки и инженерная гигиена необходимы для улучшения Developer Experience. Если ревью кода превращается в узкие места, а размер коммита (Commit size) становится чрезмерным, цикл разработки замедляется, снижая эффективность и качество результата. Для повышения зрелости авторы рекомендуют оптимизировать процессы ревью кода, стимулировать небольшие и частые коммиты, внедрять автоматизированные проверки и использовать стратегии ветвления для поддержания стабильного качества кода;
- Обучение и развитие (Learning and development). Инвестиции в обучение поддерживают актуальность навыков, предотвращают их стагнацию и повышают удержание специалистов. При этом только 19% руководителей имеют качественные программы внутреннего обучения и повышения квалификации (Upskilling, Reskilling);
- Процессы сборки (Build process). Многие организации отмечают проблемы, треть не имеют стандартизированных конвейеров сборки (Standardized build pipelines), 55% конвейеров сборки не имеют контрольных точек качества (Quality gates). Для повышения зрелости процессов сборки авторы рекомендуют внедрять шаблоны для конвейеров сборки (Build pipeline templates), включающие автоматизированные контрольные точки качества;
- Автоматизация развертывания (Deployment automation). Каждая пятая команда используют стандартизированные конвейеры развертывания, однако половина продолжают выполнять ручные шаги при развертывании кода приложений, 69% — при развертывании инфраструктурного кода, 64% — при изменениях в базах данных. Для повышения зрелости автоматизации развертывания рекомендуется стандартизировать и шаблонизировать все конвейеры развертывания, а также автоматизировать каждый этап — от кода приложений и инфраструктурного кода до изменений в базах данных.
- Стратегии развертывания (Deployment strategies). Основные проблемы: 76% инженерных команд не используют Feature flags или не имеют процессов управления жизненным циклом флагов. Большинство команд не используют современные стратегии развертывания, такие как Rolling update, Canary, Blue/green и GitOps. Для повышения зрелости рекомендуется системно внедрять современные стратегии развертывания, формировать процессы их применения и управления жизненным циклом. Это снижает риски, ускоряет обратную связь и позволяет отделять выпуск фич от развертывания кода.
- Автоматизированные откаты (Automated rollbacks). 43% инженерных команд основывают решения на субъективных данных, а не на измеримых сигналах. 44% организаций выполняют rollbacks вручную. Для повышения зрелости практики рекомендуется внедрять механизмы rollbacks для всех критически важных развертываний, а также использовать объективные метрики для принятия решений и верификации выполнения;
- Безопасность развертывания (Deployment security). 43% инженерных команд не используют централизованный менеджер секретов или HSM. Каждая десятая команда хранит секреты в открытом виде в системах развертывания. Для повышения зрелости безопасности развертывания рекомендуется внедрить централизованную систему управления секретами (Secrets management), запрещать хранение чувствительных данных в открытом виде и интегрировать проверки безопасности в конвейеры развертывания;
- Стоимость облачных ресурсов (Cloud costs). Только 2 из 5 руководителей говорят, что затраты на облачные ресурсы отслеживаются на уровне проектов, команд и подразделений. Только 12% руководителей утверждают, что процессы снижения затрат автоматизированы. Для повышения зрелости оптимизации стоимости рекомендуется внедрять автоматизированные инструменты, обеспечивающие детализированную и актуальную видимость затрат на уровне проектов, команд и рабочих нагрузок;
- Метрики и инсайты (Metrics and insights). 50% руководителей говорят, что метрики анализируются ежедневно или еженедельно. Почти половина руководителей говорят, что SLO и Error budgets не определены или не рассчитаны ни для одного сервиса. Только 13% руководителей говорят, что SLO и Error budgets рассчитываются автоматически и используются для управления развертываниями. Авторы отмечают, что формирование культуры анализа данных является основой для зрелой инженерной культуры и непрерывного улучшения;
- Тестирование качества (Quality testing). 60% руководителей утверждают, что их тестовые и staging окружения не совпадают с production окружением. Четверть руководителей говорят, что менее 30% фич имеют тест-планы. Только 20% инженерных команд имеют покрытие модульными тестами (Unit test coverage) более 90% для своих сервисов. Только 10% руководителей отмечают, что функциональное тестирование полностью автоматизировано;
- Тестирование устойчивости (Resilience testing). Современные инженерные практики включают в SDLC применение Chaos testing. Тем не менее внедрение Chaos testing остается ограниченным: 66% инженерных команд не используют Chaos testing и только 13% интегрировали Chaos testing в SDLC. Авторы рекомендуют проактивно моделировать сбои и экстремальные условия в контролируемых средах, выявлять слабые места, проверять поведение системы под нагрузкой и обеспечивать способность приложений восстанавливаться после непредвиденных событий;
- Управление инцидентами (Incident management). В управлении инцидентами сохраняются существенные пробелы: 52% инженерных команд не имеют ключевых инструментов, необходимых для управления инцидентами. 1 из 10 инженерных команд не имеет формального процесса управления инцидентами. Только 27% руководителей отмечают, что анализы инцидентов (Post-mortems) проводятся без поиска виноватых (Blameless);
- Интегрированная безопасность и управление (Integrated security and governance). Зрелые инженерные практики рассматривают подход Shift-left не как перенос дополнительной нагрузки на разработчиков, а как создание условий, позволяющих по умолчанию разрабатывать безопасное программное обеспечение. 38% руководителей говорят, что большая часть конвейеров сборки (Build pipelines) не имеют контрольных точек безопасности (Security scans) или не используют их. 45% руководителей говорят, что устранение инцидентов высокой критичности занимает более 7 дней. 1 из 10 руководителей говорит, что уязвимости высокой и критической степени опасности не устраняются до релиза;
- Software Bill of Materials (SBOM) обеспечивает критическую прозрачность всех компонентов приложения, зависимостей и связанных с ними уязвимостей. Тем не менее уровень внедрения SBOM остается низким: только 11% руководителей отмечают, что SBOM создается для всех артефактов. Более половины инженерных команд создают SBOM для менее чем 30% артефактов, включая случаи полного отсутствия SBOM;
- Обучение безопасности (Security training). Даже при наличии продвинутых инструментов и автоматизированных проверок понимание принципов Secure Software Development остается важным элементом защиты. Обучение разработчиков безопасному кодированию, типовым уязвимостям и актуальным векторам угроз позволяет уменьшить риски и повышает общее качество ПО. Тем не менее регулярность такого обучения значительно варьируется: 56% проходят обучение ежегодно или раз в полгода, у 23% разработчиков обучение по практикам отсутствует вовсе.
Основные схемы и результаты из отчета
The State of Software Engineering Excellence 2025: