Модуль 8.2. Оценка и планирование
Темы: story points vs time, план релизов, критический путь. Артефакт: план релиза. Практика: оценить фичу тремя методами.
Системный аналитик (SA) помогает команде давать реалистичные обещания. Для этого нужны три вещи:
- Единицы оценки (story points/time) и честная связь с календарём.
- План релиза (scope → зависимости → календарь → буферы → критерии выхода).
- Сетевое планирование: критический путь, запас времени, риски.
В модуле — конкретные методики (Planning Poker, T-shirt, трёхточечные оценки/PERT, throughput-прогноз), расчёты, шаблоны и анти-паттерны.
Story Points vs Time — как ужиться
Зачем story points
Story points (SP) оценивают относительную сложность: объём работы, неопределённость, риски. Это удобно на уровне бэклога и спринтов, когда точного времени не знаете.
Нормально: «эта стори ≈ в 2 раза сложнее той».
Ненормально: «1 SP = 4 часа». SP — не валюта времени.
Как прогнозировать сроки из SP
- Соберите историю скорости (velocity): выполненные SP по завершённым спринтам (лучше ≥6 спринтов).
- Считайте диапазон, а не точку: медиана и перцентили (например, 50-й/85-й).
- Прогноз даты = оставшиеся SP / ожидаемой скорости (с доверительным интервалом).
- Не переводите «1 SP → X часов». Время — на уровне календарного плана с учётом зависимостей.
Когда сразу в часах
- Системные активности вне спринтов: миграции БД, закупка сертификатов, согласование безопасности/юристов, UAT-окна, релизные «фризы».
- Внешние поставщики: SLA даёт календарные окна (не SP).
Методы оценки (используйте вместе)
Planning Poker (SP) + T-shirt
- Planning Poker: команда голосует SP из ряда Фибоначчи (1–2–3–5–8–13…), обсуждает аргументы, сходится на значении.
- T-shirt: XS/S/M/L/XL, быстро сортирует бэклог. После — калибровка: S≈3 SP, M≈5 SP, L≈8 SP (приближённо, под вашу историю).
Когда: быстрый груминг, ранние стадии эпика.
Плюсы: вовлекает всех, вскрывает риски. Минусы: субъективность, «съедает» время при споре.
Трёхточечная оценка (PERT) — в часах/днях
Для каждой задачи: O (optimistic), M (most likely), P (pessimistic).
Формулы:
- Ожидаемое время E = (O + 4M + P) / 6
-
Дисперсия Var = ((P − O) / 6)^2 → σ = √Var
Суммарно по критическому пути даёт среднее и разброс; можно получить P85/P90.
Когда: детальная фаза фичи; есть опыт подобных работ.
Плюсы: явная неопределённость. Минусы: требует дисциплины ввода.
Throughput/Monte-Carlo — по факту потока
Берём историю cycle time/throughput (сколько стори закрываем в неделю) и гоняем MC-симуляцию: «когда закроем N стори?». Выход — кривая вероятностей дат (например, «с вероятностью 85% успеем к 15 октября»).
Когда: у команды уже есть история потока, состав стори однороден.
Плюсы: объективно, учитывает вариативность. Минусы: нужна история и однотипность единиц.
Критический путь (CPM) и буферы
Термины
- Сеть работ: узлы (вехи) и активности с длительностями и зависимостями.
- Раннее начало/окончание (ES/EF) и позднее (LS/LF).
- Запас (slack/float) = LS − ES (или LF − EF).
- Критический путь: путь с нулевым запасом — определяет дату релиза.
- Feeding/Project buffer (CCPM): буферы на входах в критический путь и в конце проекта (вместо «надутых» оценок у всех задач).
Мини-пример CPM (дни, PERT-ожидания)
A: Контракт API — E=2 B: UI макет — E=3 C: Бэкенд — E=5 (зависит от A) D: UI фронт — E=4 (зависит от B и A) E: Интеграция — E=2 (зависит от C и D) F: QA/UAT — E=3 (зависит от E)
Пути:
- A→C→E→F = 2 + 5 + 2 + 3 = 12 (критический)
- B→D→E→F = 3 + 4 + 2 + 3 = 12 (тоже критический)
Вывод: два критических пути — риск выше → нужен project buffer (например, 20–30% от суммы σ по путям) и feeding buffers на входах ветвей.
План релиза: как собрать
Алгоритм
- Скоуп: список фич/стори с AC/NFR и зависимостями (внешние системы, лицензии, безопасность, DWH).
- Сетевое планирование: диаграмма зависимостей, ранжирование рисков, критический путь.
- Оценки: комбинируйте SP (Poker) + PERT на критических задачах + throughput для «массива» однородных стори.
- Буферы: project/feeding; релизный фриз (код/данные), окна UAT/безопасности.
- Cut-line: правила, что вырезаем при угрозе срока (feature flags, dark launch).
- Критерии выхода: DoD, UAT sign-off, SLO-смоки (p95, error-rate), чек-листы данных/комплаенса.
- Коммуникации: календарь событий (планинг, triage, demo, go/no-go), RACI.
Шаблон артефакта «План релиза» (скопируйте в Confluence)
# Release Plan — <Продукт> vX.Y (Sprint N..M) Owner: PO | SA: <ФИО> | Tech: <Лид> | SRE: <Лид> | Даты: <от-до> ## 1. Цели и метрики Outcome/KPI: <например, +1.5pp к конверсии чекаута, p95<2.5s 08–23> ## 2. Скоуп - Эпик E-101: Оплата и Возвраты - Фичи: F-201 Платёж, F-202 Возврат, F-203 Пагинация - Вне скоупа: <…> ## 3. Зависимости и риски - Внешние: PSP v2 (SLA 99.0%), антифрод, DWH - Риски (ID/вероятность/влияние/план): R1: «PSP задержки» H/H — деградация 202 + буфер ## 4. Сеть работ и оценка - Диаграмма ссылкой, критический путь: <ветви> - Методики: SP Poker (блок А), PERT (критические задачи), throughput (массовые стори) - Буферы: Feeding (UI→Интеграция 1д), Project 2д ## 5. Календарь (Gantt high-level) - Sprints N..M: dev & test - UAT окно: <даты> - Code freeze: <дата> - Go/No-Go: <дата+время, TZ> - Prod: <дата>, Rollback план: <ссылка> ## 6. Критерии выхода - UAT sign-off (S1=0, S2≤N), SLO-smoke зелёный, документация обновлена ## 7. Коммуникации - Каналы: #release, #war-room - Регламенты: triage ежедневно 30м, demo по пятницам ## 8. Изменения/Scope control - Cut-line: при угрозе срока выключаем F-203 (флаг `orders.cursor=false`)
Практический пример (сквозной кейс): «Фича — Создание платежа»
Метод 1 — Story Points (Planning Poker)
Калиброванные эталоны:
- 3 SP — простая CRUD-стори без внешних зависимостей;
- 5 SP — новая ручка + валидации + событие;
- 8 SP — с внешней интеграцией/миграциями.
Оценка стори фичи (пример):
- S-1 «Контракт /payments + схемы» — 3 SP
- S-2 «Серверная валидация + идемпотентность» — 5 SP
- S-3 «Интеграция с PSP (timeout/202)» — 8 SP
- S-4 «UI экран результата + ошибки/ожидание» — 5 SP
-
S-5 «Observability + алерты» — 3 SP
Итого: 24 SP
История скорости команды: медиана 20 SP/спринт, P85 = 24 SP/спринт.
Прогноз: 24 SP ≈ 1–2 спринта (P50 — 1.2 спринта; P85 — 1 спринт при хорошем потоке).
Замечание: это грубая оценка; зависимостей пока не видно.
Метод 2 — PERT (трёхточечные оценки) в днях
|
Задача |
Зависит |
O |
M |
P |
E=(O+4M+P)/6 |
σ=((P−O)/6) |
|---|---|---|---|---|---|---|
|
A Контракт API |
— |
1 |
2 |
3 |
2.0 |
0.33 |
|
B UI макет |
— |
2 |
3 |
4 |
3.0 |
0.33 |
|
C Бэкенд реализация |
A |
3 |
5 |
8 |
5.2 |
0.83 |
|
D UI фронт |
A,B |
2 |
4 |
6 |
4.0 |
0.67 |
|
E Интеграция/интегр. |
C,D |
1 |
2 |
4 |
2.2 |
0.50 |
|
F QA/UAT |
E |
2 |
3 |
5 |
3.2 |
0.50 |
Критические пути: A→C→E→F (E=2.0+5.2+2.2+3.2=12.6) и B→D→E→F (E=3.0+4.0+2.2+3.2=12.4). Берём 12.6 д.
Суммарная σ по пути A-C-E-F: √(0.33²+0.83²+0.50²+0.50²) ≈ 1.18 д.
P85 ≈ E + 1.04·σ ≈ 12.6 + 1.23 ≈ 13.8 д.
P90 ≈ E + 1.28·σ ≈ 12.6 + 1.51 ≈ 14.1 д.
Добавляем project buffer 2 д. → планируем T+~16 дн. (рабочих), плюс календарные фризы/окна UAT.
Метод 3 — Throughput/Monte-Carlo (по потоку)
Дано: за 12 недель команда завершала в среднем 6 стори/нед., p85 = 8 стори/нед.
В фиче 5 стори (см. 5.1). Прогоняем MC (умозрительно):
- P50: 1 неделя (6/нед ≥ 5)
- P85: 1 неделя (8/нед ≥ 5)
- Если в релизе 18 стори (включая соседние фичи), P50 ≈ 3 недели; P85 ≈ 3 недели (но добавятся зависимости/буферы).
Вывод: поток подтверждает, что 5 стори — ≤1 итерации; но сетевое планирование показывает календарные риски (интеграция, UAT). Планируем релиз по CPM+буферам, а не по «SP хватит».
Как согласовать сроки с бизнесом (без «магии»)
- Говорим диапазонами и вероятностями: «P50 — 4 окт, P85 — 9 окт».
- Показываем дорожную карту рисков: «критич. путь, буферы, feeding-ветви».
- Делаем cut-line до freeze: что срежем, если буфер тает (фичефлагами).
- Обновляем прогноз на каждом Review/triage по факту потока и burn-down буфера.
- Фиксируем внешние окна (UAT/юристы/маркетинг) — это календарные ограничения.
Риски и анти-паттерны
|
Анти-паттерн |
Симптом |
Что делать |
|---|---|---|
|
SP → «переводим» в часы |
Жёсткая цифра «1 SP=4ч» |
Прогнозируйте от velocity; время — через CPM |
|
«Дата сверху», оценки подгоняем |
Хронические срывы |
Работайте с диапазонами и cut-line; уменьшайте scope |
|
Нет буферов |
Любой сбой — перенос |
Project/feeding-buffers, правила их расхода |
|
Оценили только dev |
QA/UAT/безопасность «забыты» |
Включайте всё на пути к Done и sign-off |
|
Зависимости «по ходу» |
«Вдруг» нужен ключ/доступ |
Раздел «Зависимости» в плане, контроль готовности |
|
Single-point estimate |
«Попали» или «промах» |
PERT/MC, показывайте P50/P85 |
|
Горизонтальные стеки |
Нечего релизить |
Вертикальные срезы, feature flags |
|
Velocity как KPI |
Игра с очками |
Метрики потока (lead/cycle/CFD), outcome-KPI |
Вопрос–Ответ
В: Можно ли превратить SP в часы для отчёта?
О: Нельзя напрямую. Используйте историческую скорость (SP/спринт) и показывайте прогноз по датам через CPM и календарь.
В: Что взять за буфер?
О: Для неизвестности задачи используйте PERT (σ) → project buffer ~ 20–30% от суммы σ крит. пути. Плюс feeding-buffers на входах в критич. ветви.
В: Когда выбирать T-shirt vs Poker?
О: T-shirt — быстрый груминг эпика, когда задач много. Poker — когда идёт подготовка конкретных стори к спринту.
В: Как учитывать внешних поставщиков (PSP, безопасность)?
О: Это фикс-даты и календарные окна в сетевом плане, не SP. Включайте в критический путь и буферы ожидания.
В: Что делать, если velocity «прыгает»?
О: Прогноз в диапазоне по перцентилям. Дополнительно — ограничьте WIP, стабилизируйте «Definition of Ready».
В: Надо ли переоценивать стори после уточнений?
О: Да. При изменениях требований/рисков — повторный Poker/PERT; обновляйте релиз-план и коммуникации.
Практика (60–120 мин): оцените фичу тремя методами
Фича: «Создание платежа (идемпотентность, 202-деградация, UI рез-экран)»
-
SP Poker + T-shirt
- Разбейте на 5–7 стори, дайте T-shirt и SP.
- Приведите итог по SP и прогноз по velocity P50/P85.
- PERT
- Для задач на критическом пути соберите O/M/P.
- Посчитайте E и σ, определите P85/P90 по сумме.
- Добавьте буферы, получите целевую дату.
- Возьмите историю throughput или предположите (например, 6 стори/нед., p85=8).
- Оцените дата-диапазон закрытия скоупа.
- Сравните с CPM-датой → при необходимости сократите скоуп по cut-line.
- Throughput (MC-подход)
Критерии зачёта:
- Есть три оценки и обоснованный релиз-план (дата P85).
- Учтены зависимости/UAT/фризы/буферы.
- Определён cut-line и критерии выхода.
Шпаргалка (распечатайте)
- SP — относительная сложность; даты рождаются из velocity + CPM.
- Используйте SP + PERT + Throughput — вместе надёжнее.
- Планируйте диапазонами (P50/P85), показывайте буферы.
- Сетевое планирование и критический путь — движок реального календаря.
- Учитывайте QA/UAT/безопасность/данные, не только dev.
- Держите cut-line и фичефлаги для манёвра по скоупу.
- Обновляйте прогноз на каждом Review по факту потока и расходу буфера.
