Как бороться с спринтерским планированием, которое выполняется слишком долго?


14

Я занял более 5 часов в спринтерском планировании на недельный спринт. Это кажется слишком много.

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

Как мы справимся с этим?

Сколько деталей я должен обсудить во время планирования, чтобы он соответствовал всего 2 часам в спринте в неделю?


2
Что именно вы делаете в Sprint Planning? Вы ломаете истории, уточняете требования, делаете дизайн, оценивает?
Liath

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

1
Вы делаете отставание груминга на отдельной встрече? Мы обычно планируем отставание по таймбоксу до 1 часа на спринт, а планирование спринта - до 1 часа на спринт. Это хорошо работает для наших двухнедельных спринтов.
Берин Лорич

4
@ b.ben, но «дизайн» не является частью планирования спринта.
Томас Джанк

2
эй, подожди, почему ты говоришь о внедрении во время планирования спринта? Планирование спринта о чем не как .
candied_orange

Ответы:


20

Вы правы - 5 часов в Спринте Планирование на 1 неделю Спринт кажется долгим. В Scrum Guide установлены временные рамки Sprint Planning на 8 часов в течение 1 месяца Sprints и говорится, что «для более коротких Sprints событие обычно короче». Если принять во внимание соотношение, хорошей целью может быть 2 часа планирования спринта для 1-недельного спринта, но нет фиксированного временного интервала.

Итак, как вы можете решить долгое планирование спринта?

Как Scrum Master, я бы предпринял следующие шаги:

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

Во-вторых, я бы позаботился о том, чтобы команда тратила достаточно времени на уточнение отставания. В Scrum Guide указано, что деятельность по доработке обычно занимает не более 10% от потенциала команды разработчиков. Например, команда разработчиков из 4 человек, работающая в стандартную 40-часовую неделю, должна запланировать около 16 часов для уточнения отставания. Это может быть сделано индивидуально, в небольших группах или в команде. Я обнаружил, что проведение запланированного сеанса уточнения невыполненных работ для группы, а затем проведение каких-либо исследований, расследований или планирования имеет тенденцию работать лучше всего.

В-третьих, убедитесь, что команда понимает, что им не нужно правильно продумывать каждую деталь в Sprint Planning. Целью планирования спринта является составление плана достижения целей спринта. Не пытайтесь сделать большой дизайн заранее на сессии Планирования Спринта. Поймите, как различается работа, зависимости и цели, и используйте время вне сеансов планирования спринта с нужными людьми для выполнения проектирования, реализации и тестирования, необходимых для выполнения работы.

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


3
По сути, команда все равно будет проводить столько же часов на собраниях. Мы просто называем их разными встречами. :) Требуется все, что нужно, чтобы разбить все на части, чтобы команда чувствовала себя комфортно, оценивая работу, и была независимой, когда пришло время выполнять работу.
Грег Бургхардт

5
@GregBurghardt: OP пишет, что большую часть времени они занимаются дизайном. Таким образом, вся команда работает над дизайном каждой истории. Если вы разберетесь с этим, чтобы над каждой соответствующей историей работала только часть команды, вы сократите общее время, затрачиваемое на собрания.
Майкл Боргвардт

Re: «Убедитесь, что команда понимает, что им не нужно правильно продумывать каждую деталь в Планировании Спринта»: И, что еще более важно, убедитесь, что это действительно так, что им не нужно правильно продумывать каждую деталь в панорамировании спринта ,
Руах

@GregBurghardt Возможно. Но есть разница между всей командой, находящейся в комнате в течение 5 часов, и различными комбинациями людей, занятых проектированием в течение 3 часов после 2-часовой сессии планирования.
Томас Оуэнс

5

Я слышу тебя. Это слишком долго, чтобы тратить! Надеюсь, ваша команда обсуждает это в ваших ретроспективах. Мы попробовали несколько экспериментов со смешанными результатами:

  1. Каждый делает высокоуровневый дизайн для одного билета и передает его влево или вправо по столу для проверки, после чего следует групповой обзор плана для каждого билета. Не всем это понравилось, но это заставило наших юниоров попробовать. Некоторые люди в командах очень счастливы, просто позволяя другим думать, и они просто следуют инструкциям. Итак, с другой стороны, наш эксперимент вынудил всех противостоять пробелам в знаниях, что стало проблемой роста для юниоров. С другой стороны, не всем нравится быть на месте, и это не обязательно сокращает время встречи. Следующий!

  2. Парные проекты были предприняты. Группы из двух или трех человек разбили бы билет на задачи. Вся команда рассмотрит итоговые планы. Это пошло намного быстрее, но у некоторых мини-контейнеров была та же самая проблема одного человека, едущего вперед, в то время как другой делал работу над дизайном.

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

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


4
Вариант № 3 порождает команды, которые полагаются на одного человека или небольшую группу людей. Если этого человека или людей нет рядом, скорость команды падает прямо в унитаз. Раньше я делал это с нашей командой, и каждый раз, когда этот человек уходил в отпуск, начинался хаос. Ничего не сделано. Затем руководитель группы провел 3 недели, пытаясь успокоить управление проектом. Если вы работаете в команде с юниорами или не специалистами, я определенно не рекомендую # 3. Если у вас есть все эксперты (и они на самом деле эксперты), № 3 может сэкономить время.
Грег Бургхардт

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

2
По моему опыту, они не поправляются, когда кто-то ведет их через вещи. Это превращается в опытных людей, делающих это для менее опытных, потому что менее опытным потребовались на порядки дольше. Нам повезло с тем, что мы сидели в комнате и выполняли задания для разработчиков. Даже проходя код - но не во время планирования спринта. Мы называем это «написанием задач для разработчиков», потому что это то, что нужно нашей команде. Затем они стали независимыми и стали лучше и быстрее писать задачи для разработчиков.
Грег Бургхардт

Рад, что ваша команда нашла способ. Как вы думаете, ваши опытные товарищи по команде выбирали легкий путь? Я знаю, что учить людей - это головная боль. Но это приносит большие дивиденды. У большинства людей нет терпения к этому, и я точно вижу, что вы описываете - опытные люди могут легко потерять терпение в процессе и «сделать это сами». Плюс юниоры должны быть хорошими учениками.
Джейсон Зиншлаг

@GregBurghardt Я уверен, что во время планирования спринта мы сделали что-то вроде «написания задач для разработчиков». И я не уверен, что это нормально?
бенбен

3

Мне нравится ответ, который вы получили от @ Thomas-Owens, но я также добавлю еще один пункт. Рассматривали ли вы парное программирование как часть вашей гибкой реализации?

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

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


Да, это то, что я хотел. Но нашей команде не хватает старшего, чтобы сделать это. Мне пришла в голову идея, которая позволит всем членам команды написать свои абстракции и интерфейсы самостоятельно, прежде чем приступить к реализации, давайте договоримся о встрече между всеми разработчиками. Как вы думаете?
b.ben

1
@ b.ben Но вашей команде никогда не будет достаточно старших, пока вы не сделаете это. Это часть силы парного программирования. Вы должны посвятить себя этому.
Неизвестный кодер

1

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

Я вижу несколько красных флажков в том, что вы пишете:

5-часовое планирование спринта

Это слишком долго для спринта на одну неделю.

Целью планирования спринта является AFAIR для

  • позволить команде знать, каковы текущие приоритеты и
  • разработать план битвы на предстоящий спринт.

Чтобы сделать это эффективно, каждая сторона должна понимать Product Backlog items.

Чтобы понять Product Backlog itemsотставание, оно должно быть в хорошей форме.

На конкретном этапе планирования Product Backlog itemsони преобразуются в Sprint Backlog items.

Одна из возможных причин заключается в том, что эти пункты недостаточно уточнены / уточнены.

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

Обсудите очень подробно в планировании спринта

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

С другой стороны: планирование спринта предполагает профессиональное поведение каждого участника. Это включает в себя избегание велосипедных дискуссий.

Возможно, все и так понятно, но кто-то начинает велосипедную дискуссию.

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

Поскольку большинство членов команды не старшие

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

Ошибки реализации и редизайна в спринте

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

Как я сказал выше: пока Product Backlogон в хорошей форме, трудно упустить момент.

Я не могу представить ситуацию, как:

»Как пользователь, я хочу видеть несколько клиентов!«

«О, вы не имели в виду каждого из наших 2 миллионов клиентов?»

OTOH: Что в этом контексте означает редизайн ? Если разработчик выбрал медленный алгоритм выполнения, то есть следующая ясная цель: выбрать более эффективный алгоритм. Но это не «редизайн», это оптимизация.


На ваши основные вопросы:

Как с этим бороться?

Упрощенно упомянуть, но я все равно это делаю: не забывайте, что вы имеете дело с людьми .

Очень трудно иметь группу разных умов, способных делиться общими понятиями (как в Rashomon ). Чтобы эффективно справиться с этим, используйте как можно больше избыточности в своем общении: например, подробно объясните контекст предмета, даже если каждый «должен знать», что делать. Задайте вопросы, все ли понимают, какова тема данного предмета.

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

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

Сколько деталей я должен обсудить при планировании подгонки 2 часа в спринте на неделю?

Саломонический ответ: как можно меньше и столько, сколько нужно, но не больше.

ТЛ; др

  • Выберите легкий язык (если это поможет, используйте простой английский или ELI5), чтобы избежать недоразумений

  • Улучшить сбор требований

  • Улучшить отставание

  • Повысить уверенность членов команды в их индивидуальных способностях, а также в способностях команды

  • Избегайте велосипедных прогулок

  • Улучшить личную дисциплину

  • Возможно, используйте фиксированные временные рамки для каждого предмета для обсуждения

  • Укрепить позицию, scrum masterчтобы эффективно модерировать.


-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.