Оценка — одна из самых спорных тем в Agile-сообществах. Споры обычно идут так: story points против часов, относительное определение размера против абсолютного, #NoEstimates против некоторого числа оценок, planning poker против того, что пришло ему на смену.
Это реальные споры. И они, как правило, упускают более глубокую проблему — то, что аргументы о том, как оценивать, подменяют разговор о том, не является ли проблемой сама модель оценки.
Что Agile на самом деле говорил об оценке
Agile возник не для того, чтобы помочь командам лучше оценивать. Он возник, потому что кто-то заметил: в комплексной работе (в кеневиновском смысле: эмерджентной, где причинно-следственные связи видны лишь ретроспективно) — работе, где полные требования невозможно знать заранее, где правильный подход проявляется по мере дела, — точность, которую обещает оценка, оказывается ложной.
Что на самом деле означает «комплексная работа»
Эту фразу — комплексная работа, работа, где полные требования невозможно знать заранее — легко пропустить. Не стоит. Это главное, несущее утверждение поста: не усвоив его, всё последующее можно принять за спор о техниках оценки, а не о том, пригодна ли сама оценка для этой задачи.
Комплексная работа — это не про проекты, где команда была недостаточно умна или недостаточно дисциплинированна или где ещё не применили правильную методологию. Это обозначение отдельной категории: работы, где связь между причиной и следствием можно понять только задним числом. Где правильный подход проявляется на практике, а не в ходе анализа. Где требования меняются не потому, что заинтересованные стороны плохо подумали заранее, а потому, что сама работа меняет то, что нужно.
Методологии — даже превосходные — созданы для простой и сложной работы. Они действуют, применяя известные паттерны к известным типам задач. В этом и есть их ценность в тех контекстах, для которых они создавались. У комплексной работы известных паттернов нет. У неё есть эмерджентные. Применение методологии к комплексной работе не решает проблему — оно создаёт иллюзию структуры, тогда как реальная неопределённость остаётся нетронутой. Мини-Waterfall — короткоцикловое последовательное планирование, которым незаметно стали многие внедрения Agile, — попадает в ту же категорию. Длина итерации меняется; базовое допущение, что предварительное планирование способно надёжно направлять работу, — нет.
«Беспощадное упрощение» — родственный рецепт, который стоит рассмотреть. Если работу действительно можно свести к известному типу задачи — упростите, это хорошая практика. Но это гигиена, а не управление комплексной работой. То, что остаётся после всех возможных упрощений, — это та часть, которая упрощению сопротивляется, то есть сама комплексная работа; ей нужно то, чего стратегии упрощения дать не могут. В 2025 году, если конкурентный ответ на комплексность звучит как «надо упрощать ещё больше», то разговор о реальном управлении комплексной работой ещё даже не начался.
Публичный разворот Джеффриса — это не просто смена мнения о единице измерения. Это признание чего-то более глубокого: предпосылка была неверной. Оценка предполагает категорию работы, где предварительный анализ даёт надёжные прогнозы. Для простой и сложной работы это допущение выполняется достаточно хорошо. Для комплексной работы — нет, и никакая отшлифовка техники этого не изменит. Однажды усвоенное, это понимание меняет смысл всего дальнейшего.
Двухнедельный спринт, поставляющий работающее ПО, — это не лучший метод оценки. Это замена оценки эмпирическим измерением. Вместо того чтобы предсказывать, сколько времени займёт работа, вы измеряете, сколько на самом деле сделано — в реальных условиях, реальными инкрементами. Предсказание уступает место ритму и циклу обратной связи.
Это не тонкое различие. Оно означает, что команды, которые работают по Agile-процессам, но по-прежнему считают целью точную оценку в story points, в корне не поняли, зачем этот процесс нужен.
Почему споры не утихают
Споры об оценке не утихают отчасти потому, что организации, принявшие Agile, не отказались от своей исходной потребности — систем управления, построенных на прогнозах, бюджетах, сроках, контрактах. Agile-церемонии просто наложили поверх этой потребности. Story points стали заменой часам. Velocity стала исходными данными для планирования. Agile-словарь переняли, а ожидание прогнозов — нет.
Сложившаяся ситуация и правда неоднозначна. Одни команды работают там, где «никаких оценок» действительно возможно, — где заинтересованные стороны научились доверять эмпирической поставке и не нуждаются в прогнозах. Другие — там, где контракты, нормативные требования или организационная культура делают ту или иную форму прогнозирования неизбежной.
Позиция Agile не в том, что оценка всегда ошибочна. Она в том, что оценка в комплексной работе структурно ненадёжна — что приписываемая оценкам уверенность регулярно превышает реальные основания для неё, — и что дисциплина коротких циклов поставки с живой обратной связью улучшает предсказуемость сильнее, чем более совершенные методы оценки.
Проблема единиц измерения — и закономерность, которую стоит заметить
Сейчас в Agile-кругах набирает популярность отход от story points к Идеальным Человеко-Дням (IPDs) — возврат к оценке на основе времени, который его сторонники считают более интуитивным и более простым для защиты перед заинтересованными сторонами.
Стоит знать, откуда взялись story points. Рон Джеффрис — один из трёх основателей Extreme Programming и один из тех, кто подписал Agile-манифест, — изобрёл story points. Они выросли напрямую из ideal days — единицы на основе времени, которую XP-команды использовали изначально. Беда с ideal days была в том, что заинтересованные стороны слышали «три ideal days» и понимали это как обязательство уложиться в три дня, несмотря на оговорку «ideal». Поэтому отметку о времени убрали, и единицей стало голое число. Story points по своему происхождению — это ideal days, у которых убрали привязку ко времени именно для того, чтобы их не воспринимали как обязательства по срокам.
С тех пор Джеффрис написал об этом прямо. «Мне нравится говорить, что story points, возможно, придумал я, — написал он в 2019 году, — и если так, то теперь мне жаль». Сегодня он один из самых заметных сторонников #NoEstimates — позиции, согласно которой проблема не в том, какую единицу оценки вы используете, а в том, что оценка в комплексной работе принципиально ненадёжна независимо от единицы.
Стоит спросить, почему переход к IPDs происходит именно сейчас. Дело не в том, что команды нашли лучший метод оценки. Дело в том, что IPDs ложатся на финансовую инфраструктуру Waterfall — бюджетные циклы, системы проектного учёта, модели выставления счетов по контрактам и инструменты планирования штата, которые организации выстроили вокруг планирования на основе времени и не стали менять, когда переходили на Agile. Story points в эти системы не вписываются. IPDs — вписываются.
Это не эволюция Agile. Это Waterfall, который вновь заявляет о себе в одеждах Agile, — используя финансовые структуры, которые так и не демонтировали, чтобы тянуть практику назад к той модели, ради которой эти структуры и создавались. Единица оценки изменилась; организационная система, требующая обязательств по срокам, — нет. Результат — тот же театр прогнозов, только под новым названием.
Это не компании наконец-то берут штурвал и исправляют упущенное Agile. Это компании заново утверждают инфраструктуру, которая так и не изменилась. IPDs не требуют никакого сдвига в мышлении, понимании или взгляде на мир — вы просто переклеиваете ярлык на то, что и так знаете. Именно поэтому они набирают обороты.
Здесь Agile-сообщество упустило шанс на лидерство. Когда спрос на оценки сроков вернулся под видом IPDs, правильным ответом было назвать происходящее своим именем: это финансовая логика Waterfall вновь утверждается над практикой Agile. Вместо этого многие практики пошли навстречу, восприняв этот спрос как ограничение, которым надо управлять, а не как ошибку категории, которую надо исправить. В итоге команды, наиболее свободно владеющие Agile-словарём, часто реализуют самую изощрённую версию той самой модели, которую Agile должен был заменить.
Человечество учится медленно
Здесь есть закономерность глубже, чем методология оценки. Это привычка принимать смену ярлыка за смену практики — путать переход на новый словарь со сдвигом мышления, который этот словарь и должен был выразить.
Определение безумия, приписываемое Эйнштейну, цитируют часто и обычно ошибочно, но оно неизменно попадает в точку: делать одно и то же снова и снова, ожидая иного результата. Авторство, скорее всего, апокрифично. Закономерность — нет. Организации, перенявшие Agile-церемонии без Agile-мышления, теперь перенимают церемонии ему на смену, не проверяя, изменилось ли мышление под ними. Слова другие. Модель та же.
Разговор, который этот пост пытается начать, — не о единицах оценки. Он о том, действительно ли ваша организация разобралась, что такое комплексная работа и чего она требует. Если ваша инфраструктура планирования не изменилась — если вам по-прежнему нужны прогнозы, обязательства и учёт на основе времени, исходящий из того, что предварительный анализ даёт надёжные предсказания, — тогда споры об оценке лишь симптом. А указывают они на то, что сдвиг, который предлагал Agile, ещё не случился.
Комментарии 0