Зачем Scrum и откуда он взялся
Миграции в инкременте — Пакетная работа; проверка — SQL для тестировщика.
Зачем отдельная глава
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 |
| Agile — манифест и принципы | 7-03/3 |
| SDLC, сравнение с Kanban | 7-03/1 |
| Госзаказ и спринты | 7-03/2 |