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

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

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

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

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

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

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

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.