Под моей прошлой статьёй (про Scrum, который натягивают на всё подряд) читатель описал ситуацию, от которой у меня знакомо заныло под ложечкой. Пересказываю по памяти и анонимно: «У нас под предлогом адаптации отвалились оценки и демо. Команда называет это гибкостью. И теперь нечем показать бизнесу, что разработка вообще работает».

Если убрать эмоции, это самый частый вопрос, который я слышу после «какой фреймворк выбрать»: чем доказывать, что разработка работает, когда привычную витрину (оценки, графики сгорания, демо) разобрали? Я тогда пообещал в комментариях, что следующая статья будет об этом. Выполняю.

И сразу договоримся на берегу, чтобы не было ложных ожиданий. Это не манифест «долой story points». Скорее наоборот: я story points люблю, пользуюсь ими и на нескольких местах работы сам же их и внедрял. Но люблю я их как инструмент с понятной задачей, а не как подорожник, который прикладывают к любой ране в надежде, что само заживёт. Разговор впереди вообще не про оценки. Он про прозрачность: что видит бизнес, когда смотрит на вашу разработку. И почему «мы стали гибкими» так часто на деле означает «нас теперь не видно».

Прошлая статья была про структуру (как собрать несколько команд вокруг одного продукта), чтобы они не мешали друг другу. Эта — про видимость: что показывать бизнесу вместо театра оценок, чтобы вашему слову верили. Потому что оно сбывается. Всё из практики: департаменты до восьми команд, квартальные обещания, свои шишки. Цифры в примерах иллюстративные: честность мне дороже красивого графика.

Шпаргалка терминов — одна минута, дальше читается легко;
Story points (SP) — «очки сложности»: команда оценивает задачи не в часах, а в условных единицах относительно друг друга;
Velocity — сколько таких очков команда закрывает за спринт;
Throughput — сколько задач за период реально доведено до «готово», в штуках;
Cycle time — сколько дней задача живёт от «взяли в работу» до «готово»;
WIP — сколько задач в работе одновременно;
Work item age — сколько дней уже висит начатая и не законченная задача;
Rework — переделки: возвращаемся к тому, что уже считалось готовым;
Change failure rate — какая доля изменений в проде ломается и требует срочной починки;
Say/do — доля обещанного, что сделано в срок: обещали 10 задач, довезли 8 — say/do 80%;
DoR / DoD — два чек-листа: «задача достаточно ясна, чтобы её брать» и «задача действительно готова, а не почти».

Часть 1. Story points: инструмент, из которого сделали театр

Короткая история одного недоразумения

Story points придумали в среде экстремального программирования с очень практичной целью: быстро прикидывать объём работы, не увязая в человеко-часах, которые всё равно врут. Идея простая: не «сколько часов займёт», а «насколько эта задача больше вон той». Внутренняя, условная мера — для команды и только для неё!

Дальше произошло то, что происходит с любой удобной цифрой: её вынесли из команды наружу. Story points стали валютой отчётности. Velocity — «производительностью». А сравнение команд по очкам — любимым видом спорта менеджмента среднего звена (а порой и высшего 😅).

Финал этой истории лучше всех подвёл Рон Джеффрис — человек, который к изобретению story points причастен напрямую: «I may have invented story points, and if I did, I'm sorry» — «возможно, это я изобрёл story points, и если так — простите». Это не кокетство. Это усталость мастера, чьим инструментом двадцать лет забивают шурупы.

И занятный факт для споров в переговорке: в Scrum Guide 2020 года слов «story points» нет вообще. Ни одного упоминания. Scrum просит прогнозировать работу и сверяться с фактом, а мерить её в очках, штуках или попугаях, авторам безразлично. Так что фраза «мы обязаны оценивать в SP, у нас же Scrum» — чистой воды карго-культ: ритуал соблюдаем, а зачем он был нужен уже не помним.

Почему velocity ломается, как только на неё смотрят сверху

Есть закон Гудхарта, и он в этой теме главный. В короткой формулировке антрополога Мэрилин Стратерн: «когда мера становится целью, она перестаёт быть хорошей мерой». По-простому: как только по цифре начинают судить и награждать, люди перестают улучшать работу и начинают улучшать цифру. С velocity это происходит образцово:

Очки дешевеют. Стоит потребовать «velocity не ниже прошлого спринта» и команда молча ставит задачам оценки пожирнее. Вчерашняя «восьмёрка» становится «тринадцать». Velocity растёт, доставка — нет. Все довольны, кроме продукта.
Очки не сравниваются. Единица оценки у каждой команды своя — так устроена сама идея относительных оценок. Сравнивать velocity двух команд — это как сравнивать 30 градусов Цельсия с 30 градусами Фаренгейта и радоваться, что «одинаково».
Спринты зелёные, релиз стоит. «Закрыть спринт на 100%» превращается в самоцель. В прошлой статье я разбирал, как восемь «успешных» команд дают один буксующий продукт. Это тот же эффект, просто в масштабе одной команды.

При этом у velocity есть одно честное применение: команда против самой себя во времени. Стали ли наши оценки стабильнее за три месяца? Мы систематически обещаем больше, чем делаем, ... или меньше? Это полезный внутренний градусник. Человека тоже можно сравнивать только с ним самим, и то бережно. А вот «velocity на голову» поперёк команд и департаментов — это уже не измерение. Это тренажёр, на котором умные люди учатся рисовать нужную цифру. Я встречал такие требования не раз, и каждый раз через квартал-другой организация получала красивые отчёты и ноль информации.

Но вторая крайность — хуже

Теперь неудобная правда для противоположного лагеря. Выбросить оценки и демо «потому что мы гибкие» и не дать бизнесу ничего взамен — это не адаптация. Это уход от обязательств под флагом адаптации. В прошлой статье я описывал ScrumBut: «у нас Scrum, но…», когда процесс гнут, чтобы спрятать проблему. Здесь то же самое, только наоборот: процесс режут, чтобы спрятать отсутствие ответа.

Бизнес в этот момент не становится «более agile». Он слепнет. А слепой заказчик делает единственное, что умеет слепой заказчик, — начинает щупать руками. Возвращается микроменеджмент, причём уже без правил: внезапные «покажите, чем занята команда», статус-встречи по любому чиху, просьбы «скинуть табличку к вечеру». Доверие, которое копили годами, сгорает за квартал.

Есть, к слову, и радикальный лагерь — #NoEstimates (Васко Дуарте и единомышленники): совсем убрать оценки, считать поток готовых задач и прогнозировать статистикой. К самой технике я отношусь с уважением (ниже покажу, что́ из неё сам беру). Но заметьте важное: #NoEstimates не отменяет обязательств перед бизнесом. Он меняет только форму, в которой эти обязательства выражены. Убрать оценки и убрать прозрачность — две очень разные операции. Их путают постоянно.

Ключевая мысль части: спор «story points или нет» — второстепенный. Главный вопрос — на что бизнес получает ответ. Оценки — лишь одна из возможных форм ответа. Про сам ответ — дальше.

Часть 2. Контракт прозрачности: три вопроса, на которые обязана отвечать доставка

За много лет я ни разу не встретил заказчика, которому были бы нужны story points сами по себе (почти не встречал 😉). Ни одного человека, который ночами мечтал бы об очках. Каждый раз за требованием «дайте оценки» стояли три настоящих вопроса:

«Когда будет?» — чтобы планировать запуск, маркетинг, продажи, обещания клиентам;
«Здорова ли доставка?» — чтобы понимать, можно ли на вас опираться или под капотом всё горит;
«Что мешает и чем рискуем?» — чтобы вовремя помочь: снять блокер, передоговориться, добавить людей или срезать объём.

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

*Карта контракта: каждый вопрос бизнеса закрывается своим классом сигнало*

На вопрос «когда» отвечают поток и обещания. Поток — это четыре простых сигнала из словарика: throughput (сколько реально доезжает), cycle time (как долго едет одна задача), WIP (сколько едет одновременно) и work item age (что застряло). Обещания — это say/do: доля обещанного, что доехало в срок; о нём подробно в следующей части, это мой основной инструмент. И принципиальный момент: честный ответ на «когда» — всегда вероятность, а не дата-точка. «К 15 октября успеем с вероятностью около 85%, вот два главных риска» — это ответ. «Будет 15 октября» без допущений — это враньё с отложенным сроком исполнения.

На вопрос «здоровы ли» отвечает качество потока. Доля переделок (rework), баги, дошедшие до пользователей, change failure rate — как часто изменения приходится срочно чинить. Тут индустрия недавно сделала показательный шаг: DORA (многолетняя исследовательская программа Google с четырьмя каноническими метриками доставки) добавила пятую, rework rate: долю деплоев, которые были незапланированной починкой того, что уже уехало к пользователям. Метрику ввели в отчёте 2024 года, в 2025-м вышли первые ориентиры «что считать нормой». Смысл простой: скорость, за которой прячутся переделки — это не скорость. Это кредит под высокий процент.

На вопрос «что мешает» отвечают сигналы риска. Застрявшие задачи и их возраст. Внешние зависимости — кто и что нам должен (в статье про интеграции я называл это картой зависимостей). Решения, которые ждём от самого бизнеса. Это самый недооценённый класс сигналов: команды охотно показывают прогресс и стесняются показывать блокеры. А ведь именно блокеры заказчик умеет снимать лучше всех (у него для этого и полномочия, и рычаги).

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

Часть 3. Мой рабочий набор: кварталы, say/do и вероятности вместо гаданий

Теперь конкретика — как этот контракт устроен у меня. Контекст: департаменты, которыми я руководил (до восьми команд над одним продуктом; рядом жили продуктовая разработка, поддержка и сервисные команды). Всё ниже — практика, не пересказ книжек. И напомню про честность: цифры в примерах иллюстративные.

Квартальные обещания и say/do

Основная валюта моих договорённостей с бизнесом — квартальный коммитмент: список того, что направление обещает довезти за квартал. С двумя обязательными приложениями: допущения («мы исходим из того, что…») и буферы — запас на известные риски. Метрика поверх — say/do: какая доля обещанного реально доехала в срок. На say/do у меня стоит квартальная отчётность направлений, и он же — одна из составляющих мотивации менеджеров.

Про мотивацию скажу открыто, потому что чуть ниже я сам буду доказывать, что метрики нельзя привязывать к оценке людей (и на первый взгляд это противоречие). Разница вот в чём. Say/do меряет не «сколько наработали», а качество обещания. Менеджер направления/команды своим коммитментом владеет полностью: сам его собирает, сам закладывает буферы, сам говорит «нет» невыполнимому. Спрашивать с человека за точность его собственного обещания — честно. Это и есть суть менеджерской работы.

А чтобы метрика не выродилась в театр заниженных обещаний (пообещаю поменьше, выполню наверняка), у неё есть встроенный противовес: буферы и допущения — публичная часть коммитмента. Перезаложился — это видно так же хорошо, как и срыв. Запомните этот приём, он универсальный: метрика без противовеса — это приглашение к закону Гудхарта; метрика с противовесом — рабочий инструмент.

И жёсткая граница: всё это — уровень направлений и менеджеров. Say/do отдельного разработчика я не считаю никогда. Как и любую другую индивидуальную метрику потока. Почему — в части 4.

Оценка до старта: точность, достаточная для этапа

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

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

Вероятность вместо даты: Монте-Карло

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

На выходе — не дата, а честный расклад: «этот объём к этой дате — с вероятностью ~85%; нужно 95% — вот дата попозже; нужно раньше — вот что придётся отрезать». Первые такие симуляторы я писал сам, скриптами ("консолька" на C#/.NET). Сейчас, с AI-ассистентами, рабочий инструмент по выгрузке из вашего же трекера собирается за вечер — порог входа рухнул, отговорок не осталось. Жёсткое условие одно: истории должно быть достаточно. Симуляция по трём неделям данных — то же гадание, только с наукообразным лицом.

Чем это лучше привычного «средняя скорость плюс буфер на глазок»? Средняя прячет хвосты — те редкие, но неизбежные задачи-долгожители, из-за которых всё и съезжает. Распределение показывает их честно. Дедлайн, кстати, тоже их находит, но уже без предупреждения.

Границы потока: DoR, DoD и переделки

Переделки — самый тихий налог на доставку: их не видно в отчётах, но они съедают недели. Ловить их я предпочитаю на границах. Definition of Ready — на входе: сырое, недодуманное не попадает в работу (половина сорванных обещаний ломается именно здесь, на нечётком «готово к разработке»). Definition of Done — на выходе: «готово» значит готово (с тестами, ревью и мониторингом, а не «работает у меня»). Плюс постоянный сигнал: возвраты из прода. Если фичи регулярно возвращаются на доработку — поток болен, что бы ни говорила скорость. Приятно, что канон догнал практику: rework rate у DORA — ровно про это.

Дешёвая видимость: async-чейнджлог и state of delivery

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

Async-чейнджлог. Короткая регулярная заметка «что доехало»: несколько строк о том, что реально ушло в прод и что это меняет для пользователя или внутреннего заказчика. Без созвона, без слайдов — просто сообщение в общем канале. Я этим инструментом пользуюсь давно (в разной форме и интерпретации — даже можно/нужно включать в регулярный отчет по Продукту), и главный урок такой: шаблон — не догма. Поля и разделы каждый раз подстраиваются под то, что читателю действительно важно видеть. Форма меняется, суть остаётся: регулярный асинхронный сигнал о доехавшей ценности. По сути это демо за пять процентов его цены. Живое демо при этом никто не хоронит — оно прекрасно, когда есть что показать руками. Чейнджлог закрывает остальные недели: показывать нечего, а видимость нужна.

State of delivery. Регулярный срез состояния доставки для заинтересованных сторон. У меня он живёт на двух уровнях: по департаменту — сводно по направлениям, по отдельному проекту — компактнее и чаще. Каркас всегда один: как идём по обещаниям (say/do), ключевые риски и зависимости — и обязательный раздел «что нужно от вас»: решения, которых ждём от бизнеса. Формат и глубина подстраиваются под аудиторию; неизменны две вещи — ритм и повторяемая структура. Работает простая психология: заказчик, который каждый месяц видит одинаково устроенный честный срез, перестаёт дёргать команду между срезами. Проверено не раз.

Так выглядит «state of delivery» на одном экране: обещания, поток, качество, риски. Цифры иллюстративные.

Честно про сопротивление

Полный набор метрик потока (throughput, cycle time, WIP, aging) я считаю правильным языком для разговора о доставке. Скажу честно: внедрить весь набор как систему удавалось не везде. Иногда организация не готова. Иногда наверху ждут совсем других цифр — попроще и попривычнее, вроде той самой «velocity на человека». Это нормальная реальность взрослой карьеры: мандата на правильную систему измерений у вас не будет ровно тогда, когда она нужнее всего.

Поэтому мой минимальный контракт сознательно собран из того, что внедряется почти в любой культуре и почти без бюджета: обещания с публичными буферами, say/do, DoR/DoD, чейнджлог, state of delivery. Для этого не нужно ничьё разрешение — только дисциплина. А полный стек метрик потока — следующий уровень, за который стоит бороться, когда базовый контракт уже работает и накопил доверие.

Часть 4. Люди важнее механики: как внедрять и не сломать

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

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

Метрики команды — не метрики контракта. У команды есть свои внутренние градусники: хоть velocity, хоть оценки в футболках S/M/L. Это её кухня, и бизнесу туда смотреть незачем. Наружу идёт только контракт: обещания, поток, качество, риски. Когда эти два слоя смешивают, «прозрачность» начинает ощущаться командой как слежка — и умирает.

Ничего индивидуального. Никогда. Метрики потока не участвуют в оценке инженеров. Точка. В тот день, когда cycle time стал аргументом в разговоре о зарплате, у вас не стало метрики cycle time — появилось соревнование по художественной нарезке задач на мелкие (оговорку про say/do менеджеров я сделал выше: там метрика меряет обещание, которым человек владеет сам; и даже там обязателен противовес).

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

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

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

Кто на что смотрит и что не пересекает границы: кухня команды остаётся в команде, наружу идёт контракт; сравнение команд и оценка людей не проходят никуда.

Часть 5. AI-слой 2026: почему слепота подорожала

Если контракт прозрачности был полезен всегда, то в последние пару лет он стал критичен. Причина — AI-инструменты в разработке. И здесь свежие данные говорят громче любых мнений.

DORA в отчёте 2025 года фиксирует: AI-ассистентами пользуются почти все, но AI усиливает и сильные, и слабые стороны вашего потока. У кого доставка была здоровой — тот ускорился. У кого хромала — у того проблемы отмасштабировались вместе с генерацией кода. Аналитика Faros.ai (2026) показывает, куда именно переехала нагрузка: время на код-ревью выросло на 91%, размер pull request'ов — на 154%, и почти половина разработчиков признаёт: отлаживать код, написанный AI, дольше, чем ожидалось. Узнаёте картину? Это ровно тот тезис, который я отстаиваю давно: AI ускоряет ввод, а не выход. Код пишется быстрее — а узкое место переезжает дальше по конвейеру: в ревью, тестирование, переделки.

Для нашего разговора это значит простую вещь: метрики входа окончательно умерли. «Сколько кода написали», «сколько задач начали», «какой процент AI-подсказок принят» — эти цифры теперь не просто бесполезны. Они активно врут, потому что генерировать активность стало почти бесплатно. Ценность сместилась к метрикам выхода и качества: throughput доехавшего, rework rate, change failure rate. Не случайно rework rate стала пятой метрикой DORA именно сейчас — это детектор скрытой цены скорости, купленной генерацией.

Пара слов про сами рамки измерения, чтобы вы ориентировались в названиях. DX Core 4 — попытка собрать DORA, SPACE и DevEx в одну систему из четырёх измерений: скорость, эффективность, качество, бизнес-эффект. В июньской ревизии 2026 года её авторы пришли к выводу, который я бы повесил на стену: метрики результата остаются стабильной основой, а данные о применении AI — это контекст для понимания картины, но не замена ответу на вопрос «что доехало до пользователя». Проще говоря: считать токены вместо доехавшей ценности — новый способ совершить старую ошибку.

Практический вывод для руководителя: чем быстрее пишется код, тем дороже обходится слепота на выходе. Контракт прозрачности из части 2 — уже не гигиена. Это условие того, что AI принесёт вам пользу, а не красиво оформленный техдолг. В прошлой статье я говорил, что AI повышает ставки для структуры команд. К метрикам это относится в той же мере.

Четыре канонические метрики DORA + rework rate (2024/2025): пара «скорость ↔ стабильность» сбалансирована так, что разогнать одно за счёт другого незаметно не выйдет.

Часть 6. Минимальный контракт прозрачности: собери под свой контекст

Как и с фреймворками, универсального набора не существует — есть стартовая карта под контекст. Дальше адаптируете под себя.

Контекст	Минимальный набор сигналов	Чего избегать
Одна продуктовая команда	say/do по спринтам или релизам + cycle time + возвраты из прода	Отчёт velocity наружу
Несколько команд — один продукт	Квартальные обещания + say/do по направлениям + сквозной throughput продукта + rework rate	Сравнение команд между собой; «зелёные спринты» как цель
Поток поддержки, вход непредсказуем	Cycle time + возраст очереди + попадание в SLA + лимиты WIP	Спринтовые обещания там, где вход случайный
Fixed-price, жёсткая дата	Вероятностный прогноз (Монте-Карло) + буфер как публичная цифра + еженедельный срез рисков	Дата-точка без допущений; молчание до дедлайна

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

На какой вопрос бизнеса она отвечает? Ни на какой — значит, это не метрика, а украшение дашборда.
Кто её владелец и что он сделает при отклонении? Метрика без владельца и без действия — строка на кладбище графиков.
Что случится, если сделать её целью? Прогоните через закон Гудхарта заранее: как её будут рисовать? есть ли противовес? Нет противовеса — не вешайте на неё цель.

Внедрять — спокойными шагами (рекомендую разлажить на три месяца). Первый: договориться с бизнесом о трёх вопросах и повесить два-три сигнала (say/do по ближайшему обещанию плюс возвраты из прода почти всегда правильный старт). Второй: добавить ритмы (чейнджлог еженедельно, state of delivery ежемесячно) и похоронить отчёты, которые никто не читает. Третий: подключить поток (cycle time, WIP, aging) и сделать первый вероятностный прогноз по накопившейся истории. Быстрее — можно. Устойчивее — вряд ли.

Контекст → минимальный набор сигналов: одна команда, несколько команд — один продукт, поддержка, fixed-price.

Вывод

Story points не виноваты. Их можно оставить, как внутренний инструмент команды; я так и делаю и другим советую. Их можно убрать, если поток стабилен и статистика отвечает на «когда» лучше оценок. Нельзя одно-единственное: оставить бизнес слепым и назвать это гибкостью.

Прозрачность — это контракт. Обещания с публичными буферами — say/do. Честный поток — throughput и cycle time. Качество без прикрас — переделки и возвраты. И сигналы риска, поданные до пожара, а не после. Стоит такой контракт дешевле, чем кажется: короткий чейнджлог и повторяемый ежемесячный срез закрывают большую его часть. А покупает он самое дорогое, что есть у руководителя доставки — право на слово, которому верят.

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

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

А пока расскажите: что показываете бизнесу вы и что из этого он честно читает, а что вежливо пролистывает?

Источники

Scrum Guide 2020 — Schwaber & Sutherland (story points в тексте отсутствуют)
Ron Jeffries — «Story Points Revisited» (2019)
Goodhart's Law / формулировка М. Стратерн
DORA — исследовательская программа и метрики · DORA Report 2025 (AI усиливает сильные и слабые стороны потока)
Rework rate — пятая метрика DORA (введена в отчёте 2024, бенчмарки 2025); разбор Faros.ai (2026), там же данные о +91% времени ревью и +154% размера PR
DX Core 4 — рамка четырёх измерений · «Revisiting the DX Core 4 in the Age of AI» — Brian Houck, DX Newsletter, 24.06.2026
SPACE framework — Forsgren et al., ACM Queue (2021)
Daniel Vacanti — «Actionable Agile Metrics for Predictability» (2015; метрики потока и вероятностные прогнозы)
NoEstimates — Vasco Duarte; обзор подхода и Монте-Карло-прогнозов
«DORA Metrics Are Not Enough in 2026» — oobeya.io

Об авторе

Head of Delivery / R&D Director. Пишу о доставке без воды: предсказуемость, метрики, масштабирование, people management. LinkedIn: aliaksei-labachou

Убрали Story points и бизнес ослеп. Прозрачность доставки без театра оценок