Материал из AgileWiki

Определение

Статьи

Story points vs Ideal hours vs man/hours

Тема сегодняшней статьи навеяна долгой дискуссией с коллегами по поводу нужности, важности и вообще применимости такого инструмента планирования, как story point.

В частности, спор велся о том, что лучше и легче использовать — story points, идеальные часы или реальные человеко-часы. Давайте начнем сравнение с того, что дадим определение каждому из инструментов.

Человеко-час: это количество работы, выполняемой средним работником за один час.

Идеальный час: количество часов в день, которые работник тратит на непосредственное выполнения задач перед ним поставленных. В эти часы не входят всякого рода чаепития, совещания, игры в Quake3 и прочие, не очень относящиеся или совсем не относящиеся к работе занятия. В очень хорошем случае у вас в одном рабочем дне будет 7 идеальных часов. Нижней границы нет: в некоторых особо запущенных проектах хорошо, если их 3-4.

Story point: единицы относительного размера, используемые в оценке требований как альтернатива единицам времени. Story points — единицы измерения сложности или размера требования, а не количества времени, требуемого для реализации требования.

А теперь ответьте, пожалуйста, на вопрос: что лучше подходит для оценки, ну скажем, необходимой мощности трансформатора: вольты или амперы? Ну или если электричество в свое время прошло мимо вас, что лучше подходит для оценки красоты здания: количество используемых цветов или площадь поверхности под витражами?

Для тех, кто не понял, к чему я клоню скажу прямо: story point нельзя сравнивать ни с человеко-часами, ни с идеальными часами — это совершенно разные инструменты. Идеальные часы и часы — сравнивайте на здоровье, даже формула есть для конвертации одного в другое. Но поскольку блог о Scrum, далее мы поговорим об идеальных часах и story point, о том, как они могут и должны использоваться в одной и той же команде.

Если вы хоть раз принимали участие в Scrum-треннинге, вам наверняка приводили такой пример: вам показывали ближайшее здание и спрашивали ваши соображения насчет его высоты. После сравнительно небольшой паузы вы наверняка выдавали число, причем понятия не имели насколько оно соответствует действительности. А потом вам показывали второе здание и спрашивали, насколько первое здание выше или ниже второго. Тут вы наверняка быстро и уверенно отвечали на вопрос.

В этом, собственно, и заключен основной принцип story point. Человеческий мозг устроен таким образом, что ему легче сравнивать, чем оперировать абсолютными величинами.

Теперь об идеальных часах. Оценка в идеальных часах делается следующим образом: сначала делается оценка в идеальных часах, а потом вы умножаете полученное значение на определенный коэффициент в итоге получая оценку в реальных часах. Коэффициент рассчитать просто — посчитайте сколько времени из 8 рабочих часов в день вы тратите непосредственно на работу, а потом разделите 8 на это значение. Пример:

Допустим, за день я успеваю:

1. Daily scrum — 15 минут

2. 2 партии в Quake3 по 15 минут каждая

3. Каждый час выхожу покурить по 5 минут каждый из перекуров

4. В среднем меня отрывают от работы 5 раз за день, каждый раз на 5 минут

Итого: 15 + 30 + 40 + 25 = 110 минут ~ 2 часа. Т.е. в моем случае коэффициент пересчета будет равен 1.333. Таким образом, если я считаю, что на задачу нужно потратить 12 часов, на ее выполнение я планирую 16.

Если у вас возник вопрос зачем же все-таки нужны story points, если есть идеальные часы, то именно сейчас вы получите ответ на этот вопрос.

В проекте, который разрабатывается по Scrum есть несколько видов детализации задач: user stories и, собственно, задачи или task'и.

User stories — это большие и концептуальные описания требований на очень высоком уровне. Пример:

В качестве пользователя системы Google Reader я могу импортировать все свои RSS-ленты с использованием OPML для того, чтобы я мог читать их с использованием этой системы.

Story points используются для оценки именно user stories. И тому есть несколько причин:

1. Поскольку user stories обычно очень велики их долго точно оценить в часах

2. Поскольку user stories специально не содержат всех деталей их очень сложно точно оценить в часах.

Story points — это инструмент для планирования релизов — как окончательных, так и промежуточных. Для этого вам нужно собрать статистику, сколько story points «сжигает» команда за один спринт — вы получите так называемую velocity. Далее, просуммировав story points во всем product backlog и разделив это значение на velocity вы получите количество спринтов, необходимое для того, чтобы реализовать все требования в product backlog на текущий момент (!!!). Вот это «на текущий момент» очень важно. Дело в том, что Scrum не только не запрещает вносить новые требования и изменять существующие, но и поощрает это. А потому и даты релизов могут меняться, а значит вам нужен быстрый и относительно точный инструмент для этих расчетов. Конечно, вы можете потратить неделю составляя детальный Gaant chart и оказаться очень разочарованным когда неделя вашей работы пойдет на смарку из-за отклонений ваших оценок от действительности и из-за изменений требований проекта.

После того, как релизы спланированы можно переходить к планированию спринта, и тут нужны уже идеальные часы: Story points могут оказаться для вас слишком грубым инструментом для планирования на такой непродолжительный срок как 1-4 недели.

Здесь хотелось бы оговориться особенно: лично я использую story points и для планирования спринтов. Уже минимум полгода команда показывает приблизительно постоянную velocity, все привыкли и прочувствовали понятие story point и, как показывает практика, это работает, как минимум для моей команды. Planning meeting для нас в первую очередь необходим для получения деталей историй, которые мы хотим реализовать и для разбиения этих историй на задачи, которые мы так же оцениваем в story points.

Честно говоря, я несколько раз слышал от различных тренеров о том, что так делать неправильно, но пока не могу ни понять причин этого, ни найти какой-нибудь материал, который бы объяснял почему нельзя планировать спринт использую story points. Жду ваших комментариев!

Источник: http://blog.laway.in.ua/practices/story-points/story-points-vs-ideal-hours-vs-manhours/

Комментарии:

Хорошая статья. Чувствуется, что объяснение шло от самого сердца и основывалось на личном опыте, что самое важное :-)

По поводу последних вопросов самому себе об использовании Story Points, я думаю в этой же статье есть и ответы. Попробую процитировать и прокомментировать. "... Story point: единицы относительного размера... "

Абсолютно верно. Основная цель использования этого инструмента — абстрагироваться от метрических оценок (часы, метры, см и т.п. ) и начать СРАВНИВАТЬ User Stories между собой, а не используя некий «золотой эталон» который существует для _всех_ метрических единиц.

"... Story points — это инструмент для планирования релизов ... "

И это тоже верно. Майк Кон, автор книг Agile Estimation and Planning и User Stories Applied, постоянно повторяет: 3 уровня планирования — три уровня точности.

На уровне Product Backlog, где мы планируем релиз из нескольких итераций, нам нужны Story Points как инструмент долгосрочного планирования. Цитата: «... а значит вам нужен быстрый и относительно точный инструмент для этих расчетов» :-)

На уровне Спринта (итерации), мы уже говорим о 10 рабочих днях, которые мы ощущаем вполне физически, а с поправкой на идеальные часы, бюджет команды очень и очень осязаем. Тоже самое происходит с работой — каждую фичу (Историю Пользователя) мы начинаем разбивать на _конкретные_ технические задачи. Поэтому на этом уровне, уже не составляет труда найти вполне точное соотношение (т.е. оценку каждой _задачи_ в идеальных часах).

Ну и на уровне каждого дня, любой человек может выбрать примерно то, что он думает успеет за сегодня и на следующий день команда выясняет успел или не успел. В тоже время, по сравнению с одним рабочим днем общий бюджет спринта достаточно велик и если кто-то ошибся на 1 час в большую сторону, то скорее всего кто-то другой ошибся в меньшую, поэтому команда все равно видит ясную картину всего спринта.

Когда планируем спринт, то можно использовать _СРЕДНИЙ VELOCITY_ как усредненный показатель. Т.е. «вчерашняя погода» — он ни в коем случае не ограничивает количество работы, которое команда может взять на себя в спринте — это просто индикатор. Типа знака «Внимание» на дороге, который говорит, что мы прошли критическую точку и теперь каждую новую фичу нужно внимательно анализировать, чтобы быть уверенным, что мы успеем ее закончить.

И на последок от себя лично, конкретно про вашу ситуацию: это здорово, что вы уже выработали постоянный ритм и в то же время плохо, что команда начала выводить прямой коэфициент между Story Points и часами (пусть даже идеальными). Думаю следует вернуться к первой цитате и напомнить об относительном, а не абсолютном сравнении. Может вам поменять шкалу? :-D

P.S.

Сорри, за «много буков»

Тимофей Евграшин
Источник: http://blog.laway.in.ua/practices/story-points/story-points-vs-ideal-hours-vs-manhours/#comment-61

Случайно забрел на твой блог и решил добавить маленький комент под эту статью. На самом деле оценка стори пойтнов или человеко-часов имеет несколько более глубокий смысл.

Любая оценка выставляемая во время игры в карты является командной собственностью.

Что же это значит? Это значит многое, но я бы хотел остановиться на «ответственности».

За метрику использованную во время игры в карты в ответе находится команда. Это и есть ключевой момент который может выступать как в роли защиты команды так и в роли контроля ответственности каждого из членов команды. Все будет зависеть только от выбранной метрики и/или желания менеджера/скрам мастера и конечно же ряда возможных других причин ...

Итак в случае оценки в часах мы получим не только ответсвенность команды в часах перед клиентом, но и усредненную ответственность каждого человека в команде.

В случае же стори пойтнов мы получим ответственность команды за стори пойнты перед клиентом и индивидуальную отвественность за индивидуальную оценку тех или иных задач в часах, предварительно усреднено оцененных в стори пойнтах.

В обоих случаях мы что-то выиграем и что-то проиграем. Что конкретно, я думаю можно догадаться.

Alexey Nayda
Источник: http://blog.laway.in.ua/practices/story-points/story-points-vs-ideal-hours-vs-manhours/#comment-108