По следам перевода статьи Джефа Сазерленда опубликованного сегодня на сайте Agile Russia.
Тема стори поинтов интересная и на моих тренингах вопросы о стори поинтах задаются постоянно. Хотелось бы раскрыть эту тему побольше. К великому сожалению, люди очень плохо умеют оценивать в абсолютных величинах. Насыпьте в небольшой стакан гороха и попросите 10 случайных людей оценить сколько в нем горошин. Или попросите людей навскидку прикинуть какова длина спортивного зала в шагах. Запишите ответы. Результаты будут неутешительны. Большой разброс оценок, и цифры в среднем будут очень далеки от истины.
С другой стороны, люди очень неплохо умеют делать относительные (сравнительные) оценки. Отберите из стакана 50 горошин, и сделайте 10 шагов начиная от стенки в спорт зале. Внезапно, большинство людей сможет дать оценку очень близкую к истине. Глядя на то, какая часть гороха исчезла из стакана и видя какую примерно часть спортзала вы уже прошли, люди смогут сказать: “ага, из стакана исчезла пятая часть гороха, значит полный стакан где-то 250 горошин”, или “он уже прошел примерно десятую часть спортзала, значит весь зал – 100 шагов”.
Насчет неумения оценивать в абсолютных величинах, есть множество научных источников. Отдельным блог постом Люди не умеют оценивать, вынес результаты самого веселого, из повстречавшихся мне, исследования, проведенным норвежским научно-исследовательским институтом Simula Research Lab.
Итак, первый вывод: мы не умеем оценивать в абсолютных величинах, и неплохо оцениваем в относительных.
Сначала пройдемся по понятиям: многие оценки, которые делают разработчики сегодня – абсолютные (мы пытаемся оценить протяженность по времени, а именно сколько я буду делать ту или иную задачу), делаются, такие оценки, обычно в идельных часах (или идеальных днях). Делая их, человек думает, что он не будет отвлекаться на звонки телефона, е-мейлы, твиттер, в контакте, фейсбук, одноклассники, не будет ходить в туалет, пить кофе, курить, отвечать на глупые вопросы коллег, достали, гады, чтоб они… со своими вопросами… под землю… что-то я отвлекся :). Так вот, человек думает, что он сфокусируется на этой задаче и будет поглощен ею целиком и полностью, и в этом случае сделает ее за Х идеальных часов.
Лирическое отступление. Типично, после произведения такой оценки, человек просто умножит полученное на греческое число пи (чтобы скомпенсировать идеальность) и сообщит полученное число куда следует (читай: проджект менеджеру или менеджеру или еще куда). Кстати, проджект менеджер сложит, оценки полученные от всех участников проекта и снова умножит на греческое число пи :). И так далее поднимаясь по служебной лестнице вверх и умножая на пи (3,14159263589… дальше не помню я всего лишь физмат заканчивал). Самые смелые, кстати, умножают на е (2,718281828).
Возможно оценивать задачи в стори поинтах, или, давайте все-таки в попугаях, так оно роднее как-то и ухо не так режет. Итак, вместо того, чтобы пытаться оценить длительность задачи по времени, мы будем стараться оценивать ее размер, по сравнению с другими задачами. Это ключевой момент, давайте я повторю эту фразу, перечитайте ее и задумайтесь: Не оценивайте длительность задач по времени! Оценивайте размер этой задачи, по отношению к другим задачам.
Таким образом, если мы выберем некую контрольную задачу и присвоим ей размер в 2 попугая, все остальные задачи будут оценены, по отношению к этой контрольной. Типа, это выглядит в два раза сложнее контрольной, значит это 4 попугая, а эта выглядит в два раза легче, значит – один попугай. Попугаи как известно, гораздо лучше (причем не только потому, что удав в них длиннее).
Предположим, что мы сделали оценку бэклога в (идеальных) часах. Получили, к примеру, 5000 часов суммарно. Вдруг, выясняется, что мы ошиблись с оценкой одной из задач. Она вместо первоначально оцененных 10 часов, на самом деле теперь оценивается в 40. Гант накрылся, вместе с ним и критическая линия, и теперь проджект менеджеру предстоит неутешительная задача перепланирования всего-всего. Это проблема абсолютных оценок.
Теперь постараемся взгянуть на ту же ситуацию, если оценка производилась в попугаях. То есть, мы оценили беклог, и, всего, получилось 5000 попугаев. Вдруг выясняем, что то, что было 10 попугаев, стало 40 попугаев. Есть ли в этом какая-либо проблема? Как выясняется особых проблем нет. При подобной ошибке, лишь упадет средняя скорость команды, но никаких поправок и изменений вносить не потребуется. Ошибка будет съедена нашими условными единицами. Просто количество попугаев сделанных в итерацию станет меньше и мы сможем сделать прогнозирование окончания даты проекта, на основе этой средней скорости.
Таким образом, второй вывод: не пытайтесь оценивать длительность задач, оценивайте их отностительный размер и потом вычисляйте длительность.
А какими единицами измерения пользуетесь вы? Делимся в комментариях.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
" У разработчика все-равно есть чувство насколько одна работа сложнее другой."
В статье и комментариях столько ложных (или не работающих в общем случае) утверждений, что это бросает тень на компетентность в затронутой теме.
День добрый, Сергей, в вашем примере вы как раз приводите пример как работают расчеты при относительных оценках (оценки в story point как раз относительные, абсолютные оценки это оценки в часах или человеко-днях).
Коллеги, добрый день.
Объясните, а как использовать относительные оценки при расчете с заказчиком ?
в случае абсолютных оценок всё понятно: 1000 руб/story point * 5 story point = 5000 руб.
А как рассчитываться с заказчиком, если оценки относительные ?
[…] не умеют оценивать в абсолютных величинах, поэтому стори-поинты лучше, чем часы. Что касается четвертого атрибута (бизнес ценность), […]
[...] как лучше оценивать работу приведена тут в статье Почему стори-поинты лучше, чем часы. Основная идея – проще мерять известными [...]
Cпасибо за комментарий, Илья.
Когда вы пользуетесь стори-поинтами необходимость в фокус факторе отпадает. У вас просто получается некая скорость (velocity), которая учитывает все возможные переменные (прерывания, переключения, отвлечения, и тп) эмпирически.
Я рад что вы привели конкретную цифру не стесняясь. Хочу успокоить вас и огорчить большинство менеджеров, фокус фактор 0,4 для более или менее крупной организации является очень высоким. Большие компании кто реально может похвастаться своей продуктивностью на весь мир приводят примеры с фокус фактором 0,5. Так что ваши 0,4 очень солидный результат. Из моего опыта, я видел организации с отрицательным фокус фактором. Это те предприятия, где люди постоянно фиксят производимые ими баги. Иногда им удается сделать что-то новое, обычно за счет сверх-урочных и энтузиазма своих работников, которые выходят за рамки своих рабочих инструкций :)
Хотел обратить внимание читателей на еще один очень важный аспект вашего комментария, а именно:
Это и есть настоящий аджайл. Надо чтобы было удобно. Нужно помнить, что оценки мы делаем все-таки не ради цифр, а ради того чтобы вместе поговорить о рисках, о нашем понимании проблем, которые собираемся решать, о наших взглядах на возможные решения и тп. Дело же не в цифре в конце-концов.
Я очень расстраиваюсь когда вижу тщетные попытки менеджеров, вывести некий фактор зависимости между стори поинтами и человеко-часами апосля (сам был этим грешен, делая свои первые шаги в аджайл). Потому что стори поинты вещь во многом метафорическая. Именно поэтому многие аджайл команды всерьез задумываются над вопросом "А нужны ли вообще оценки?". Это, наверное, достойная тема для отдельного поста.
Мы на протяжении двух лет пользовались "идеальными днями" но была проблема - сложно сказать лучше мы стали работать или нет. (ведь каждый спринт набирали одно и тоже количество идеальных дней, но фактически за идеальный день стали делать больше). Velocity рассчитывали на основе предыдущих спринтов используя "фокус фактор".
Теперь, стартанув новый проэкт, начали использовать стороипойнты, оценили беклог, на первый спртинт взяли задач и в конце получили "цифру" - наша новая Velocity в сторипойнтах. Нам этой цифрой пользоваться удобно, но наш нынешний сторипойнт объективно больше прежнего "идеального дня". И как следствие фокус фактор стал ниже прежнего - сейчас около 0.4.
Правильно? Или мы что-то упустили в расчете?
1. Есть много примеров работы с "идеальными днями" и много статей о том, что относительные стоорипойнты лучше "идеальных дней". Но как работать со сторипойнтами описано мало.
2. Упоминание фокус фактора чаще используют для идеальных дней, а что со сторипойнтами? пользоваться теми же формулами?
3. Как то тяжело сейчас говорить, что причина нашего низкого фокус фактора это несфокусированность разработчиков на задячах, размер сторипойнта больше чем идеальный день.
Все ваши примеры про горох и шаги говорит не о том, что люди не могут достаточно точно оценивать в абсолютных единицах, потому что понятия абсолютная единица нет.
Все в мире относительно. Поэтом любую "абсолютную" единицу можно назвать относительной, а любую относительную принять за "абсолютную".
Естественно, людям проще оценивать задачи на которые уходит от 0,5 до нескольких дней в днях, а не в секундах. Также и горох в стакане удобнее мерить не горошинами, а частями стакана, состоящими из горошин. Но это не означает, что стакан перестают мерить объемом.
Так и со сложностью, ее можно мерить временем или кол-вом элементарных (равнозначных) операций.
Но разбивать каждую задачу (в том числе и базовую в 1 story point) на элементарные операции и сравнивать их кол-во (делить одно на другое) ужасно неудобно.
Каждый программист знает, что такую-то типовую задачу он делает столько-то времени, а такую-то столько, а такая-то типовая задача состоит примерно из таких-то типовых задач, значит займет примерно столько-то времени.
Я считаю, что такой способ оценки наиболее эффективен.
Если ваш "еще один" способ оценки, о котором вы ничего не говорите, извините, но попахивает шарлатанством. Разве это не кот в мешке?
Можно сказать, что я учу людей прыгать до луны, а после обучения сказать, что тренируйтесь, у вас все получается, просто нужно прыгать выше :)
Или приклеить на стенку фото луны и сказать, что вы подпрыгнули до луны, разве на фото не луна? :)
Но это же будет мошенничество, неправда ли?
"могу предполагать больше или меньше времени у меня займет"
"Без вовлечения временных отрезков"
Сергей, а в чем же вы тогда меряете время? В попугаях? Можно, конечно, и на руках ходить, но это не значит, что это удобно и эффективно. Ну, только в случае, если у вас нет ног, может быть :)
Иван, то, что вы сейчас не умеете, не значит, что вас нельзя научить ;)
Я как столяр могу предполагать больше или меньше времени у меня займет стул по сравнению со столом. Без вовлечения временных отрезков.
P.S. точнее это не то, чтобы проще, другого способа оценки, чем через временные отрезки я не вижу. Ну, не умею я сравнивать столы в стульях (перекладывая на программирование), не задумываясь о сроках.
Сергей, ну как вы сравните сложность создания стола в стульях?
По любому вы оцените сколько вам нужно времени, чтобы создать стол и сколько нужно времени, чтобы создать стул. И только потом вы сможете дать эту оценку стола в стульях. Так не проще ли все мерить во временных отрезках, называя их story point, не вкладывая в них после оценки фактического срока выполнения?
Хочу с вами не согласится, Иван.
Оценки в стори поинтах строятся как раз на подобных сравнениях. У разработчика все-равно есть чувство насколько одна работа сложнее другой. Вот это чувство мы и пытаемся использовать при использовании относительных оценок.
Вообще полный бред это, ИМХО :)
Извините.
Особенно про то, что несоблюденные часы чему-то мешают, а несоблюденные story points ничему не мешают. Хорошо, так, переименовали часы в story points и все у нас хорошо сразу стало.
Да и на счет удобства оценки в попугаях - это сильное преувеличение. Спортзал или стакан я оцениваю легче, в приведенном примере, так как наглядно вижу как соотносится часть и целое. А если, например, не показывать мне наглядное соотношение 10-ти шагового отрезка и спортзала, то ответить, какова длинна спортзала в 10-ти шаговых отрезках мне будет ничуть не легче, чем дать оценку в шагах.
Так же и с задачами. Зная, что задача организации формы редактирования - это 1 story point оценить в story points создание какого-то (пусть конкретного) отчета я не смогу, потому что прямо это не сравнимые вещи. Конечно, я в итоге отвечу, сколько в этом случае story points будет занимать отчет, но для этого я прикину, сколько дней (моих, например) примерно займет задача организации формы редактирования, а потом сколько дней займет задача создания отчета, и поделив одно на другое дам ответ.
Т.о. единственный реальный вариант давать оценки во временных отрезках, например рабочих днях, но назвать их story point, чтобы подчеркнуть, что сколько это фактически будет дней зависит от многих условий, кто будет делать задачу, насколько он будет отвлекаться при выполнении, каково будет его самочувствие и т.д. Это уже будет из разряда производительности, это называют фокус-фактор.
Оценивают его точно также субъективно, в том числе на основе предыдущего опыта работы команды.
Типа - мы оцениваем всегда в 2 меньше, т.е. фактически тратим раб. дней получается в 2 раза больше, чем планируемых story points, значит давай при планировании времени story points умножать на 2. Но, естественно, это не дает никаких гарантий, что в этот раз мы уложимся в отведенное время.
Вот и вся хитрость в этих story points.
Вот! Про треугольник - это пять! С этого всегда и начинайте!
2Гость,
Мне тоже регулярно приходится объяснять как именно использовать эти оценки в пунктах/попугаях. Возможно вам поможет лучше понять мой пост на эту тему "Как правильно использовать скорость команды и оценки в пунктах" (http://tim.com.ua/2011/10/how-to-use-velocity-and-story-points/).
Кстати, там же есть ссылка на "Еще один способ быстрой оценки Бэклога". А то на практике Planning Poker тоже не всегда лучший выбор оказывается.
2Гость: пытался объяснить в самой статье, но очевидно не смог.
Попробую еще раз: если есть аджайл и стори-поинты, то Ганта скорее всего нет, поэтому он и не ломается :), хехе.
А вообще, если у нас аджайл, то дата фиксированная, и бюджет фиксированный, остается лишь scope, который как раз и не зафиксирован, поэтому, то что попугаи окажутся на поверку меньше заявленных, скажется на скорости команды, что просто приведет к тому что мы сделаем меньше, но никакой переоценки делать не придется, потому что фичи оценены относительно между собой, а не по их продолжительности выполнения.
Ух, понимаю, что все-равно ничего не понятно. Придется вживую на салфетке. Встречаемся на следующем AgileDays Russia :)?
Ок, верю. Правда я имел ввиду, что был бы рад услышать ответ на вопрос о том, как стори-поинты не ломают Гант? Столь громкое утверждение без объяснения в статье вызывает только недоверие. Боюсь, что окажется, что Гант совсем не имеет отношения к стори-поинтам. Можете ли вы объяснить свою точку зрения здесь в комментариях?
30%-40% своего времени провожу помогая организациям перейти на рельсы аджайл. Немного обо мне.
И еще раз услышать несуразную логику? Неудачная завлекаловка. Был бы рад сначала увидеть, что Вы сами практик и понимаете тему.
С удовольствием научу, записываемся на тренинг.
Странный вывод - увеличение количества часов с 10 до 40 ломает Гант, а увеличение попугаев с 10 до 40 - не ломает!? И я так хочу! Научите!
А если серьезно, то смотрите в сторону динамического Ганта и не ломайте себе голову какими-то стори-поинтами.