Agile и Scrum: ценности, роли, церемонии, честная критика

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

Читать стоит подряд с обзором трека — там карта того, как темы связаны между собой.

1. Зачем вообще итерации: проблема, а не мода

Стоимость информации

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

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

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

Рисунок выше — самая полезная модель для понимания всего остального. Каждая церемония Scrum — это гарантия, что петля определённого масштаба замкнётся не позже определённого срока. Daily закрывает суточную петлю, Review — спринтовую, Retro — процессную. Если петля не замыкается, ошибка живёт дольше и обходится дороже — цена растёт не линейно, а примерно экспоненциально с возрастом ошибки, потому что на неверном фундаменте успевают построить следующий слой.

Инверсия «железного треугольника»

Классический менеджмент фиксирует объём и торгуется сроком и бюджетом. Проблема в том, что срок и бюджет — это то, о чём бизнес договаривается с внешним миром (маркетинг, контракты, конкуренты), а объём — самая мягкая из трёх переменных, потому что 80% ценности обычно лежит в 20% скоупа.

Agile-подход фиксирует дату и состав команды, а объём делает переменной. Качество при этом не переменная: в устойчивом процессе оно константа, зафиксированная в Definition of Done (подробно — в статье Качество, Definition of Done и релизный менеджмент). Как только качество становится переменной торга, вы берёте кредит под очень высокий процент — технический долг, — и следующие спринты уходят на его обслуживание.

2. Краткая, но честная история

Два вывода из этой хронологии. Первый: итеративность старше Agile на десятилетия — Крэг Ларман и Виктор Басили в обзоре «Iterative and Incremental Development: A Brief History» (IEEE Computer, 2003) показывают итеративные проекты вплоть до 1950-х. Второй: Манифест 2001 года был не изобретением, а обобщением уже работавших практик (Scrum, XP, Crystal, FDD, DSDM) — и это важно, потому что практики появились раньше идеологии, а не наоборот.

Оригинальные источники, которые стоит прочитать целиком (они короткие):

• agilemanifesto.org — 4 ценности и 12 принципов, суммарно одна страница;
• Scrum Guide 2020 — 13 страниц, русский перевод;
• Takeuchi H., Nonaka I. The New New Product Development Game, HBR, 1986.

3. Манифест: что там написано на самом деле

Четыре ценности сформулированы как сравнения, и главное в них — вторая часть, которую обычно забывают:

Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

Из 12 принципов инженерно значимы прежде всего эти:

Обратите внимание: в Манифесте нет ни слова про Scrum, спринты, story points и стендапы. Всё это — конкретные реализации, а не сам Agile.

4. Когда итеративность оправдана: сложность против неопределённости

Не всякая работа выигрывает от Scrum. Полезная эвристика — матрица Стейси (с оговоркой: сам Ральф Стейси публично возражал против того, как её применяют в Agile-тренингах, — его работа была про динамику организаций, а не про выбор фреймворка).

Практические выводы:

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

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

5. Scrum по букве гайда: три роли, пять событий, три артефакта

Scrum Guide 2020 намеренно минималистичен: он определяет каркас и обязательно оставляет пустоты, которые команда заполняет сама. Практики (TDD, CI, парное программирование, оценка) в гайде отсутствуют — это не забывчивость, а дизайн-решение, и одновременно главная уязвимость фреймворка (см. раздел 9).

Три ответственности (accountabilities)

Product Owner — одна личность, не комитет. Его единственная реальная власть: порядок элементов в Product Backlog. Всё остальное — производное. Типичный провал: PO-«диспетчер», который передаёт требования от стейкхолдеров без права сказать «нет». Признак здорового PO — он регулярно отказывает влиятельным людям, и организация это поддерживает. Про то, как PO выбирает порядок, — трек Product Management.

Developers — все, кто создаёт инкремент: программисты, тестировщики, аналитики, дизайнеры. Гайд намеренно избегает специализаций, потому что фиксированные роли создают очереди и локальные оптимумы. Ответственность коллективная: «я свою часть сделал» — не результат, пока инкремент не соответствует DoD.

Scrum Master — не администратор встреч и не «начальник команды». В гайде это true leader who serves: отвечает за эффективность Scrum в организации. Практический тест: если Scrum Master уходит в отпуск на месяц и процесс не разваливается — он работал правильно; если разваливается, он был диспетчером задач.

Пять событий и их таймбоксы

Официальные таймбоксы для месячного спринта: Planning ≤ 8 ч, Daily = 15 мин, Review ≤ 4 ч, Retro ≤ 3 ч; для более коротких спринтов — пропорционально меньше. Сам Sprint — тоже событие и контейнер для остальных: он не может быть длиннее месяца и не имеет пауз между итерациями.

Суммарно для двухнедельного спринта: ~4 + 2,5 (дейли) + 2 + 1,5 + ~4 (рефайнмент) ≈ 14 часов на человека из ~72 рабочих. Это около 19% времени — самая частая претензия к Scrum. Честный ответ: часть этих обсуждений произошла бы всё равно, но в неструктурированном виде и с худшим охватом; при этом 19% — это верхняя граница таймбоксов, а не норма.

Взаимодействие ролей за спринт

Три вещи, которые ломают эту схему чаще всего:

1. Daily как отчёт менеджеру. Три вопроса («что делал / что буду / что мешает») в гайде 2020 убраны специально — они превращали инспекцию цели в перекличку. Правильный фокус: «мы всё ещё дойдём до Sprint Goal? если нет — что меняем сегодня?».
2. Review как презентация. Review — рабочая сессия с реальными пользователями и заинтересованными лицами, где решают, что делать дальше. Слайды вместо работающего софта — надёжный симптом, что инкремента нет.
3. Retro без последствий. Если улучшения не попадают в бэклог спринта с владельцем и сроком, ретро за 3–4 итерации превращается в ритуальную жалобу.

Жизненный цикл элемента бэклога

Два состояния из этой схемы дают больше всего пользы при измерении:

• Заблокирован — время в блокировке почти всегда доминирует над временем в работе. Если вы измеряете только «сколько программист программировал», вы оптимизируете 20% времени задачи.
• Не влез, возвращён — доля таких элементов показывает, насколько реалистично планирование. Стабильные 30%+ означают, что команда систематически берёт больше, чем может.

6. Числа: velocity, капасити и вероятностный прогноз

Velocity — измерительный инструмент, а не KPI

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

"""Базовая работа с историей velocity: диапазон вместо одной цифры."""
from statistics import mean, pstdev

# Реальный след команды: story points, доведённые до DoD за спринт
velocity_history = [23, 31, 18, 27, 25, 34, 21, 29, 26, 30, 24, 28]


def velocity_range(history: list[int], window: int = 6) -> dict[str, float]:
    """Оценка ёмкости спринта по последним `window` спринтам.

    Возвращает не одну цифру, а полосу: пессимистичную (min),
    среднюю и оптимистичную (max) — именно так велосити и надо
    предъявлять бизнесу.

    Сложность: O(window) по времени, O(1) дополнительной памяти.
    """
    recent = history[-window:]
    return {
        "min": min(recent),          # консервативное обязательство
        "avg": mean(recent),         # для среднесрочного прогноза
        "max": max(recent),          # оптимистичный предел, не обещание
        "sd": round(pstdev(recent), 1),  # разброс: > 25% от avg — процесс нестабилен
    }


def sprints_to_finish(backlog_points: int, history: list[int]) -> tuple[float, float]:
    """Грубая вилка «за сколько спринтов сделаем оставшийся объём»."""
    r = velocity_range(history)
    return backlog_points / r["max"], backlog_points / r["min"]


stats = velocity_range(velocity_history)
print(stats)   # {'min': 21, 'avg': 26.33, 'max': 30, 'sd': 3.1}
best, worst = sprints_to_finish(180, velocity_history)
print(f"от {best:.1f} до {worst:.1f} спринтов")   # от 6.0 до 8.6 спринтов

Три правила использования velocity, нарушение которых превращает её в яд:

1. Velocity нельзя сравнивать между командами. Story points — локальная валюта; сравнение команд по velocity гарантированно вызывает инфляцию оценок (закон Гудхарта: «мера, ставшая целью, перестаёт быть мерой»).
2. Velocity не является целью. Её нельзя «повышать» — можно только повышать поток ценности, а velocity лишь отразит это (или не отразит).
3. Незавершённая работа даёт 0 очков. Частичный кредит убивает смысл метрики и маскирует хронический перебор объёма.

Подробно про природу оценок, PERT и #NoEstimates — в статье Оценка и планирование.

Капасити спринта: считаем честно

"""Расчёт доступной ёмкости спринта в человеко-днях."""
from dataclasses import dataclass, field


@dataclass
class Member:
    name: str
    days_off: int = 0            # отпуск, обучение, праздники
    focus_factor: float = 0.7    # доля времени на работу спринта


@dataclass
class SprintCapacity:
    working_days: int                        # рабочих дней в спринте
    members: list[Member] = field(default_factory=list)
    support_reserve: float = 0.15            # резерв на поддержку/инциденты

    def person_days(self) -> float:
        """Ёмкость с учётом отсутствий, фокус-фактора и резерва.

        focus_factor 0.7 — не «лень», а эмпирика: церемонии, ревью
        чужого кода, помощь коллегам, переключение контекста.
        Значение > 0.8 в командах, живущих в проде, — самообман.
        """
        raw = sum((self.working_days - m.days_off) * m.focus_factor
                  for m in self.members)
        return round(raw * (1 - self.support_reserve), 1)


team = SprintCapacity(
    working_days=10,
    members=[
        Member("Аня"),
        Member("Борис", days_off=3),
        Member("Вера", focus_factor=0.5),   # 50% времени на другой проект
        Member("Глеб"),
    ],
)
print(team.person_days())   # 20.3 человеко-дня вместо наивных 40

Наивный расчёт даёт 40 человеко-дней, честный — около 20. Разрыв в два раза и есть источник большинства «команда опять не успела».

Вероятностный прогноз методом Монте-Карло

Единственная цифра («сделаем к 15 сентября») — это ложь по построению, потому что игнорирует разброс. Правильный ответ бизнесу — распределение: «с вероятностью 85% уложимся в 9 спринтов». Такой прогноз строится симуляцией на исторических данных и не требует оценок вообще, если считать по числу завершённых элементов (throughput).

"""Монте-Карло прогноз: сколько спринтов нужно на остаток бэклога.

Идея: будущее сэмплируем из прошлого. Никаких распределений
не предполагаем — берём эмпирические данные команды.
"""
import random
from collections import Counter

# Throughput: сколько ЭЛЕМЕНТОВ доведено до DoD за спринт (не очков!)
throughput = [7, 5, 9, 6, 8, 4, 7, 10, 6, 7, 5, 8]


def forecast_sprints(
    remaining_items: int,
    throughput: list[int],
    trials: int = 20_000,
    split_rate: float = 1.0,     # 1.3 = бэклог обычно распухает на 30%
    rng: random.Random | None = None,
) -> dict[int, float]:
    """Возвращает {число_спринтов: вероятность_уложиться (CDF)}.

    Сложность: O(trials * E[sprints]) по времени — на практике
    порядка сотен тысяч операций, доли секунды.
    Память: O(уникальных исходов) ≈ O(десятки).
    """
    rng = rng or random.Random(42)
    target = remaining_items * split_rate
    results: Counter[int] = Counter()

    for _ in range(trials):
        done, sprints = 0.0, 0
        while done < target:
            done += rng.choice(throughput)   # сэмплируем реальный спринт
            sprints += 1
            if sprints > 500:                # страховка от вырожденных данных
                break
        results[sprints] += 1

    cdf, cumulative = {}, 0
    for n in sorted(results):
        cumulative += results[n]
        cdf[n] = round(cumulative / trials, 3)
    return cdf


cdf = forecast_sprints(remaining_items=60, throughput=throughput, split_rate=1.25)
for sprints, p in cdf.items():
    if 0.05 <= p <= 0.999:
        print(f"{sprints} спринтов -> {p:.0%} вероятность уложиться")
# 10 спринтов -> 13% вероятность уложиться
# 11 спринтов -> 55% вероятность уложиться
# 12 спринтов -> 91% вероятность уложиться   <- обещаем эту дату
# 13 спринтов -> 99% вероятность уложиться

Что здесь важно:

• split_rate моделирует то, что бэклог растёт: крупные элементы при уточнении дробятся на несколько. Историческое соотношение «элементов стало / элементов было» — реальный измеримый коэффициент, у большинства команд 1,2–1,6.
• Прогноз даёт сервис-уровень: обещайте бизнесу 85-й перцентиль, а не медиану. Обещание по медиане проваливается в половине случаев по построению.
• Метод не требует story points вообще — он работает на счётчике задач, что резко дешевле. Первоисточник подхода — Troy Magennis, Focused Objective, и книга Daniel Vacanti «Actionable Agile Metrics for Predictability».

Псевдокод той же идеи, чтобы отделить суть от Python:

ВХОД: остаток_элементов R, история пропускной способности T[1..n], число прогонов K
ДЛЯ k = 1..K:
    сделано ← 0; спринтов ← 0
    ПОКА сделано < R:
        сделано ← сделано + СЛУЧАЙНЫЙ_ЭЛЕМЕНТ(T)     # bootstrap-сэмплирование
        спринтов ← спринтов + 1
    ЗАПОМНИТЬ(спринтов)
ВЫХОД: эмпирические перцентили запомненных значений (50%, 85%, 95%)

Definition of Done как исполняемый контракт

DoD полезно хранить не в вики, а рядом с кодом — и по возможности проверять автоматически.

# .github/definition-of-done.yml — контракт команды, ревьюится как код
version: 2
applies_to: "все элементы Product Backlog"

automated:              # проверяется CI, человек не участвует
  - id: unit-tests
    rule: "все тесты зелёные, покрытие изменённых строк >= 80%"
  - id: static-analysis
    rule: "линтер и типы без ошибок, новых critical-issue в SAST нет"
  - id: migrations
    rule: "миграции обратимы и проверены на копии прод-схемы"
  - id: observability
    rule: "новые эндпоинты отдают метрики RED и структурные логи"
  - id: perf-budget
    rule: "p95 ключевых сценариев не деградировал более чем на 5%"

manual:                 # проверяется людьми, фиксируется в PR
  - id: code-review
    rule: "минимум одно одобрение от разработчика вне автора"
  - id: docs
    rule: "публичный API и runbook обновлены"
  - id: feature-flag
    rule: "рискованное поведение под флагом с планом раскатки"
  - id: acceptance
    rule: "PO подтвердил критерии приёмки на стенде"

not_done_examples:      # антипримеры полезнее правил
  - "готово, но не задеплоено"
  - "готово, но тесты отключены"
  - "готово, но включим в следующем релизе вручную"

Ключевое свойство: DoD должен быть одинаков для всех элементов и не понижаться под давлением дедлайна. Понижение DoD ради срока — это перевод переменной «качество» из констант в торгуемые, то есть возврат к waterfall с дополнительными встречами.

7. Что ломается на практике: каталог антипаттернов

Разберём три самых дорогих подробно.

Спринт как мини-водопад. Симптом: диаграмма сгорания — плоская линия, обваливающаяся в последний день. Причина: работа передаётся по эстафете между специализациями, вместо того чтобы делаться сквозными вертикальными срезами. Лечение: ограничить число одновременно взятых элементов (WIP-лимит внутри спринта), декомпозировать по вертикали (тонкая функциональная нарезка через все слои), а не по слоям.

Velocity как KPI. Симптом: velocity растёт три квартала подряд, а поставок и удовлетворённости пользователей не прибавляется. Причина: команда — рациональный агент, она оптимизирует то, что измеряют. Лечение: измерять то, что нельзя раздуть локально — частоту поставки, время цикла, долю отказов изменений, время восстановления (метрики DORA, см. DORA и метрики инженерной эффективности), а также продуктовые результаты.

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

8. Как это выглядит в проде

Несколько наблюдений о том, как Scrum живёт в реальных инженерных организациях, а не в тренинге.

Спринт двухнедельный почти везде — но по инерции. Аргумент за: две недели дают ритм планирования и позволяют защитить фокус. Аргумент против: если вы деплоите в прод несколько раз в день, спринт перестаёт быть единицей поставки и остаётся единицей планирования. Многие зрелые команды приходят к гибриду: поток задач по Kanban + фиксированный ритм ревью/ретро раз в две недели. Это законная эволюция, а не «отказ от Scrum» — Scrum Guide не запрещает ограничивать WIP или деплоить в середине спринта (инкремент можно поставлять в любой момент спринта).

Спринт-цель важнее списка задач. Команды, которые формулируют одну связную цель («пользователь может оплатить корзину картой»), заметно устойчивее к внешним вбросам: у них есть основание сказать «это не приближает цель, кладём в бэклог». Команды со списком из 14 несвязанных тикетов такого основания не имеют, и любой вброс проходит.

Рефайнмент — самая недооценённая практика. Планирование, которое затягивается на 4 часа со спорами о смысле требований, — это всегда следствие отсутствия рефайнмента. Дешёвое правило: элемент не берут в спринт, если по нему нет ответа на три вопроса — зачем это пользователю, как проверим, что сделано, какие есть неизвестные. Это и есть Definition of Ready (в гайде его нет, но на практике он окупается).

Дежурство спасает предсказуемость. Один человек в спринте вне спринтового объёма принимает всё внешнее: инциденты, вопросы поддержки, срочные баги. Ротация по спринтам. Без такого клапана прод-нагрузка размазывается по всем и делает капасити невычислимым.

Скрам не отменяет инженерных практик — он их требует. Мартин Фаулер описал это как Flaccid Scrum: команда берёт церемонии, не берёт технические практики XP (TDD, рефакторинг, непрерывная интеграция, простой дизайн), первые спринты идут быстро, затем скорость падает под грузом накопленного долга — и вина сваливается на Scrum. Это самый распространённый сценарий провала.

Распределённые команды. Daily в 15 минут по видеосвязи работает, если у команды есть общий рабочий контекст (доска, канал, договорённость об асинхронных ответах). При разнице часовых поясов больше 4–5 часов синхронные события становятся налогом; работающая замена — асинхронный письменный стендап + одна общая синхронная точка в неделю. Про коммуникацию подробнее — Команда, коммуникации, конфликты и мотивация.

9. Честная критика: где Scrum действительно слаб

Это не раздел «Scrum плохой». Это раздел про границы, которые полезно знать заранее.

1. Фреймворк молчит про инженерию. Scrum Guide не содержит ни одной инженерной практики. Формально — потому что «Scrum — фреймворк, а не методология». Фактически — это перекладывание самой сложной части на команду, которая часто не знает, что именно ей нужно. XP, у которого практики есть, оказался куда менее коммерчески успешен, потому что его сложнее продать менеджменту: он требует изменений в способе писать код, а не только в расписании встреч.

2. Слабая доказательная база. Прямых рандомизированных исследований «Scrum vs не-Scrum» практически нет; отраслевые отчёты вроде State of Agile — самоотчёты с очевидной систематической ошибкой. Знаменитая статистика Standish CHAOS о «в 3 раза выше успех у Agile» подвергнута обстоятельной критике за методологию: см. работы Магне Йоргенсена (например, «Do Agile Methods Work for Large Software Projects?», а также его разборы отчётов CHAOS, simula.no). Аккуратная формулировка: итеративная поставка малыми партиями имеет прочное теоретическое и эмпирическое обоснование (теория очередей, DORA-исследования в «Accelerate»), а конкретный ритуальный набор Scrum — существенно слабее обоснован.

3. Сертификационная индустрия. Двухдневный CSM-курс, выдающий «мастера», — источник значительной части плохого Scrum. Мартин Фаулер называет это Agile Industrial Complex: методология, навязанная сверху и лишённая права команды выбирать свой процесс, противоречит первому принципу Манифеста. Дэйв Томас, один из подписантов, в докладе «Agile is Dead» предлагал вообще отказаться от слова «Agile» как существительного и оставить прилагательное «agile» — качество, а не продукт.

4. Оценки как театр. Story points задумывались как относительная мера сложности для внутреннего прогноза. На практике их регулярно конвертируют в часы, требуют «стабильности» и используют для сравнения команд. Рон Джеффрис, соавтор XP, написал «Developers Should Abandon Agile» именно про то, во что превратилось внедрение процессов сверху.

5. Плохая пригодность для потоковой и реактивной работы. Поддержка, платформенные команды, SRE, инфраструктура — там, где входящий поток непредсказуем, спринтовое обязательство создаёт ложную предсказуемость и постоянный стресс. Kanban с явными классами обслуживания честнее.

6. Масштабирование. Scrum спроектирован для одной команды 3–9 человек. Всё, что происходит при масштабировании, гайдом не покрывается, а фреймворки поверх (SAFe, LeSS, Nexus) — предмет отдельных споров; разбор — в Масштабирование процессов.

Что делать с этой критикой практически. Разумная позиция: относиться к Scrum как к стартовому набору умолчаний. Он даёт работающую отправную точку команде без своего процесса. Дальше команда обязана инспектировать и адаптировать сам процесс — включая право убрать событие, которое не приносит ценности, если сохранены прозрачность, инспекция и адаптация. Команды, которые этого права не имеют, занимаются не Scrum, а его имитацией.

10. Чек-лист диагностики: работает ли у вас Scrum

Пройдитесь по списку — каждый пункт проверяется фактами, а не ощущениями.

• Инкремент в конце спринта можно поставить в прод без дополнительной фазы стабилизации.
• Есть одна формулируемая Sprint Goal, а не только список задач.
• Product Backlog упорядочен одним человеком, и порядок объясним через ценность/риск.
• Команда сама решает, сколько взять в спринт; никто снаружи не «доливает» объём.
• На Review приходят реальные пользователи или их представители, и по итогам меняется бэклог.
• Хотя бы одно улучшение с прошлой ретро закрыто и проверяемо.
• Velocity не фигурирует ни в чьих личных целях и ни в одном сравнении команд.
• DoD включает автоматические проверки и не понижался ни разу за последний квартал.
• Технический долг присутствует в бэклоге как элементы с приоритетом, а не как устные жалобы.
• Незапланированная работа (инциденты, поддержка) измеряется и имеет выделенный клапан.
• Deployment frequency и lead time измеряются и не ухудшаются от спринта к спринту.

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

11. Мини-итог

• Итерации нужны не ради скорости, а ради сокращения петли обратной связи: раньше узнать об ошибке дешевле, чем быстрее её сделать.
• Манифест — про приоритеты в условиях выбора, а не про отрицание правой части сравнений.
• Scrum — минимальный каркас: три ответственности, пять событий, три артефакта, три обязательства (Product Goal, Sprint Goal, Definition of Done). Всё остальное команда добавляет сама.
• Эмпирический контроль стоит на прозрачности, инспекции и адаптации; выньте один столп — рухнут остальные.
• Velocity — случайная величина для прогноза, а не показатель эффективности. Прогнозировать корректнее методом Монте-Карло на throughput и обещать 85-й перцентиль.
• Scrum без инженерных практик деградирует предсказуемо — это Flaccid Scrum, самый частый сценарий провала.
• Критика Scrum по большей части справедлива и относится к внедрению сверху и сертификационной индустрии, а не к идее коротких петель. Границы применимости — знать заранее.

Источники

• Agile Manifesto и 12 принципов
• The Scrum Guide 2020, Ken Schwaber, Jeff Sutherland
• Takeuchi H., Nonaka I. The New New Product Development Game, Harvard Business Review, 1986
• Larman C., Basili V. Iterative and Incremental Development: A Brief History, IEEE Computer, 2003
• Beck K. «Extreme Programming Explained: Embrace Change», 2nd ed.
• Kniberg H. Scrum and XP from the Trenches — бесплатная книга InfoQ
• Vacanti D. «Actionable Agile Metrics for Predictability» — вероятностное прогнозирование
• Forsgren N., Humble J., Kim G. «Accelerate» — эмпирика по метрикам доставки
• Fowler M. FlaccidScrum, The State of Agile Software in 2018
• Jeffries R. Developers Should Abandon Agile
• Thomas D. Agile is Dead (Long Live Agility)
• Verwijs C., Schartau J., Overeem B. «Zombie Scrum Survival Guide», 2020

Что дальше

Scrum задаёт ритм, но не отвечает на вопрос «почему задача три недели висит в колонке In Progress». На это отвечает управление потоком: WIP-лимиты, время цикла, закон Литтла и диаграммы накопленного потока.

Дальше — Kanban и управление потоком: WIP, cycle time, диаграммы.