Инструмент, придуманный для упрощения работы, стал самоцелью, и это зло.
В статье 2019 года, почти 20 лет спустя после появления идеи Story Points, автор методологии описывает вырождение неплохой, в общем-то, идеи. Сравнивать скорость команд, превращать Story Points в KPI и требовать «делать больше» — путь в никуда.
Автор статьи — Рон Джеффрис: соавтор Agile-манифеста, один из создателей методологии Extreme Programming, человек, которого называют автором Story Points. В этой статье он критикует свою же методологию. И мы в Хекслет решили перевести его опус о «Story Points» и разобраться, за что же Рон так возненавидел своё творение.
Рон Джеффрис — один из трёх создателей методологии «экстремальное программирование» (XP) и подписант Agile-манифеста. Именно его называют автором идеи Story Points — системы оценки сложности задач. Статья вышла ещё в 2019 году, и с тех пор в ней мало что устарело.
Ситуация, знакомая многим: руководство просит «привести оценки к единому масштабу», сравнивает скорость работы двух команд, а на ретро спрашивает, почему фактическое время исполнения задачи разошлось с оценкой. Или того хуже — превращает поинты в KPI и требует «делать больше».
Джеффрис, придумавший метрику Story Points, рассказывает, почему так делать не стоит. Он говорит: инструмент выродился, стал самоцелью и мешает главному — достигать реальных результатов.
Мне нравится говорить, что это я, возможно, придумал Story Points. И если это так, то теперь я сожалею об этом. Давайте обсудим мой нынешний взгляд на Story Points: по крайней мере одному из нас интересно, что я думаю по этому поводу.
Пользовательские истории (User Stories) пришли, как известно, из Extreme Programming, а не из Scrum. Специалисты по Scrum каким-то образом их переняли.
Несмотря на то, что в официальном Scrum Guide используется термин «элементы бэклога», превращение этих элементов в пользовательские истории стало распространённой практикой в Scrum. По крайней мере в тех случаях, когда истории применяют правильно, а это происходит не всегда.
Я уже писал о том, как стоит использовать пользовательские истории. А здесь речь пойдет именно о Story Points.
В Extreme Programming пользовательские истории изначально оценивались по времени — по тому времени, которое требуется для их реализации. Довольно быстро мы пришли к понятию «идеальных дней», которое неформально описывалось как время, за которое пара разработчиков сделала бы задачу, если бы всякие мерзавцы им не мешали.
Идеальные дни умножались на «коэффициент нагрузки» — так мы получали реальное время реализации. Обычно этот коэффициент был около трёх: чтобы получить результат одного идеального дня разработчики тратили три реальных.
Мы говорили об оценках в днях, обычно опуская слово «идеальный». В итоге заказчики часто не понимали, почему требуется три дня на работу, заложенную на один «идеальный день» или почему мы не можем выполнить работу пятидесяти «идеальных дней» за три недели.
Насколько я помню, именно тогда вместо термина «идеальные дни» мы начали использовать понятие “points”. Так, пользовательская история могла получить оценку в три поинта, что означало примерно девять реальных дней на реализацию. В основном мы использовали points только для того, чтобы решить, сколько работы взять в итерацию, и если мы говорили «набралось около 20 поинтов» — никто особо не возражал.
Возможно, именно я предложил сменить название. Если это так, то теперь я об этом сожалею.
Вот некоторые мои мысли на эту тему, взятые из письма моему коллеге Саймону, который задал такой вопрос:
Ты действительно жалеешь, что изобрёл Story Points, или тебе просто не нравится, когда их используют неправильно, не понимая идею относительной оценки?
Я ответил, что:
Мне действительно не нравится, когда Story Points используют неправильно.
Я считаю, что использовать Story Points для прогнозов «когда мы закончим работу» — это, в лучшем случае, слабая идея.
Я считаю, что сравнивать фактические показатели с прогнозами — в лучшем случае пустая трата времени.
Я считаю, что сравнивать команды по качеству их прогнозов или по скорости — вредно.
Взглянем на всё это повнимательнее.
Некоторые подходы в Agile действительно рекомендуют приводить Story Points в разных командах к единому масштабу — ради удобства планирования. На первый взгляд это звучит разумно, но при таком подходе легко скатиться к сравнению команд между собой, и, увы, организации зачастую именно так и поступают.
Сравнение команд
Прежде всего: даже если две истории «выглядят одинаково», у каждой команды свои навыки и рабочая среда. Поэтому если команды смотрят на две истории, которые выглядят сходными, и одна команда назначает истории два поинта, а другая — шесть, то само по себе это не особенно интересно и уж точно не может служить хорошим способом для сравнения команд.
Мы с вами, увидев такую ситуацию, отнеслись бы к ней с любопытством. Сначала стоило бы разобраться, действительно ли эти истории сопоставимы, а затем потребовалось бы понять, не нужна ли команде с более высокой оценкой какая-то помощь, которую мы могли бы оказать. Это был бы хороший подход.
А вот сделать прямой или косвенный вывод «более медленная команда хуже или в чём-то ошибается» — это очень плохо, но, к сожалению, чаще всего так и происходит.
Я думаю, что в ситуации, когда две команды работают над проектом, у многих менеджеров возникает непреодолимое желание сравнить эти команды. И это желание настолько сильно, что я бы предпочел вообще отказаться и от идеи Story Points и, где это возможно, от оценки историй.
Мы ещё вернемся к вопросу о том, как работать с меньшим количеством оценок, этому посвящены и другие статьи.
Отслеживание
Для многих менеджеров само существование прогноза подразумевает, что должны быть и фактические показатели, а значит прогноз нужно сравнивать с фактом и следить, чтобы они совпадали. Если же они не совпадают — то это воспринимается как сигнал, что команда должна прогнозировать работу точнее.
В настоящем Agile мне важно выбрать несколько следующих задач и оперативно их выполнить. Ключевой вопрос в том, чтобы найти самые ценные задачи и сделать их быстро. А быстрое выполнение сводится к тому, чтобы делать небольшие кусочки высокой ценности и быстро итерироваться. Оценка стоимости историй в этом почти не помогает.
Таким образом, сам факт существования оценки отвлекает руководство от создания результата и заставляет его сосредоточиться просто на улучшении прогнозирования — и это отвлекает внимание от главной цели: от быстрой выдачи реальных результатов.
Из этого я делаю вывод, что оценок, что в поинтах, что во времени, лучше избегать.
Давление
С темой оценок и фактических показателей связано естественное давление руководства, которому всегда хочется «больше». Сколько бы команда ни делала, этого всегда недостаточно. Больше, больше, больше.
Лучшая результативность не в том, чтобы делать больше, а в том, чтобы постоянно выдавать результат. Если вместо оценки историй мы будем нарезать истории на достаточно маленькие «кусочки», мы сможем выйти на плавный поток результатов и поставлять их непрерывно.
Фокус на «больше» мешает наращивать результат. Давление «делайте больше» почти всегда приводит к обратному эффекту. Команда пытается ускориться и начинает экономить на качестве кода и тестах. Вскоре она начинает допускать больше ошибок, замедляется из-за возросшего объема переделок и замедляется ещё сильнее из-за быстрого падения качества кода. Ситуация становится всё хуже, давление растет — и всё катится к катастрофе.
Оценка сроков и объёмов так или иначе способствует возникновению этого чрезмерного давления, и я предпочёл бы вообще обойтись без этой оценки.
Пойду ещё дальше. Я предпочёл бы отказаться и от планирования итераций или спринтов. В такой ситуации мы бы не стали заполнять бюджет на следующие несколько недель, а занялись бы составлением списка наиболее важных задач на ближайшее будущее.
Прогнозирование
Обычная практика выглядит так. Составляется список важных задач, о них какое-то время размышляют, а затем решают, что именно из них будет состоять очередной релиз продукта. Следующий вопрос, разумеется, звучит так: «Когда всё это будет готово?».
Ответ в том, что этого не знает никто. Можно проделать большую работу, чтобы уменьшить это незнание, и в некоторых областях и в некоторых случаях оно того стоит — например, когда на кону крупный контракт, который ещё предстоит заполучить. Но если речь идёт о разработке решений для внутренних или внешних заказчиков, лучше часто выкатывать результаты небольшими порциями, чем ждать большого релиза, который вечно отодвигается всё дальше в будущее.
Гораздо лучше выбрать близкую дату следующего релиза для клиентов и включить в этот релиз как можно больше полезных решений. Оценка, будь она выражена в Story Points, в мармеладных мишках или во времени, только помешает такому подходу.
На мой взгляд, от оценки лучше отказаться везде, где это возможно.
Нарезка историй
Возникает вопрос: «если вам не нравится оценка историй, что вам тогда нравится?». Мне нравится нарезка историй — практика, когда большие истории делят на мелкие, каждая из которых максимально ценна, но требует очень немного времени на реализацию, в идеале — меньше дня или даже пару часов.
Я не буду спорить о том, обязательно ли оценивать время при нарезке. Если вы или ваша команда оцениваете задачи в голове и никому об этом не рассказываете, то проблемы, связанные с оценками хоть в поинтах, хоть во времени, скорее всего вообще не возникнут.
И, конечно, оценка на уровне «достаточно маленькая задача» и «недостаточно маленькая задача» — это не то же самое, что оценка «три дня» и «один день».
Кроме того, есть ещё один приём. Я упоминал его в статьях Getting Small Stories и Slicing, Estimating, Trimming. Об этом приёме я узнал от Нила Киллика: нарезайте пользовательские истории до тех пор, пока для их проверки не будет достаточно одного теста. После небольшой практики это позволяет довольно точно подобрать нужный объём задачи.
И, конечно, есть и другие статьи на тему оценки, они доступны на моём сайте по тегам [Agile-Related, Dark-Agile, Dark-Scrum, SAFe, success. чтобы узнать больше, чем когда-либо хотелось.
Предсказание будущего
Но разве не существует объективной потребности знать, сколько времени займёт релиз продукта, и разве для этого не нужны оценки?
Возможно. Но не факт, что нужно оценивать именно пользовательские истории. Скорее всего, вы не сможете детализировать требования проекта до уровня историй, а если и сможете, то эти требования, скорее всего, окажутся слишком громоздкими и, по большей части, бесполезными.
Разумеется, если вам всё равно приходится это делать — делайте. Что бы я ни делал сам и что бы я ни думал о том, как вы должны поступить, это всего лишь мои идеи. В конце концов вам придётся делать то, что нужно для успеха именно в вашей ситуации. Но, на мой взгляд, есть подход лучше.
Первым делом обдумайте одну или нескольких важных задач для следующего релиза. Обсудите, какие проблемы они решают и какое программное обеспечение может в этом помочь. Рассмотрите самые простые варианты реализации, которые могли бы дать хоть какой-то эффект. Не обязательно решать все проблемы сразу: будет достаточно небольшого шага, чтобы дело сдвинулось с места.
Затем определите ближайший срок, к которому вы смогли бы реализовать эти задачи. Установите этот дедлайн и приступайте к работе.
Далее: нарезайте важные задачи на тонкие срезы и реализуйте их. Обычно такие срезы довольно легко довести до объёма на день или меньше. Работайте только над самыми важными частями, не пытайтесь довести каждую задачу до идеала. Старайтесь настроиться на мысль «если бы мы просто сделали вот эту штуку, заказчик Джек уже мог бы этим пользоваться». Затем сделайте «эту штуку» и дайте опробовать её заказчику Джеку. Мы хотим как можно быстрее выйти на непрерывную поставку результатов.
Мы хотим сделать свои результаты настолько заметными, чтобы владелец продукта и другие заинтересованные лица не могли дождаться, когда всё это выйдет в свет. И тогда мы будем работать правильно, со Story Points или без них.
Подводя итог
Если я действительно изобрел Story Points, то теперь мне, наверное, немного жаль, но не слишком сильно.
Я действительно считаю, что зачастую их используют неправильно и что многих проблем можно избежать, вообще отказавшись от оценки историй. Если они не приносят вашей команде или компании большой пользы, я бы посоветовал от них отказаться: это лишняя трата ресурсов.
Если же вы их по-прежнему любите — что ж, продолжайте в том же духе!