Команды до сих пор ломают копья в спорах о правилах Скрама, размахивая статьями из нулевых. Фреймворк не высечен в камне, его создатели переписывали официальный документ шесть раз, выжигая костыли и микроменеджмент. Разберем сухие факты: как мутировал Scrum Guide и почему старые привычки убивают вашу разработку прямо сейчас.
История эволюции: От хаоса к эмпиризму
Кен Швабер и Джефф Сазерленд впервые публично представили Scrum в 1995 году на конференции OOPSLA. Долгое время правила передавались исключительно через книги, тренинги и сарафанное радио. Это породило хаос. Компании называли Скрамом любой процесс, где есть утренние созвоны и стикеры на стене.
Чтобы зафиксировать единый стандарт, в 2010 году авторы выпустили первый официальный Scrum Guide. С тех пор документ постоянно худеет. Авторы целенаправленно вырезают жесткие предписания, превращая пошаговую инструкцию для программистов в универсальный каркас для решения сложных проблем. Scrum Guide эволюционирует от жесткого контроля к радикальному эмпиризму. Выживают только те правила, которые физически необходимы для обеспечения прозрачности, инспекции и адаптации.
Если вы до сих пор используете правила из 2010 года, вы не Скрам-команда. Вы музейный экспонат, который пытается ехать на современном рынке. Agile — это про адаптацию не только продукта, но и собственных знаний
Таблица
| Версия | Главный вектор изменений | Влияние на процесс разработки |
|---|---|---|
| 2010 | Фиксация стандарта | Убита анархия. Появились жесткие таймбоксы и артефакты. |
| 2011 | Отказ от микроменеджмента | Оценки задач стали «прогнозом», а не «клятвой на крови». |
| 2013 | Легализация бэклога | Уточнение задач (Refinement) стало официальной активностью. |
| 2016 | Фокус на культуре | Внедрены ценности. Без них фреймворк признан карго-культом. |
| 2017 | Гибкость таймбоксов | Отмена жестких скриптов на Daily Scrum. Упор на инспекцию. |
| 2020 | Радикальный минимализм | Уничтожение «команд внутри команд». Введение жестких Commitments. |
Что именно вырезали авторы
1995 год: Дикий Запад Agile
До появления гайда Scrum существовал в виде набора инженерных и управленческих практик. Документ для конференции OOPSLA описывал общую концепцию: итеративность, эмпирический контроль, самоорганизацию. Никаких жестких правил еще не было. Разработчики экспериментировали, нащупывая баланс между хаосом и бюрократией.
Версия 2010: Рождение стандарта и метафоры
Первый Scrum Guide был тяжелым и прескриптивным. Авторы пытались регламентировать каждый шаг. В тексте присутствовала метафора про «Свиней и Кур», которая делила участников процесса на полностью вовлеченных (Свиньи — команда) и просто сочувствующих (Куры — стейкхолдеры). Использование диаграмм сгорания (Burndown Charts) для отслеживания прогресса Спринта было строгим обязательством. Фреймворк требовал жесткого планирования релизов.
Версия 2011: Великая чистка и спасение разработчиков
Авторы осознали, что ИТ-сленг мешает бизнесу воспринимать фреймворк всерьез. Метафору про животных безжалостно вырезали — она обижала стейкхолдеров и строила глухую стену между бизнесом и разработкой. Диаграммы сгорания перестали быть обязательными.
Но главное изменение коснулось обязательств. Слово «Commitment» (Обязательство) по отношению к Бэклогу Спринта заменили на «Forecast» (Прогноз). Менеджеры использовали старую формулировку как кнут, заставляя инженеров овертаймить, если те не успевали закрыть все тикеты. Авторы четко заявили: объем работы в Спринте это прогноз, он может меняться. Неизменной остается только Цель Спринта.
Версия 2013: Прозрачность и Refinement
Появилось официальное признание того, что Бэклог Продукта требует непрерывной технической работы до старта Спринта. Термин «Grooming» заменили на «Product Backlog Refinement» (Уточнение). Видимо, кто-то наконец понял, что в английском это слово звучит двусмысленно и криминально. Гайд рекомендовал тратить на эту активность до 10% емкости команды.
Планирование Спринта (Sprint Planning), которое раньше делилось на две жесткие части (Что делаем и Как делаем), объединили в единое событие. В этой же версии авторы жестко прописали концепцию прозрачности артефактов: если бэклог скрыт или непонятен, эмпиризм ломается.
Версия 2016: Внедрение ценностей
Текст обновился фундаментально с точки зрения психологии. Авторы добавили пять Скрам-ценностей: Смелость, Фокус, Приверженность, Уважение, Открытость. Стало очевидно: механика без культуры генерирует Zombie Scrum. Вы можете идеально проводить планирование, но без Смелости отклонять бредовые гипотезы и без Открытости признавать баги команда никогда не станет эффективной.
Версия 2017: Свобода на Daily и фокус на улучшениях
Три классических вопроса на ежедневном стендапе («Что делал вчера? Что буду делать сегодня? Какие есть блокеры?») перестали быть обязательными. Эти вопросы превращали Daily Scrum в унылый статус-репорт перед лидом. Команды получили право проводить встречу в любом формате, если это помогает инспектировать план на 24 часа.
Ретроспектива получила жесткое правило: минимум одно конкретное улучшение (Action Item) обязано попасть в Бэклог следующего Спринта. Больше никаких пустых разговоров только реальные изменения процесса.
Версия 2020: Радикальный минимализм и единая команда
Документ похудел до 13 страниц. Из текста вычистили все отсылки к ИТ, тестированию и программированию. Scrum стал универсальным фреймворком.
Главный удар — ликвидация термина «Команда Разработки» (Development Team). Раньше возникал конфликт «мы и они»: разработчики против Владельца Продукта. Теперь есть только одна Scrum Team, состоящая из Product Owner, Scrum Master и Developers. Никаких «команд внутри команд».
Скрам-мастер перестал быть мягким «лидером-слугой» (Servant Leader) и стал «истинным лидером» (True Leader), ответственным за эффективность.
Появились жесткие привязки (Commitments) для каждого артефакта. Бэклог Продукта получил Product Goal. Бэклог Спринта получил Sprint Goal. Инкремент получил Definition of Done. Эти привязки закрыли дыры, через которые команды уклонялись от ответственности за финальный бизнес-результат.
Главная мысль
Scrum Guide эволюционирует в сторону упрощения. Авторы вырезают инструменты, оставляя только голую физику процесса. Чем меньше правил в документе, тем больше ответственности ложится на плечи команды. Фреймворк больше не дает пошаговых туториалов — он задает жесткие границы, внутри которых инженеры обязаны думать своей головой, применять инженерные практики (XP, DevOps) и адаптировать процесс под суровую реальность.
Часто задаваемые вопросы (FAQ)
Они превращали встречу в статус-репорт. Разработчики отчитывались, вместо того чтобы планировать работу. Теперь команда сама решает, как синхронизироваться, главное — сфокусироваться на Цели Спринта и вскрыть блокеры.
Чтобы уничтожить конфликт между бизнесом и разработкой. Существование отдельной команды внутри Скрам-команды плодило барьеры и перекидывание ответственности. Теперь все сидят в одной лодке и несут единую ответственность за доставку ценности.
Нет. Фреймворк обновлен на основе мирового опыта сотен тысяч команд. Старые версии содержат костыли, которые индустрия давно признала вредными антипаттернами (например, использование Спринт Бэклога как жесткого обязательства).
Авторы удалили прескриптивные практики. Scrum — это фреймворк, а не методология. Меньше текста означает больше свободы для интеграции инженерных практик и методов управления потоком (Kanban). Вы сами решаете, как именно писать код.
Раньше Бэклог Продукта часто превращался в бесконечную свалку несвязанных тикетов. Product Goal задает долгосрочный вектор. Если задача не бьет в эту цель, Владелец Продукта обязан выкинуть ее из бэклога. Это спасает продукт от распыления.