Я составил график сгорания моей команды и его скорость за итерацию. Для меня это выглядит очень плохо (скорость сильно колеблется). Что я должен искать, чтобы диагностировать причину этого поведения?
Почему это выглядит плохо? Большинство проектов начинаются с целого ряда простых для решения проблем, а затем переходят к более поздним, поскольку некоторые из первоначальных предположений оказываются неверными и должны быть исправлены для решения последующих проблем.
Blrfl
1
Ваша команда набирает 1000 очков за спринт?
Брайан Оукли
@BryanOakley Больше похоже на 100 очков / спринт. Я принимаю верхнюю строку за «накопленную стоимость».
Калеб
«Точки» намеренно произвольны - даже если это 1000 очков за спринт, это может означать, что одна точка - это, может быть, десять человеко-минут или что-то в этом роде.
tdammers
1
@KirkBroadhurst Посмотри внимательно. Линия, помеченная «Скорость» в ключе, является сплошной черной и соответствует нижней строке на графике. Строка с пометкой «Acc. Значение в ключе серое, как и верхняя линия на графике. Вы также можете проверить осмотром, что верхняя линия, скорее всего, является промежуточной суммой нижних точек данных: линия ровная в течение нескольких недель, когда нижняя линия близка к нулю (спринты 6, 9, 15 ...), имеет постоянный наклон нижняя линия ровная (спринты 3-6, 10-13) и никогда не уменьшается.
Калеб
Ответы:
20
Вполне нормально иметь колебания в первых десяти или около того спринтах, пока команда находит свой ритм. После этого вполне нормально, что скорость колеблется в среднем. Попробуйте построить скользящее среднее из последних пяти спринтов или около того, и вы должны увидеть его выравнивание. Если нет, то некоторые из следующих могут быть виновниками:
Команда пытается скорректировать свои оценки историй, основываясь на их недавней скорости, вместо того, чтобы сохранять исторические точки постоянными и корректировать, сколько историй они берут.
Вы не ломаете истории достаточно маленькими.
Слишком много ваших историй находятся в более высокой степени детализации. Например, у вас есть много 20 указателей, которые вы не хотите менять на 13 или 40.
У вас есть много «похмельных» историй, которые не совсем заканчиваются в одном спринте.
Что вы собираетесь делать для историй о «похмелье»? Особенно, если спринт становится «завершенным», по крайней мере, для части команды, а затем им приходится перетаскивать историю из спринта за несколько дней до окончания спринта. Из того, что мне сказали, «это в среднем». Разве это не правильный образ мышления?
Earlz
Лично для меня это «хорошо», и моя команда Scrum соглашается. Другие команды делают такие вещи, как двойная проверка готовых историй, добавление дополнительного тестирования, разбивка историй на более мелкие части или собачьи кучи на истории, чтобы избежать похмелья, и это действительно больше соответствует «чистой схватке».
Карл Билефельдт
Хотя когда-нибудь это плохо? Например, много раз мы будем выполнять обязательства исключительно по скорости. Commit будет включать в себя множество текущих статей, а затем мы будем перетаскивать истории в спринт по мере необходимости (и это запланировано и ожидается).
Earlz
Плохо, если ваш код не находится в состоянии отправки в конце спринта. Пуристы Scrum считают, что планировать вставлять истории в спринт в принципе плохо, даже если ваш код может быть отправлен в конце спринта. Лично я чувствую, что не плохо адаптировать процесс под свою команду.
Карл Билефельдт
4
Вы неправильно используете скорость в качестве показателя производительности, как будто некоторое количество принятых баллов - это «хороший» спринт, а что-то меньшее, чем «плохой» спринт.
Скорость (которая является ужасно неправильно названной концепцией) должна использоваться в качестве перспективного инструмента для оценки того, сколько функций команда может использовать в следующем спринте, т.е. скорость должна использоваться для планирования мощности.
Вот заметная цитата из статьи: «Проблема заключается в весе, придаваемом скорости и превращающем ее в показатель производительности».
Там может быть проблема в том, что похоже на значительные различия в вашей скорости. Это не означает, что команда делает что-то не так, но результат в том, что способность команды к будущим спринтам нельзя предсказать очень хорошо. К сожалению, это не тот вопрос, на который любой из нас может ответить для вас. Вы должны копаться в предмете с помощью ретроспективы. Что на самом деле происходит?
В любом случае, самая важная мера отсутствует в вашем графике. Насколько хорошо команда справилась с поставленной задачей? Изменяется ли скорость, потому что они превышают свои обязательства в некоторых спринтах, но не в других, она колеблется, потому что они не заканчивают рассказы, или она колеблется, потому что обязательства также колеблются?
Дополнительная потенциальная причина: во время более поздних спринтов вы выплачиваете техническую задолженность по более ранним спринтам.
Например, у вас есть демо-версия управления после спринта 3 и вам нужно показать сценарий счастливого дня. Чтобы сделать это, вы делаете кодирование без обработки ошибок, без поддержки перевода, без юнит-тестирования. Это правильное решение, вам просто нужно знать о последствиях.
Итак, позже вы добавите все приятные вещи, такие как среда обработки возбуждения, поддержка перевода, среда модульного тестирования и так далее. Ваша существующая кодировка из первых 3-х спринтов пока не использует это, поэтому ее необходимо обновить. Это усилие замедляет создание ценности во время более поздних спринтов.
На ваш вопрос трудно сказать, почему он имеет колебания, потому что это может быть связано с историей, людьми в команде или способностями владельца продукта. Итак, по моему опыту, скорость будет колебаться, потому что, например:
Возможно, ваш член команды не является преданным членом команды. Чтобы работать и понимать друг друга, им нужно работать вместе достаточно долго. Если ваша команда часто меняет людей в команде на вход / выход, это делает ее динамичной и влияет на скорость.
Карты истории слишком велики. Таким образом, команда не может вдаваться в подробности при планировании / оценке. Во время спринта они обнаружат, что что-то сложнее, чем они думают.
Я думаю, что вы делаете разборки. В Scrum мы должны выполнить часть 1 планирования спринта (владелец продукта выбирает, что делать) и часть 2 планирования спринта (команда решает, сколько они могут сделать). Таким образом, ситуация может быть такой: после того, как владелец продукта выберет карты для спринта, команда не будет достаточно подробно разбираться в части 2 планирования спринта, поэтому они не смогут найти скрытую проблему, о которой им нужно сообщить владельцу продукта. Если они сначала обнаружат проблемы, они сломают их ИЛИ подумают, как избавиться от риска. Это делает оценку достаточно точной перед началом работы над спринтом.
Если сюжет карты не детализирован, оценка не будет точной. Оценка вначале может быть грубой, но перед началом спринта или перед тем, как карты истории отправятся в спринт, их необходимо разделить и уточнить, чтобы получить почти правильную оценку. Это помогает скорости команды быть более стабильной.
Владелец продукта может быть не в состоянии прояснить сюжетные карты достаточно ясно, прежде чем начать работу над спринтом. Это также очень важно, потому что это цель команды работать в течение этих двух недель. Если владелец продукта просто выбирает карту для спринта, а команда еще не понимает ее, им все равно нужно понять их во время спринта, и может получиться ответ, что у него больше, чем они обсуждали, и оценка неверна. Итак, это явно влияет на скорость.
и т.д...
Во всяком случае, на мой взгляд, я не думаю, что колебания скорости важны, пока мы знаем, какова ситуация на каждом спринте. Скорость это просто вещь, чтобы сказать вам, насколько стабильной может работать ваша команда. Если это не стабильно, мы должны детально выяснить каждый спринт о «что случилось». Это просто способ прояснить / заставить проблему возникнуть, чтобы мы могли ее исправить. Итак, скорость просто скажет нам, что происходило в этом спринте, чтобы мы могли вспомнить и улучшить его, чтобы сделать его стабильным. Скорость - это проекция проекта. И колебания скорости не означают, что команда не может предоставить продукт, это просто помогает вам думать о прогнозировании в будущем и о том, какие проблемы нужно решить, чтобы все было гладко.
Ваша скорость имеет шум (колебания). Возможные причины:
Истории слишком велики, и довольно часто наполовину законченная история поднимается до следующего спринта.
Истории не были точно оценены. Это может быть из-за неопытной команды или опять-таки слишком больших историй.
Этот шум не обязательно сам по себе является проблемой: шумовая скорость, которая колеблется вокруг постоянного среднего, все еще позволяет вам точно планировать выпуск.
Однако, если вы отфильтруете шум (скользящее среднее за 5 последовательных спринтов), то ваша скорость все равно будет снижаться после 20 спринтов. Это затрудняет планирование релизов, и это стоит изучить:
Является ли «определение выполненного» слишком слабым, и команда накапливает оставшуюся работу от предыдущих спринтов?
Становится ли организация лучше отвлекает внимание от разборок и навязывает команде невыполненную работу?
Большие истории (эпопеи) внизу журнала были оценены более оптимистично, чем более подробные истории сверху?
Ответы:
Вполне нормально иметь колебания в первых десяти или около того спринтах, пока команда находит свой ритм. После этого вполне нормально, что скорость колеблется в среднем. Попробуйте построить скользящее среднее из последних пяти спринтов или около того, и вы должны увидеть его выравнивание. Если нет, то некоторые из следующих могут быть виновниками:
источник
Вы неправильно используете скорость в качестве показателя производительности, как будто некоторое количество принятых баллов - это «хороший» спринт, а что-то меньшее, чем «плохой» спринт.
Скорость (которая является ужасно неправильно названной концепцией) должна использоваться в качестве перспективного инструмента для оценки того, сколько функций команда может использовать в следующем спринте, т.е. скорость должна использоваться для планирования мощности.
http://jimhighsmith.com/velocity-is-killing-agility/
Вот заметная цитата из статьи: «Проблема заключается в весе, придаваемом скорости и превращающем ее в показатель производительности».
Там может быть проблема в том, что похоже на значительные различия в вашей скорости. Это не означает, что команда делает что-то не так, но результат в том, что способность команды к будущим спринтам нельзя предсказать очень хорошо. К сожалению, это не тот вопрос, на который любой из нас может ответить для вас. Вы должны копаться в предмете с помощью ретроспективы. Что на самом деле происходит?
В любом случае, самая важная мера отсутствует в вашем графике. Насколько хорошо команда справилась с поставленной задачей? Изменяется ли скорость, потому что они превышают свои обязательства в некоторых спринтах, но не в других, она колеблется, потому что они не заканчивают рассказы, или она колеблется, потому что обязательства также колеблются?
источник
Дополнительная потенциальная причина: во время более поздних спринтов вы выплачиваете техническую задолженность по более ранним спринтам.
Например, у вас есть демо-версия управления после спринта 3 и вам нужно показать сценарий счастливого дня. Чтобы сделать это, вы делаете кодирование без обработки ошибок, без поддержки перевода, без юнит-тестирования. Это правильное решение, вам просто нужно знать о последствиях.
Итак, позже вы добавите все приятные вещи, такие как среда обработки возбуждения, поддержка перевода, среда модульного тестирования и так далее. Ваша существующая кодировка из первых 3-х спринтов пока не использует это, поэтому ее необходимо обновить. Это усилие замедляет создание ценности во время более поздних спринтов.
источник
На ваш вопрос трудно сказать, почему он имеет колебания, потому что это может быть связано с историей, людьми в команде или способностями владельца продукта. Итак, по моему опыту, скорость будет колебаться, потому что, например:
Во всяком случае, на мой взгляд, я не думаю, что колебания скорости важны, пока мы знаем, какова ситуация на каждом спринте. Скорость это просто вещь, чтобы сказать вам, насколько стабильной может работать ваша команда. Если это не стабильно, мы должны детально выяснить каждый спринт о «что случилось». Это просто способ прояснить / заставить проблему возникнуть, чтобы мы могли ее исправить. Итак, скорость просто скажет нам, что происходило в этом спринте, чтобы мы могли вспомнить и улучшить его, чтобы сделать его стабильным. Скорость - это проекция проекта. И колебания скорости не означают, что команда не может предоставить продукт, это просто помогает вам думать о прогнозировании в будущем и о том, какие проблемы нужно решить, чтобы все было гладко.
источник
Ваша скорость имеет шум (колебания). Возможные причины:
Этот шум не обязательно сам по себе является проблемой: шумовая скорость, которая колеблется вокруг постоянного среднего, все еще позволяет вам точно планировать выпуск.
Однако, если вы отфильтруете шум (скользящее среднее за 5 последовательных спринтов), то ваша скорость все равно будет снижаться после 20 спринтов. Это затрудняет планирование релизов, и это стоит изучить:
источник