Как измерить оценочные и исторические баллы в Scrum?
Давайте возьмем пример, предположим, что у нас есть 5 историй A,B и C,D,E.
Importance Name Estimate
90 B
70 A
50 C
35 E
10 D
Истории упорядочены в зависимости от их важности (приоритета). Как вы их оцениваете? Это оценивается на основе размера функции? Например, я дал им оценочные значения:
Importance Name Estimate
90 B 10
70 A 12
50 C 9
35 E 20
10 D 11
Давайте предположим, что это 2-недельный спринт. Это размер 14 дней =5,14x5=70 человеко-дней. Теперь, что означает значение 10? Означает ли это количество времени (часов или дней), которое команда должна провести? А что такое сюжетные моменты? Предположим, это первый спринт; Как вы будете оценивать количество спринтов, если у вас нет скорости последнего спринта?
6 ответов
Argh! Служит мне право писать по памяти.
Сюжетная точка связана с оценкой курса, и когда вы пытаетесь выяснить, сколько вы можете сделать для спринта, сюжетная точка - это одна единица "работы", необходимая для реализации части или целой функции. Одна история может быть днем, часом или чем-то промежуточным. Я перепутал "оценку" и "сюжетную точку" ниже, не знаю, о чем я думал.
То, что я первоначально написал, было "оценками" и "пунктами истории". То, что я хотел написать (и отредактировал ниже), было "сюжетными пунктами" и "скоростью".
Точки рассказа и скорость идут рука об руку, и они работают вместе, чтобы попытаться дать вам ощущение того, "сколько мы можем выполнить за данный период времени".
Давайте возьмем пример.
Допустим, вы хотите оценить функции в часах, поэтому оценка одного из четырех компонентов займет 4 часа, поэтому вы назначаете такую оценку всем функциям. Таким образом, вы рассматриваете эту особенность или ее "историю", которая стоит 4 балла, когда дело доходит до конкуренции за ресурсы.
Теперь давайте также скажем, что у вас есть 4 человека в вашем проекте, каждый из которых работает обычную 40-часовую неделю, но из-за других вещей, происходящих вокруг них, таких как поддержка, общение в маркетинге, встречи и т. Д., Каждый человек сможет только 75% работают над реальными функциями, остальные 25% будут использоваться для других задач.
Таким образом, у каждого человека есть 30 часов в неделю, что дает вам 30*4 = 120 часов в общей сложности за эту неделю, когда вы подсчитываете всех 4 человек.
Теперь давайте также скажем, что вы пытаетесь создать спринт за 3 недели, что означает, что у вас есть работа в 3*120 часов, которую вы можете выполнить. Это ваша скорость, как быстро вы двигаетесь, сколько "сюжетных очков" вы можете набрать.
Единица вашей скорости должна быть совместима с единицей для ваших очков истории. Вы не можете измерить истории "сколько чашек потребит разработчик (и) при реализации" с "сколько часов у нас есть".
Затем вы пытаетесь найти набор функций, которые в совокупности занимают, но не более 120 баллов, ранжированных по их приоритету. Это будет просто суммировать накопление сверху и снизу, пока вы не достигнете задачи, которая опрокидывает сумму или равна этим 120 баллам. Если это опрокинуло, не включайте задачу.
С таким же успехом вы можете оценить количество дней, потребляемых разработчиком, или количество чашек кофе, точно так же, как число соответствует типу работы, которую вы выполняете, и может быть связано с фактической работой, которую вы будете выполнять (т.е. как много времени у вас есть в наличии).
Вы также должны оценить свою рабочую нагрузку после каждого спринта, чтобы выяснить, является ли это число 75% точным. Например, если вам удалось выполнить только половину из того, что вы намеревались сделать, выясните, были ли ваши оценки характеристик неправильными или оценки рабочей нагрузки были неверными. Затем примите во внимание то, что вы узнали, при оценке и планировании следующих спринтов.
Также обратите внимание, что функции должны быть разделены, если они становятся слишком большими. Основная причина этого заключается в том, что в более крупные оценки заложена гораздо большая неопределенность, и вы можете уменьшить ее, разбив ее на подфункции и оценив их. Большая общая особенность становится суммой всех подфункций. Это также может дать вам возможность разделить функцию на несколько человек, назначая разные подфункции разным людям.
Хорошее практическое правило заключается в том, что функции, оценка которых превышает 1 день, вероятно, следует разделить.*
Помните, что Очки - это просто ПЗУ (приблизительный порядок), созданные с использованием " Планирования покера" в качестве обычной практики. Первые несколько спринтов - это когда вы начинаете определять, что очки значат для команды, и чем дольше вы идете, тем точнее становится команда.
Плюс обратите внимание на использование точек, которые немного более разнесены. Практика, которую я видел и использовал, заключается в использовании последовательности Фибоначчи, которая гарантирует, что у вас не будет слишком много разностей в 1 балл.
Также не забывайте о тестировщиках: когда вы рассказываете историю, кому-либо, занимающемуся тестированием, нужно взвесить, так как иногда простая задача разработки может вызвать большие усилия по тестированию, и если они верны, Спринтс, то идея состоит в том, чтобы все было завершено так, как оно могло быть отправлено, проверено и задокументировано). Таким образом, оценка истории определяется командой, а не человеком.
Значение 10 - это просто значение относительно других оценок, например, оно вдвое сложнее, чем 20, или немного сложнее, чем 9. Не существует конкретного перевода 1 балл = х часов усилий - это то, на что следует указать,
Там, где я работаю, у нас есть то, что мы называем "эпическими точками", то есть насколько сложна какая-то высокоуровневая история, например, интегрировать Поиск в новый веб-сайт, который будет состоять из нескольких историй для завершения, а затем мы оцениваем часы для каждой созданной истории. от разбивки каждого эпоса, например, просто вставьте Поиск для документов поддержки на сайте. "Эпические точки" распределены в вариациях чисел Фибоначчи (1,2,3,5,8,13,21,28,35), так что более широкие, более расплывчатые эпики просто получают большое значение, например, больше 8 является показателем того, что его можно разбить на более легко оцениваемые истории. Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в рамках каждого спринта день теряется на такие встречи, как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому на спринт уходит только 9 дней. При добавлении в парное программирование некоторых вещей, времени на исправление ошибок и другой внепроектной работы, такой как заявки на поддержку, и становится довольно трудно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.
Первые несколько спринтов - это когда значения начинают становиться более конкретными, так как на основе полученного опыта оценки могут стать более четкими с точки зрения того, как угадать значение.
Хорошие ответы повсюду.
Я хотел бы добавить еще один момент: не очень важно, что вы выбираете в качестве основы для значения ваших баллов (часы, идеальные дни и все остальное). Важно, чтобы оно было последовательным.
Если вы сохраняете его постоянным, это позволит вам обнаружить "истинную скорость" вашей команды. Например, скажем, у вас было несколько итераций:
iteration 1 = 120 points
iteration 2 = 95 points
iteration 3 = 115 points
И теперь вы начинаете итерацию 4, и у вас есть следующее в очереди (отсортировано по приоритету):
item 1 = 50 points
item 2 = 30 points
item 3 = 30 points
item 4 = 40 points
Теперь, предполагая, что ваши оценки очков последовательны, вы можете быть достаточно уверены, что команда завершит пункты 1,2 и, вероятно, 3, но определенно не 4.
Вы можете применить то же самое к журналу отставания, чтобы улучшить свой прогноз даты выпуска. Это то, что позволяет командам Scrum улучшать свои оценки по мере их продвижения.
С новой командой или проектом мы всегда начинаем с предположения, что сюжетная точка - это один "идеальный день", и мы рассчитываем, что каждый разработчик получает около 3,5 идеальных дней в неделю, как мы рассчитываем нашу вероятную начальную скорость.
После того, как вы прошли стадию "планирования покера" и сбалансировали / сравнили все свои истории, реальная длительность сюжетной точки в реальном мире действительно неизвестна - все, что у вас есть, - это довольно хорошее представление об относительной продолжительности, и используйте свою лучшее решение, чтобы придумать вероятную скорость.
По крайней мере, так я это делаю!
Если вы также стремитесь, чтобы точки вашей истории были примерно равны идеальному дню, тогда я бы предложил разбить ваши истории на более мелкие истории, в противном случае вы не сможете хорошо провести время при планировании и отслеживании итераций.
У Дж.Б. Кинга есть лучший ответ, но нет голосов, что означает, что неверная информация распространяется и способствует плохой интерпретации разборок. Пожалуйста, посмотрите реальные ответы от одного из людей, которые разработали Scrum здесь:
http://blog.mountaingoatsoftware.com/seeing-how-well-a-teams-story-points-align-from-one-to-eight
Помните, что это усилие, а не сложность.
Теперь прочитайте и посмотрите видео здесь:
http://www.agilebok.org/index.php?title=Relative_Sizing_and_Story_Points