Как измерить оценки и баллы истории в Scrum?[закрыто]

StackOverflow https://stackoverflow.com/questions/1232281

Вопрос

Давайте рассмотрим пример: предположим, что у нас есть 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

Предположим, это двухнедельный спринт.Это 14 дней, размер = 5,14x5 = 70 человеко-дней.Что же означает значение 10?Означает ли это количество времени (часов или дней), которое должна потратить команда?А что такое сюжетные точки?Предположим, это первый спринт;как вы оцените количество спринтов, если у вас нет скорости последнего спринта?

Это было полезно?

Решение

Ааа!По праву, пишу по памяти.

Конечно, точка истории связана с оценкой, и когда вы пытаетесь выяснить, сколько вы можете сделать за спринт, точка истории — это одна единица «работы», необходимая для реализации части или всей функции.Одной точкой истории может быть день, час или что-то среднее между ними.Я перепутал «оценку» и «историю» ниже, не знаю, о чем я думал.

Первоначально я написал «оценки» и «точки истории».Я хотел написать (и отредактировал ниже) «точки истории» и «скорость».

Сюжетные очки и скорость идут рука об руку, и они работают вместе, чтобы дать вам представление о том, «сколько мы можем выполнить за определенный период времени».

Давайте возьмем пример.

Допустим, вы хотите оценить функции в часах, поэтому для завершения функции с оценкой 4 потребуется 4 часа одному человеку, поэтому вы назначаете такую ​​оценку всем функциям.Таким образом, вы считаете, что эта функция или ее «история» приносит 4 очка, когда дело доходит до конкуренции за ресурсы.

Теперь предположим, что в вашем проекте работают 4 человека, каждый из которых работает обычную 40-часовую неделю, но из-за других вещей, происходящих вокруг них, таких как поддержка, общение с отделом маркетинга, встречи и т. д., каждый человек сможет только 75% работают над реальными функциями, остальные 25% будут использоваться для других задач.

Таким образом, у каждого человека есть 30 свободных часов каждую неделю, что дает вам 30*4 = 120 часов в общей сложности на эту неделю, если посчитать всех 4 человек.

Теперь предположим, что вы пытаетесь создать спринт продолжительностью 3 недели, что означает, что у вас есть 3*120 часов работы, которую вы можете выполнить.Это ваша скорость, насколько быстро вы двигаетесь, сколько «сюжетных очков» вы можете пройти.

Единица вашей скорости должна быть совместима с единицей измерения ваших сюжетных очков.Вы не можете измерять истории в том, «сколько чашек разработчик(ы) выпьют при реализации этого» с «сколько часов у нас есть в наличии».

Затем вы пытаетесь найти набор функций, которые вместе набирают около 120 баллов, но не более, в порядке их приоритета.Это будет просто суммирование сверху вниз до тех пор, пока вы не достигнете задачи, которая превысит или равняется этим 120 баллам.Если это опрокинуло его, не включайте задачу.

С таким же успехом вы можете оценить количество дней или чашек кофе, выпитых разработчиком, поскольку это число является репрезентативным для типа работы, которую вы выполняете, и может быть связано с фактической работой, которую вы будете выполнять (т.сколько времени у вас есть).

Вам также следует оценивать свою рабочую нагрузку после каждого спринта, чтобы выяснить, верна ли цифра в 75%.Например, если вы справились только с половиной того, что планировали, выясните, были ли ваши оценки функций неправильными или оценки рабочей нагрузки были неправильными.Затем примите во внимание полученные знания при оценке и планировании следующих спринтов.

Также обратите внимание, что функции следует разделить, если они становятся слишком большими.Основная причина этого заключается в том, что в более крупные оценки заложено гораздо больше неопределенности, и вы можете смягчить это, разделив их на подфункции и оценив их.Тогда большая общая функция становится суммой всех подфункций.Это также может дать вам возможность разделить функцию между несколькими людьми, назначив разные подфункции разным людям.

Хорошее практическое правило заключается в том, что объекты, оценка которых превышает 1 день, вероятно, следует разделить.*

Другие советы

Помните, что Очки - это просто ПЗУ (приблизительный порядок), созданные с помощью Planning Poker & Quot; как обычная практика. Первые несколько спринтов - это когда вы начинаете определять, что очки значат для команды, и чем дольше вы идете, тем точнее становится команда.

Плюс обратите внимание на использование точек, которые немного более разнесены. Практика, которую я видел и использовал, заключается в использовании последовательности Фибоначчи . слишком много различий в 1 балл

Также не забывайте о тестировщиках: при наведении сюжета любому, кто занимается тестированием, необходимо взвесить, поскольку иногда простая задача разработки может привести к значительным усилиям по тестированию, и, если они верны в Sprints, идея состоит в том, чтобы все было завершено, как могло бы быть. отправлен (построен, испытан и задокументирован). Таким образом, оценка истории определяется командой, а не отдельным человеком.

Значение 10 является просто значением относительно других оценок, например, это вдвое сложнее, чем 20 или чуть сложнее, чем 9. Нет конкретного перевода в 1 балл = х часов усилий - это то, на что можно указать.

Там, где я работаю, у нас есть то, что мы называем «эпическими точками». как трудно это какая-то история высокого уровня, например. интегрировать Поиск в новый веб-сайт, который будет состоять из нескольких историй для завершения, а затем мы рассчитываем часы для каждой истории, созданной в результате разбивки каждого эпоса, например. просто вставьте Поиск для документов поддержки на сайте. «Эпические точки» распределены в вариации чисел Фибоначчи (1,2,3,5,8,13,21,28,35), так что более широкие, более расплывчатые эпопеи просто получают большое значение, например, все, что больше 8, является показателем того, что его можно разбить на более легко оцениваемые истории. Здесь также стоит отметить, что там, где я работаю, мы работаем только 5 дней в неделю, и в рамках каждого спринта день теряется на такие встречи, как демонстрация, встреча по планированию итераций, ретроспектива и обзор, поэтому на спринт уходит только 9 дней. Добавление парного программирования для некоторых вещей, времени для исправления ошибок и другой внепроектной работы, такой как заявки на поддержку, и становится довольно трудно сказать, сколько часов будет потрачено горсткой разработчиков в спринте.

Первые несколько спринтов - это когда значения начинают становиться более конкретными, так как на основании полученного опыта оценки могут стать более четкими с точки зрения того, как угадать значение.

С новой командой или проектом мы всегда начинаем с предположения, что сюжетная точка - это «идеальный день», и мы рассчитываем, что каждый разработчик получает около 3,5 идеальных дней в неделю, как мы рассчитываем нашу вероятную начальную скорость.

Как только вы пройдете через " планирование покера " Сценический и сбалансированный / сравнивший все ваши истории, реальная реальная длительность сюжетной линии действительно неизвестна - все, что у вас есть, - это довольно хорошее представление о продолжительности относительной , и вы должны прислушиваться к своему мнению с вероятной скоростью.

По крайней мере, так я это делаю!

Если вы также нацеливаете свои исторические точки на то, чтобы они были примерно равны идеальному дню, тогда я бы предложил разбить ваши истории на более мелкие истории, иначе вы не будете хорошо проводить время при планировании и отслеживании итераций.

Хорошие ответы повсюду.

Я хотел бы добавить еще один момент: не очень важно, что вы выбираете в качестве основы для значения ваших баллов (часы, идеальные дни и все остальное). Важно, чтобы оно было последовательным.

Если вы сохраните его согласованным, это позволит вам обнаружить «истинную скорость». вашей команды. Например, допустим, у вас было несколько итераций: 

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 улучшать свои оценки по мере их продвижения.

У Дж. Б. Кинга лучший ответ, но нет голосов, что означает, что неверная информация распространяется и способствует плохой интерпретации разборок. Пожалуйста, посмотрите реальные ответы от одного из людей, которые разработали 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

Не связан с StackOverflow
scroll top