Можем ли мы выделить время на сюжетные очки?

Я скрам-мастер, свободно использующий следующую систему:

  • 0,2 балла примерно < 1 часа
  • 0,5 балла примерно > 2 часов, но < 3 часов
  • 1 балл примерно > 4 часов (полдня)
  • 2 балла примерно > 8 часов (1 день)
  • 3 балла примерно > 16 часов (2 дня)

Я использую приближения в качестве ориентира того, сколько примерно времени займет задача. Используйте это в качестве руководства для определения стоимости работы за неделю. Мои спринты обычно длятся 4 дня. Таким образом, в этом случае команда суммирует очки за недельный эквивалент примерно.

Отслеживая прогресс моей команды после 3-4 спринтов, я обнаружил, что выделение времени на баллы становится бессмысленным, поскольку общее количество баллов, которые они могут выполнить, увеличивается с течением недель. На прошлой неделе было 6,2 балла, на этой неделе эта цифра увеличилась до 9, обычно это меняется, и я пытаюсь найти среднюю скорость команды.

Должен ли я измерять производительность команд по среднему количеству очков, которые они могут набрать в спринте, или привязывая время к очкам в качестве приближения.

Спасибо

Сюжетные точки могут быть связаны со временем, но не напрямую. Майк Кон описывает это как распределение, поэтому 3 балла равны, например, пяти дням со стандартным отклонением X. Но чтобы добраться до точки, где вы можете сделать это приближение, вам сначала нужно запустить несколько спринтов, не думая о преобразовании времени. Таким образом, ваш коэффициент преобразования будет возникать из опыта, а не наоборот. scrumalliance.org/community/spotlight/mike-cohn/june-2014/…
Если мы можем напрямую сопоставить точки со временем, какой цели служит скорость? Что представляет собой наша основанная на доказательствах обратная связь для правильности этого отображения, если не скорость?
Вы явно путаете пользовательские истории с задачами. Вы можете оценивать задачи в идеальных часах, если хотите, но если вы пытаетесь преобразовать баллы в идеальные часы, вы делаете Agile Estimation Wrong® .

Ответы (4)

Story Points — это АБСТРАКТНОЕ измерение сложности приращения продукта. Идея состоит в том, что сложность одинакова для всех, тогда как усилия, необходимые для ее завершения, различаются в зависимости от навыков и опыта разработчика. Так что подсчет времени по сюжетным очкам для меня вообще не имеет смысла. Поскольку вы уже испытываете рост скорости, в то время как рабочее время остается стабильным, вы можете видеть, что нет прямой зависимости между точками истории и временем. И я бы не рекомендовал измерять производительность команды ни временем, ни стори-пойнтами. Вместо этого я рекомендую смотреть на работоспособность (сколько команда может успешно выполнить за спринт) и на фокус (сколько времени они фактически тратят на достижение цели спринта).

«Вместо этого я рекомендую смотреть на работоспособность (сколько команда может успешно выполнить за спринт)» — как мне это измерить?
@ bobo2000 Вы захотите сравнить выделенные сюжетные очки с завершенными. Емкость обычно основана на баллах.
@ bobo2000 вот один метод, который мне очень подходит. Просто измерьте, сколько сделано и сколько времени это заняло. pm.stackexchange.com/a/18279/21039

Таким образом, потенциально здесь происходит несколько вещей.

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

Сказав это, у меня есть пара наблюдений/мыслей.

  1. Мои спринты обычно длятся 4 дня.

Я думаю, что ваши спринты слишком короткие, чтобы получить точное представление о производительности вашей команды с течением времени. Исходя из личного опыта, я ожидаю, что вы часто будете переносить или завершать истории, которые не тестируются. Я думаю, что лучше всего, чтобы спринты были не короче 1 недели и не длиннее 4 недель; и чаще всего спринты составляют 2 недели.

  1. Отслеживая прогресс моей команды после 3-4 спринтов, я обнаружил, что выделение времени на баллы становится бессмысленным, поскольку общее количество баллов, которые они могут выполнить, увеличивается с течением недель.

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

  1. Ваша шкала баллов кажется мне неправильной. Я бы рассмотрел возможность использования чисел Фибоначи, если вы должны использовать числа, или если вам сойдет с рук это [Маленький, Средний, Большой, Большой] или какой-либо вариант [Эффективность, Квартира, Кондо, Дом, Особняк], который вам удобен. На мой взгляд, все, что меньше 1 балла/полдня, слишком мало для оценки, и если ваша команда использует эти баллы/шкалу для оценки, они, скорее всего, будут ошибочными, потому что разработчики, как правило, слишком оптимистичны в отношении того, сколько можно сделать.
Делал «маленький», «средний» и «большой» раньше - это не отслеживается диаграммой выгорания. Делают только точки. Также раньше я выполнял недельные спринты, но это не нравилось заинтересованным сторонам, поэтому мне пришлось делать 4 дня, все, что это означало, это то, что я должен был выделить работу на 4 дня.
@ bobo2000 Сколько разработчиков в вашей команде / проверяется ли работа на качество, прежде чем она будет помечена как выполненная? Почему заинтересованная сторона непреклонна в отношении четырехдневных спринтов? Вы можете представить концепцию точки взаимодействия с заинтересованной стороной в середине спринта.
@dmeel да и да. Он хочет четырехдневные спринты, потому что его расстраивает то, что он не может делать запросы на изменение, т.е. добавлять вещи в спринты после того, как спринт начался. У нас 2 разработчика и 1 QA-тестер.
@ bobo2000 Похоже, вам нужно накопить невыполненную работу. Если у вас уже есть бэклог, содержащий работы на несколько спринтов, похоже, что ваша заинтересованная сторона действительно не верит в agile-процесс. Если 4 дня в спринте — это то, что должно быть, я думаю, вы по-прежнему будете испытывать большие колебания в средних баллах из-за того, как ваши истории должны быть написаны, чтобы соответствовать 4-дневному спринту.
@ bobo2000 вы не думали о том, чтобы позволить ему изменить приоритеты в середине спринта? Я знаю, это звучит безумно, но вот и я. Ваш PO хочет изменить приоритеты в середине спринта, поэтому вы проводите его к доске и позволяете ему. Но вы должны подчеркнуть, что он не собирается что-то добавлять в спринт, не убрав что- то, и он не может убрать что-то из того, что уже начато. Он быстро начнет лучше расставлять приоритеты в отставании, если непосредственно почувствует боль, которую причиняет, прерывая спринт. Также обязательно отслеживайте изменения емкости относительно количества изменений приоритета.
@RubberDuck Я уже делал это, но когда я это делаю, это кажется грязным, так как я видел, как люди здесь говорят, что «вы не можете изменить невыполненную работу спринта», как только команда примет это.
Нет ни одного настоящего Agile-способа @bobo2000. ИМО, нет ничего плохого в том, чтобы изменить приоритеты невыполненной работы на лету, учитывая, что вы не бросаете работу, которая уже выполняется. Примите это с долей скептицизма, я работаю по Канбану, а не по Скраму. В моем рабочем процессе нет понятия обязательства по спринту или невыполненной работы по спринту. Просто постоянно обновляемый и расставленный по приоритетам бэклог продукта, в котором мы делаем следующее самое ценное. Все, что я могу сказать, это то, что это работает для нас.

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

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

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

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

Пытаясь связать точки со временем, вы подрываете всю систему.

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

Вы не можете сказать что-то вроде «нам нужно сделать эту дату с этими функциями, и вы не можете присваивать баллы функциям.

Большая часть первоначального материала XP была посвящена исправлению управления проектом, а не разработке проекта, и самые важные моменты, подобные этому, — это те, которые просочились в ответвления, такие как схватка. Чтение некоторых оригинальных материалов XP может помочь понять, почему некоторые из этих процессов работают.

Можем ли мы выделить время на сюжетные очки?
СпросиСетьПолитика конфиденциальности1y, 0v