Сравнение всех методологий: waterfall, RUP, XP, Scrum, Kanban, Scrumban, LeSS, SAFe, Lean

Спор «Scrum против Kanban» имеет примерно столько же смысла, сколько спор «молоток против рулетки». Это разные инструменты с разными допущениями, и почти всегда, когда команда спорит о названии процесса, настоящая проблема лежит на два слоя ниже: слишком большие партии работы, слишком длинная петля обратной связи, слишком много незавершёнки.

Предыдущие статьи трека разбирали методологии поштучно: Scrum, Kanban, Lean, Scrumban и гибриды, RAD, спиральная модель и RUP, фреймворки масштабирования. Эта статья не пересказывает их механику. Она делает то, чего нельзя сделать в статье про одну методологию: строит общую систему координат, кладёт в неё все девять подходов и честно отвечает на вопросы «чем они реально отличаются», «сколько каждый стоит», «что говорят данные» и «что выбрать под вашу конкретную ситуацию».

Часть 1. Почему обычные сравнения бесполезны

Типичная сравнительная таблица в интернете выглядит так: «Scrum — итерации, роли, церемонии; Kanban — непрерывный поток, без ролей». Формально верно и практически бесполезно, потому что сравнивает словарь, а не поведение системы.

Полезное сравнение отвечает на три вопроса:

1. Какое допущение о мире методология делает? Waterfall предполагает, что требования познаваемы заранее. XP предполагает обратное. Это не деталь оформления, это несовместимые модели реальности.
2. Какую переменную она отказывается двигать? Всё зафиксировать нельзя. Выбор методологии — это выбор жертвы.
3. Как быстро она узнаёт, что ошиблась? Длина петли обратной связи определяет цену ошибки сильнее, чем любая другая характеристика процесса.

1.1. Восемь осей, по которым методологии реально различаются

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

Часть 2. Родословная: кто от кого произошёл

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

Ключевая линия влияния, которую видно не сразу: Toyota → Lean → и Kanban, и XP, и Scrum одновременно. Понятие «поток», «вытягивание», «остановить конвейер при дефекте» пришло в разработку из производства, но разными путями — и поэтому в Scrum оно превратилось в спринт-бэклог, в Kanban — в WIP-лимит, а в XP — в красный билд, который останавливает всех.

Два наблюдения, которые стоит удержать:

• SAFe — это ре-синтез. Он собирает Scrum, XP-практики, Lean-мышление и каденцию поезда в один пакет. Отсюда и его размер, и его главная претензия: он пытается быть всем сразу.
• Continuous Delivery — сходящаяся точка. К нему независимо пришли и Lean, и XP, и Kanban. Когда три разные ветви эволюции приходят к одному ответу, это сильный сигнал, что ответ про физику, а не про моду.

Часть 3. Общий знаменатель: размер партии

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

Классическая модель стоимости партии (Рейнертсен, «The Principles of Product Development Flow»): есть транзакционная стоимость $T$ — цена одного прогона через процесс (сборка, регрессия, релизное окно, согласование), и стоимость удержания $H$ на единицу работы за единицу времени (устаревание, риск конфликтов, замороженная ценность). Общая стоимость на единицу при размере партии $B$:

$$C(B) = \frac{T}{B} + \frac{H \cdot B}{2}$$

Минимум достигается при

$$B^\ast = \sqrt{\frac{2T}{H}}$$

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

Функция плоская около минимума: ошибка в размере партии вдвое стоит всего около 25 % надбавки. Поэтому «примерно правильный» размер партии достаточен, а вот ошибка в десять раз — уже больно.

import math

def batch_cost(B: float, T: float, H: float) -> float:
    """Стоимость на единицу работы при размере партии B.

    T — транзакционная стоимость одного прогона (в часах инженера),
    H — стоимость удержания единицы работы за период (в часах эквивалента).
    """
    return T / B + H * B / 2


def optimal_batch(T: float, H: float) -> float:
    """Аналитический оптимум. O(1) по времени и памяти."""
    return math.sqrt(2 * T / H)


def scan(T: float, H: float, sizes) -> list[tuple[float, float]]:
    """Численный скан — O(n) по времени, O(n) по памяти.

    Нужен, чтобы увидеть, насколько плоское дно у кривой:
    именно плоскость объясняет, почему спор о 1- и 2-недельном спринте — шум.
    """
    return [(B, batch_cost(B, T, H)) for B in sizes]


# Организация A: ручная регрессия перед релизом, 40 часов на прогон
print(round(optimal_batch(T=40, H=0.5), 1))   # ≈ 12.6 задач в партии — то есть релиз-поезд
# Организация B: полностью автоматизированный пайплайн, 0.3 часа на прогон
print(round(optimal_batch(T=0.3, H=0.5), 1))  # ≈ 1.1 задачи — то есть continuous delivery

for B, c in scan(T=40, H=0.5, sizes=[4, 8, 12, 16, 24, 40]):
    print(f"партия {B:>3}: {c:6.2f}")
# партия   4:  11.00   партия  12:   6.33   партия  24:   7.67
# дно между 8 и 16 — почти плоское, края растут быстро

Практический вывод. Прежде чем менять фреймворк, посчитайте свою $T$. Смена Scrum на Kanban не уменьшает транзакционную стоимость релиза ни на минуту. Автоматизация регрессии — уменьшает на порядок, и после неё «правильная» методология меняется сама, без реорганизации.

Подробнее про транзакционные издержки поставки — в качестве и поставке, про очереди и закон Литтла — в Kanban.

Часть 4. Спектр петель обратной связи

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

Обратите внимание: у XP кратчайшая петля — минуты (тест не прошёл, пара сказала «стоп»), у водопада — недели и месяцы. Это разница не в стиле, а в порядке величины цены ошибки. Классическая кривая роста стоимости дефекта по фазам (Бём) даёт множитель порядка 10× на фазу; даже если современные оценки скромнее, направление не оспаривается никем.

Ловушка № 1. Многие «переходы на Agile» удлиняют петлю, а не укорачивают. Команда работала в потоке с релизами по готовности, ей внедрили двухнедельные спринты с релизом в конце — цикл обратной связи вырос с двух дней до двух недель. Формально agile, фактически регресс.

Ловушка № 2. Длина петли в методологии — это её обещание, а не ваша реальность. Если ваш спринт-ревью проходит без пользователя, а фича попадает в прод через месяц после «Done», ваша настоящая петля — месяц, что бы ни было написано на доске.

Часть 5. Что каждая методология фиксирует

Проект имеет четыре ограничения: объём, срок, команда, качество. Зафиксировать все четыре невозможно арифметически. Выбор методологии — это выбор, что вы отказываетесь двигать.

Самое честное наблюдение этой картинки: у водопада плавает качество — не потому, что его авторы были против качества, а потому что при фиксированных объёме, сроке и штате качество остаётся единственной переменной. Все итеративные подходы делают ровно один ход: снимают фиксацию с объёма и переносят её на качество. Отсюда Definition of Done в Scrum, «не обсуждается» в XP, дзидока в Lean.

SAFe в этой таблице — гибрид: он возвращает фиксацию объёма (цели PI — это обязательство на 8–12 недель) и одновременно декларирует фиксацию качества. Обе фиксации сразу возможны только при переменном сроке или переменном штате, чего SAFe тоже не предполагает. Практическое разрешение противоречия обычно происходит через «uncommitted objectives» — буфер в 10–20 %, то есть тихую расфиксацию объёма. Это работает, но полезно понимать, что именно там работает.

Часть 6. Развёрнутое сравнение по осям

6.1. Планирование и объём

6.2. Поток, WIP и ритм

6.3. Инженерные практики и предписательность

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

Часть 7. Как выбирать: модель Бёма и Тёрнера

Самая полезная работа по выбору методологии — не сравнительная таблица, а «Balancing Agility and Discipline» Бёма и Тёрнера (2003) и связанная с ней статья «Get Ready for Agile Methods, with Care». Их модель описывает «домашнюю территорию» (home ground) каждого семейства через пять факторов:

1. Размер — сколько людей должны согласовываться.
2. Критичность — цена отказа: неудобство, потеря денег, потеря жизни.
3. Динамизм — доля требований, меняющихся за месяц.
4. Персонал — доля людей, способных работать без подробных предписаний.
5. Культура — комфортно ли людям в хаосе или им нужен порядок.

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

Читать так: XP в правом нижнем углу не потому, что он для несерьёзных проектов, а потому что его экономика окупается там, где изменения часты и можно позволить себе быстрый откат. Медицинское устройство с сертификацией FDA живёт слева вверху — и там водопад с полной трассируемостью не глупость, а требование регулятора. Заметьте при этом, что даже в этой зоне современная практика сместилась: инженерные практики XP (тесты, CI, ревью) применяются и там, меняется только объём документации и момент фиксации объёма.

7.1. Дерево решений, которое реально работает

Обратите внимание на две ветки, которые чаще всего пропускают:

• «Сначала чините поставку». Если релиз занимает недели, любая методология выродится в батчинг. Это не процессная проблема, это инженерная.
• «Режьте продукт». Выбор между LeSS и SAFe почти всегда должен предваряться попыткой вообще не масштабировать координацию — см. статью о масштабировании.

Часть 8. Сколько это стоит

Разговор о методологиях почти никогда не включает цену. А она есть, и она измерима.

Простейший расчёт для двухдневного PI planning: сто человек × 2 дня × 4 раза в год = 800 человеко-дней в год, примерно 3,5 % годового capacity — только на само событие, без подготовки. Подготовка обычно добавляет столько же. Это не аргумент против SAFe: если событие снимает зависимости, которые иначе стоили бы месяцы простоя, оно окупается многократно. Это аргумент за то, чтобы считать, а не верить.

def process_overhead(headcount: int,
                     recurring: dict[str, tuple[float, int]],
                     working_days: int = 220) -> dict:
    """Доля capacity, уходящая на регулярные события процесса.

    recurring: {название: (длительность события в днях на человека,
                           количество раз в год)}
    Сложность: O(k) по числу типов событий.
    """
    per_person = {name: dur * times for name, (dur, times) in recurring.items()}
    total_days_per_person = sum(per_person.values())
    return {
        "по событиям, дней на человека в год": per_person,
        "всего дней на человека": round(total_days_per_person, 1),
        "доля capacity": f"{total_days_per_person / working_days:.1%}",
        "человеко-дней организации": round(total_days_per_person * headcount),
    }


safe_like = {
    "PI planning": (2.0, 4),          # 2 дня, 4 раза в год
    "подготовка к PI": (1.0, 4),
    "спринт-планирование": (0.25, 26),
    "ревью и ретро": (0.25, 26),
    "стендап": (0.03, 220),
    "scrum of scrums": (0.06, 52),
}
print(process_overhead(headcount=100, recurring=safe_like))
# доля capacity ≈ 12.6 % — и это ещё оптимистично, без синхронизаций архитекторов

scrum_like = {
    "спринт-планирование": (0.25, 26),
    "ревью и ретро": (0.25, 26),
    "стендап": (0.03, 220),
    "груминг": (0.12, 26),
}
print(process_overhead(headcount=100, recurring=scrum_like))
# доля capacity ≈ 8.0 %

Цифра сама по себе ничего не доказывает. Полезен вопрос, который она позволяет задать: что именно мы покупаем за эти 12 %? Если ответ «снятые зависимости и общий план» — хорошо. Если ответ «руководство видит статус» — это дорогой дашборд.

Часть 9. Что говорят данные

Здесь придётся быть неприятно честным: прямых доказательств превосходства одного фреймворка над другим практически нет.

CHAOS Report Standish Group — самый цитируемый источник «водопад проваливается в 70 % случаев» — методологически несостоятелен. Йоргенсен и Молёккен-Эствольд разобрали цифры 1994 года и показали, что они не воспроизводятся и противоречат другим измерениям того же периода (Information and Software Technology, 2006). Эвелинс и Верхуф в IEEE Software показали, что определения «успеха» у Standish систематически смещены: проект, выполненный с недооценкой, автоматически попадает в «провалы», а проект с раздутой оценкой — в «успехи» (The Rise and Fall of the Chaos Report Figures). Если вы видите эти проценты в презентации — это красный флаг качества источника.

DORA / Accelerate — лучшее, что у нас есть. Многолетнее исследование (dora.dev/research) показывает устойчивую связь производительности доставки с практиками, а не с фреймворками: транковая разработка, автоматизированное тестирование, непрерывная интеграция, слабо связанная архитектура, малый размер изменений. Названия «Scrum» или «Kanban» в списке предикторов не появляются. Подробный разбор — в статье про DORA.

Отраслевые опросы (например, State of Agile) полезны как карта распространённости, но это самоотчёты без контроля и без определения зависимой переменной. «87 % организаций применяют Agile» означает «87 % так себя называют».

Что из этого следует практически:

1. Выбирайте практики, а не бренды. Практики измеримо коррелируют с результатом.
2. Любой фреймворк, который не даёт вам транковой разработки, автотестов и малых партий, не даст и результата — какой бы логотип на нём ни стоял.
3. Фреймворк полезен как строительные леса: он даёт словарь и ритм на время, пока команда учится. Леса не должны оставаться навсегда.

Часть 10. Карго-культ: как каждая методология вырождается

Ричард Фейнман описывал «карго-культ науки» как воспроизведение внешней формы без понимания механизма. У каждой методологии свой характерный способ выродиться — и по симптому можно диагностировать, что именно потеряли.

Общий знаменатель всех веток: сохранена форма, потерян механизм обратной связи. Стендап без права поменять план — это отчёт. Ретро без изменений — это терапия. WSJF с числами, подогнанными под заранее выбранный приоритет, — это ритуал.

Мартин Фаулер назвал этот процесс semantic diffusion: термин расходится широко, теряя по дороге содержание, пока не начинает означать «то, что мы и так делали». Практическое противоядие — не защищать слова, а проверять механизм: спрашивайте не «делаем ли мы Scrum», а «когда мы последний раз изменили план из-за того, что узнали на стендапе».

Часть 11. Миграции: какие переходы работают

Организации редко выбирают методологию с чистого листа — они мигрируют. Некоторые траектории устойчивы, некоторые — известные тупики.

Три вещи, которые видно на этой схеме:

Water-Scrum-Fall — самый частый исход. Разработка работает спринтами, но требования приходят из большого предварительного анализа, а релиз происходит раз в квартал через отдельную команду. Спринты при этом не дают ничего, кроме иллюзии: петля обратной связи по-прежнему квартальная. Выход из этого состояния всегда лежит через поставку, а не через процесс.

Все дороги ведут в CD. Это не идеология: когда транзакционная стоимость релиза падает, формула $B^\ast = \sqrt{2T/H}$ сама выталкивает вас к малым партиям, и различия между методологиями становятся косметическими.

Обратные переходы редки и подозрительны. «Мы вернулись от Kanban к Scrum, потому что нужна предсказуемость» почти всегда означает «мы не построили вероятностный прогноз по циклу времени». Kanban даёт предсказуемость лучше, чем velocity, — но только если вы считаете перцентили; см. оценку и планирование.

Часть 12. Собрать свой процесс

Правильный итог сравнения — не «выберите X», а «соберите нужное». Ключ в том, чтобы делать это явно и письменно, иначе гибрид выродится в отсутствие правил. Ниже — рабочий формат описания процесса как конфигурации, который можно положить в репозиторий рядом с кодом и менять через pull request.

# process.yaml — рабочее соглашение команды, версионируется вместе с кодом
team: payments-core
version: 7
updated: 2026-07-16
review_every: "6 недель на ретроспективе"

# 1. Единица работы и размер партии
work_item:
  max_size: "3 дня цикла времени на 85-м перцентиле"
  split_policy: "больше — режем по вертикали, до слоя данных не режем"

# 2. Ограничение WIP — главный рычаг
wip_limits:
  in_progress: 4        # ≈ 0.6 × размер команды
  in_review: 3
  ready_for_deploy: 2   # если упёрлись — вся команда идёт чинить деплой

# 3. Ритм: что от Scrum, что от Kanban
cadences:
  standup:        { every: "1 день",  duration: "15 мин", purpose: "разблокировать поток" }
  replenishment:  { every: "1 неделя", duration: "45 мин", purpose: "вытянуть новое" }
  review_with_users: { every: "2 недели", duration: "60 мин", purpose: "обратная связь по ценности" }
  retro:          { every: "2 недели", duration: "60 мин", outcome: "не более 2 изменений процесса" }
# спринт-планирования нет: объём не фиксируем, вытягиваем по готовности

# 4. Классы обслуживания вместо приоритетов 1..5
classes_of_service:
  expedite:  { wip: 1, policy: "нарушает лимиты, требует постмортема" }
  fixed_date:{ policy: "стартуем по обратному отсчёту от даты + буфер 40 %" }
  standard:  { policy: "FIFO внутри класса" }
  intangible:{ policy: "берём, когда standard-очередь пуста" }

# 5. Definition of Done — то, что не торгуется
definition_of_done:
  - "код в trunk, ветка жила меньше суток"
  - "автотесты на новый путь, прогон зелёный"
  - "фича за флагом, флаг задокументирован"
  - "выкачено в прод, метрика и алерт настроены"
  - "документация обновлена, если менялся контракт"

# 6. Прогноз: вероятностный, без story points
forecasting:
  method: "Monte Carlo по историческому throughput, окно 12 недель"
  commitment_level: "85-й перцентиль наружу, 50-й — для внутреннего планирования"

# 7. Инженерные практики — обязательны, взяты из XP
engineering:
  trunk_based: true
  pairing: "на всём, что затрагивает деньги или схему БД"
  ci_max_duration: "10 мин"
  rollback_target: "5 мин"

Этот файл — сам по себе методология. В нём есть Scrum (каденции ревью и ретро), Kanban (WIP-лимиты, классы обслуживания, вытягивание), XP (транк, парность, CI), Lean (ограничение партии, остановка потока при затыке) и вероятностное планирование. Названия не важны — важно, что каждое правило имеет причину, и его можно отменить через pull request, когда причина исчезнет.

Обязательное условие: гибрид работает только с явными политиками. Разница между зрелым Scrumban и хаосом — ровно в наличии такого файла и в том, что команда его соблюдает. Подробнее о механике гибридов — в Scrumban и гибридных процессах.

Часть 13. Диагностика: какая у вас методология на самом деле

Название процесса в вики и реальный процесс — разные вещи. Реальный можно измерить по данным трекера и git. Скрипт ниже определяет не то, как вы себя называете, а как вы работаете.

from dataclasses import dataclass
from statistics import median

@dataclass
class Signals:
    median_cycle_time_days: float      # от «взяли в работу» до «в проде»
    deploy_interval_days: float        # медиана между деплоями
    median_branch_life_hours: float    # медиана жизни ветки до мержа в trunk
    wip_per_dev: float                 # среднее число одновременных задач на человека
    scope_change_within_period: float  # доля работ, добавленных после старта периода
    test_automation_ratio: float       # доля путей, покрытых автотестами

def diagnose(s: Signals) -> list[str]:
    """Эвристическая диагностика реального процесса. O(1)."""
    out = []
    if s.deploy_interval_days > 30:
        out.append("Реальная петля — месяц и больше: что бы ни было на доске, это водопад "
                   "с внутренними итерациями (Water-Scrum-Fall).")
    elif s.deploy_interval_days <= 1 and s.median_branch_life_hours <= 24:
        out.append("Фактически continuous delivery: спор о фреймворке уже не про вас.")

    if s.wip_per_dev > 2.0:
        out.append(f"WIP {s.wip_per_dev:.1f} на человека — лимитов нет по факту. "
                   "Цикл времени растёт линейно по закону Литтла.")

    if s.scope_change_within_period > 0.35:
        out.append("Больше трети объёма приходит после старта периода — "
                   "фиксация объёма не работает, спринт-планирование вы платите зря. "
                   "Смотрите в сторону вытягивания.")
    elif s.scope_change_within_period < 0.05:
        out.append("Объём почти не меняется — гибкость вам не нужна, "
                   "нужна предсказуемость. Каденции можно удлинить.")

    if s.test_automation_ratio < 0.4 and s.deploy_interval_days < 7:
        out.append("Частые деплои при слабой автоматизации тестов — "
                   "вы покупаете скорость за счёт риска, это не Agile, это рулетка.")

    if s.median_cycle_time_days > 3 * s.deploy_interval_days > 0:
        out.append("Цикл времени сильно длиннее интервала деплоя — "
                   "узкое место до кода: аналитика, согласования, ожидание ревью.")
    return out or ["Явных патологий по этим сигналам нет — смотрите на распределение, не на медианы."]


print("\n".join(diagnose(Signals(
    median_cycle_time_days=14, deploy_interval_days=45,
    median_branch_life_hours=120, wip_per_dev=3.4,
    scope_change_within_period=0.42, test_automation_ratio=0.25,
))))

Такая диагностика полезнее любой ассессмент-анкеты «на сколько вы agile», потому что опирается на данные, а не на самооценку. Она также обычно показывает, что менять надо не фреймворк: в примере выше проблема — 45 дней между деплоями и WIP 3,4, и ни одно изменение церемоний это не исправит.

Часть 14. Один объём, две раскладки

Полезно увидеть, как один и тот же объём работы выглядит в двух парадигмах — при одинаковом общем трудозатратном бюджете.

Обе полосы заканчиваются примерно в одно время — и это важная честность: итеративность не ускоряет доставку полного объёма. Она даёт другое:

• первая ценность приходит на 165 дней раньше (25-й день против 190-го);
• каждые 25 дней есть точка, где можно остановиться или развернуться;
• риск интеграции размазан, а не сконцентрирован в конце;
• обнаружение ошибки в требованиях стоит один инкремент, а не весь проект.

И одну реальную цену: суммарные накладные расходы на семь интеграций выше, чем на одну. Если ваша транзакционная стоимость интеграции высока (см. часть 3), инкрементальная раскладка проиграет и по срокам тоже. Это ровно та причина, по которой Agile без автоматизации поставки работает хуже водопада — и почему в этой ситуации первым шагом должна быть инженерия, а не реорганизация.

Часть 15. Типичные ошибки

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

Менять фреймворк вместо устранения узкого места. Если релиз стоит три недели, а согласование дизайна — месяц, смена Scrum на Kanban изменит форму доски и ничего больше. Найдите узкое место по цепочке лид-тайма (см. Kanban) и чините его.

Считать, что фреймворк включает инженерные практики. Scrum их не включает сознательно. Kanban тоже. Если вы не добавили их сами, вы получили ритуалы без механизма.

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

Оставлять фреймворк навсегда. Строительные леса нужны, пока идёт стройка. Зрелая команда постепенно снимает правила, у которых больше нет причины. Если за два года ни одно правило не было отменено, ретроспективы не работают.

Копировать процесс успешной компании. Spotify-модель — самый известный случай: скопировали снимок структуры на конкретный момент, без контекста, без людей и без того, что сам Spotify её к тому времени изменил. См. масштабирование.

Использовать методологию как инструмент контроля. Стендап, превращённый в отчёт, velocity как KPI, burndown как способ давить — всё это работает ровно один квартал, после чего команда учится управлять цифрами вместо работы. Это закон Гудхарта; разбор — в статье о метриках.

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

Часть 16. Как это выглядит в проде

Стартап, 8 человек, продукт в поиске рынка. Kanban-доска из четырёх колонок, WIP 3, релиз по готовности, транковая разработка, флаги фич. Никаких спринтов: объём меняется быстрее, чем любая фиксация имеет смысл. Формальных ретро нет, есть 30 минут в пятницу. Всё, что похоже на процесс, помещается в один markdown-файл.

Продуктовая компания, 60 инженеров, 9 команд, один продукт. LeSS-подобная схема: один бэклог, один PO, общий двухнедельный спринт, общий Definition of Done, включающий деплой в прод. Внутри команд — фактически Scrumban: каденции от Scrum, WIP-лимиты от Kanban. Инженерные практики обязательны и записаны. Координация между командами — через контракты API и общую архитектурную группу, а не через отдельный слой ролей.

Корпорация, 400 инженеров, регуляторные требования. SAFe на уровне программы, потому что нужен предсказуемый горизонт для смежников и бюджета. Внутри команд — Kanban с SLE. Главное отличие успешного внедрения от неуспешного: параллельно идёт программа декомпозиции монолита, и через два года число команд, участвующих в одном PI planning, падает вдвое. SAFe здесь осознанно используется как временный костыль на период, пока архитектура не позволяет иначе.

Команда поддержки платформы, 6 человек. Чистый Kanban с классами обслуживания: expedite для инцидентов (WIP 1), fixed_date для регуляторных задач, standard для остального. Спринты бессмысленны: работа приходит потоком и не планируется. SLE 85-го перцентиля вместо обещаний по датам.

Встроенное ПО медицинского прибора. Фазовый процесс с полной трассируемостью требований — этого требует регулятор, и это не обсуждается. Но внутри: CI, автотесты, ревью, короткие внутренние итерации. Формально водопад, инженерно — XP. Это самый недооценённый сценарий: инженерные практики отделимы от процессного каркаса, и брать их можно в любой конфигурации.

Мини-итог

• Методологии различаются не словарём, а тремя вещами: когда фиксируется объём, какого размера партия и насколько коротка петля обратной связи. Всё остальное — оформление.
• Оптимальный размер партии определяется транзакционной стоимостью поставки, а не философией. Формула $B^\ast = \sqrt{2T/H}$ объясняет, почему водопад был рационален при дорогих релизах и перестал быть рациональным при дешёвых.
• Зафиксировать объём, срок, команду и качество одновременно нельзя. Waterfall фиксирует три первых и жертвует качеством; итеративные подходы снимают фиксацию с объёма.
• Прямых доказательств превосходства какого-либо фреймворка нет. Есть устойчивые доказательства превосходства практик: транк, автотесты, малые изменения, слабая связность.
• Модель Бёма и Тёрнера (размер, критичность, динамизм, персонал, культура) — самый рабочий инструмент выбора. Большинство проектов попадает в середину и требует гибрида.
• Гибрид работает только с явными письменными политиками. process.yaml в репозитории — честнее любого названия методологии.
• Каждая методология вырождается характерным образом, и симптом всегда один: форма сохранена, механизм обратной связи потерян.
• Фреймворк — строительные леса. Если за два года вы не сняли ни одного правила, ретроспективы у вас не работают.

Источники

• Royce W. W., «Managing the Development of Large Software Systems», 1970 — статья, которую цитируют как манифест водопада, хотя автор приводил схему как пример неработающего подхода.
• Boehm B., «A Spiral Model of Software Development and Enhancement», IEEE Computer, 1988, doi:10.1109/2.59.
• Boehm B., «Get Ready for Agile Methods, with Care», IEEE Computer, 2002 — концепция home ground.
• Boehm B., Turner R., «Balancing Agility and Discipline», 2003 — пятифакторная модель выбора.
• Kruchten P., «The Rational Unified Process: An Introduction», 2003.
• Beck K., «Extreme Programming Explained», 2nd ed., 2004.
• Schwaber K., Sutherland J., Scrum Guide — актуальная редакция, 13 страниц.
• Anderson D. J., «Kanban: Successful Evolutionary Change for Your Technology Business», 2010; Kanban Guide.
• Ladas C., «Scrumban: Essays on Kanban Systems for Lean Software Development», 2008.
• Poppendieck M., Poppendieck T., «Lean Software Development: An Agile Toolkit», 2003.
• Reinertsen D. G., «The Principles of Product Development Flow», 2009 — экономика размера партии и очередей.
• Humble J., Farley D., «Continuous Delivery», 2010.
• Larman C., Vodde B., LeSS — материалы фреймворка и законы Лармана.
• Scaled Agile Framework — первоисточник SAFe.
• Forsgren N., Humble J., Kim G., «Accelerate», 2018; актуальные отчёты — dora.dev/research.
• Jørgensen M., Moløkken-Østvold K., «How large are software cost overruns? A review of the 1994 CHAOS report», Information and Software Technology, 2006.
• Eveleens J. L., Verhoef C., «The Rise and Fall of the Chaos Report Figures», IEEE Software, 2010.
• Fowler M., «The New Methodology», «Flaccid Scrum», «Semantic Diffusion».
• Conway M., «How Do Committees Invent?», 1968.
• Manifesto for Agile Software Development — четыре ценности и двенадцать принципов, первоисточник на одной странице.

Что дальше

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

Куда идти дальше:

• Вернуться к карте трека и пройти пропущенное — Управление проектами в IT: карта трека.
• Разобраться, откуда берётся приоритет и что вообще стоит делать — трек Product Management.
• Снизить транзакционную стоимость поставки, без чего ни одна методология не работает — DevOps.
• Уменьшить связность, из-за которой приходится масштабировать координацию — Domain-Driven Design и архитектурные паттерны.
• Фундамент инженерных практик, на которые всё это опирается — принципы проектирования и паттерны проектирования.
• Общая карта портала и порядок изучения — Roadmap.