Agile/Scrum Framework

В 1993 году Джефф Сазерленд пришёл в компанию Easel Corporation на должность главного инженера с задачей создать продукт быстрее и лучше существующих на рынке аналогов. Прежде чем изобретать процесс заново, он с командой изучил литературу по управлению разработкой продуктов — и нашёл, по его собственным словам, лучшую из найденных статью: «The New New Product Development Game» Хиротаки Такеути и Икудзиро Нонаки (Harvard Business Review, январь 1986). Авторы сравнивали целостный, командный подход к разработке продукта с игрой в регби — «мяч передаётся внутри команды по мере её продвижения», единым слаженным построением, схваткой (scrum). Статья дала Сазерленду и формальную модель, и название для нового фреймворка. Вместе с Джоном Скумниоталесом (ставшим первым Scrum-мастером) и Джеффом Маккенной он реализовал первую полноценную Scrum-команду для разработки продукта Object Studio — и уже в 1995 году, объединив усилия с Кеном Швабером, формализовал и публично представил фреймворк на конференции OOPSLA.

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

Происхождение и исследовательская база

Agile — более широкая философия управления, отдающая приоритет реагированию на изменения перед следованием жёсткому плану, формализованная семнадцатью разработчиками на встрече в Сноуберде (Юта, 2001) в виде Agile Manifesto — четырёх ценностей и двенадцати принципов. Scrum — конкретный фреймворк, реализующий эту философию на практике, с собственной, более ранней родословной: академический первоисточник термина и метафоры — статья Такеути и Нонаки 1986 года, практическая реализация в разработке ПО — Джефф Сазерленд и его команда в Easel Corporation с 1993 года, формализация — Сазерленд и Кен Швабер на OOPSLA 1995. То есть Scrum как конкретная техника на девять лет старше самого термина «agile» в его современном софтверном значении и возник независимо, до объединения разных школ в единый манифест 2001 года.

Масштаб потенциального эффекта иллюстрирует кейс, который сам Сазерленд подробно разобрал в книге «Scrum: The Art of Doing Twice the Work in Half the Time» (2014) — проект Sentinel Федерального бюро расследований США. Компания Lockheed Martin потратила на разработку системы 405 миллионов долларов, выполнив лишь половину объёма работ с отставанием на год; независимая экспертная оценка показала, что для завершения потребуется ещё 6-8 лет и минимум 350 миллионов долларов. 3 марта 2010 года ФБР отказалось от контракта с Lockheed Martin. Новое руководство ИТ-департамента ФБР перевело разработку внутрь ведомства, собрало выделенную команду из 40 разработчиков и организовало работу по Scrum — проект был завершён примерно за 20 месяцев, обойдясь в 30 миллионов долларов. Даже с учётом того, что цифры об экономии происходят из источника, заинтересованного в успехе метода (самого Сазерленда), порядок величины расхождения (десятки против сотен миллионов долларов, месяцы против многолетнего провала) делает Sentinel одним из самых часто цитируемых примеров практического эффекта Scrum за пределами типичного стартапного контекста.

Ключевые идеи и принципы

1. Принцип: люди и взаимодействие важнее процессов и инструментов

   Живое взаимодействие команды ценится выше формальных процедур — Agile-манифест явно ставит это на первое место среди своих ценностей, и Scrum как конкретный фреймворк реализует этот приоритет через короткие личные синхронизации, а не через формальные отчёты.

2. Принцип: продуктовый backlog вместо списка проектов

   Годовая цель переформулируется не в проекты, а в приоритизированный по ценности список конкретных, измеримых результатов для клиента или бизнеса.

3. Принцип: спринт — фиксированная цель и ресурсы на короткий срок

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

4. Принцип: демонстрация результата, а не активности

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

5. Принцип: ретроспектива на основе фактов

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

6. Принцип: три роли, пять событий, три артефакта

   Официальный Scrum Guide (Швабер и Сазерленд) формализует фреймворк через строго определённый минимальный набор: три роли (Product Owner — отвечает за ценность и приоритизацию backlog; Scrum Master — отвечает за соблюдение процесса и устранение препятствий; команда разработки — самоорганизующаяся, кросс-функциональная), пять событий (спринт как рамочное событие, планирование спринта, ежедневный стендап, обзор спринта, ретроспектива) и три артефакта (продуктовый backlog, backlog спринта, инкремент). Минимализм намеренный: любое дополнение к этому базовому набору Scrum Guide явно называет не самим Scrum, а практикой, надстроенной поверх него.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: спринт оценивается по активности, а не по результату.

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

   Как избежать

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

2. Ошибка 2: backlog не приоритизирован по ценности.

   Список задач формируется в порядке поступления или по громкости запроса, а не по влиянию на бизнес-метрику.

   Как избежать

   явно ранжировать backlog по ожидаемому влиянию на прибыль или ключевую метрику, а не по хронологии.

3. Ошибка 3: ретроспектива проводится формально.

   На вопрос «как прошёл спринт» отвечают «всё хорошо» без реального разбора процесса — команда не учится на собственном опыте.

   Как избежать

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

4. Ошибка 4: внедряются ритуалы без изменения управленческой философии.

   Команда проводит стендапы и спринты, но руководство продолжает требовать точных планов на квартал вперёд без права на изменение курса.

   Как избежать

   синхронизировать ожидания руководства с гибким горизонтом планирования спринтами, а не годовыми фиксированными планами.

5. Ошибка 5: Scrum применяется к полностью предсказуемым линейным процессам.

   Гибкость и короткие итерации не нужны там, где процесс и результат заранее детально известны — метод создаёт лишние накладные расходы.

   Как избежать

   оценивать применимость Scrum по степени неопределённости задачи — для рутинных предсказуемых процессов использовать другие инструменты.

6. Ошибка 6: Scrum пытаются внедрить через внешнего подрядчика без выделенной постоянной команды.

   Как показал провал первой попытки на проекте Sentinel у ФБР, работа через внешнего подрядчика с распределённой, не полностью сфокусированной командой систематически даёт худшие результаты, чем выделенная внутренняя команда, полностью сосредоточенная на одном продукте — именно перевод разработки внутрь ведомства с постоянной командой из 40 человек, а не смена подрядчика, стал структурной причиной успеха повторной попытки.

   Как избежать

   формировать выделенную, стабильную команду, полностью сфокусированную на продукте, а не распределять внимание подрядчика между несколькими параллельными контрактами.

План внедрения

1. Неделя 1: выбор инициативы и первый backlog

   Выбрать одну стратегическую инициативу и сформулировать для неё первый конкретный «продуктовый» результат.

2. Недели 2-3: первый спринт

   Провести первый спринт (2 недели) с фиксированной целью и выделенными ресурсами.

3. Неделя 4: обзор и ретроспектива

   Провести обзор спринта (демонстрация рабочего результата) и ретроспективу процесса с одним конкретным изменением.

4. Далее: регулярный ритм спринтов

   Закрепить регулярный ритм спринтов и приоритизировать backlog по ценности на постоянной основе.

Как реализовать этот план с помощью фрейма «Agile/Scrum Framework» в OrgDevTools

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

Книги по теме

Hirotaka Takeuchi, Ikujiro Nonaka — «The New New Product Development Game» (Harvard Business Review, январь 1986). Академический первоисточник термина и метафоры регби, вдохновивший Джеффа Сазерленда на создание Scrum.

Ken Schwaber, Jeff Sutherland — «The Scrum Guide» (актуальная редакция, обновляется авторами). Официальный первоисточник фреймворка Scrum — роли, артефакты, события.

Jeff Sutherland — «Scrum: The Art of Doing Twice the Work in Half the Time» (2014). Практическое изложение принципов Scrum с реальными кейсами применения за пределами IT.