Зачем Scrum и откуда он взялся
Зачем отдельная глава
Scrum часто воспринимают как набор встреч: спринт, дейли, ретро. Без контекста зачем это появилось процесс легко превращается в отчётность. Исторически метод вырос как ответ на детальный план «от и до» и долгие фазы без поставляемой ценности — в пользу коротких циклов с работающим инкрементом и обратной связью. Ниже — сжатая карта для IT-проекта; нормативные правила ролей и событий — в Scrum Guide и в статье Роли, артефакты и события.
Когда «всё по плану» ломается
Диаграммы Ганта и каскад
До широкого распространения Agile многие IT-проекты вели каскадно: требования → проектирование → код → тесты → внедрение, с диаграммами Ганта (метод Генри Ганта, 1910-е; массово — с ПК в 1980-х). График выглядит убедительно: каждая фаза, дата, ответственный. На практике как только план встречается с реальностью, он перестаёт соответствовать фактам, а организации иногда продолжают обновлять картинку, вместо того чтобы менять способ работы.
Формулировка в духе Эйзенхауэра: планировать важно, слепо цепляться за устаревший план — контрпродуктивно. В Scrum план живёт на уровне спринта и уточняется по мере появления знаний.
Кейс ФБР — Virtual Case File и Sentinel
Известный пример — модернизация ИТ ФБР после 11 сентября 2001 года.
Virtual Case File (VCF) — многолетний проект с подрядчиками; по итогу — сотни миллионов долларов и система, непригодная к работе. Документы оставались в бумажном контуре; аналитики не могли связать разрозненные данные — один из факторов, названных комиссией 11 сентября.
Sentinel (с 2005 года) снова шёл по знакомой схеме: крупный подрядчик (Lockheed Martin), детальный план, срыв сроков и бюджета. В 2010 году руководство остановило внешнюю разработку; Джефф Джонсон (внутренняя команда ФБР) взял спасение проекта.
Поворот, который часто приводят как иллюстрацию Scrum:
| Было (каскад + подряд) | Стало (внутренняя Scrum-команда) |
|---|---|
| Годы без рабочего продукта | Двухнедельные спринты с демонстрацией |
| Оценка сроков «с потолка» | Velocity после нескольких спринтов |
| Разрозненные подрядчики | Согласованные команды, снятие препятствий |
| Скепсис заказчиков | Открытые обзоры спринта для агентов и руководства |
Джонсон ~три месяца наблюдал реальную скорость команд, прежде чем назвать срок завершения. По открытым отчётам о проекте — порядка 18 месяцев на доведение кода и ПО плюс внедрение у сотрудников — на фоне прежних десятилетий и сотен миллионов при каскаде. Сильная сторона такого подхода — демонстрация результата на каждом этапе, а не отчёт о «проценте готовности».
Публичные сроки и множители продуктивности из крупных госпроектов нельзя переносить в свой продукт без измерений. Берите принципы: прозрачность, инкремент, снятие блокеров, измерение скорости команды.
Healthcare.gov — фасад и «не моё дело»
Второй антипример: портал Healthcare.gov — удобный UI сделали быстро (часть работ шла итеративно), серверная интеграция — десятки подрядчиков, каскадное планирование, тесты в последние дни. Ошибки накопились; система не заработала в срок. Урок: Agile на одном слое стека при водопаде на другом не спасает продукт.
Эволюционная идея вместо «большого взрыва»
Scrum описывают как эволюционную, адаптивную, самокорректирующуюся систему — по аналогии с:
- OODA loop (Джон Бойд): observe → orient → decide → act — цикл наблюдения и действия; в IT-литературе его связывают с робототехникой Родни Брукса (децентрализованные «конечности», обучение на столкновениях со средой, без гигантской «базы знаний»).
- Адаптивное управление: простые правила + частая обратная связь эффективнее одного «центрального плана» в меняющейся среде.
Для команды разработки вывод такой: частые инспекции реальности (демо, метрики, дейли) и адаптация важнее однократного «идеального ТЗ».
Истоки в индустрии
MidContinent — ранний эксперимент
Один из ранних опытов в финтехе (MidContinent Computer Services, банкоматы): отдельная автономная структура, премии от результата команды, а не личных KPI, недельные циклы, владелец продукта, резерв проекта. За полгода — самая рентабельная единица холдинга. Термины Scrum оформились позже, но ритм уже был.
Такеучи и Нонака — «The New New Product Development Game»
Статья 1986 года в Harvard Business Review сравнила каскад (NASA-style) с подходом Honda, Fuji-Xerox, 3M, HP: параллельные потоки, автономные кросс-функциональные команды, лидерство как служение (снятие препятствий), метафора rugby scrum — команда движется к цели единым мячом.
Easel Corporation (1993)
Команда разработки осознанно применила rugby-подход к ПО: отказ от бессмысленных Гантов, обещание рабочего куска системы через месяц. Продукт сдали в срок и бюджет — редкость для отрасли того времени. Это часто считают практическим рождением Scrum в software.
Деминг, Toyota, PDCA
Уильям Эдвардс Деминг в послевоенной Японии заложил культуру измерять → улучшать → не останавливаться. Цикл PDCA (Plan–Do–Check–Act) используют в тренингах по Scrum и связывают с производственной системой Toyota (Тайити Оно): непрерывный поток, устранение потерь — тема потерь в Scrum.
Публикация 1995 и Scrum Guide
На конференции OOPSLA 1995 Кен Швабер и соавторы представили доклад SCRUM Development Process; позже название упростили до Scrum. Сегодня эталон правил — Scrum Guide (обновляется сообществом Scrum.org / Scrum Alliance).
Три столпа эмпиризма (связь с практикой)
В обзоре методологий Scrum уже связан с эмпиризмом. Ими объясняют, почему работают церемонии:
| Столп | На практике |
|---|---|
| Прозрачность | Бэклог, доска, демо «живого» инкремента, открытые обзоры (как в ФБР) |
| Инспекция | Daily, review, метрики спринта, честный разбор WIP |
| Адаптация | Ретроспектива, перепланирование, снятие препятствий SM |
Без прозрачности остаются красивые отчёты вместо управления продуктом.
Рост продуктивности — реалистичные ожидания
После освоения Scrum команды часто сокращают потери (ожидание, полуготовые задачи, лишние согласования) и ускоряют поставку. Для учебника разумная интерпретация:
- рост даёт сокращение потерь и автономия, а не «магия названия»;
- нужны кросс-функциональность и доверие;
- маркетинговые цифры из кейсов — не SLA для вашего контракта.
Краткие выводы главы
- Scrum возник как ответ на долгие каскадные проекты без поставляемой ценности.
- Истоки — lean/Toyota, rugby team (Такеучи/Нонака), эмпирические циклы (PDCA, OODA), первый заметный IT-опыт 1993.
- Кейсы ФБР и Healthcare.gov показывают: важны инкремент, единая цель и тест по ходу, а не только «правильная диаграмма».
- Дальше по маршруту раздела — как устроен Scrum на практике.
Что читать дальше
| Тема | Ссылка |
|---|---|
| Роли, события, артефакты | ./2 |
| SDLC, Agile, сравнение с Kanban | 7-03/1 |
| Госзаказ и спринты | 7-03/2 |
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). Product Owner, Scrum Master, Developers; Product Backlog, Sprint Backlog, Increment; планирование, Daily, Review, Retrospective — по Scrum Guide и типовой практике внедрения. Размер команды 3–9, кросс-функциональность, каналы коммуникации, автономия, роль Scrum Master и фундаментальная ошибка атрибуции. Фиксированная длина спринта, velocity, Scrum-доска, burndown, демонстрация инкремента и циклическое восприятие времени. Lean и Toyota в Scrum: потери, WIP, multitasking, muri, Definition of Done и принцип «сделано наполовину — не сделано». Product Backlog, приоритизация, относительные оценки, последовательность Фибоначчи и Planning Poker — практика Scrum и аналитики. 11 шагов запуска Scrum, контекст внедрения в России, Scrum-театр, гибриды с waterfall и госзаказом. Краткое сравнение Scrum с waterfall и Kanban, когда выбирать фреймворк и куда смотреть дальше в энциклопедии. Диагностика: работает ли у вас Scrum или только названия в Jira — роли, спринт, инкремент, события и потери.Scrum — роли, артефакты и события
Scrum — команда и Scrum Master
Scrum — спринт, ритм и прозрачность
Scrum — потери, фокус и готово
Scrum — бэклог, приоритеты и оценка
Scrum — внедрение и типичные ошибки
Scrum — итоги раздела
Scrum — чек-лист самопроверки