Оценка и планирование: story points, PERT, #NoEstimates

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

Эта статья про то, как перестать врать себе и заказчику: как устроена природа ошибки оценки, какие техники существуют (от planning poker до трёхточечных оценок и Монте-Карло), где проходит граница полезности оценок и что имеют в виду люди, которые пишут в твиттере #NoEstimates. Мы продолжаем разговор, начатый в статьях про Agile и Scrum и Kanban и управление потоком — оценка бессмысленна в отрыве от того, как устроен ваш процесс поставки.

1. Три разных слова, которые все путают

Стив Макконнелл в Software Estimation: Demystifying the Black Art (Microsoft Press, 2006) начинает именно с этого разграничения, и оно решает половину проблем ещё до всякой математики:

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

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

Жизненный цикл одной оценки

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

2. Почему мы систематически ошибаемся (и всегда в одну сторону)

2.1 Ошибка планирования

Канеман и Тверски в 1979 году описали planning fallacy: люди прогнозируют собственные задачи так, будто всё пойдёт по лучшему сценарию, даже зная, что раньше так не выходило. Ключевой эксперимент — студенты оценивали срок сдачи диплома: медиана «реалистичного» прогноза 33,9 дня, «если всё пойдёт плохо» — 48,6, фактическая медиана — 55,5 дней. То есть пессимистичный прогноз оказался оптимистичнее реальности (Buehler, Griffin & Ross, 1994, Exploring the “planning fallacy”).

Подробный разбор — в Thinking, Fast and Slow, глава 23. Там же вводится лекарство: reference class forecasting — не «сколько займёт эта задача», а «сколько занимали похожие задачи у нас раньше».

2.2 Асимметрия распределения

Более глубокая причина — математическая. Длительность задачи ограничена слева и не ограничена справа:

Быстрее физического минимума задачу не сделать — слева жёсткая стенка. Справа стенки нет: может отвалиться внешний API, уйти в отпуск единственный человек с доступом, всплыть требование безопасности. Поэтому распределение скошено вправо (обычно похоже на логнормальное), и у него мода < медиана < среднее.

Человек, отвечая «сколько это займёт», интуитивно называет моду — самый вероятный, «нормальный» сценарий. Планировать при этом надо от среднего или, лучше, от высокого перцентиля. Разрыв между модой и P85 на картинке — это не «запас на лень», а честная плата за неопределённость.

2.3 Конус неопределённости

Точность оценки — функция того, сколько вы уже знаете о системе. Барри Боэм в Software Engineering Economics (1981) показал, что на стадии идеи разброс достигает 4× в обе стороны, и сужается только по мере принятия решений:

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

2.4 Организационные эффекты

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

• Закон Паркинсона: работа занимает всё отведённое время. Дали две недели на трёхдневную задачу — она займёт две недели.
• Студенческий синдром (Голдратт): запас, заложенный в каждую задачу, тратится в начале на прокрастинацию, а не в конце на риски.
• Эффект якоря: любое названное число («ну это же дня три?») притягивает к себе оценку команды. Поэтому в planning poker карты вскрывают одновременно.
• Давление: если за срыв оценки наказывают, оценки растут; если за «раздутую» оценку ругают, они падают. Оба режима ломают информационный канал.

Голдратт (Critical Chain, 1997) на этом строит вывод: локальные запасы в каждой задаче съедаются гарантированно, поэтому буфер надо вынимать из задач и агрегировать в буфер проекта. К этому мы вернёмся в разделе 6.

3. Единицы измерения: часы, story points, размеры

3.1 Зачем вообще относительная оценка

Человек плохо оценивает абсолютные величины и заметно лучше — относительные. «Сколько метров до того дома?» — промах в разы. «Тот дом дальше этого?» — почти всегда верно. Story points эксплуатируют именно это: команда сравнивает задачу с эталонной, а не выдумывает часы.

Story point — безразмерная величина, свёртка трёх факторов: объём работы, сложность, неопределённость. Конвертация в часы не предполагается — она возникает апостериори, через velocity.

Шкала обычно фибоначчиподобная: 1, 2, 3, 5, 8, 13, 20, 40, ∞. Смысл нелинейности не мистический: относительная погрешность оценки растёт с размером, поэтому шкала должна огрублять большие значения. Разница между 1 и 2 реальна, разница между 20 и 21 — шум.

3.2 Velocity и её ловушки

velocity = сумма story points завершённых историй за спринт. Прогноз строится как спринтов = оставшиеся points / средняя velocity — не по среднему, а по диапазону последних 6–12 спринтов.

Что ломает velocity:

• Velocity как KPI. Как только за неё премируют или ругают, работает закон Гудхарта: «когда мера становится целью, она перестаёт быть хорошей мерой». Инфляция points происходит бесшумно и необратимо. Подробнее о вменяемых метриках — в DORA и метрики инженерной эффективности.
• Сравнение команд. Points одной команды несопоставимы с points другой — это разные единицы. Складывать их на портфельном уровне нельзя, хотя очень хочется.
• Изменение состава команды. Новый человек первые пару месяцев уменьшает velocity, а не увеличивает (эффект из The Mythical Man-Month).
• Незакрытые истории. Частично сделанная работа не даёт points, поэтому velocity шумит тем сильнее, чем крупнее истории.

3.3 Сравнение единиц

Последняя строка — мостик к разделу 7. Если все истории нарезаны до сопоставимого размера, их количество прогнозирует не хуже суммы points, и это эмпирически подтверждается (Vacanti, Actionable Agile Metrics for Predictability, 2015).

4. Техники групповой оценки

4.1 Planning poker

Придуман Джеймсом Греннингом (2002), популяризирован Майком Коном в Agile Estimating and Planning (2005). Смысл не в числе на карте, а в обнаружении расхождений в понимании.

Правила, без которых техника вырождается в театр:

1. Никогда не усреднять. Среднее между 3 и 13 — это 8, но полученное молча 8 не содержит знания про откат миграции. Ценность в разговоре.
2. Не более двух-трёх раундов на историю. Не сошлись — значит, история недостаточно прояснена: её надо разбить или отправить на исследование (spike).
3. Таймбокс 2–3 минуты на историю — трёхчасовая сессия оценки оплачивается зарплатой всей команды.
4. Оценивает тот, кто делает. Оценка, спущенная архитектором или тимлидом, теряет и точность, и приверженность.

4.2 Быстрые техники для больших бэклогов

• Affinity mapping / magic estimation: 60–100 карточек молча раскладывают по столу от «маленьких» слева к «большим» справа, потом накрывают шкалой. 80 историй за 40 минут — реально.
• Bucket system: корзины 1/2/3/5/8/13, карточки раскладывают параллельно несколько подгрупп; спорные обсуждают отдельно. Каждая оценка триангулируется двумя эталонами: «точно больше вон той тройки и меньше вон той восьмёрки?».
• Аналогия (reference class): «прошлый импорт из внешней системы занял 14 дней; чем этот принципиально отличается?». Самая недооценённая и самая точная техника.
• Wideband Delphi (Boehm, 1981): для крупных незнакомых работ — несколько раундов анонимных оценок с обменом аргументами. Дорого, но устойчиво к доминированию самого громкого участника.

5. Трёхточечная оценка и PERT

5.1 Идея

Вместо одного числа эксперт называет три:

• O (optimistic) — если всё пойдёт хорошо (≈P10);
• M (most likely) — самый вероятный исход (мода);
• P (pessimistic) — если пойдёт плохо, но без катастрофы (≈P90).

PERT (Program Evaluation and Review Technique, разработан ВМС США для проекта Polaris в 1958) аппроксимирует распределение бета-распределением и даёт:

$$\mu = \frac{O + 4M + P}{6}, \qquad \sigma = \frac{P - O}{6}$$

Веса 4 и 6 — не физическая константа, а инженерное упрощение: коэффициент 4 при моде отражает асимметрию, деление размаха на 6 предполагает, что от O до P укладывается ±3σ. Есть более консервативный вариант (triangular): μ = (O + M + P) / 3, дающий больший вес хвосту.

5.2 Главный фокус: агрегация

Ключевая ценность PERT не в оценке одной задачи, а в сложении. Дисперсии независимых величин складываются, а стандартные отклонения — нет:

$$\mu_{\text{сумма}} = \sum \mu_i, \qquad \sigma_{\text{сумма}} = \sqrt{\sum \sigma_i^2}$$

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

"""PERT-оценка и агрегация по бэклогу. O(n) времени, O(1) доп. памяти; квантиль — O(1)."""
from math import sqrt
from statistics import NormalDist

Task = tuple[str, float, float, float]   # (имя, оптимистичная, вероятная, пессимистичная) в днях


def mean(t: Task) -> float:      # ожидание бета-распределения в приближении PERT
    _, o, m, p = t
    return (o + 4 * m + p) / 6


def sd(t: Task) -> float:        # размах считаем равным шести стандартным отклонениям
    _, o, _m, p = t
    return (p - o) / 6


def forecast(tasks: list[Task], confidence: float = 0.85) -> tuple[float, float, float]:
    """(ожидание, сигма портфеля, значение на перцентиле).
    Допущения, которые надо проговаривать вслух: задачи независимы и n >= ~10 (работает ЦПТ)."""
    assert all(o <= m <= p for _, o, m, p in tasks), "должно выполняться o <= m <= p"
    mu = sum(map(mean, tasks))
    sigma = sqrt(sum(sd(t) ** 2 for t in tasks))     # дисперсии складываются, сигмы — нет
    return mu, sigma, mu + NormalDist().inv_cdf(confidence) * sigma   # z(0.85) ≈ 1.036


backlog: list[Task] = [
    ("Схема БД и миграции", 2, 3, 8),        ("API импорта", 3, 5, 14),
    ("Парсер CSV с валидацией", 2, 4, 9),    ("UI мастера импорта", 4, 6, 12),
    ("Нагрузочное тестирование", 1, 2, 6),   ("Документация и релиз", 1, 2, 5),
]
mu, sigma, p85 = forecast(backlog)
print(f"{mu=:.1f} {sigma=:.1f} {p85=:.1f}")                       # mu=25.8 sigma=2.9 p85=28.9
print(sum(t[1] for t in backlog), sum(t[3] for t in backlog))     # 13 (оптимизм) 54 (пессимизм)

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

5.3 Где PERT врёт

1. Независимость задач — миф. Если тормозит общая инфраструктура или болеет ключевой человек, поплывут все оценки сразу. Корреляция увеличивает реальную σ, иногда в разы. Лечится добавлением явных рисковых сценариев — см. Управление рисками.
2. Забытая работа не оценивается. Основная ошибка портфеля — не «оценили задачу в 5, вышло 8», а «задачи в списке не было вообще». В среднем бэклог растёт на 20–50% в ходе исполнения.
3. P — не катастрофа. Люди называют пессимизмом «плохой рабочий день», а не «подрядчик сорвал сроки на месяц». Калибровка: «в 9 случаях из 10 уложимся».
4. Нормальность на малых n. При 3–5 задачах ЦПТ не работает и квантиль по z занижен — честнее Монте-Карло.

6. Монте-Карло: прогноз без оценок задач

6.1 Идея

Если у вас есть история потока — сколько задач команда завершала в день или неделю — вам не нужно оценивать отдельные задачи. Вы многократно «проигрываете» будущее, каждый раз вытягивая случайный день из истории, и смотрите на распределение дат завершения. Условие применимости одно: бэклог нарезан на сопоставимые куски (right-sizing до 3–5 дней), иначе выборка throughput нерепрезентативна и прогноз будет уверенно неверным.

6.2 Реализация

"""Монте-Карло прогноз даты завершения по историческому throughput.

Сложность: O(trials * L), где L ≈ backlog / средний throughput — число периодов до
исчерпания бэклога. Память O(trials); при больших trials перцентили считают потоково (t-digest).
"""
import random


def simulate(throughput_history: list[int], backlog_size: int,
             split_rate: float = 0.0, trials: int = 50_000, seed: int = 42) -> list[int]:
    """Отсортированные длительности (в периодах) по симуляциям.
    throughput_history — закрытых задач за период; split_rate — доля историй,
    которые «размножатся» при вскрытии деталей."""
    rng = random.Random(seed)
    results: list[int] = []
    for _ in range(trials):
        # честно моделируем рост объёма: часть задач породит новые
        remaining = backlog_size + sum(1 for _ in range(backlog_size)
                                       if rng.random() < split_rate)
        periods = 0
        while remaining > 0:
            remaining -= rng.choice(throughput_history)   # bootstrap из истории
            periods += 1
        results.append(periods)
    return sorted(results)


def percentile(values: list[int], q: float) -> int:
    return values[min(int(q * len(values)), len(values) - 1)]


history = [1, 0, 2, 1, 3, 0, 1, 2, 1, 1, 0, 2, 3, 1, 1, 2, 0, 1, 2, 1]  # задач в день за 20 дней
res = simulate(history, backlog_size=60)
print([percentile(res, q) for q in (0.50, 0.70, 0.85, 0.95)], res[-1])
# [48, 51, 53, 57] 71   — P50/P70/P85/P95 и худший случай из 50 000 прогонов, рабочих дней

res2 = simulate(history, backlog_size=60, split_rate=0.25)   # бэклог вырастет на ~25%
print(percentile(res2, 0.85))   # 67 — вместо 53

Три вывода, ради которых всё затевалось:

• P50 — это подбрасывание монеты. Обещать медиану — значит опоздать в половине случаев. При этом ровно так поступает большинство планов.
• Стоимость уверенности нелинейна. С 48 до 53 дней (P50→P85) — плюс 10%; с 53 до 57 (P85→P95) — ещё 8% за куда меньший прирост уверенности. Выбор перцентиля — бизнес-решение о цене риска, а не техническое.
• Рост объёма дороже разброса скорости. split_rate=0.25 сдвинул P85 с 53 к 67 дням — сильнее, чем любая неточность в оценке отдельных задач. Поэтому дисциплина управления объёмом важнее точности оценок.

6.3 Калибровка по собственной истории ошибок

Если оценки в часах у вас уже есть, самый дешёвый способ их улучшить — не «оценивать лучше», а домножать на исторический коэффициент промаха:

"""Bootstrap-калибровка оценки по истории «оценка → факт»: O(trials), без модели распределения."""
import random
from statistics import mean, median

history = [(2, 3), (3, 4), (5, 12), (1, 1), (8, 9), (3, 7),
           (2, 2), (5, 6), (13, 21), (1, 3), (8, 15), (3, 4)]   # (оценка, факт) в днях
ratios = [actual / est for est, actual in history]
print(round(median(ratios), 2), round(mean(ratios), 2))   # 1.42 (медиана) 1.64 (среднее)


def calibrate(raw: float, ratios: list[float], q: float = 0.85,
              trials: int = 20_000, seed: int = 1) -> float:
    rng = random.Random(seed)
    return sorted(raw * rng.choice(ratios) for _ in range(trials))[int(q * trials)]


print([round(calibrate(e, ratios), 1) for e in (5, 13, 21)])   # [12.0, 31.2, 50.4] — P85

Двенадцать пар «оценка/факт» из вашего трекера дают больше, чем любая методология. Это и есть reference class forecasting Флиуберга в самом дешёвом исполнении (Flyvbjerg, 2006, From Nobel Prize to Project Management).

7. #NoEstimates: что на самом деле утверждают

Хештег запустил Вуди Зуилл около 2012 года; книги и доклады написали Васко Дуарте (NoEstimates: How to Measure Project Progress Without Estimating, 2015) и Аллен Холуб. Радикальная формулировка «оценки — это чистые потери» вызывает справедливое раздражение, поэтому разберём аргументацию по частям.

Что реально утверждается:

1. Оценка стоит денег: час всей команды на планировании — это час, не потраченный на поставку. И часто она не влияет на решение: если фича делается в любом случае, зачем её оценивать?
2. Прогноз по историческому throughput точнее оценок (эмпирически — см. Vacanti, Дуарте на данных сотен проектов).
3. Оценки токсичны: превращаются в обязательства, обязательства — в дедлайны, дедлайны — в технический долг и выгорание.
4. Замена — right-sizing: не «сколько это займёт», а «влезает ли это в наш максимальный размер истории»; если нет — режем.

Что не утверждается: «не планируйте». #NoEstimates — про отказ от оценки отдельных задач в единицах времени, а не от планирования, приоритизации или обязательств перед бизнесом.

Честная критика:

• Нужна история потока: у новой команды на новом продукте её нет, и первые месяцы придётся оценивать по-старому.
• Требует дисциплины нарезки — навык более трудный, чем оценка: right-sizing работает, только если истории действительно режутся до сопоставимого размера.
• Не отвечает на вопрос «стоит ли вообще браться за проект за 8 млн?» до старта и плохо ложится на фиксированные контракты и регуляторику, где число нужно до начала работ.

Синтез, который работает на практике:

Дискуссия задокументирована у Рона Джеффриса и Мартина Фаулера; у последнего критерий сформулирован в одну фразу: оценка полезна тогда и только тогда, когда от неё зависит решение.

8. Планирование на разных горизонтах

Оценка — сырьё. План — то, что из неё делают. Ключевая идея: горизонт определяет и точность, и обязательность.

Две вещи, на которые стоит посмотреть на этой диаграмме:

1. Буфер стоит отдельной задачей и виден всем (отмечен как критичный). Это идея Голдратта: вместо того чтобы прятать по 30% запаса в каждую задачу, вынимаем его и держим один общий буфер проекта. Его расход — главный индикатор здоровья плана: сожгли 70% буфера, пройдя 40% работы, — сигнал тревоги задолго до дедлайна.
2. Детализация падает с горизонтом, и единицы на разных горизонтах разные — дни, right-sized истории, T-shirt. Расписывать по дням третий квартал бессмысленно: приоритеты изменятся. Это и есть rolling wave planning (PMBOK Guide).

Ёмкость команды: считайте календарь, а не идеальные дни

Классическая ошибка — умножить 5 человек на 10 дней и получить 50 человеко-дней. Реальность:

5 человек × 10 рабочих дней                             = 50 чел.-дней
− отпуска и больничные (~10%)                           = 45
− дежурства и поддержка прода (~15%)                    = 38
− собеседования, ревью, встречи (~15%)                  = 32
− непредвиденное: инциденты, hotfix (~10%)              = 29  ← «на фичи», 58% от номинала

Коэффициент focus factor 0,5–0,7 — типичная норма, а не признак плохой команды. Планирование от 100% загрузки не только нереалистично, но и вредно: как показано в статье про поток, время ожидания растёт нелинейно при приближении утилизации к единице.

9. Типичные ошибки

1. Отвечать числом там, где нужен диапазон. «Три недели» вместо «P50 — 3 недели, P85 — 5 недель, вот из-за чего разброс».
2. Оценка как обязательство по умолчанию. Названное на встрече число через два дня оказывается в договоре.
3. Обещать P50. Формально честно, фактически — гарантированное опоздание в половине случаев.
4. Забыть про не-фичевую работу — ревью, багфиксы, миграции, инфраструктуру, отпуска. Половина сорванных планов сорвана здесь.
5. Прятать буфер внутри каждой задачи. Съедается студенческим синдромом, а снаружи выглядит как раздутые оценки.
6. Сравнивать velocity команд или оценивать за команду: разные единицы измерения плюс упавшая точность и испарившаяся ответственность.
7. Не пересчитывать прогноз после первой недели фактических данных и игнорировать рост объёма: бэклог растёт на 20–50%, и если это не заложено, план ошибочен с первого дня.
8. Оценивать то, что не влияет на решения. Если фича делается в любом случае и очередь фиксирована — оценка это чистые накладные расходы.
9. Наказывать за честный пессимизм и путать идеальные дни с календарными. Первое навсегда портит качество входных данных, второе даёт промах ровно в два раза.

10. Как это выглядит в проде

Продуктовая команда в потоке. Никаких story points. Все истории режутся до «≤ 3 дней», раз в неделю пересчитывается Монте-Карло по throughput за 8 недель, в роадмап уходят P85-даты с явной пометкой «прогноз обновляется еженедельно». Заинтересованным сторонам показывают не дату, а полоску вероятностей. Работает отлично, требует зрелой нарезки историй и доверия к метрикам продукта.

Платформенная команда с внешними обязательствами. Есть регуляторный дедлайн — дата не двигается. Тогда фиксируем дату, а переменной делаем объём: MoSCoW-разделение на Must/Should/Could, буфер проекта в конце, еженедельный отчёт «сожжено буфера X% при выполненных Y% работ». Обязательство берётся по P90–P95 только на Must.

Аутсорс с фиксированной ценой. Худший из миров: обязательство берётся в самой широкой части конуса. Индустриальный ответ — двухфазный контракт: оплачиваемая фаза discovery (2–4 недели, прототип и уточнение требований), по итогам которой фиксируется цена уже в узкой части конуса. Если заказчик на это не идёт, закладывается множитель 2–3× и это честно называется страховкой от неопределённости.

Портфельный уровень. Отдельные проекты сравнивают не по оценке трудоёмкости, а по стоимости задержки и приоритизации: WSJF = Cost of Delay / длительность. Здесь достаточно T-shirt-точности, потому что решение — порядок очереди, а не дата, и ошибка в 2× редко меняет ранжирование.

Что мерить, чтобы улучшаться. Минимальный набор:

• доля обязательств, выполненных в срок (цель — соответствие перцентилю: обещали P85 — попадаем в ~85% случаев; 100% означает раздутые буферы);
• распределение отношения факт/оценка (калибровка выше) и рост объёма за спринт/квартал (scope creep rate);
• cycle time и его 85-й перцентиль — база для right-sizing.

11. Мини-итог

• Оценка, цель и обязательство — три разных объекта. Смешение убивает и планы, и доверие.
• Ошибка оценки систематична и однонаправленна: planning fallacy плюс скошенное вправо распределение. Лечится калибровкой по истории, а не силой воли.
• Story points полезны как относительная мера внутри команды; сравнивать их между командами или превращать в KPI — гарантированный вред. PERT ценен агрегацией: σ = √Σσᵢ² показывает, что перестраховываться в каждой задаче не нужно и вредно.
• Монте-Карло по throughput даёт вероятностный прогноз без оценки задач, требуя взамен дисциплины right-sizing.
• #NoEstimates — не «не планируйте», а «не платите за оценки, которые ни на что не влияют».
• Обещайте перцентиль, а не среднее; буфер держите общим и видимым; прогноз пересчитывайте еженедельно. Управление объёмом влияет на срок сильнее, чем точность любых оценок.

Источники

• Steve McConnell. Software Estimation: Demystifying the Black Art. Microsoft Press, 2006 — самая полная книга по теме.
• Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2005 — story points, planning poker, релизное планирование.
• Daniel Kahneman. Thinking, Fast and Slow, гл. 23 «The Outside View», 2011; Buehler, Griffin & Ross, 1994 — эксперименты по planning fallacy.
• Bent Flyvbjerg. From Nobel Prize to Project Management: Getting Risks Right, Project Management Journal, 2006 — reference class forecasting.
• Daniel Vacanti. Actionable Agile Metrics for Predictability, 2015 — прогноз по потоку, Монте-Карло, right-sizing; Eliyahu Goldratt. Critical Chain, 1997 — агрегированные буферы.
• Barry Boehm. Software Engineering Economics, 1981 — конус неопределённости, COCOMO, Wideband Delphi; Frederick Brooks. The Mythical Man-Month, 1975/1995.
• Martin Fowler. Purpose of Estimation — критерий полезности оценки; Ron Jeffries. The #NoEstimates Movement; Vasco Duarte. NoEstimates, 2015.
• Troy Magennis. Focused Objective — открытые инструменты Монте-Карло-прогнозирования.

Что дальше

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

Управление рисками в IT-проектах