RAD, спиральная модель, RUP и итеративные подходы: наследие и что осталось

Существует удобная легенда: до 2001 года индустрия страдала под гнётом водопада, потом собрались семнадцать человек в Сноуберде, написали манифест — и наступила итеративность.

Легенда ложная во всех трёх частях. Итеративная разработка старше водопада. Человек, которого обвиняют в изобретении водопада, водопад критиковал. А почти всё, что сегодня считается «аджайл-практикой» — таймбоксы, инкрементальная поставка, приоритизация по риску, архитектурный забег в начале, ревью с заказчиком каждые несколько недель — было описано, названо и внедрено в проектах на десятилетия раньше.

Эта статья — археология. Не из уважения к древности, а потому что доагильные итеративные модели решали задачи, которые Scrum и Kanban не решают: как вести проект, где главный риск технический, а не продуктовый; как принимать решение «продолжать или закрывать»; как встроить архитектуру в процесс, а не надеяться на эмерджентность. Эти задачи никуда не делись — просто перестали иметь имена.

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

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

Часть 1. Миф о водопаде

1.1. Что на самом деле написал Ройс

Уинстон Ройс, статья «Managing the Development of Large Software Systems» (Proceedings of IEEE WESCON, 1970). Знаменитая диаграмма из семи последовательных блоков на второй странице — та самая, что кочует по учебникам как «модель водопада». Ройс подписал её так:

«I believe in this concept, but the implementation described above is risky and invites failure.»

Дальше — восемь страниц о том, как это чинить. Пять предложений Ройса:

1. Предварительное проектирование программы до начала анализа требований — чтобы архитектурные ограничения были известны заранее.
2. Документировать дизайн явно и подробно.
3. «Do it twice» — построить пилотную версию системы, выбросить её и построить настоящую. Буквально прототип с выбрасыванием.
4. Планировать, контролировать и мониторить тестирование как отдельную инженерную деятельность, а не хвост проекта.
5. Вовлекать заказчика формально и на протяжении всего проекта, а не в конце.

Пункты 1, 3 и 5 — это ровно то, что через 18 лет назовут спиральной моделью, а через 31 год — аджайлом. Ройс никогда не использовал слово «waterfall»; термин закрепил Белл и Тайер в 1976, уже ссылаясь на Ройса как на автора того, что тот критиковал.

1.2. Почему водопад всё-таки победил — на бумаге

Проблема была не в инженерах, а в закупках. Государственный заказчик не умеет покупать «мы будем итеративно выяснять, что вам нужно». Он умеет покупать вехи, приёмо-сдаточные документы и фиксированную цену. Так появился DoD-STD-2167 (1985) — стандарт Министерства обороны США, привязавший оплату к последовательным документным вехам. Его редакция 2167A (1988) формально не требовала водопада, но структура отчётности не оставляла выбора. Только MIL-STD-498 (1994) явно разрешила итеративные и эволюционные жизненные циклы — и одним из её идеологов был Барри Боэм.

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

1.3. Итеративность была всегда

Крейг Ларман и Виктор Басили собрали историю в статье «Iterative and Incremental Development: A Brief History» (IEEE Computer, июнь 2003). Хронология уничтожает миф:

Space Shuttle — особенно неудобный для мифа пример: программное обеспечение бортового комплекса (около 400 тысяч строк) разрабатывалось восемью итеративными релизами на протяжении шести лет, и итоговый дефектный поток составлял единицы дефектов на миллион строк. Это доагильная, тяжеловесная, документированная — и при этом последовательно итеративная разработка.

Часть 2. Итеративность ≠ инкрементальность

Эти слова путают постоянно, а разница фундаментальна и объясняет половину провалов «гибких» процессов. Каноническое различение — Алистер Кокбёрн:

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

Все три модели этой статьи — итеративно-инкрементные, но с разным центром тяжести:

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

Часть 3. Спиральная модель Боэма

3.1. Идея: процесс — это функция риска

Барри Боэм, «A Spiral Model of Software Development and Enhancement» (IEEE Computer, май 1988; ранняя версия — 1986, ACM SIGSOFT). Центральный тезис не «разработка идёт по спирали», а следующий:

Нет правильного жизненного цикла. Есть риск-профиль проекта, и он определяет, какой процесс применить на следующем шаге.

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

3.2. Механика витка

Радиус — накопленные затраты, угол — прогресс внутри витка. Четыре квадранта проходятся в каждом витке:

1. Цели, альтернативы, ограничения. Что мы хотим получить на этом витке (производительность? подтверждение реализуемости? одобрение заказчика?), какие есть способы, что нельзя нарушать.
2. Оценка альтернатив, выявление и снижение рисков. Прототипы, моделирование, бенчмарки, опросы пользователей, аналитические модели. Это сердце модели.
3. Разработка и верификация артефакта витка — им может быть прототип, спецификация, архитектурный документ или рабочий инкремент.
4. Ревью со всеми заинтересованными сторонами и планирование следующего витка. Здесь принимается решение: продолжаем, повторяем виток, меняем стратегию или закрываем.

3.3. Что означает «снижение риска» количественно

Боэм ввёл две простые величины, которые до сих пор недооценены (см. также статью про риски):

• Risk Exposure (RE) = вероятность неблагоприятного исхода × размер потерь.
• Risk Reduction Leverage (RRL) = (RE_до − RE_после) / стоимость мероприятия.

RRL — это ROI действия по снижению риска. Он превращает вопрос «чем заняться на следующей итерации» из вкусовщины в арифметику. Ниже рабочий планировщик витка:

"""Риск-ориентированное планирование итерации по Боэму.

Вход: реестр рисков и список мероприятий (спайки, прототипы, бенчмарки).
Выход: набор мероприятий, максимизирующий снижение RE в рамках бюджета итерации.
"""
from dataclasses import dataclass
from typing import Iterable


@dataclass(frozen=True)
class Risk:
    id: str
    prob: float          # вероятность реализации, 0..1
    loss_days: float     # потери в человеко-днях, если риск реализуется

    @property
    def exposure(self) -> float:
        """Ожидаемые потери — то, чем мы реально рискуем."""
        return self.prob * self.loss_days


@dataclass(frozen=True)
class Action:
    """Мероприятие витка: спайк, прототип, нагрузочный тест, интервью."""
    name: str
    risk_id: str
    cost_days: float          # стоимость проведения
    prob_after: float         # ожидаемая вероятность риска ПОСЛЕ мероприятия
    loss_after: float | None = None   # если мероприятие ещё и снижает ущерб


def rrl(action: Action, risk: Risk) -> float:
    """Risk Reduction Leverage: сколько ожидаемых потерь снимает один день работы."""
    loss_after = risk.loss_days if action.loss_after is None else action.loss_after
    re_after = action.prob_after * loss_after
    return (risk.exposure - re_after) / action.cost_days


def plan_iteration(risks: Iterable[Risk], actions: Iterable[Action],
                   budget_days: float) -> list[Action]:
    """Жадный отбор по RRL — классический greedy для дробного рюкзака.

    Сложность: O(n log n) по времени (сортировка), O(n) по памяти.
    Для целочисленного рюкзака жадность не оптимальна, но при типичных
    n < 30 и грубости входных оценок разница лежит внутри шума данных.
    """
    index = {r.id: r for r in risks}
    ranked = sorted(actions, key=lambda a: rrl(a, index[a.risk_id]), reverse=True)

    chosen, spent = [], 0.0
    for a in ranked:
        if spent + a.cost_days <= budget_days and rrl(a, index[a.risk_id]) > 1.0:
            chosen.append(a)          # RRL > 1 — снимаем больше потерь, чем тратим
            spent += a.cost_days
    return chosen


if __name__ == "__main__":
    risks = [
        Risk("R1", prob=0.6, loss_days=120),   # не тянет нагрузку -> переписывание ядра
        Risk("R2", prob=0.3, loss_days=40),    # неудобный UX -> переделка экранов
        Risk("R3", prob=0.15, loss_days=200),  # вендор не даст SLA -> смена провайдера
    ]
    actions = [
        Action("Нагрузочный прототип ядра", "R1", cost_days=8,  prob_after=0.15),
        Action("Полный отказоустойчивый стенд", "R1", cost_days=45, prob_after=0.05),
        Action("Кликабельный макет + 5 интервью", "R2", cost_days=4, prob_after=0.10),
        Action("PoC на альтернативном вендоре", "R3", cost_days=10, prob_after=0.05),
    ]

    for a in plan_iteration(risks, actions, budget_days=20):
        r = next(x for x in risks if x.id == a.risk_id)
        print(f"{a.name:38s} RRL={rrl(a, r):5.1f}  цена={a.cost_days:4.1f} д.")

Вывод:

Кликабельный макет + 5 интервью        RRL=  2.0  цена= 4.0 д.
Нагрузочный прототип ядра              RRL=  7.8  цена= 8.0 д.
PoC на альтернативном вендоре          RRL=  2.0  цена=10.0 д.

Обратите внимание, что «Полный отказоустойчивый стенд» отвергнут: он снимает риск сильнее, но RRL = (72 − 6) / 45 ≈ 1,5 против 7,8 у дешёвого прототипа. Спираль не требует снимать риск полностью — она требует снимать его дёшево и рано. Это ровно та логика, которая сегодня живёт в спайках Scrum, в «pre-mortem» и в бюджетировании исследовательских задач.

3.4. Якорные вехи: LCO, LCA, IOC

Главное практическое наследие спирали — не картинка, а «Anchoring the Software Process» (Boehm, IEEE Software, 1996). Проблема спирали в чистом виде: витки могут продолжаться бесконечно, у проекта нет общих точек синхронизации, заказчик не понимает, за что платит. Боэм ввёл три вехи, определяемые содержанием артефактов, а не датой:

Эти вехи выжили лучше, чем сама спираль: они лежат в основе фазовой структуры RUP (см. ниже), в модели поэтапных инвестиций Rational, а по существу — во всех современных stage-gate-процессах. Их ценность в том, что критерий прохождения — демонстрируемый артефакт, а не подписанный документ.

3.5. Где спираль работает

Честные границы применимости:

• Работает: крупные системы с высокой ценой ошибки и техническим риском — аэрокосмическая, оборонная, медицинская техника, телеком-инфраструктура, R&D-проекты с неочевидной реализуемостью, ML-проекты с неизвестным потолком качества модели, миграции унаследованных систем.
• Не работает: типовые продуктовые фичи в известном стеке. Здесь риск-анализ каждого витка — чистые накладные расходы; дешевле просто сделать и посмотреть. Стоимость самой процедуры анализа рисков — от 3 до 10% бюджета итерации, и она окупается только если ожидаемые потери действительно велики.

3.6. Карго-культ спирали

Боэм с соавторами описали типовые подделки в отчёте SEI «Spiral Development: Experience, Principles, and Refinements» (CMU/SEI-2000-SR-008). Признаки того, что «спираль» у вас — декорация:

1. Витки фиксированной длины с фиксированным содержанием. Если содержание витка определено в плане на год вперёд, риск не управляет процессом. Это водопад, нарезанный на дольки.
2. Нет ни одного артефакта из квадранта 2. Прототипов, бенчмарков, моделей нет, а «анализ рисков» — таблица в Excel, которую заполняют перед комитетом.
3. Виток никогда не приводит к отмене или развороту. Если за три года ни один виток не завершился решением «эта альтернатива не работает, берём другую» — решения не принимаются, а протоколируются.
4. Ревью только с внутренним руководством. Квадрант 4 требует всех ключевых заинтересованных сторон; без пользователя и эксплуатации ревью бессмысленно.
5. Риски не имеют владельца, срока и цены. Реестр без RE и RRL — это список тревог, а не инструмент.

Часть 4. RAD: скорость как первичное требование

4.1. Происхождение

Джеймс Мартин, книга «Rapid Application Development» (Macmillan, 1991), опиравшаяся на работы Скотта Шульца в DuPont (метод RIPP) и на идеи Боэма о таймбоксинге. Экономическая предпосылка простая: в конце 1980-х корпоративные информационные системы разрабатывались по 2–3 года, а бизнес-требования менялись за 6–12 месяцев. Система приезжала морально устаревшей по построению. RAD объявил скорость поставки не пожеланием, а жёстким ограничением, ради которого можно жертвовать всем остальным.

Ключевой разворот железного треугольника (см. обзор трека): срок фиксируется первым, скоуп плавает. Именно этот приём, а не прототипирование, оказался главным вкладом RAD в индустрию.

4.2. Механика

4.3. DSDM: RAD, который выжил

Чистый RAD Мартина был методологически рыхлым и легко вырождался в «быстро и как попало». В 1994 году консорциум британских компаний выпустил DSDM (Dynamic Systems Development Method) — фактически стандартизованный, дисциплинированный RAD, и это единственный доагильный метод, который дожил до наших дней в поддерживаемом виде (сейчас Agile Business Consortium, фреймворк AgilePF).

Ядро DSDM — структура таймбокса, у которой есть внутренние контрольные точки:

Правило распределения по MoSCoW в DSDM количественное и жёсткое: Must — не более 60% трудоёмкости таймбокса, Should — около 20%, Could — около 20%. Эти 20% Could и есть встроенный буфер: их отбрасывание не считается срывом. Это принципиально честнее типичного спринта, где 100% объёма помечено «обязательно», а буфера нет вовсе.

4.4. Где RAD ломается

RAD — метод с очень узкой честной областью применимости, и Мартин это признавал.

Главный системный дефект RAD — прототип становится продуктом. Код, написанный за неделю ради демонстрации экрана, не проектировался для эксплуатации: нет обработки ошибок, транзакционности, тестов, миграций. Организация видит работающий экран и отказывается платить за переписывание. Технический долг накапливается быстрее, чем поставляется ценность — и через полтора года скорость поставки падает ниже, чем была бы при «медленном» подходе. Это ровно та кривая, о которой говорит статья о качестве.

Защита ровно одна и она организационная: явное решение перед началом прототипа — он выбрасываемый (throwaway) или эволюционный (evolutionary). Для throwaway запрещено переносить код в продакшн; для evolutionary с первого дня действуют продакшн-стандарты качества. Смертельная ошибка — не принять это решение вовсе.

4.5. RAD не умер — он стал low-code

Современные low-code/no-code платформы (OutSystems, Mendix, Retool, Appsmith, Power Apps, плюс весь класс backend-as-a-service) — это буквальная реинкарнация CASE-инструментов RAD, с теми же обещаниями и теми же граблями.

Правило принятия решения одно и то же, что и тридцать лет назад: если приложение является вашим конкурентным преимуществом — не стройте его на RAD-инструменте. Если это внутренний расходник — не стройте его вручную.

Часть 5. RUP: самая проработанная и самая осмеянная модель

5.1. Родословная

RUP собран в Rational Software (1996–1998) из трёх линий:

• Objectory Ивара Якобсона — сценарии использования (use cases) как ось процесса;
• метод Буча — итеративный объектно-ориентированный дизайн;
• OMT Джеймса Рамбо — объектное моделирование.

Их слияние породило сначала UML (стандартизован OMG в 1997), затем — процесс вокруг него. Каноническое изложение — Филипп Крухтен, «The Rational Unified Process: An Introduction» (3-е издание, 2003). Он же автор модели «4+1 представлений архитектуры» (IEEE Software, 1995) — логическое, процессное, разработки, физическое плюс сценарии. Эта модель пережила RUP и до сих пор используется в архитектурной документации (см. паттерны архитектуры).

5.2. Структура: две оси

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

Это и есть знаменитая «диаграмма горбов». Её обычно показывают как символ бюрократии, но читать её надо ровно наоборот: все горбы перекрываются, ни одна дисциплина не кончается на границе фазы. Тестирование начинается в проработке, а не после кодирования; требования уточняются в построении. Если ваши фазы — непересекающиеся прямоугольники, у вас не RUP.

Фазы и их вехи — прямое наследие якорных вех Боэма:

Самая недооценённая идея RUP — исполняемый архитектурный прототип на выходе Elaboration. Не диаграмма, не документ: работающий скелет системы, в котором реализованы архитектурно значимые сценарии (самые рискованные, а не самые ценные), и он прогоняется под нагрузкой. Пока такого артефакта нет, архитектура — гипотеза. Современный аналог — walking skeleton и тонкий вертикальный срез через все слои.

5.3. Как выглядит план проекта в RUP

Обратите внимание на пропорции: Elaboration занимает 30 дней из 150 (20%), и до её завершения ни одна «фича» в привычном смысле не поставляется — поставляется снятый архитектурный риск. Именно это делает RUP пригодным для систем, где переделка архитектуры на середине проекта стоит дороже всего проекта.

5.4. Шесть практик RUP

Rational продвигала процесс через шесть «best practices». Все шесть сегодня банальны — что и есть лучшее доказательство их правоты:

1. Разрабатывать итеративно.
2. Управлять требованиями (прослеживаемость от сценария к тесту).
3. Использовать компонентную архитектуру.
4. Визуально моделировать (UML).
5. Непрерывно верифицировать качество — тестирование в каждой итерации.
6. Управлять изменениями — конфигурационное управление и контроль версий.

Пункты 1, 5 и 6 стали воздухом индустрии: CI, автотесты, git. Пункт 4 умер почти полностью — UML как язык проектирования проиграл коду и лёгким диаграммам. Пункты 2 и 3 живы в enterprise и в регулируемых отраслях.

5.5. Почему RUP умер

Причины смерти поучительны, потому что повторяются с каждым тяжёлым фреймворком — и ровно те же претензии сегодня предъявляют SAFe (см. масштабирование):

1. Продукт, а не процесс. RUP продавался как лицензируемый продукт — база знаний на тысячи веб-страниц, с шаблонами, ролями (порядка 30) и артефактами (порядка 70). Купившая его организация естественным образом стремилась «использовать всё купленное».
2. Тайлоринг был обязателен, но никто его не делал. Крухтен прямым текстом писал, что RUP — меню, из которого проект составляет свой development case, и типовой проект должен использовать 20–30% содержимого. На практике development case не составлялся, и команда получала все 100% церемоний.
3. Фазы прочитали как водопад. Четыре фазы с названиями «анализ — проектирование — реализация — внедрение» слишком похожи на водопад, чтобы организация с водопадной культурой прочитала их иначе. Внутри фаз итераций не заводили. Получился «водопад в четырёх коробках» — самый распространённый диагноз RUP-проектов.
4. UML-паралич. Инструменты Rational поощряли моделирование ради моделирования; появились проекты, где месяцами рисовали диаграммы без единой строки кода.
5. Конкуренция снизу. XP и Scrum давали 80% пользы за 5% веса, и были бесплатны. Для менеджера выбор «месяц обучения и лицензия» против «двухдневный тренинг» был очевиден.

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

5.6. Наследники

• OpenUP — минимальная открытая редакция Unified Process в Eclipse Process Framework; всё ещё живой референс для тех, кому нужен лёгкий, но формально описанный процесс.
• AUP (Agile Unified Process) Скотта Эмблера — упрощение до 7 дисциплин, позже поглощено Disciplined Agile (теперь под PMI).
• EssUP Якобсона → инициатива SEMAT → стандарт OMG Essence: попытка выделить общее ядро всех процессов (альфы: возможность, стейкхолдеры, требования, система, работа, команда, способ работы) и собирать метод из карточек-практик. Академически элегантно, индустриально почти не прижилось — но идея «процесс = композиция практик, а не монолит» верна и полезна.

Часть 6. Что осталось живого

Сводная таблица «идея → где живёт сегодня»:

И честный список того, что умерло и правильно сделало: UML как основной язык проектирования; ролевые модели на 30 позиций; документ-центричные вехи; CASE-генерация как основа разработки; идея, что процесс можно купить готовым.

Часть 7. Когда осознанно применять это сегодня

7.1. Home ground: пять факторов Боэма и Тёрнера

В книге «Balancing Agility and Discipline» (2003) Боэм и Тёрнер предложили не выбирать между «гибким» и «дисциплинированным», а оценить проект по пяти осям и собрать гибрид. Оси и их прочтение:

Практическое применение: оцените каждую ось от 1 до 5, отметьте выбросы. Проект 5 человек / низкая критичность / высокий динамизм — чистый Scrum, и вся эта статья для него бесполезна. Проект 60 человек / медицинское устройство / стабильные требования — Scrum там будет ритуалом поверх фактического стейдж-гейта, честнее взять гибрид с явной фазой Elaboration.

7.2. Три ситуации, где доагильная механика прямо лучше

1. Технический риск доминирует над продуктовым. Например, вы не знаете, достижима ли требуемая точность модели или укладывается ли latency в бюджет. Продуктовая итерация «сделаем фичу, покажем пользователю» тут бесполезна: пользователь не может ответить на вопрос, который стоит перед вами. Нужен виток спирали: гипотеза → эксперимент → решение о продолжении. Это стандартный режим ML-проектов (см. machine learning).

2. Стоимость архитектурной ошибки превышает стоимость проекта. Схема данных платёжной системы, протокол обмена между сорока сервисами, формат хранения архива на десять лет. Эмерджентный дизайн здесь — не смелость, а халатность. Фаза Elaboration с исполняемым прототипом на 15–20% бюджета честнее и дешевле.

3. Внешний заказчик с фиксированной ценой. Контракт time-and-material недоступен, скоуп надо зафиксировать. Единственный честный ход — DSDM-модель: фиксируем срок и бюджет, фиксируем список Must, оставляем Should и Could плавающими. Это юридически оформляемо и не превращает проект в водопад.

7.3. Как встроить якорные вехи в современный процесс

Вехи Боэма легко ложатся на обычный CI/CD-процесс как проверяемый чеклист гейта — не документ, а конфигурация:

# release-gates.yaml — якорные вехи как проверяемые критерии,
# а не как совещание с презентацией
gates:
  - id: LCA
    name: "Архитектура жизненного цикла"
    when: "перед началом массовой разработки"
    # проходим, только если ВСЕ пункты объективно проверяемы
    criteria:
      - id: walking-skeleton
        check: "e2e-сценарий проходит через все слои в staging"
        evidence: "ссылка на прогон CI"
      - id: nfr-proven
        check: "p99 latency <= 200ms при 2x ожидаемой нагрузки"
        evidence: "отчёт нагрузочного теста"
      - id: risks-burned
        check: "все риски с exposure > 20 человеко-дней имеют статус mitigated"
        evidence: "выгрузка реестра рисков"
      - id: adr-complete
        check: "ADR существует для каждого архитектурно значимого решения"
        evidence: "docs/adr/*.md"
    on_fail: "продлить elaboration или сменить архитектурную альтернативу"
    # анти-паттерн: on_fail: 'зафиксировать риск и идти дальше'

  - id: IOC
    name: "Первая эксплуатационная готовность"
    when: "перед пилотом с реальными пользователями"
    criteria:
      - id: runbook
        check: "runbook и алерты существуют, дежурный назначен"
      - id: rollback
        check: "откат релиза выполнен на staging за <= 10 минут"
      - id: data-migration
        check: "миграция прогнана на копии продакшн-данных, есть план отката"

Ценность в одной строке: on_fail — не формальность. Веха, которую нельзя не пройти, не является вехой.

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

1. Считать, что «итеративно» = «без плана». Спираль, RAD и RUP — все итеративные и все плановые. Итерация — это горизонт обязательства, а не отсутствие обязательств.
2. Называть спринтами нарезанный водопад. Если внутри спринта идёт «аналитика → разработка → тестирование» и на выходе нет работающего инкремента — это RUP-фаза длиной в две недели, причём худший её вариант.
3. Заимствовать фазы RUP без итераций внутри. Самая частая форма карго-культа. Проверка: есть ли внутри Construction хотя бы три отдельных прогона «код → тест → демо»? Если один — это водопад.
4. Не решать судьбу прототипа. Throwaway или evolutionary — решение принимается до написания первой строки и фиксируется письменно.
5. Elaboration без исполняемого артефакта. Фаза, закрытая набором диаграмм, не снимает архитектурного риска: гипотеза остаётся гипотезой.
6. Риск-реестр без exposure. Список рисков без вероятности, ущерба и владельца — ритуал. Считайте RE, сортируйте по RRL, иначе бюджет идёт на самые пугающие, а не на самые дорогие риски.
7. Ссылаться на Chaos Report как на доказательство. Знаменитые цифры Standish («31% проектов провалены») методологически разобраны в статье «The Rise and Fall of the Chaos Report Figures» (Eveleens & Verhoef, IEEE Software, 2010) — выборка и определение «успеха» делают их непригодными для сравнения методологий. Спорить о процессах на этих цифрах — спорить ни о чём.
8. Тайлорить фреймворк «потом». Если решение «что не используем» не принято на старте, оно не будет принято никогда, и вы получите весь вес.

Часть 9. Цена процесса

Любой процесс — это накладные расходы, которые окупаются только через снятый риск. Порядки величин из практики крупных проектов (числа ориентировочные, зависят от организации, но соотношения устойчивы):

Ключевой вывод таблицы: дешёвые элементы наследия (таймбоксы, вехи, риск-скоринг) почти всегда окупаются, а дорогие (полное моделирование, ролевая структура) — почти никогда. Именно поэтому индустрия сохранила первое и выбросила второе.

Мини-итог

• Водопад в чистом виде никогда не был рекомендацией — он был артефактом закупочных процедур. Ройс предлагал «делать дважды» ещё в 1970-м.
• Итеративность отвечает на неопределённость, инкрементальность — на объём. Это разные инструменты, и путаница между ними стоит дорого.
• Спираль Боэма — не картинка, а мета-модель: риск определяет, какой процесс применить дальше. Живое наследие — RE/RRL-скоринг и якорные вехи LCO/LCA/IOC.
• RAD дал таймбокс с плавающим скоупом, MoSCoW и совместные воркшопы — это фундамент современного спринта. Его смертельный дефект (прототип становится продуктом) сегодня воспроизводится в low-code один в один.
• RUP был технически лучшей моделью своего времени и погиб от собственного веса и от того, что продавался как продукт. Его лучшая идея — исполняемая архитектура на выходе Elaboration — сегодня зовётся walking skeleton.
• Универсальный урок: любой процесс, который можно купить целиком, будет внедрён целиком. Тайлоринг — не опция, а условие работоспособности.

Источники

• W. Royce. Managing the Development of Large Software Systems, IEEE WESCON, 1970.
• C. Larman, V. Basili. Iterative and Incremental Development: A Brief History, IEEE Computer, 2003.
• B. Boehm. A Spiral Model of Software Development and Enhancement, IEEE Computer, 1988.
• B. Boehm. Anchoring the Software Process, IEEE Software, 1996.
• B. Boehm et al. Spiral Development: Experience, Principles, and Refinements, SEI CMU/SEI-2000-SR-008.
• B. Boehm, R. Turner. Balancing Agility and Discipline, Addison-Wesley, 2003.
• J. Martin. Rapid Application Development, Macmillan, 1991.
• Agile Business Consortium. DSDM Project Framework.
• P. Kruchten. The Rational Unified Process: An Introduction, 3rd ed., 2003.
• P. Kruchten. Architectural Blueprints — The 4+1 View Model, IEEE Software, 1995.
• A. Cockburn. Incremental versus iterative development.
• T. Gilb. Principles of Software Engineering Management, Addison-Wesley, 1988.
• OMG. Essence — Kernel and Language for Software Engineering Methods.
• J. L. Eveleens, C. Verhoef. The Rise and Fall of the Chaos Report Figures, IEEE Software, 2010.

Что дальше

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

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