Эмпиризм и метрики: velocity, burndown и как ими злоупотребляют

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

Ирония в том, что ни velocity, ни burndown, ни стори-поинты в Scrum Guide не упоминаются вообще. Ни одного раза. Это не оговорка составителей и не устаревание текста — это осознанное решение 2020 года. При этом Scrum целиком построен на измерении: без эмпирических данных инспекция превращается в обмен мнениями.

Эта статья про то, как удержать оба тезиса одновременно: измерять обязательно, но измерять не то и не для того — хуже, чем не измерять вовсе. Мы разберём, что такое эмпиризм как механика управления, откуда взялись velocity и burndown, какие у них законные применения, какими способами их ломают, и что Scrum-мастер предлагает взамен, когда сверху приходит запрос «дайте цифру».

Предыдущие статьи трека дали контекст: https://courses.digitable.life/post/scrum-master/04-events/ описал события как точки инспекции, https://courses.digitable.life/post/scrum-master/05-artifacts/ — артефакты и обязательства, https://courses.digitable.life/post/scrum-master/06-product-backlog/ — оценку и декомпозицию. Здесь мы смотрим, что именно течёт по этим петлям обратной связи.

Эмпиризм — это не философия, это теория управления

Что написано в Scrum Guide. Scrum основан на эмпиризме и бережливом мышлении. Эмпиризм утверждает, что знание берётся из опыта, а решения принимаются на основе наблюдаемого. Scrum использует итеративный, инкрементальный подход для оптимизации предсказуемости и управления риском. Три опоры эмпиризма: прозрачность, инспекция, адаптация.

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

• прозрачность — качество сигнала на входе измерителя;
• инспекция — само измерение и сравнение с целью;
• адаптация — управляющее воздействие.

Сломайте любое звено — контур разомкнётся. Причём каждое звено ломается по-своему, и Scrum-мастер должен уметь диагностировать, какое именно.

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

Зачем вообще измерять

Полезное определение из книги Дугласа Хаббарда «How to Measure Anything» (hubbardresearch.com): измерение — это наблюдение, которое уменьшает неопределённость относительно конкретного решения. В этом определении три обязательных элемента, и все три надо назвать до того, как заводить график:

1. Какое решение мы собираемся принять?
2. Какая сейчас неопределённость относительно него?
3. Насколько это наблюдение её уменьшит?

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

Отсюда практическое правило Scrum-мастера: у каждой метрики должен быть назван потребитель и решение. «Velocity — чтобы команда на планировании понимала, сколько брать» — законно. «Velocity — чтобы руководитель на квартальном ревью сравнил команды» — уже нет, и ниже мы разберём почему.

Чего в Scrum Guide нет — и почему это важно для экзамена

Это тот пункт, на котором на PSM I сыпятся уверенные практики с пятилетним опытом.

Редакция 2017 года в разделе «Monitoring Progress Toward Goals» прямо перечисляла проективные практики — burndown, burn-up, cumulative flow — с оговоркой «они не заменяют важности эмпиризма». В 2020 году авторы вычистили из Guide почти все предписания такого рода, сократив документ примерно с 19 до 13 страниц. Актуальный текст: scrumguides.org, сравнение редакций — scrumguides.org/revisions.html.

Почему убрали. Guide намеренно двигали в сторону «минимально достаточного фреймворка», из которого выкинуто всё, что можно превратить в обязательный ритуал. Каждый пример практики в нормативном документе рано или поздно читается как требование: «в Guide написано про burndown — значит, надо вести burndown». Убрав примеры, авторы оставили только обязательство: команда должна делать прогресс прозрачным. Каким инструментом — её дело.

Что из этого следует для экзамена. Формулировки вида «Scrum требует…», «согласно Scrum, команда должна отслеживать velocity», «Scrum-мастер обязан вести burndown» — почти всегда неверные варианты. Правильный ответ обычно звучит скучно: это дополнительная практика, она может быть полезна, но фреймворком не предписана.

Важная зеркальная ошибка: из того, что velocity нет в Guide, не следует, что velocity запрещена или вредна. Guide не запрещает практики — он их не предписывает. Ответ «команде нельзя использовать стори-поинты, потому что их нет в Scrum Guide» на экзамене тоже неверен.

Velocity: что это на самом деле такое

Определение. Velocity — сумма оценок элементов продуктового бэклога, доведённых до состояния «Done» за один спринт. Практика пришла из Extreme Programming, где Кент Бек описывал её как основу «yesterday’s weather»: планируй на следующую итерацию столько же, сколько закрыл в прошлой.

Три свойства, из которых вытекает почти всё остальное.

1. Единица измерения произвольна и локальна. Стори-поинт — это не час и не «сложность вообще». Это единица относительного сравнения внутри одной команды, откалиброванная по её собственному эталону. У команды A «тройка» — это два дня работы двух человек в их легаси-монолите; у команды B «тройка» — полдня в свежем сервисе. Числа совпадают, за ними нет ничего общего.

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

3. Velocity — величина с разбросом. Одно число — это не velocity, это последнее наблюдение. Осмысленное представление — распределение за последние 6–12 спринтов: минимум, медиана, максимум.

# Velocity как диапазон, а не как точка.
# Вход: закрытые за спринт поинты (только элементы, доведённые до Done).

history = [23, 31, 18, 27, 29, 21, 34, 26]

def velocity_range(history: list[int]) -> dict[str, float]:
    """Диапазонный прогноз ёмкости вместо обманчивого среднего."""
    if not history:
        raise ValueError("нужна история хотя бы за один спринт")
    ordered = sorted(history)
    n = len(ordered)
    return {
        "пессимистично": ordered[0],                 # худший наблюдавшийся спринт
        "медиана":       ordered[n // 2],
        "оптимистично":  ordered[-1],
        "среднее":       sum(ordered) / n,           # само по себе почти бесполезно
    }

print(velocity_range(history))
# {'пессимистично': 18, 'медиана': 27, 'оптимистично': 34, 'среднее': 26.125}

Сложность: O(n log n) по времени из-за сортировки, O(n) по памяти — на реальных объёмах (десятки спринтов) это неважно, важна интерпретация. Разница между 18 и 34 — это не «нестабильность команды», которую надо чинить. Это честная ширина неопределённости. План, построенный на среднем 26, промахнётся примерно в половине случаев — и ровно эту половину промахов потом называют «команда не выполнила обязательства».

Единственное законное применение velocity

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

Всё остальное — производные степени сомнительности:

Как метрика перестаёт работать: закон Гудхарта в живой природе

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

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

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

Численный пример без всякой математики. Команда за квартал «выросла» с 25 до 40 поинтов. Разбираем:

Velocity выросла на 60%. Количество доведённых до Done элементов не изменилось. Выросла только средняя оценка элемента — то есть единица измерения сжалась. Это не рост производительности, это инфляция валюты, которую команда сама печатает. И заметить её можно только потому, что мы посмотрели на вторую метрику — счётчик элементов.

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

Burndown: что он может и чего не может

Sprint burndown — график остатка работы по дням спринта. Идея честная и старая: сделать динамику остатка видимой команде, чтобы она сама заметила, что не успевает, и что-то предприняла внутри спринта, а не в последний день.

Что burndown делает хорошо:

• показывает форму процесса — где были плато, где обвалы;
• делает видимым расхождение между планом и фактом достаточно рано;
• даёт материал для вопроса «что произошло между вторником и четвергом?».

Чего burndown не делает и не может:

• не показывает ценность — только объём работы;
• не показывает изменение объёма — добавленный в спринт объём выглядит как «команда стала медленнее»;
• не показывает качество — можно идеально сжечь остаток и получить инкремент, который нельзя выпустить;
• не показывает готовность к цели спринта — можно закрыть 90% элементов и не достичь цели, и наоборот.

Последний пункт — самый важный и любимый экзаменом. Прогресс в Scrum измеряется приближением к цели спринта и цели продукта, а не процентом сожжённых поинтов.

Читать эти формы Scrum-мастер должен как врач — кардиограмму: не как оценку, а как повод задать точный вопрос.

• Обрыв (A). Классический мини-водопад внутри спринта: разработка всю неделю, тестирование и интеграция в конце. Вопрос на ретро: «что мешает нам доводить элементы до Done по одному, а не пачкой?» Обычно ответ — крупные элементы, отдельная фаза тестирования или зависимость от внешней команды. Подробно разберём в https://courses.digitable.life/post/scrum-master/10-antipatterns/.
• Идеальная прямая (B). Реальная разработка так не выглядит. Ровная линия почти всегда означает, что остаток «подгоняют»: списывают часы по плану, а не по факту. Это отказ прозрачности — самый опасный из четырёх случаев, потому что данные выглядят прекрасно.
• Ступеньки (C). Норма. Работа закрывается порциями, есть плато. Плато — это вопрос «что застряло?», а не «кто отстаёт?».
• Рост линии (D). В спринт добавляют объём или всплывает скрытая работа. Burndown это скрывает: остаток растёт, и график выглядит как деградация команды. Лечится переходом на burn-up — там линия сделанного и линия общего объёма нарисованы отдельно, и рост объёма виден как рост объёма.

Sprint burndown, release burn-up и кто чем владеет

Что говорит Scrum Guide. Бэклог спринта — это план, составленный Developers, для Developers, и это «высоко видимая картина работы в реальном времени». Отсюда однозначный вывод, который любят проверять на экзамене: отслеживание оставшейся работы — ответственность Developers, а не Scrum-мастера и не Product Owner.

Как делают на практике. Scrum-мастер часто помогает поставить инструмент, объясняет, как читать график, иногда первые спринты обновляет доску вместе с командой. Это нормально как временная помощь.

Как делать не стоит. Scrum-мастер ведёт burndown сам и отчитывается по нему перед менеджментом. Здесь происходит сразу три подмены: команда теряет свой инструмент, Scrum-мастер становится администратором отчётности, а график превращается в оценку команды снаружи.

Это и есть работа Scrum-мастера с метриками: не отказать («мы не даём цифры»), не подчиниться («вот таблица»), а вернуть разговор к решению, ради которого цифра запрашивалась, и предложить данные, которые действительно на него отвечают. Отказ без альтернативы читается как саботаж и стоит Scrum-мастеру доверия — про работу с сопротивлением подробнее в https://courses.digitable.life/post/scrum-master/08-coaching-and-conflicts/.

Прогноз без velocity: считаем на элементах

Если velocity так хрупка, чем прогнозировать? Ответ, проверенный практикой и статистикой: считать элементы, а не поинты, и прогнозировать вероятностно.

Идея, популяризованная Даниэлем Ваканти в «Actionable Agile Metrics for Predictability» и Васко Дуарте в движении #NoEstimates: количество закрытых за спринт элементов (throughput) прогнозирует почти так же хорошо, как сумма оценок, — потому что размеры элементов внутри одной команды распределены довольно стабильно, а ошибки оценки взаимно гасятся. Зато throughput нельзя раздуть: элемент либо доведён до Done, либо нет.

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

import random

def forecast_sprints(throughput_history: list[int],
                     backlog_size: int,
                     runs: int = 10_000) -> dict[str, int]:
    """Сколько спринтов нужно, чтобы закрыть backlog_size элементов.

    throughput_history — сколько элементов доводили до Done в прошлых спринтах.
    Возвращает перцентили: P50 — «в половине случаев уложимся»,
    P85 — граница, которую разумно называть заказчику.
    """
    if not throughput_history or max(throughput_history) <= 0:
        raise ValueError("нужна история с хотя бы одним ненулевым спринтом")

    results = []
    for _ in range(runs):
        remaining, sprints = backlog_size, 0
        while remaining > 0:
            remaining -= random.choice(throughput_history)
            sprints += 1
        results.append(sprints)

    results.sort()
    pick = lambda p: results[min(int(runs * p), runs - 1)]
    return {"P50": pick(0.50), "P85": pick(0.85), "P95": pick(0.95)}


history = [6, 9, 4, 7, 8, 5, 10, 6]     # элементов в Done за спринт
print(forecast_sprints(history, backlog_size=60))
# примерно {'P50': 9, 'P85': 11, 'P95': 12}

Сложность: O(runs × k) по времени, где k — среднее число спринтов в одном розыгрыше, плюс O(runs log runs) на сортировку; память O(runs). Десять тысяч прогонов считаются за доли секунды.

Ценность здесь не в коде, а в форме ответа. «Девять спринтов» — обещание, которое будет нарушено примерно в половине случаев. «С вероятностью 85% уложимся в одиннадцать спринтов» — честное утверждение, которое к тому же ведёт к нормальному разговору: «а если нужно к восьмому — что вынимаем из объёма?»

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

Подробный разбор техник оценки и планирования — в https://courses.digitable.life/post/project-management/03-estimation-and-planning/, потоковые метрики и CFD — в https://courses.digitable.life/post/project-management/02-kanban-and-flow/.

Метрики потока: что смотреть вместо velocity

Velocity отвечает на вопрос «сколько влезает в спринт». Метрики потока отвечают на вопрос «где мы теряем время», а это почти всегда полезнее.

Самая недооценённая из них — work item age. Cycle time — метрика посмертная: она сообщает про уже закрытые элементы, когда что-то менять поздно. Age — метрика живая: элемент висит 9 дней при обычной медиане 4, и это повод для разговора прямо на сегодняшнем дейли. Это ровно тот сдвиг от отчётности к управлению, ради которого метрики вообще нужны.

Между этими величинами есть жёсткая связь — закон Литтла: WIP = Throughput × Cycle Time. Практический вывод из него сильнее, чем кажется: при фиксированной пропускной способности сокращение незавершённой работы напрямую сокращает время цикла. Хотите быстрее — не «работайте усерднее», а начинайте меньше одновременно. Это одно из самых конвертируемых наблюдений, которые Scrum-мастер может принести команде.

Инженерные метрики поставки (DORA: lead time for changes, deployment frequency, change failure rate, time to restore) разобраны отдельно в https://courses.digitable.life/post/project-management/07-dora-and-engineering-metrics/ — они дополняют картину со стороны «как быстро изменение доезжает до пользователя», и для Scrum-мастера это часто самый убедительный набор данных в разговоре с инженерным руководством.

Evidence-Based Management: официальный ответ Scrum.org

У Scrum.org есть отдельный документ на эту тему — Evidence-Based Management Guide. Для PSM I он не входит в обязательный минимум, но задаёт правильную рамку и иногда всплывает в вопросах про измерение ценности.

EBM предлагает измерять не работу команды, а состояние продукта и организации через четыре области ценности (Key Value Areas).

Сила этой рамки — в её напряжениях. Четыре области нарочно тянут в разные стороны, и решения рождаются из выбора между ними:

• Высокий UV при плохом T2M — ценность на рынке есть, но мы не успеем её забрать; вкладываться надо в скорость доставки, а не в новые фичи.
• Хороший CV при низком A2I — продукт работает, но команда захлёбывается в легаси; через год конкурент обгонит, а мы даже не сможем ответить.
• Рост T2M без внимания к CV — научились быстро выкатывать то, что никому не нужно.

Обратите внимание: ни одна из четырёх областей не измеряет, сколько задач сделала команда. Это и есть содержательный ответ на вопрос «а что вместо velocity»: вместо метрики усилия — метрики состояния. Про продуктовые метрики и работу с ними подробнее в https://courses.digitable.life/post/product-management/02-metrics/.

Куда метрики попадают на карте: чем платим за наблюдаемость

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

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

Три сценария и что делает Scrum-мастер

Сценарий 1. «Поднимите velocity на 20% к концу квартала»

Директор по разработке ставит трём командам цель по velocity и привязывает её к квартальной оценке.

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

Что делает Scrum-мастер. Не спорит про Scrum Guide — это проиграет. Разбирает механику: показывает на данных своей команды, что стори-поинт — субъективная шкала, которую сама команда и назначает, и предъявляет расчёт из таблицы выше (velocity выросла, число элементов не изменилось). Затем переводит разговор: «Какую бизнес-проблему решает +20%? Если хотите быстрее выпускать — давайте измерим время от готовности элемента до продакшена, там сейчас семь дней ожидания, и это не про скорость программирования».

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

Сценарий 2. «Мы не успеваем, давайте закроем задачи наполовину»

Четверг двухнедельного спринта, burndown почти плоский. На дейли кто-то предлагает отметить три элемента как Done с оговоркой «тесты допишем в следующем спринте».

Что здесь на самом деле сломалось. Не burndown. Сломался Definition of Done, а вслед за ним — прозрачность инкремента. Если это пройдёт один раз, оно станет нормой: график будет красивым, а недоделанная работа накопится в невидимый долг, который всплывёт на релизе.

Что делает Scrum-мастер. Напоминает, что DoD — обязательство инкремента, а не пожелание, и что незаконченная работа возвращается в продуктовый бэклог и переоценивается. И сразу переводит фокус на настоящий вопрос: достижима ли цель спринта? Если да — какие элементы можно вынуть, чтобы её достичь; это разговор Developers с Product Owner, и он абсолютно легитимен внутри спринта. Если нет — Product Owner имеет право отменить спринт, хотя на практике чаще доводят до конца и разбирают на ретроспективе.

Формулировка, которая работает на дейли. Не «так нельзя по Scrum Guide», а «если мы отметим это как Done, что мы сможем показать на обзоре и что произойдёт с этим кодом через три спринта?»

Сценарий 3. «У команды B velocity 45, а у вас 22»

Product Owner на встрече портфеля сравнивает две команды.

Что делает Scrum-мастер. Объясняет несопоставимость шкал одним примером, а не лекцией: «У них тройка — это день работы, у нас — три дня, потому что мы работаем в модуле биллинга. Их 45 и наши 22 — это как сравнить 45 фунтов с 22 килограммами». Затем предлагает сопоставимую величину: сколько элементов дошло до пользователей, за какое время, сколько из них потребовали доработки после релиза.

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

Вопросы в формате PSM I

1. Что Scrum Guide говорит об отслеживании velocity?

A. Velocity должна отслеживаться каждый спринт и предъявляться на обзоре. B. Velocity — обязательство Developers наряду с целью спринта. C. Scrum Guide не упоминает velocity; это дополнительная практика. D. Velocity отслеживает Scrum-мастер и передаёт менеджменту.

Ответ: C. Слова «velocity» в Guide нет. Guide требует прозрачности прогресса, но не предписывает инструмент. B неверен ещё и потому, что обязательства в Guide — это цель продукта, цель спринта и Definition of Done; velocity к ним не относится. D добавляет вторую ошибку: Scrum-мастер не является каналом отчётности о команде.

2. Кто отвечает за отслеживание оставшейся работы в бэклоге спринта?

A. Scrum-мастер. B. Developers. C. Product Owner. D. Менеджер проекта.

Ответ: B. Бэклог спринта принадлежит Developers, это их план, и они отвечают за его прозрачность. Scrum-мастер может научить пользоваться инструментом, но не ведёт учёт за команду. D — в Scrum такой ответственности вообще нет.

3. Через три дня после начала спринта Developers понимают, что взяли слишком много работы. Что им следует сделать?

A. Продлить спринт на несколько дней. B. Как можно скорее обсудить объём работ с Product Owner и пересмотреть бэклог спринта, сохранив цель спринта. C. Работать сверхурочно, чтобы выполнить обязательства. D. Сообщить Scrum-мастеру, чтобы он согласовал перенос с руководством.

Ответ: B. Guide прямо говорит: объём работ может уточняться и пересматриваться с Product Owner по мере получения новых знаний. Длительность спринта фиксирована — A исключено. Бэклог спринта — это прогноз, а не контракт; обязательством является цель спринта, а не список элементов. Кстати, историческая деталь: в редакции 2011 года слово «commitment» применительно к бэклогу спринта заменили на «forecast» именно из-за этой путаницы.

4. Инкремент готов, но Product Owner считает, что цель спринта не достигнута. Что происходит?

A. Спринт продлевается до достижения цели. B. Незаконченные элементы автоматически переходят в следующий спринт. C. Спринт завершается в срок; незавершённая работа возвращается в продуктовый бэклог и переоценивается. D. Ретроспектива отменяется, так как обсуждать нечего.

Ответ: C. Спринт заканчивается по таймбоксу независимо от результата. Незавершённые элементы возвращаются в продуктовый бэклог — не «автоматически переезжают», потому что Product Owner может решить, что они больше не нужны, а Developers — что оценка изменилась. Именно этот нюанс отличает B от C. Ретроспектива в такой ситуации не отменяется, а становится особенно нужной.

5. Организация хочет измерить эффективность Scrum-команды. Что лучше всего подходит?

A. Velocity в сравнении с другими командами. B. Процент выполнения плана спринта. C. Ценность, полученная пользователями от выпущенных инкрементов. D. Количество часов, отработанных командой.

Ответ: C. Единственный вариант, измеряющий результат, а не активность. A несостоятелен из-за несопоставимости шкал, B поощряет заниженные планы, D измеряет присутствие. Общий приём для экзамена: среди вариантов выбирайте тот, что ближе к ценности для пользователя, а не к загрузке команды.

6. Как Scrum-мастер должен поступить, если менеджмент требует еженедельный отчёт о загрузке каждого разработчика?

A. Отказаться, сославшись на то, что этого нет в Scrum Guide. B. Настроить сбор данных и предоставлять отчёт. C. Выяснить, какое решение стоит за запросом, и предложить данные о работе команды и потоке, которые на него отвечают. D. Передать запрос Product Owner.

Ответ: C. Scrum-мастер служит организации, помогая ей понимать эмпирический подход. Это означает не отказ (A — формализм, который ничего не решает и подрывает доверие) и не капитуляцию (B — метрика по индивидам разрушает командную ответственность и провоцирует локальную оптимизацию). Работа состоит в том, чтобы вскрыть реальную потребность и предложить работающую альтернативу.

Чек-лист гигиены метрик

Перед тем как завести любой новый график, прогоните шесть вопросов:

1. Какое решение эта метрика обслуживает? Если ответа нет — не заводите.
2. Кто потребитель? Если данные о команде уходят наверх без её участия — это отчётность, готовьтесь к искажениям.
3. Кто может на неё повлиять, не меняя реальность? Назовите конкретный способ. Если он дешёвый — метрика умрёт.
4. Какая парная метрика страхует от перекоса? Скорость — качеством, объём — ценностью, загрузка — временем цикла.
5. Это метрика активности или результата? Активность допустима только внутри команды.
6. Когда мы её выключим? У метрики должен быть срок жизни. Метрика, поставленная под конкретную проблему, после её решения превращается в ритуал.

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

Мини-итог

• Эмпиризм — это контур обратной связи: прозрачность (качество сигнала), инспекция (измерение), адаптация (воздействие). Метрики живут в инспекции и бесполезны, если сломана прозрачность или отсутствует право на адаптацию.
• Velocity, burndown, стори-поинты в Scrum Guide не упоминаются — ни в положительном, ни в отрицательном смысле. Это практики. Для PSM I: «Scrum требует velocity» — неверно, «Scrum запрещает velocity» — тоже неверно.
• Единственный законный потребитель velocity — сама команда, единственное решение — сколько взять в спринт. Всё остальное запускает закон Гудхарта.
• Инфляция стори-поинтов происходит без злого умысла: субъективная шкала сдвигается туда, где не наказывают. Ловится парной метрикой — числом доведённых до Done элементов.
• Burndown надо читать по форме, а не по последней точке. Обрыв — мини-водопад, идеальная прямая — подгонка данных, рост линии — изменение объёма, которое burn-up показал бы честнее.
• Прогресс в Scrum — это приближение к цели спринта и цели продукта, а не процент сожжённых поинтов. Отслеживание остатка — ответственность Developers.
• Замена velocity — не другая метрика скорости, а метрики потока и ценности: время цикла, возраст элемента, throughput с вероятностным прогнозом, четыре области EBM.
• Роль Scrum-мастера при запросе метрик — ни отказ, ни капитуляция, а вскрытие решения, стоящего за запросом, и предложение данных, которые на него действительно отвечают.

Источники

• Scrum Guide 2020 и история редакций — что убрали в 2020 и почему.
• Evidence-Based Management Guide, Scrum.org — четыре области ценности.
• Daniel Vacanti. Actionable Agile Metrics for Predictability — метрики потока, закон Литтла, Монте-Карло. См. также actionableagile.com.
• Douglas Hubbard. How to Measure Anything — измерение как снижение неопределённости решения: hubbardresearch.com.
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate — метрики DORA и почему они устойчивы к искажению: dora.dev.
• Martin Fowler. CannotMeasureProductivity — почему продуктивность разработки в принципе не измеряется напрямую.

Что дальше

Мы разобрали, как ломаются измерения. Следующий шаг — каталог того, как ломается сам Scrum: команды, где все события на месте, но эмпиризма нет ни грамма.

Антипаттерны Scrum: карго-культ, зомби-скрам, мини-водопад