В Agile-сообществе идут непрекращающиеся дебаты по поводу преимуществ использования “пунктов” и/или идеальных часов для планирования спринта. У каждого лагеря есть свои доводы в пользу преимущества одного подхода над другим.

Майк Кон является главным сторонником разбиения Историй Пользователя на задачи, которые потом оцениваются в часах. В тоже время, Джеф Сазерленд говорит, что одни из самых лучших команд, с которыми он работал, сжигали “пункты”. И еще многие аджилисты выразили свои точки зрения по поводу того, что они предпочитают и почему.

Майк не любит использовать “пункты” при планировании спринта, поскольку они скорее служат долгосрочными оценками и не очень подходят для краткосрочных планов. В своей статье Майк пишет

Представьте себе баскетбольную команду в середине сезона. Они в среднем получали по 98 очков за игру в течение 41 игры. Будет справедливо, если они заявят: “скорее всего, мы будем забивать в среднем по 98 очков до конца сезона”. Но они не должны говорить перед каждой отдельной игрой: “Наш средний счет 98, и поэтому сегодня мы тоже забьем 98 очков”.
Вот почему я говорю, что средняя скорость полезна для долгосрочных планов, но бесполезна для краткосрочных прогнозов.

Тара Ли Вайтакер не согласна, что “пункты” не годятся для краткосрочных оценок. Она пишет:

Если каждая история достаточно маленькая для того, чтобы ее “точно” оценить, и достаточно проверяемая, чтобы создать приемочные тесты, тогда вряд ли будут выгоды от разбиения ее на более мелкие части и переоценки их в часах.

Она выражает большие сомнения о целесообразности оценки историй в часах.

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

Джим Шиель допускает, что можно планировать спринт одновременно в “пунктах” и часах. Тем не менее, полезность времени, потраченного на оценку в часах, невысока, чтобы сделать этот вариант целесообразным. Как говорит Джим:

Тепер, давайте посмотрим на Scrum команду, которая планирует на спринт десять 2х “пунктовых” элементов бэклога. Если они закончат их все, то они получат среднюю скорость 20 “пунктов” в итерацию. На следующий спринт, они, скорее всего, возьмут 20 “пунктов” опять. И на последующий спринт –  плюс/минус столько же, в зависимости от того как пройдет предыдущий. Это будет продолжаться от спринта к спринту, и средняя скорость команды будет где-то между 18 и 22.

Можем ли мы сделать тоже самое с часами? Да, но это будет стоить нам гораздо больших денег, для того чтобы сделать это правильно. За что ВЫ готовы платить: за работающий продукт или за точные оценки?

Джек Милунски еще больше подкрепил значимость “пунктов”, когда упомянул о следующих преимуществах:

* Универсальные измерения – “Пункты” являются универсальным измерением для всей команды. Они не привязаны к чьему-то одному опыту или навыкам, и основаны на общих знаниях всей команды.
* Устойчивость измерений – После трех или четырех спринтов, команда достигает постоянства в своих оценках, и это облегчает Владельцу Продукта работу по заполнению бэклога продукта элементами, оценками которых не меняются постоянно.
* Зона доверия – Как только команда достигает постоянства в своих оценках, то бизнес начинает считаться с технической командой, и это позволяет ей переместиться в зону доверия и высокой мотивации.

Томас Бъоркхолм упоминает следующие доводы в пользу подхода “пунктов”:

Повод №1. Оценки в “пунктах” – это подход по определению размера истории, а не то, как долго займет ее реализация.
Повод №2. Идеальный рабочий день – это единица, которая изменяется со временем, в зависимости от общей командной производительности. В тоже самое время, “пункты” относительно постоянны.
Повод №3. Доказано, что относительные оценки более точны, нежели абсолютные, и так как идеальные рабочие дни так или иначе связаны с единицами времени, то легко продолжать делать абсолютные оценки, даже если они будут использоваться как относительные.

Томас также добавляет:

Во время рассказа о Помодоро технике (Pomodoro technique), Стефан Нотеберг упоминает, что большинство людей чувствуют себя некомфортно, когда вынуждены давать оценку в реальных часах. Ага, подумал я, когда людям некомфортно, то они менее продуктивны, поэтому и оценка в днях менее продуктивна.

Майк Кон предполагает, что нет линейной зависимости между “пунктами” и количеством часов. Согласно Майку, есть размах распределения у каждой истории по сравнению со стандартным отклонением.

Один “пункт” равен распределению со средним X и некоторым стандартным отклонением. То же самое относится, конечно, к двух “пунктным” историям, и так далее …

Исходя из этого, мы не можем сказать заказчикам, что при определенной скорости в “пунктах” команда может дать прогноз окончания проекта к определенной дате. Это должен быть некий промежуток времени.

Этот промежуток может быть вокруг определенных дат, например “Мы можем завершить все элементы бэклога продукта, и это будет Май или Июнь, когда мы закончим”. Или это может быть промежуток функциональности, например “Мы можем закончить проект 20-го мая, как вы хотите, и это будет где-то между 120 и 140 пунктами, что соответствует вот этому промежутку в бэклоге продукта”.

Майк Кон также предложил альтернативный путь, который соответствует принципами бережливого производства (Lean), называется планирование спринта через приверженность инициативе. В рамках этого подхода, команды не обсуждают “пункты” или скорость. Они просто берут высокоприоритетные элементы бэклога, разбивают их на задачи и оценивают их в часах, и потом берут работы в соответствии с их доступными возможностями, а после этого просто идут и выполняют свои обязательства.

Таким образом, существуют “за” и “против” каждого из подходов к планированию спринта. В конце концов, все может сводиться к тому, что удобно для вашей конкретной команды.

А какую технику предпочитаете вы и почему?

Написано Викасом Хазрати (Vikas HAzrati) для сайта InfoQ.