Комментарии 11
Почему в днях, а не в часах? Задача вида "изменить текст подсказки у поля" тоже до дня округлится? Или у вас дробные дни?
У нас на проекте подсчет ведется в человеко-днях. Можно перевести все на человеко-часы, подобные схемы есть. В нашей команде 20+ человек, а спринт длится месяц, поэтому проще посчитать человеко-дни (значения обычно на уровне 100+), а не человек-часы (их тогда будет 1000+).
Как правило, такого рода задачи — это составляющие более крупной задачи. В нашем бэклоге задач меньше 1 человеко-дня нет.
Не изобретайте суржик.
К сожалению, такой подход работает только, если ваша команда почти идеально оценивает задачи. Если точность оценки задач не идеальна (а обычно это так), то она будет сильно аффектить решение той проблемы, которую вы изначально решали - "а почему не все фичи допилили?" Да потому что задачи оценили неправильно.
Истпытываю ощущение, что капасити команды можно определить без расчетов, просто пробежав вместе с командой несколько спринтов и посмотрев, сколько часов продуктовой разработки на человека успеваем сделать по фактически списанным часам на задачу.
У меня был такой опыт: мы планировали 26 часов на человека в неделю. Пришел шеф и говорит, а давайте по 30 часов. Мы такие, да легко. Запланировали по 30. Успели все равно по 26. Такие дела.
Пришел шеф и говорит, а давайте по 30 часов. Мы такие, да легко. Запланировали по 30. Успели все равно по 26.
Если для отчётности надо - я все 48 придумаю на что списать ))) А вот реальная продуктовая - это реальная продуктовая.
Осмелимся предположить, что в нашем случае оценка задачи командой — это нажитый опытом хороший бонус сейчас на проекте. Команда к этому шла не один месяц, набивая себе шишки.
Извиняюсь, но я не увидел, как вы решили проблему, которую описали в начале статьи
"мы заметили, что ежемесячно команда не успевала выполнить все 100% из запланированного пула работ"
От того, что вы поняли, что у разработчика не 8 рабочих часов в одном дне, а 6 - проблему точности прогнозирования разработчиков не решают.
Математически мало смысла. Оценка капаситета команды в чем либо - просто оценка объема сферического коня в вакууме. 30 человекодней, 50 попугаев - просто числа и буквы. Хотя да, можно их подсчитать достаточно точно
Как только мы из натягиваем на фичи, возникает банальная проблема - фичи не имеют оценки сами по себе. Так грустно устроена жизнь :) К каждой фиче мы просто приписываем оценку тоже в попугаях. К примеру, играем в скрам покер. Но важно для понимание другое. Точность такой оценки довольно таки мала. Именно математически. Условно это может быть плюс минус 50%. После чего возникает вопрос.
Если с одной стороны у вас довольно таки точное знание о капаситете команды в человекочасах, а с другой фичи в этих же человеко часах, но с погрешностью 50%, то какой смысл сильно напрягаться в первой части. Все равно комбинационный результат капаситета и объема работ даст большую погрешность. Может это и не буде 50%, лениво поднимать курс метрологии и считать, но это и не нужно, так как знания того, что есть большая погрешность достаточно. При такой погрешности абсолютное значение вероятностной величины довольно таки обесценивается.
Если вы померяли отрезок, и его длина равно 3 метра плюс-минус полтора, то ценность числа 3 в практическом смысле почти нулевая
Поэтому не парьтеся, играйте в скрам покер и занимайтесь рнальным project execution, а не фигней с арифметикой
Planning Poker, Velocity, относительная оценка, которая выполняется не в часах, а в условных единицах, потому что классический проектный менеджмент в спринтах (которые есть только в Scrum и больше нигде) не работает, нет?
И, конечно, если вдруг вы претендуете на Agile, а похоже, что именно так, раз говорите про спринты, то вам точно следует узнать, что оценка производится командой для команды, а не для менеджмента. Потому что как только менеджмент начинает в это влезать, то получается как в той истории, когда высший менеджер сказал команде больше выполнять поинтов за спринт, а они просто начали оценивать пользовательские истории в других единицах, потому что реальный Velocity не просто так получается (как выше уже сказали).
Capacity команды продуктового проекта: как рассчитать и на что влияет