Инженерия ПО
Эстимация и планирование
NASA потеряла марсоход Mars Climate Orbiter в 1999 году из-за ошибки в 327 миллионов долларов - одна команда считала в метрических единицах, другая в имперских. Никто не уточнил допущения. Эстимация - это не про числа, это про синхронизацию понимания.
- **Spotify** измеряет velocity squad'ов в SP для квартального планирования OKR - но никогда не сравнивает SP разных команд между собой
- **Basecamp** отказался от оценок в пользу "appetite" - команда сама решает, сколько времени стоит инвестировать в фичу, и останавливается если не уложилась
- **Amazon** использует T-shirt sizing на стадии PR/FAQ (Product Requirements): до написания кода инициативы ранжируются как S/M/L чтобы отсеять XL-монстров на раннем этапе
Story Points
**Story Point** - относительная единица измерения сложности задачи, а не времени. Команда сравнивает задачи между собой: если регистрация пользователя = 3 SP, то OAuth-интеграция = 8 SP, потому что она в ~2.5 раза сложнее по совокупности усилий, неопределённости и риска.
Story Points измеряют три фактора: **сложность** (насколько трудна задача технически), **объём работы** (сколько кода/инфраструктуры затронуто), **неопределённость** (насколько хорошо понято решение). Ключевое свойство - SP привязаны к конкретной команде, а не к универсальным часам.
Spotify использует SP для планирования кварталов: команды squad'ов эстимируют свой backlog, а PO видит реальный capacity. Главное правило - **velocity команды нельзя сравнивать между командами**: 40 SP в команде A не равно 40 SP в команде B.
Команда оценила задачу в 13 SP. Что это означает?
T-Shirt Sizing
**T-Shirt Sizing** - метод быстрой приоритизации backlog'а с помощью категорий XS/S/M/L/XL вместо числовых оценок. Используется когда точность не нужна, но нужно быстро отфильтровать "мелочь" от "слонов".
T-Shirt Sizing идеален для **Product Discovery** и **Roadmap Planning** - когда backlog из 50 идей нужно расставить по приоритетам за одну встречу. Amazon использует подход "two-pizza team" с T-shirt sizing на quarterly planning: команды быстро классифицируют инициативы и отсеивают XL-задачи до появления детального решения.
Перевод T-shirt в Story Points делается командой один раз: XS=1, S=3, M=8, L=21, XL=требует декомпозиции. После нескольких спринтов команда накапливает velocity и может строить прогнозы.
Когда T-Shirt Sizing предпочтительнее Story Points?
#NoEstimates
**#NoEstimates** - движение (Vasco Duarte, 2012), утверждающее что традиционные оценки создают ложное чувство уверенности и генерируют overhead без реальной ценности. Вместо эстимации - декомпозиция задач до одинакового размера и измерение throughput (пропускной способности).
Ключевые аргументы #NoEstimates: 1) **Estimation bias** - люди систематически недооценивают задачи (Planning Fallacy, Канеман). 2) **Sunk cost** - команды тратят 10-20% спринта на сам процесс оценки. 3) **False precision** - оценка в SP всё равно ошибается на 40-60% для новых типов задач.
Basecamp (создатели Ruby on Rails) работают по #NoEstimates: команды берут "appetite" (сколько времени стоит потратить на фичу) вместо оценки. Если за 6 недель не уложились - фича возвращается в backlog или переосмысляется. Это называется Shape Up methodology.
Что является основой прогнозирования в #NoEstimates подходе?
Planning Poker
**Planning Poker** - техника коллективной оценки задач, при которой каждый участник выбирает карту с числом независимо, а затем все открывают одновременно. Расхождения в оценках запускают дискуссию, выявляя скрытые риски и разное понимание задачи.
Planning Poker основан на **Delphi method** - итеративном сборе мнений экспертов до консенсуса. Одновременное раскрытие карт исключает **anchoring bias** (влияние первой названной цифры на остальных). Если трёх раундов недостаточно - задача требует декомпозиции или дополнительного исследования (spike).
GitHub Engineering ввёл анонимное голосование через Slack-бота: `/estimate 5` и бот показывает все оценки одновременно. Это убирает социальное давление - junior не боится поставить 13 когда все ставят 3, если действительно видит сложность.
Planning Poker - пустая трата времени, лучше просто спросить техлида
Коллективная оценка выявляет скрытые предположения и риски, которые каждый держит в голове, но не озвучивает
Когда только техлид оценивает - команда не понимает задачу и не берёт ownership. Расхождение в оценках (например 3 vs 13) почти всегда означает, что люди решают разные задачи в голове. Дискуссия синхронизирует понимание до начала работы.
Почему в Planning Poker все участники открывают карты одновременно?
Итоги
- **Story Points** измеряют относительную сложность, а не время - velocity конкретной команды строит прогнозы через накопленную статистику
- **T-Shirt Sizing** (XS/S/M/L/XL) - инструмент для быстрой приоритизации большого backlog'а на уровне roadmap, а не спринта
- **#NoEstimates** предлагает измерять throughput (задач/неделю) вместо SP - это работает если задачи декомпозированы до примерно одинакового размера
- **Planning Poker** ценен не консенсусом, а дискуссией при расхождениях - она синхронизирует понимание задачи до начала работы
Связанные темы
Эстимация неотделима от процессов доставки и команды:
- Kanban и Lean — Kanban-метрики (cycle time, throughput) - основа #NoEstimates подхода
- Техническое лидерство — Техлид фасилитирует Planning Poker и отвечает за реалистичность оценок перед стейкхолдерами
- CI/CD Pipeline — Скорость pipeline напрямую влияет на velocity команды - медленные билды снижают количество завершённых задач
Вопросы для размышления
- Какой метод эстимации используется в текущей команде? Насколько точными оказываются оценки на практике?
- Бывали ли случаи, когда разные участники команды оценивали одну задачу кардинально по-разному? Что это выявило?
- Если бы команда перешла на #NoEstimates - что изменилось бы в планировании спринтов и общении со стейкхолдерами?