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

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

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

В двухнедельном спринте регрессия часто превращается в лотерею: фичи доделывают до последнего дня, полный прогон не помещается в окно, а красному CI уже никто не верит. В итоге команда выпускается, ориентируясь на ощущение, а не на понятную картину рисков.

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.