Scrum в ML-работе, Kanban и оценки

Оценка: story points и planning poker

Story points — относительная оценка объёма работы с учётом сложности, риска и неопределённости, а не часы. Команда сравнивает элемент с уже сделанными: «это вдвое больше той задачи». Людям легче сказать «втрое больше», чем «13,5 часа». Оценивают те Developers, которые будут делать работу.

Частый приём — planning poker. Каждый молча выбирает карту (типичная колода: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100), все открывают одновременно, самый высокий и самый низкий объясняют свои числа, команда оценивает ещё раз. Смысл — разговор. Одновременное открытие убирает anchoring (привязку к первому названному числу), а разброс вскрывает скрытую работу: например, что для второго языка нужен отдельный eval-набор.

Напомню из прошлого урока: ни story points, ни velocity в Scrum Guide нет, это дополнительные практики.

Velocity и прогноз диапазоном

Velocity — сумма points полностью сделанных за Sprint элементов; наполовину сделанное считается как 0. Это инструмент прогноза для самой команды.

Пример. За три двухнедельных Sprint команда сделала 31, 27 и 35 points, в среднем 31. До выпуска в Backlog осталось 124 points. Прогноз: 124 / 31 = 4 Sprint. Диапазон по лучшему и худшему Sprint: 124 / 35 ≈ 3,5 и 124 / 27 ≈ 4,6 Sprint, то есть 7–10 недель. Прогноз называют диапазоном, а не датой.

Velocity — не мера продуктивности. Шкала у каждой команды своя, поэтому сравнивать команды бессмысленно. А цель «поднять velocity с 28 до 40» решается раздуванием оценок или срезанием проверок: прогноз теряет смысл, качество падает. Ron Jeffries, который, по его собственным словам, возможно, придумал story points, пишет, что «comparing teams on quality of estimates or velocity is harmful». В AI-команде падение velocity часто честное: в DoD добавили eval gate (автоматическую проверку качества, без которой изменение не проходит), и каждый элемент стал тяжелее.

Burndown chart показывает остаток работы по дням Sprint. Burnup chart показывает две линии — сделано и общий объём, поэтому рост объёма на нём виден. Для AI-работы, где объём растёт после экспериментов, burnup честнее.

Неопределённое — в timebox, а не в points

Часть ML-Backlog — это вопросы, а не features: дотянет ли маленькая модель до качества большой? Такую работу не оценивают в points, будто исход известен. Её оформляют как spike (короткое исследование) или timeboxed experiment (эксперимент с жёстким бюджетом времени). Шаблон:

• Question: может ли модель на 8B параметров сравняться с большой моделью на нашем наборе споров по картам?
• Timebox: 3 дня, 1 инженер, бюджет GPU задан заранее.
• Method: те же 200 задач, тот же prompt и tools, 4 прогона на задачу, языки отдельно.
• Decision rule: переходим, если task success хуже не больше чем на 2 пункта и в safety-наборе ноль новых провалов; иначе остаёмся.
• Done when: решение записано с числами, каким бы оно ни было.

Главная фраза: «An experiment that answers the question is done, even if the answer is no». Sprint Goal для такой работы формулируют как решение или пригодный Increment, а не обещание «модель достигнет 90%»: этим числом никто не управляет. Гайд прямо включает в работу Scrum Team «experimentation, research and development».

Definition of Done для AI-increment

Обычный DoD — код проверен, тесты пройдены, выложено на staging. Для AI-increment добавляют проверки, которые можно запустить:

Где живёт гарантия: DoD в wiki — совет, а CI gate, который блокирует merge при провале eval, — гарантия. Ещё два правила. Режь работу вертикально: один intent (тип запроса) от вопроса до ответа на одном языке, с eval и передачей человеку, а не «Sprint 1 — данные, Sprint 2 — модель, Sprint 3 — интерфейс». На Sprint Review показывай eval dashboard с провалами, а не три удачных диалога: это и есть transparency.

Если внешняя проверка (model risk, security) длиннее Sprint, отдели «Done» от «released»: Increment прошёл DoD и стоит в shadow mode, пока идёт проверка, а пакет для проверяющих — отдельный элемент Backlog.

Kanban: поток вместо Sprint

Kanban по Kanban Guide (версия 2025.5) — «a strategy for optimizing the flow of value through a process». Три практики: определить и показать workflow (поток работы), активно управлять элементами в потоке, улучшать workflow. Фиксированных Sprint нет. Четыре метрики: WIP (work in progress — начато и не закончено), throughput (закончено за единицу времени), work item age (сколько идёт незаконченный элемент), cycle time (от начала до конца). SLE (service level expectation) — прогноз срока с вероятностью, по истории: «85% запросов на разметку закрываются за 6 дней».

Little's Law (закон Литтла из теории очередей; в самом Kanban Guide его нет): средний cycle time ≈ WIP / throughput. В работе 12 элементов, команда заканчивает 4 в неделю — средний элемент идёт около 3 недель. Хочешь 1,5 недели при том же throughput — держи WIP около 6. Меньше начатого параллельно — быстрее каждое дело.