Scrum и Story Points-почему идеальные человеко-дни не идеальные человеко-часы? [закрытый]
Я привык думать об оценках времени так, как предложил Джоэл Спольски - что если запланированный элемент занимает более 16 часов, его следует разделить на более мелкие задачи. Теперь я внедряю Scrum в свою команду вместе с оценками на основе сюжетных точек. Мне кажется, что хорошей единицей для сюжетной точки был бы идеальный человеко-час, а не человеко-день. Если бы я использовал дни, большинство моих проблем имели бы оценки 1/2 или 1.
Вы имеете любую идею, почему польза идеальных человеко-дней упоминается чаще всего в литературе Scrum?
6 ответов
эта фраза звучит очень странно, и не правда. Где вы читали, что существует корреляция между сюжетными точками и идеальным мужским днем? Идеальные человеко-дни, возможно, использовались в первые дни Scrum, но для меня сюжетные точки (SPs) - это другое...
сюжетные точки-это способ количественной оценки относительные усилия, связанные с конкретным элементом отставания продукта (PBI), который состоит из нескольких задач. Некоторые команды используют числовой размер (т. е. масштаб от 1 до 10) для оценки "размера" PBI, другие используют размеры футболок (XS, S, M, L, XL, XXL, XXXL), некоторые используют последовательность Фибоначчи(1, 2, 3, 5, 8, 13, 21, 34, etc). И кстати, вы заметили, что SP-это unit-less?
Если бы я использовал дни, большинство моих проблем имели бы оценки 1/2 или 1.
ну и что? Это означало бы ... что у вас есть маленькие PBIs, что не плохо (по крайней мере, не для самого важного). Но не забывайте, что теоретически в Scrum существует два уровня оценки: уровень отставания продукта в пунктах и уровень отставания спринта в часах. Как я упоминал в предыдущем абзаце, PBI состоят из задач, и они должны быть разделены на задачи во время второй части совещания по планированию спринта. И задачи затем оцениваются в часах, и правило 16h применяется здесь: задача не должна превысьте 16h. Если это так, он слишком велик и должен быть разделен на более мелкие задачи (потому что мы слишком плохо оцениваем большие вещи).
у вас есть идеи, почему использование идеальных человеко-дней упоминается чаще всего в литературе Scrum?
это устарело в любом случае. В будущем все может измениться, но нынешний консенсус заключается в том, чтобы оценивать в единицах меньше. Точки полностью decorrelated из любой единицы времени, и это намеренно, чтобы избежать каких-либо сопоставление с реальной единицей мира, производительность работы должна измеряться со скоростью (количество очков, которые команда может достичь за одну итерацию).
оценка на часовом уровне слишком мелкозернистая. Он также будет стремиться к микро-управлению, что несколько противоречит принципам agile.
Если у меня есть четыре задачи, каждая из которых оценивается в полдня, я могу быть относительно уверен, что через два дня я хорошо справлюсь с ними.
но 16 1 час задачи? У меня гораздо меньше уверенности в том, что это будет сделано за тот же период времени, так как любая из задач слишком много изменчивость.
цель сюжетных точек и оценивающей игры в целом состоит в том, чтобы эффективно судить о скорости в течение нескольких спринтов.
поэтому на самом деле не имеет значения, какие единицы используются для оценки, если все в команде оценивают одинаково, и те же единицы используются на каждом сеансе оценки.
также очень важно убедиться, что разные команды не попробуйте соотнести их сюжетные точки. То, что я считаю сюжетной точкой, не будет обязательно будь тем, что есть у тебя.
Итак - я не могу дать ответ, кроме как "пойти с тем, что кажется подходящим".
Googling для "scrum ideal man hour" дает 6500 результатов, в то время как" scrum ideal man day " дает 10000 результатов. Не такая уж большая разница. В литературе я не заметил ни того, ни другого.
ничего действительно ценного редко делается менее чем за полдня (мин. продолжительность задания) или даже неделю (мин. продолжительность спринта).
оценка в часах может дать ложное ощущение точности. Хотя 5 идеальный мужчина часы точно, это, вероятно, не более точно, чем 0,5 идеальных дней человека.
идеальные единицы человека также передают понятие отображения в реальный мир подобных единиц, таких как часы или дни. Отображение редко бывает простым. Вот почему многие agilists предпочитают unitless story points в качестве меры размера задачи. Затем метрика скорости команды выполняет отображение от абстрактных оценок размера до реального времени.
Если вы следуете правильной гибкой практике, с полным охватом модульных тестов и циклом red-green-refactor, существует исчезающе небольшое количество значимых задач, которые займут менее половины дня. Кроме того, использование дней противодействует тенденции разработчиков недооценивать время, необходимое для выполнения задачи. И конечно, лучше переоценивать время и перерасход, чем недооценивать и недооценивать.
Я не знаю, но я готов предположить, что это потому, что "стандартная" длина scrum составляет 30 дней. Если ты планирование работы в блоках по 30 дней, тогда вам понадобятся более грубые единицы измерения, чем если бы у вас была длина спринта 1 или 2 недели.
большинство реализаций scrum, которые я видел, имеют длину пружины 1 или 2 недели-так что подсчет "идеальные часы" более полезны, потому что относительные размеры задач меньший.
до относительная мера усилия касается и предполагая, что вы используете Scrum для разработки программного обеспечения я подсчитайте количество отдельных коммитов исходного кода вы можете сделать, если вы разработали каждую задачу чисто и использовать это в качестве меры.