Проблемы с выгоранием Scrum [закрыты]
https://stackoverflow.com/questions/91257
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Мы используем Scrum около 9 месяцев, и он в значительной степени был успешным.Однако наши графики выгорания редко похожи на графики "модели", вместо этого они больше напоминают ужасающую поездку на американских горках с вызывающими рвоту подъемами и падениями.
Чтобы попытаться бороться с этим, мы тратим больше времени перед спринтом на создание прототипов и проектирование, но, похоже, во время спринта мы все равно обнаруживаем гораздо больше работы, чем предполагалось изначально.Примечание:Под этим я подразумеваю, что работа, необходимая для выполнения невыполненной работы, более сложная, чем кажется на первый взгляд, а не то, что мы определили новые пункты для невыполненной работы.
Является ли это распространенной проблемой в Scrum и есть ли у кого-нибудь какие-либо советы, которые помогут сгладить ситуацию?
Я должен отметить, что большая часть нашей работы по разработке ведется не с нуля, поэтому мы поддерживаем функциональность существующего большого и сложного приложения.Является ли scrum менее подходящим для этого типа разработки просто потому, что вы не знаете, какие проблемы вызовет существующий код?
Сколько времени мы должны потратить до того, как в ходе спринта начнется проработка деталей разработки?
Обновить:Сейчас мы добиваемся большего успеха и движемся более плавно.Во многом это связано с тем, что мы придерживаемся более пессимистичного взгляда при оценке, что дает нам больше пространства для маневра, когда все идет не по плану.Можно сказать, это позволяет нам быть более "гибкими".Мы также пытаемся изменить представление о том, что диаграмма выгорания - это своего рода график, а не указание объема ресурсов.
Решение
Несколько советов, как все уладить.
1) Как говорили другие - попробуйте разбить задачи на более мелкие части.Более очевидный способ сделать это - попытаться более детально разбить технические задачи.Там, где это возможно, я бы посоветовал вам поговорить с владельцем продукта и посмотреть, можете ли вы вместо этого сократить объем или "утончить" историю.Я нахожу последнее более эффективным.Манипулировать приоритетами и оценками проще, если и команда, и владелец продукта понимают, о чем идет речь.
Мое общее эмпирическое правило гласит, что любая оценка, превышающая половину идеального дня, вероятно, неверна :-)
2) Попробуйте делать более короткие спринты.Если вы совершаете месячные спринты - попробуйте пробежать две недели.Если вы работаете две недели - попробуйте одну.
- Это ограничивает размер истории, поощряя владельца продукта и команду работать над небольшими историями, которые легче точно оценить
- Вы чаще получаете отзывы о своих оценках - и легче увидеть связь между решениями, которые вы приняли в начале спринта, и тем, что произошло на самом деле
- С практикой все становится лучше :-)
3) Используйте стендапы и ретроспективы, чтобы подробнее рассмотреть причины взлетов и падений.Это когда вы проводите время с определенными областями базы кода?Вызвано ли это непониманием людьми владельца продукта?Случайные чрезвычайные ситуации, которые отнимают у команды время на разработку?Как только вы лучше поймете, откуда берутся взлеты и падения, вы часто сможете конкретно решать эти проблемы.Опять же, более короткие спринты могут помочь сделать это более очевидным.
4) Верьте своей истории.Вы, наверное, знаете этого человека...но я все равно это скажу :-) Если возня с этим ужасным устаревшим пакетом Foo заняла в 3 раза больше времени, чем вы думали, что это продлится спринт - тогда это также займет в 3 раза больше времени, чем вы думаете о следующем спринте.Неважно, насколько эффективнее, по вашему мнению, вы будете на этот раз ;-) Доверяйте истории и используйте такие вещи, как вчерашняя погода, для составления прогнозов следующей весной.
Надеюсь, это поможет!
Другие советы
Я рад слышать, что scrum был в значительной степени успешным для вас - это важнее, чем то, чтобы график выгорания в спринте выглядел идеально.Анализ результатов спринта - это всего лишь инструмент для команды, помогающий ей понять, находится ли она на пути к достижению целей спринта.если бы команда достигла целей спринта, я бы не слишком беспокоился о том, что график выглядит как американские горки.Несколько предложений
- Во время ретроспективы спринта спросите команду, откуда берется дополнительная работа
- Дополнительная работа может быть связана с отсутствием хороших приемочных тестов в начале спринта
- Дополнительная работа может возникнуть из-за отсутствия ухоженного списка невыполненных работ.Хорошее эмпирическое правило состоит в том, чтобы тратить не менее 5% времени команды на обдумывание историй следующего спринта заранее.
- Следите за ходом работы - не слишком ли много команда делает параллельно?
- Во время планирования спринта - как команда относится к распределению задач, составляющих истории?
Если вы не достигли целей спринта - используйте установленную командную скорость, чтобы взять на себя меньше усилий во время следующего спринта.Ты должен научиться ходить, прежде чем научишься бегать.
По моему опыту, Scrum определенно больше ориентирован на новую разработку, чем на техническое обслуживание.Новая разработка гораздо более предсказуема, чем поддержание старой, большой базы кода.
С учетом сказанного, одна из возможных проблем заключается в том, что вы не разбиваете задачи на достаточно маленькие фрагменты.Распространенная проблема, с которой сталкиваются люди при планировании программного обеспечения в целом, заключается в том, что они думают: "о, эта задача должна занять у меня 2 дня", на самом деле не задумываясь о том, что входит в выполнение этой задачи.Часто вы обнаружите, что, если вы сядете и подумаете об этом, эта задача состоит из выполнения пунктов A, B, C и D и в итоге занимает более 2 дней работы.
Как говорили другие, я бы ожидал, что выгорание будет нарастать и спадать.Всякое случается!Вы должны использовать фрагменты "вверх и вниз" в качестве материала для ваших ретроспектив.
Убедитесь, что всем ясно, что означает "выполняется", и используйте это совместное понимание для управления вашими сессиями планирования.Часто наличие списка того, что считается выполненным, (а) поможет вам вспомнить то, что вы могли забыть, и (б), скорее всего, вызовет больше идей для задач, которые в противном случае появились бы позже.
Еще один момент, о котором стоит подумать - если вы работаете месяц за месяцем с непредсказуемой кодовой базой, я бы все равно ожидал, что ваша скорость нормализуется до достаточно стабильного уровня.Просто сопоставьте свой успех с запланированной работой и используйте при планировании максимум выполненных заданий.Затем сосредоточьтесь на своих незапланированных задачах и посмотрите, есть ли какие-либо закономерности, которые предполагают, что есть вещи, которые вы можете сделать по-другому, чтобы включить их в запланированную работу.
У меня были похожие проблемы.Моя предыдущая команда (занимавшаяся ИТ больше года) была большой, и мы поддерживали очень большую, быстро меняющуюся кодовую базу для серии первых запусков продуктов.Наши поджоги выглядели постыдно, но это было лучшее, что мы когда-либо могли сделать.
Одна вещь, которая может помочь (улучшить внешний вид вашего графика), - это придерживаться постоянного количества часов / очков.Если вы недооценили задачу и вам пришлось удвоить количество часов, извлеките что-нибудь из спринта.Если вы выполняете новую задачу, очевидно, что она имеет более высокий приоритет, чем то, чему обязалась ваша команда, поэтому выполняйте эту другую задачу.
Мы попробовали разбить задачу на множество задач во время планирования и до него, но, похоже, это так и не помогло.На самом деле, это просто дало нам больше чертовых билетов, за которыми нужно следить во время спринта.Требования начали переноситься в билеты и (что неудивительно) затерялись во всей этой суматохе.
В моей новой команде мы применили довольно радикальный подход и начали создавать большие тикеты (некоторые продолжительностью более недели), в которых говорится что-то вроде "реализовать функции версии v1.2 в ProjectX". Списки требований / функций для ProjectX (включая версию 1.2) хранятся в wiki, поэтому тикет очень чистый и отслеживает только выполненную работу.Это нам очень помогло - у нас есть способ меньше билетов, за которыми нужно следить, и мы смогли завершить все наши спринты, даже несмотря на то, что нас постоянно отрывают от спринтерских заданий, чтобы помочь другим командам или потушить пожары.
Мы продолжаем выталкивать предметы из спринта тогда (и только тогда), когда нас заставляют (мужчина) вносить новые предметы.
Еще один простой совет, который нам помог:добавьте "общее количество часов в спринте" в свой отчет.Это должна быть сумма всех оценок.Работа над сохранением этой линии может помочь и повысить видимость проблем, с которыми может столкнуться ваша команда (при условии, что это не приведет к вашему понижению в должности ...)
-ab
У меня тоже были похожие проблемы во время моего выгорания.Я "исправил" это, уточнив то, что было включено в выгорание.
Сикип прокомментировал:
Достижения отставание некоторые для этого спринта, который может или может не до конца как избавления.
Поскольку вы выбрали определенные вещи для спринта, и это то, что есть в burndown, я не уверен, что вся "новая работа" должна появиться в burndown.Я бы увидел, что это переходит в бэклог (не влияя на выгорание), если только это не является достаточно важным, чтобы перейти к вашему текущему спринту (который затем проявился бы как восходящий тренд при выгорании).
Это сказало, незначительные подъемы и спады - это нормально, если линия тренда в основном соответствует вашей ожидаемой скорости.Я был бы обеспокоен тенденцией к американским горкам, о которой вы упоминаете.Однако идея изолировать процесс выгорания путем добавления только высокоприоритетных элементов в текущий спринт может помочь смягчить эти подъемы и спады в вашем процессе выгорания.
Как уже говорили другие, планирование перед началом спринта должно быть коротким ... (не более 4 часов).
Мы используем "ограниченную по времени" задачу для незапланированных задач.Всякий раз, когда предстоит высокоприоритетная работа или внезапно всплывают ошибки, мы можем использовать время из тайм-бокса (но мы никогда не можем опуститься ниже нуля).Этот метод имеет дополнительное преимущество в том, что мы можем легко отслеживать, какие задачи были непредвиденными, и учитывать их при планировании следующего спринта.
Вы можете интегрировать новую работу в дату начала спринта, чтобы получить великолепно выглядящую итоговую диаграмму.
Вы можете пометить специальным маркером дополнительную работу и в конце спринта оценить, почему вы не смогли определить эти задачи раньше.
Сейчас мы используем диаграмму выгорания.Вместо того чтобы просто подсчитывать объем оставшейся работы, мы подсчитываем две вещи:объем выполненной работы и общий объем работ (т.е.завершено + не выполнено).
Это дает вам две линии на графике, которые должны встретиться, когда вся работа будет выполнена.Это также имеет большое преимущество в том, что оно четко показывает, когда прогресс идет медленно, потому что было добавлено больше работы.
Если хотите, ПО "владеет" одной строкой (общая работа), а разработчики / тестировщики "владеют" другой строкой (выполненная работа).
Строка PO будет подниматься и опускаться по мере добавления / удаления работы.
Строка dev / tester будет увеличиваться только по мере завершения работы.
Статья Это твой график выгорания? объясняет, что означает данный статус в таблице выгорания.В нем также содержатся предложения, что с этим делать.
Некоторые примеры, описанные в статье:
Так и должно быть.Если ваша диаграмма выгорания похожа на диаграмму модели, у вас проблемы.Диаграмма поможет понять, сможете ли вы взять на себя обязательства и закончить все истории.
Открытие историй во время спринта будет происходить всегда.В идеале вы могли бы спроектировать и определить задачи заранее, но если бы они работали, почему бы большому предварительному дизайну не сработать?Чтобы ответить на ваш последний вопрос, планирование спринта должно занять самое большее четыре часа.
