Толпа и Точки Истории - почему идеальные человеко-дни не идеальные человеко-часы? [закрытый]
Это должно возвратить текстовое значение выбранного значения
var vSkill = document.getElementById('newSkill');
var vSkillText = vSkill.options[vSkill.selectedIndex].innerHTML;
alert(vSkillText);
Опоры: @Tanerax для чтения вопроса, знания, что спросили и ответ на него перед другими, понял его.
Редактирование: DownModed, вызовите, я на самом деле считал вопрос полностью и ответил на него, печальный мир, который это.
6 ответов
Мне кажется, что хорошей единицей для Story Point был бы идеальный человеко-час, а не человеко-день.
Эта фраза звучит очень, очень странно, и не соответствует действительности. Где вы читали, что существует взаимосвязь между сюжетными точками и идеальным человеко-днем? Идеальные человеко-дни, возможно, использовались в первые дни Scrum, но для меня Story Points (SP) - это совсем другое ...
Story Points - это способ количественно оценить относительных усилий связанный с конкретным элементом журнала невыполненных работ (PBI), который состоит из нескольких задач. Некоторые команды используют числовые размеры (например, шкалу от 1 до 10) для оценки «размера» PBI, другие используют размеры футболок (XS, S, M, L, XL, XXL, XXXL), некоторые используют шкалу Фибоначчи. последовательность (1, 2, 3, 5, 8, 13, 21, 34 и т. д.). И, кстати, вы заметили, что SP не имеют единиц измерения?
Если бы я использовал дни, большинство моих выпусков имеют оценки 1/2 или 1.
И что? Это просто означало бы, что у вас есть небольшие PBI, что неплохо (по крайней мере, не для самого важного). Но не забывайте, что в Scrum теоретически существует два уровня оценки: уровень бэклога продукта в баллах и уровень бэклога спринта в часах. Как я упоминал в предыдущем абзаце, PBI состоит из задач, и они должны быть разделены на задачи во время второй части собрания по планированию спринта. Затем задачи оцениваются в часах, и здесь применяется правило 16 часов: задача не должна превышать 16 часов. Если это так, то оно слишком велико и должно быть разделено на более мелкие задачи (потому что мы слишком плохо умеем оценивать большие вещи).
Есть ли у вас какие-либо идеи, почему использование идеальных человеко-дней чаще всего упоминается в Литература по Scrum?
Это все равно устарело. Все может измениться в будущем, но в настоящее время консенсус заключается в оценке без единиц измерения. Очки полностью декоррелированы с любой единицей времени, и это сделано намеренно, чтобы избежать сопоставления с единицами реального мира, работоспособность должна измеряться скоростью (количество очков, которые команда может получить за одну итерацию).
Оценка на часовом уровне является слишком точной. Это также будет приводить к чрезмерному микроменеджменту, что в некоторой степени противоречит принципам гибкой разработки.
Если у меня есть четыре задачи, каждая из которых занимает полдня, я могу быть относительно уверен, что через два дня у меня будет четыре задачи. хорошо справляется с ними.
Но 16 часовых задач? У меня гораздо меньше уверенности в том, что те, которые выполняются в один и тот же период времени, поскольку любая из задач подвержена слишком большой вариативности.
Цель сюжетных точек и оценочной игры в целом состоит в том, чтобы эффективно судить о скорости в течение нескольких спринтов.
Таким образом, на самом деле не имеет значения, какие единицы используются для оценки, пока каждый в команде оценивает в таким же образом, и одни и те же единицы используются на каждом сеансе оценки.
Также очень важно убедиться, что разные команды не пытаются соотнести свои сюжетные точки. То, что я считаю сюжетной точкой, не обязательно будет тем, что у вас.
Итак - я не могу дать другого ответа, кроме «иди с тем, что кажется подходящим».
Поиск в Google по запросу «идеальный человеко-час схватки» дает 6500 результатов, в то время как «идеальный человеко-день схватки» дает 10 000 результатов. Не такая уж большая разница. Я не заметил в литературе предвзятого отношения к обоим.
Ничего действительно ценного редко делается менее чем за полдня (минимальная продолжительность задачи) или даже за неделю (минимальная продолжительность спринта).
Оценка в часы могут дать ложное ощущение точности. Даже при том, что 5 идеальных человеко-часов - это точное значение, это, вероятно, не больше, чем 0,5 идеальных человеко-дня.
Идеальные человеко-часы также передают понятие сопоставления с аналогичными единицами реального мира, такими как часы или дни. Отображение редко бывает простым. Вот почему многие агилисты предпочитают безразмерные истории в качестве меры размера задачи. Затем метрика скорости команды преобразует абстрактные оценки размера в реальное время.
Если вы следуете правильным методам Agile, с полным покрытием модульного тестирования и циклом красно-зеленого рефакторинга, существует исчезающе небольшое количество значимых задач, которые займут менее половины дня. . Кроме того, использование дней противодействует тенденции разработчиков недооценивать время, необходимое для выполнения задачи. И, конечно же, лучше переоценить время и выполнить завышение, чем недооценить или недооценить.
Я не знаю, но готов предположить, что это потому, что «стандартная» продолжительность схватки составляет 30 дней. Если вы планируете выполнять работу блоками по 30 дней, тогда вам понадобятся более грубые единицы измерения, чем если бы у вас была продолжительность спринта в 1 или 2 недели .
Большая часть схватки реализации, которые я видел, имеют длину пружины в 1 или 2 недели, поэтому подсчет «идеальных часов» более полезен, потому что относительные размеры задач меньше.
Что касается относительного измерения усилий. и предполагая, что вы используете scrum для разработки программного обеспечения, я бы подсчитал количество отдельных коммитов исходного кода , которые вы могли бы сделать, если бы вы разработали каждую задачу чисто, и использовали бы это как меру.