В 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.

Планирование Спринта: "Пункты" против Часов
Tagged on:             
  • DmytroL

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

    Это все замечательно, но только в том случае, если бизнесу не нужно средне- и долгосрочное планирование. В каких-то проектах оно действительно не нужно, но я вполне могу представить себе и заказчиков, которых явно не устроит ответ «сделаем, когда сделаем» — даже если команда демонстрирует стабильный прогресс

  • Дима, согласен, что подход через «приверженность инициативе» не должен идти сам по себе.
    На мой взгляд, хорошо работает комбинация подходов: для долгосрочного планирования используется средняя скорость, а уже для планирования каждого спринта «commitment» и фокус-фактор.

  • Дима, согласен, что подход через «приверженность инициативе» не должен идти сам по себе.
    На мой взгляд, хорошо работает комбинация подходов: для долгосрочного планирования используется средняя скорость, а уже для планирования каждого спринта «commitment» и фокус-фактор.

    В тоже время, всегда набирать работу в спринт только по средней скорости не целесообразно и это быстро становиться понятно.