Scrum сегодня: как устроено современное внедрение фреймворка

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

Delivery (Scrum + Kanban + инженерные практики) и Discovery работают параллельно и питают друг друга через непрерывное обучение - именно так, по совокупности разобранных источников, устроено зрелое внедрение Scrum.

Scrum полностью определён в Scrum Guide, который написали и поддерживают его создатели - Кен Швабер и Джефф Сазерленд. Руководство ведётся независимо от какой-либо компании и переведено более чем на 30 языков.

Швабер и Сазерленд впервые совместно представили Scrum на конференции OOPSLA в 1995 году. Действующая версия руководства - редакция от 18 ноября 2020 года, выпущенная к 25-летию фреймворка. Обновление сократило текст до 13 страниц и сделало формулировки менее предписывающими: например, из Daily Scrum убрали три обязательных вопроса, а Development Team перестал быть отдельной от Product Owner и Scrum Master сущностью - теперь это единая Scrum Team с тремя зонами ответственности.

• Product Goal - новое понятие, дающее команде долгосрочный ориентир крупнее, чем один спринт; каждый спринт должен приближать продукт к этой цели.
• Единая Scrum Team - акцент на самоуправлении команды целиком, без деления на «начальника» и «исполнителей».
• Смягчение предписаний - там, где раньше были жёсткие форматы событий, руководство оставляет больше пространства для контекста организации.

Официальный документ
The Scrum Guide (2020) - Кен Швабер, Джефф Сазерленд. Определяет зоны ответственности, события, артефакты и правила Scrum. Распространяется бесплатно под лицензией Creative Commons Attribution-ShareAlike.

Прежде чем разбирать, чем Scrum дополняют, стоит зафиксировать, чем он не является - согласно самому Scrum Guide. Инструменты, метрики и практики, которые часто отождествляют со Scrum, на деле находятся вне его официального определения и могут использоваться (или не использоваться) по усмотрению команды.

Sprint, Daily Scrum, Sprint Planning, Sprint Review и Sprint Retrospective, Product Backlog и Sprint Backlog - это официальные события и артефакты Scrum Guide. Проблема не в них самих, а в практиках, которые к ним пристраивают: story points, velocity, инструменты трекинга и формат Daily как отчёта нигде в Scrum Guide не упоминаются и не являются его частью.

Если Scrum Guide отвечает на вопрос «как работает команда», то Evidence-Based Management (EBM) - на вопрос «какую ценность это приносит организации». EBM разработан Кеном Швабером совместно с Кристиной Швабер, сообществом Scrum.org и Professional Scrum Trainer Community. Framework помогает организациям принимать более обоснованные решения через целенаправленные эксперименты и обратную связь, фокусируясь на улучшении результатов, измерении ценности, снижении рисков и оптимизации инвестиций.

EBM намеренно не фиксирует конкретные метрики (Key Value Measures) - они приводятся в приложении к руководству как примеры, а не обязательный стандарт. Среди примеров метрик для Ability to Innovate руководство прямо ссылается на отчёт DORA 2019 года - то есть официально признаёт инженерные метрики поставки частью измерения ценности Scrum-команд.

Официальный документ
The Evidence-Based Management Guide - Кен Швабер, Кристина Швабер, Scrum.org. Определяет четыре Key Value Area и логику постановки стратегических, промежуточных и тактических целей через гипотезы и эксперименты.

The Kanban Guide for Scrum Teams впервые опубликован в 2017 году вместе с курсом Professional Scrum with Kanban, обновлён в январе 2021 года. Это результат сотрудничества сообщества Scrum.org с лидерами Kanban-сообщества - в числе соавторов Дэниел Ваканти и Стив Портер. Руководство не заменяет и не отменяет ни одну часть Scrum Guide: оно расширяет практики Scrum и предполагает, что читатель уже работает по Scrum-фреймворку целиком.

В основе Kanban лежит понятие потока - движения ценности через систему разработки продукта. Гайд опирается на закон Литтла: чем больше задач команда ведёт одновременно, тем дольше в среднем каждая из них будет выполняться. Отсюда - практическая рекомендация: если цикл выполнения задач затягивается, первое, что стоит проверить - ограничение на количество параллельной работы (WIP).

Четыре метрики потока

• Work in Progress (WIP) - количество начатых, но не завершённых элементов работы.
• Cycle Time - время, за которое элемент работы проходит через процесс.
• Throughput - количество завершённых элементов работы за единицу времени.
• Work Item Age - как долго элемент работы находится в процессе прямо сейчас, до завершения.

Официальный документ
The Kanban Guide for Scrum Teams - Сообщество Scrum.org совместно с лидерами Kanban-движения. Добавляет к Scrum четыре практики визуализации потока и связанные с ними метрики.

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

Scrum Guide описывает, как команда доставляет инкремент, но не отвечает на вопрос, что именно стоит доставлять. Этот пробел закрывает continuous discovery - практика, которую системно описала Тереза Торрес в книге Continuous Discovery Habits. Торрес определяет непрерывный discovery как минимум еженедельные контакты с клиентами, которые проводит сама продуктовая команда, в формате небольших исследовательских активностей, направленных на достижение желаемого результата.

Ключевая единица работы у Торрес - «продуктовый трио» (product trio): продакт-менеджер, дизайнер и инженер, которые вместе интервьюируют клиентов и строят Opportunity Solution Tree - дерево, связывающее бизнес-результат с возможностями и вариантами решений. Марти Каган использует то же понятие продуктового трио в своих работах, что делает эту практику одной из немногих точек согласия между авторами Product Management и Product Discovery.

Outcome вместо output - сквозная тема источников

Смещение фокуса с «сколько сделали» на «что это изменило» - не изобретение одного автора, а тема, которая независимо повторяется в разных источниках: EBM измеряет Current и Unrealized Value, а не количество завершённых Product Backlog Item; Торрес строит discovery вокруг «desired outcome»; официальное руководство по ИИ отдельно предупреждает, что рост числа фич, сгенерированных с помощью ИИ, это output, который может не создавать outcome.

Scrum Guide намеренно не описывает инженерные практики - он оставляет это «другим источникам». Одним из таких источников де-факто стали исследования DORA (DevOps Research and Assessment) и книга Accelerate Николь Форсгрен, Джеза Хамбла и Джина Кима, обобщившая четыре года исследований на данных свыше 23 000 респондентов из более чем 2000 организаций.

Авторы Accelerate выявили четыре метрики, которые статистически связаны с производительностью организации: частоту развёртывания (Deployment Frequency), время на внесение изменений (Lead Time for Changes), время восстановления после сбоя (Mean Time to Recovery) и долю неудачных изменений (Change Failure Rate). Ключевой вывод исследования: между скоростью и качеством поставки нет компромисса - high-performing организации показывают лучшие результаты по обоим направлениям одновременно.

Evidence-Based Management Guide прямо ссылается на отчёт DORA 2019 года как на источник примеров метрик для области Ability to Innovate - это единственная официальная точка пересечения Scrum-документации с инженерными DevOps-метриками.

В январе 2026 года Ральф Йохам и Джефф Сазерленд, один из создателей самого Scrum, опубликовали официальное расширение к Scrum Guide Expansion Pack под названием AI and Scrum. Это на сегодня наиболее авторитетный источник о том, как ИИ встраивается именно в Scrum, а не в разработку ПО вообще.

Главный парадокс: скорость есть, ценности не всегда прибавляется

Руководство фиксирует так называемый «парадокс генеративного ИИ»: по данным цитируемых в нём исследований McKinsey, к 2025 году 78% компаний уже использовали ИИ, но около 80% не зафиксировали значимого влияния на бизнес-результаты. Авторы связывают это с тем, что команды производят фичи без достаточной продуктовой валидации — то есть без того самого discovery, о котором говорилось выше.

По данным опроса Stack Overflow, который цитирует руководство, к концу 2025 года около 84% разработчиков в той или иной форме пользовались ИИ-инструментами для написания кода, а более половины - ежедневно. При этом доверие к точности сгенерированного ИИ кода снизилось с 69% в 2024 году до 54% в 2025-м. Отдельное исследование, упомянутое в руководстве, зафиксировало, что у опытных инженеров производительность на сложных задачах снижалась примерно на 19% при использовании ИИ-ассистента - из-за времени на проверку и исправление сгенерированного кода.

Что руководство рекомендует ролям Scrum

• Product Owner становится «когнитивным дирижёром» (cognitive orchestrator): формулирует ИИ чёткие цели и ограничения, а не просто принимает то, что сгенерировано, и удерживает фокус команды на outcome, а не на количестве фич.
• Scrum Master помогает команде выработать рабочие соглашения об использовании ИИ-агентов, включает вопросы применения ИИ в Sprint Planning и Retrospective, следит за психологической безопасностью, если у части команды возникает тревога из-за автоматизации.
• Разработчики несут полную ответственность за качество инкремента независимо от того, кто - человек или ИИ - написал код; роль смещается от «написания кода» к «курированию качества и архитектуры».

Отдельная рекомендация руководства - не ослаблять, а усиливать Definition of Done при использовании ИИ, добавляя обязательную проверку и тестирование любого ИИ-сгенерированного результата.

Официальные руководства описывают, как должен работать Scrum. Но именно отклонения от этой модели формируют повседневный опыт большинства организаций. The Scrum Anti-Patterns Guide Стефана Вольперса и книга Fixing Your Scrum Райана Рипли и Тодда Миллера независимо друг от друга фиксируют один и тот же набор повторяющихся проблем.

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

Real World Scrum: A Grounded Theory of Variations in Practice

Зайнаб Масуд, Рашина Ходa и Келли Блинко (университеты Окленда и Монаша) провели исследование по методологии обоснованной теории: 45 полуструктурированных интервью с практиками из 30 компаний и наблюдения за пятью командами. Работа опубликована в IEEE Transactions on Software Engineering в 2022 году.

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

A Theory of Scrum Team Effectiveness

Кристиан Вервейс и Дэниел Руссо провели семилетнее смешанное исследование в два этапа. Сначала на основе 13 полевых кейсов была индуктивно выведена теоретическая модель, затем она проверена методом структурного моделирования (SEM) на данных опроса около 5000 разработчиков и 2000 Scrum-команд. Работа опубликована в ACM Transactions on Software Engineering and Methodology в 2023 году.

Модель показала очень хорошее соответствие эмпирическим данным (CFI = 0,959; RMSEA = 0,038; SRMR = 0,035) и выделила пять факторов эффективности Scrum-команд, раскрытых через 13 более детальных показателей:

• Responsiveness - способность команды быстро реагировать на изменения.
• Stakeholder concern - ориентация на потребности заинтересованных сторон.
• Continuous improvement - постоянное совершенствование процесса.
• Team autonomy - автономность команды в принятии решений.
• Management support - поддержка со стороны менеджмента.

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

Консультанты AgileLAB помогают компаниям внедрять Scrum как основу для эффективной разработки продуктов и управления сложными проектами. Мы работаем с организациями из IT, телекоммуникаций, финансового сектора, ритейла, промышленности и других отраслей, адаптируя Scrum под реальные условия бизнеса.

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

Обучение SCRUM в AgileLAB
AgileLAB проводит профессиональное обучение Scrum для Scrum Masters, Product Owners, руководителей и команд разработки. Наши программы основаны на актуальном Scrum Guide, современных практиках продуктовой разработки и многолетнем опыте внедрения Scrum в международных компаниях.

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