Комментарии 46
Основная проблема оценки в часах — невозможность точно определить, сколько же нужно времени на решение задачи.
…
Scrum — разновидность гибкой методологии разработки (Agile), в которой задачи распределяются на временные отрезки (спринты) и могут оцениваться в SP.
Вы сами не чувствуете, как запредельно глупо это выглядит?
То есть взяли сторипойнты, начали оценивать задачи в попугаях и профит!!! Получите точную оценку! В попугаях, ага… Спринты - временнЫе отрезки, срок завершения проекта определен. А вы со своим скрам-мастером попугаев штабелями укладываете.
Что мешает всю эту суету с анализом спринтов, с покером, если угодно, производить с оценкой в часах? По этим же методикам через несколько спринтов может и начнете точнее потребное на задачи время определять? Для пущего наукообразия можете и числа Фибоначчи оставить. Чтобы легче было верхнему руководству по ушам ездить…
Что мешает всю эту суету с анализом спринтов, с покером, если угодно, производить с оценкой в часах?
Проблема в том, что если задача оценена в 1 час, а заняла 15 минут, она всё равно займёт 1 час. А если задача оценена в 2 попугая, а заняла 15 минут, то она займёт 15 минут, а разработчик закроет больше попугаев за спринт. Естественно, это всё теория, а на практике бывает разное. И чаще фигня, чем не фигня. (сам я скрумом не пользуюсь и никого не призываю, если что)
Спорный момент, пользуетесь часами при оценке, значит должны адекватно учитывать трудозатраты и оглядываться на ситуации когда оценили в час, а вышло 15 минут.
При SP все зависти от базового значения и его корреляции со временем)
P.S На практике, попасть точно с оценкой можно только в случае типовых задач, которые 20 раз делали и всем все понятно, а так, в среднем по больнице синусоида +/- 15% от оценки и неожиданные всплески
Попугаев вообще не нужно коррелировать со временем. В скруме важно оптимально упихать спринт. А знать какая конкретно задача сколько времени заняла не так важно
согласен, не так важно,с точки зрения планирования можно просто корректировать значение SP, которое команда способна выполнить за спринт. Тут имел ввиду, что что может 2SP за 15 минут это норма, а если нет, то на ревью можно будет разобраться в чем дело, может просто переоценили задачу и тд (если конечно именно эта задача как то повлияла на спринт).
Это где вы так счастливо живёте? Если для высокого руководства нужно построить хоть какую-то дорожную карту, Привет, переводим стори пойнты в дни.
Если вы разработчик, то конечно это не ваша головная боль
Это где вы так счастливо живёте?
Встроенные системы. Продуктовая разработка. Тендеры, долговременные клиенты и вот это вот всё.
Если для высокого руководства нужно построить хоть какую-то дорожную карту
У вас простите высокое руководство интересуется, сколько времени займёт каждую кнопочку добавить? План для руководства делают по-большому обычно. Каждый пункт в сотню попугаев. Да к тому же, мы же про разработку ПО говорим. Все знают что мы никогда не укладываемся в сроки.
Ещё раз повторюсь, что весь смысл мероприятия с попугаями заключается в том, что:
время разработки одного попугая может сильно варьироваться. Время разработки сотни попугаев будет варьироваться намного меньше. И,
с другой стороны разработчик получивший задачу на два попугая не станет жертвой тех же ожиданий (как внешних, так и внутренних), что разработчик получивший задачу на 2 часа.
Тендеры, долговременные клиенты и вот это вот всё.
Планирование то у вас есть?
Просто вы создали свою виртуальную единицу измерения времени, которую понимает только команда и менеджер.
Всё равно в конечном итоге это всё утрамбовывается в двухнедельный спринт, по сути SP всё равно равен какому-то количеству человекочасов.
разработчик получивший задачу на два попугая не станет жертвой тех же ожиданий (как внешних, так и внутренних), что разработчик получивший задачу на 2 часа.
Та же история: тебе дали задачу на половину стори поинта, ты её два дня делал, "ты что совсем что ли?"
Команда должна в днях оценивать крупные User Story, а конкретные мелкие задачи по добавлению кнопочек и изменению цвета, разработчик вообще не должен знать какая у них оценка.
И какая проблема? Правим оценку для таких задач, ведь есть анализ по результатам спринта. И ровно то же самое делаем, если «соучастниками» являются модные попугаи. Что меняется? Да ровным счетом ничего. Причём, если анализа спринта нет, то тоже ничего не меняется. Продолжаем брать оценку с потолка.
Что интересно, если проект выполняется на аутсорсе, там попугаи не прокатывают. Наверное потому, что вопрос об отношениях попугаев и часов встанет в первые же дни.
И какая проблема?
Никто никогда не узнает, что задача на самом деле заняла 15 минут. И, соответственно, никто ничего не сможет скорректировать.
Что интересно, если проект выполняется на аутсорсе, там попугаи не прокатывают.
На аутсорсе только счёта выставляются за часы. А внутри работа может быть устроена как угодно.
Никто никогда не узнает, что задача на самом деле заняла 15 минут. И, соответственно, никто ничего не сможет скорректировать.
Так же и и со сторипойнтами. Никто и никогда не узнает, что вот эта задача была оценена в десять сторипойнтов неправильно. Но это ведь будет возможным только в том случае, если весь скрам у вас скукожился до попугаев. Если же упомянутые в статье процессы отстроены, то узнают. И вот сюрприз, в одинаковой мере и про часы, и про попугаев.
вы подразумеваете, что есть некая "правильная" привязка попугаев к часам. А её нет. Есть среднее количество попугаев на спринт и предполагается, что в установившемся режиме оно мало меняется от спринта к спринту. Конечно, можно произвести нехитрую калькуляцию и пересчитать попугаев в часы. Но этого не нужно делать, потому что весь смысл скрума как раз в том, чтобы планировать спринтами.
Так точно так же, если в сприт влезает только X условных дней разработки, то вот сколько есть. Остальное - это резерв на коммуникации и влёты.
Ещё раз, проблема в том, что если разработчику дали задачу на 4 часа, она никогда не займёт меньше 4х часов. С попугаями такой проблемы нет, потому что от попугаи не равны какому-то фиксированному количеству часов.
Это как? Закрыл таску, посмотрел что у неё оценка выше и пошёл курить? Он по идее на сабтаске оценку видеть и не должен.
По здравому смыслу, разработчики должны оценивать крупные Стори, а подзадачи - это уже детали. Если упарываться до 1-4 часов, то вы только этим и будете заниматься.
С попугаями такой проблемы нет
Изи, в спринт влезает 10 попугаев, задачу оценили в 10 попугаев, следовательно меньше спринта она не займет)
вы подразумеваете, что есть некая "правильная" привязка попугаев к часам. А её нет.
Отнюдь… Я пытаюсь сказать, что введение оценки задач в размерах трусов или в попугаях изначально вещь предназначенная только для создания дымовой завесы. Нужная лишь для того, чтобы в любой момент как всю команду, так и любого исполнителя нельзя было взять … за определенное место и попросить дать ответ, а чем вы тут вообще страдаете уже третью неделю?
Повторюсь, никуда вы не денетесь от того, что определяет все реальный мир с его временнЫми требованиями, сроками сдачи, продолжительностью спринтов в днях и т.д. Или вы что, всерьез считаете, что пресловутая гибкость, которую дает скрам, обеспечивают ваши попугаи и числа Фибоначчи? Ни разу даже и не смешно… А вот имитировать скрам с помощью попугаев - удобно, не спорю…
весь смысл скрума как раз в том, чтобы планировать спринтами.
Но спринт - это временной отрезок и в любом случае попугаев придётся уложить в часы.
Более того спонсору заказчика прежде всего важны деньги, сколько стоит заказанная доработка. А деньги это трудозатраты в человеко-часах и днях.
У спринта Capacity также оценивается в сторипойнтах, этот тот объем который команда в состоянии закрыть за 2 недели согласно статистике, которая уже накопилась к этому времени. Так что никто не сравнивает попугаи с часами. И уж гораздо проще оценить задачу в безразмерных единицах (пусть даже в размерах футболок как описано в статье), имеющих при этом свой вполне определенный внутрикомандный вес и эталон, чем в человекочасах
Все эти стори пойнты нужны исключительно для того чтобы не пугать особо чувствительных разработчиков, когда они опять облажались с оценками.
Менеджеру всё равно приходится переводить эти стори поинты в часы. А хороший менеджер оценку в часах от команды всё равно домножает на поправочные коэффициенты.
Мой опыт показывает, что оценка в часах она понятнее для всех, на больших масштабах сходится к понятному коэффициенту поправки.
Для оценки в часах можно также использовать покер планирования, груминги, условный Middle разработчика час. В нашем случае, мы вообще все истории оцениваем в условных днях.
SP действительно не дают точной оценки в абсолютных единицах времени, но их цель и не в этом. Они нужны для более гибкого планирования работы в команде, учитывая неопределённости и вариативность задач.
В данном случае фокус внимания с задач переходит на спринты. Т.е. тут сам спринт выступает в роли одной большой задачи, которую проще оценить в относительных единицах, благодаря чему в долгосрочной перспективе получается более точная статистика по закрытым задачам за спринт - меньше разброс и лучшее понимание возможного выполненного объема при следующем планировании.
Если мы будем это же оценивать в условных человека днях, то чем это хуже, кроме большей понятности прозрачности?
Да, условный "человеко день" в конце концов будет равен примерно полтора рабочих дня реальных.
Дни понятнее для менеджмента и новых разработчиков в команде, которые приходя в storypoint команды охреневают, что за сторипоинты как в них оценивать.
Я в это много раз играл в разных компаниях и нигде нормально не работало. Менеджмент не умеет в абстрактные стори-поинты и в конце концов тебе все равно придется вводить коэффициент перевод попугаев в мартышек. А если тебе все равно переводить надо, то почему бы сразу и не оценивать целевых единицах.
Фишка стори-поинтов в том, что они не про время вообще. Мы внутри себя договорились расценивать их как некую единицу неопределенности.
Если задача понятная - бери и делай, то это будет 1 стори поинт (ну 2), даже если это вручную заменить в 100 классах А на Б. Сложно? Нет. Долго? Долго. Т.е. эта задача может занять весь спринт по времени.
А бывают задачи, которые хрен знает как решать. Может надо какую либу готовую поискать или подход погуглить. Т.е. ты примерно представляешь, но слишком много неизвестных. Поэтому ты честно говоришь, что это 7-12 баллов. Хотя по факту ты можешь нагуглить что-то готовое и решить эту задачу за пару часов.
А в чём разница то?
Вот есть у меня маленькая задача. Можно оценить её в час, можно в XXS, а можно в SP1. Но если окажется, что задача не такая уж и маленькая, все три вида оценки окажутся неверными.
Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача решаема на текущей инфраструктуре и с текущими инструментами.
Нет никакой разницы, кроме частотности значений на шкале оценки и связанных с этим проблем. Ценность покера больше в том, что задачи обсуждаются, выдвигаются какие-то гипотезы, принимаются решения и задаче проставляется какой-то вес, глядя на который можно примерно оценить усилия в соотвествии с принятой в команде шкалой.
Если впоследствии окажется, что оценка не верна, то ничего не мешает ее поменять. Конечная оценка при резолве задачи уходит в статистику. Если процесс не меняется, то со временем получаем примерную производительность
Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача решаема на текущей инфраструктуре и с текущими инструментами.
Для нахождения подводных камней есть предварительные процессы по анализу задач, что и должно обеспечивать уже на самом планировании определенную оценку.
Оценка временем для задач, особенно сложных и новых, может быть крайне неточной.
SP избегают иллюзии точности во времени, а больше ориентированы на сложность и ресурсоемкость.
Например, незнания, как добавить модалку и как добавить многоязычность в проект немного разные… В обоих случаях ты не знаешь что/как делать, но у тебя есть понимание, что одна задача по любому займет больше ресурсов, чем другая.
Из этого и выйдет, что в соответствии с критериями оценки будет выставлена подходящая. А в будущем будет ясно сколько похожих задач можно сделать за спринт.
SP избегают иллюзии точности во времени
А как оно работает? Если я решил, что задача -- это SP1, то мы же потом всё равно делаем Scrum Poker и прикидываем время на выполнение этой простой задачи. То есть сначала мы от времени избавляемся, а потом снова возвращаем.
SP избегают иллюзии точности во времени, а больше ориентированы на сложность и ресурсоемкость.
Ага отлично, создают иллюзию вообще какой-то оценки, которую вообще невозможно никуда ни во что перевести. А нам нужно понять, что мы за Ближайшие полгода сможем хотя бы примерно сделать, Особенно это весело с новой командой.
Мне пришёл новый разработчик новая команда, и оценили задачу в 32 story point, что мне с этим делать? Как понять много ты или мало, смогут они это сделать за неделю или за месяц?
Если пришла новая команда новые разработчики, оценили задачу условно в месяц разработки - я прекрасно понимаю, что с учетом рисков, того что там вылезет, всяких интеграций, тестирования, подводных камней в инфраструктуре заказчика, это всё растянется на 2 месяца. Ну, окей, User Story нарезали, поехали пилить
Проблема же не оценить в час, а как-то понять, что подводных камней не найдётся и что вообще задача
Это как раз то, от чего пытаются спрятаться за сторипоинты. Но на самом деле в реальности на больших объёмах какая-то задача заняла больше времени, а другая наоборот Меньше времени, и как раз в среднем появляется 10-15% погрешности в ту или иную сторону, которая в будущем просто надо учитывать.
Но днями, и неделями куда проще оперировать чем мутными сторипонтами, которые не разработчики не понимают толком, не менеджеры.
Естественно, если у нас бирюзовый старта, которому вообще пофиг, что когда будет сделано, мы просто сидим и делаем, то там можно вообще ничего не оценивать.
Всегда удивляла оценка в малых числах. Учитывая, что используем мы целые, то с 1 до 2 разрыв в 2 раза, с 2 до 3 - 1,5 раза. Это мешает построить ровный график зависимости а самое главное, в реальности при этом задачи могут так сильно не различаться по сложности на низком уровне. От умножить на 100 и уже варьировать легче.
Но самое главное - это все не решает ошибку при назначении оценки. Что вы будете выбирать из карточек с поинтами, часами, размерами порноактрис, чем менее рутинная задача, тем выше шанс назначить не тот "маркер", так как работа становиться более творческой, если можно так сказать.
По сути, вся реальная ценность во всех этих оценках это просто разделить задачи на простые и нет. И дальше определиться с приоритетами. Ну что в первую очередь, что нет.
А понять сколько это займет времени в целом невозможно. Ну можно только очень грубо прикинуть.
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
Тогда к чему эти новые виртуальные единицы измерения времени, если можно мерить в днях, только потом вводить поправочные коэффициенты в зависимости от эффективности команды?
Потому что добавляя поправочные коэффициенты ты уже создаёшь новую сущность "времени" , и у тебя все равно появляется виртуальный "час" который не равен часу в реальности. И это проблема, потому что и то и то называется "час", но от команды к команде значит разное.
По этому со СП работать проще, потому что это довольно понятная абстракция и не нужно вводить никаких доп коэффициентов и иметь одинаковые слова для разных понятий.
потому что и то и то называется "час", но от команды к команде значит разное
в отличие от сторипоинтов, которые на самом деле от команды к команде значат разное, час от команды к команде как раз значит одно и то же) из команды эта оценка уходит уже после применения "доп коэффициентов". Впрочем час это плохая единица, бизнесу она не интересна, для разработчиков она стрессовая, вот день это норм
По моему опыту даже новая команда, где разработчики друг друга первый раз видят, достаточно точно оценивают трудозатраты задач в днях, в среднем на больших масштабах ошибаясь в меньшую сторону примерно на 20-25%
Прочитал всю статью, комментарии и остался при своем мнении: самая точная оценка времени выполнения задачи — как только, так сразу )
Если я правильно понял то измерение в story point работает так. Заказчик хочет пачку фич. Эту пачку раскладывают по story points. Каждая отдельная story point выкатывает в прод несколько фич из пачки и показывает заказчику прогресс . Каждая story point имеет свою себестоимость в человекочасах работы команды. Эту себестоимость, плюс частично общепроизводственные расходы, плюс прибыль, плюс налоги и оплачивает заказчик.
Поправьте если я ошибся.
SP относительная единица.
Время тоже относительная единица.
И у любого человека есть представление что такое секунда, минута, час и т.д.
А вот как оценить задачу в майках или стори поинтах человеку придется учиться.
Но по факту в голове разработчика будет лежать мапа 1 SP = 30 минутам и в голове менеджера будет лежать мапа 1 SP = 20 минутам. И того и те и другие оценивают задачи по времени, но еще и используют промежуточную конвертацию при общении между собой.
И это я еще лишь слегка упомянул о разном восприятии "1 Попугая" у разных людей.
Ну... У нас на работе майки использовали по-другому. Размер называли только для предварительной оценки, чтобы дать примерное понимание, что вот эта задача займёт около 1-2 дней, а вот та - примерно полтора месяца.
Но, если бизнес принимает план и приоретизирует задачу - мы делали уже более детальный эстимейт в часах.
Это к тому, что у маек не было прямого перевода в часы, они скорее сумма времени и сложности.
Самое интересное случилось, когда я однажды поделил часы на количество стори-поинтов для завершенного проекта.
Получилось 1sp = 8 рабочих часов 😅
Простите, не хочу никого обидеть, но вся эта история с SP выглядит очень надуманно и по-школьному. Как будто собралась группа джунов, которая не очень разбирается в теме и не может +/- прикинуть, сколько времени у них займёт разобраться в проблеме и её решить и, которая из-за неуверенности, боится брать на себя ответственность.
Чтобы помочь таким неопытным или неуверенным участникам в оценке участвует вся команда. Плюс лид или продакт менеджер или системный аналитик (где как) на эту оценку накидывает некий коэффициент погрешности исходя из опыта работы в данном проекте и с данной командой. Оценка задач не сверх сложное мероприятие)
А заказчику тоже в попугаях оценку озвучивать? Заказчика не интересуют даже часы, их интересует оценка в деньгах. ИМХО стори поинты применимы для оценки внутренних проектов, когда ты и есть заказчик.
На предыдущей работе у нас было так:
- Так, вот эта задача, да... Ну, тут дня на два, часов 10... ой, сколько у нас сегодня стори-поинт, 4 часа? Ну тогда 2,5 стори-поинта пиши
Почему иногда лучше оценить задачу в размерах майки, чем в часах