Смущает изменение журнала спринта во время спринта

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

Тем не менее, я прочитал Scrum и XP из траншей, и это описывает раздел для незапланированных предметов на доске задач. Затем я посмотрел Руководство по Скраму и там говорится, что во время спринта «Не было сделано никаких изменений, которые могли бы повлиять на Цели Спринта», и в ходе обсуждения Цели Спринта «Если работа окажется отличной от ожидаемой Команды разработчиков, затем они сотрудничают с владельцем продукта, чтобы договориться о масштабах отставания Sprint в Sprint ». Далее говорится в обсуждении спринта:

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

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

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

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

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

Во-первых, у меня не было бы жестких правил по этому поводу; весь смысл схватки в том, чтобы позволить вам адаптироваться к ситуации. Таким образом, вы должны быть в состоянии изменить отставание спринта во время спринта, если это абсолютно необходимо (как будто вы забыли что-то критическое).

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

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

1. Добавить новый элемент в спринт.
   НО удалите предмет такого же размера из спринта.
2. Бросьте предмет, который был плохо спланирован из этого спринта (чтобы вы могли правильно спланировать его в следующем спринте).
   • Добавление альтернативы (соответствующего размера) из верхней части списка невыполненных работ по продукту (который должен быть в приоритетном порядке на совещании по планированию спринта).
   • Или, когда все элементы спринта завершены, разработчики могут избавиться от отставания продукта.

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

Затем на следующем совещании по планированию новая задача будет соответствующим образом проанализирована и добавлена ​​в спринт (при необходимости).

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

Путаница связана с неоднозначным языком.

Журнал ожидания спринта имеет два уровня детализации. Во-первых, это список предметов (пользовательских историй), которые команда обязалась доставить. Во-вторых, это все ЗАДАЧИ, которые команда намерена сделать, чтобы донести каждую из этих историй.

Поэтому, когда люди говорят о бэклоге спринта, они должны четко понимать, что они имеют в виду. Когда вы прочитаете Руководство по Скраму, вы увидите, что оно гласит: «Журнал ожидания Спринта» - это набор элементов Журнала работы с продуктом, выбранных для Спринта, а также план доставки Приращения продукта и реализации цели Спринта.

Таким образом, это ОБАЙТИ список продуктов, оставшихся в очереди, и плана (задач) для их доставки.

Теперь многим командам нравится добавлять все предлагаемые задачи (план) в начале Спринта, чтобы они могли отслеживать график выгрузки, основываясь на оставшихся часах. Другие команды позволяют задачам появляться по мере необходимости. ЭТО - то, когда можно добавить к «Журналу спринта», так как команда должна сделать это, чтобы осмотреть и приспособиться, чтобы доставить Предметы и достичь Цели Спринта.

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

Так что у нас это; ДА ... команды ДОЛЖНЫ добавлять Задачи в план Журнала Спринта по мере необходимости. НЕТ, они обычно не добавляются в список элементов журнала невыполненных работ, которые определяют область действия спринта.

Я надеюсь, что это проясняет ситуацию.

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

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

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

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

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

Идея: дать руководству 3 кредита-переключателя, чтобы тратить каждый квартал в качестве компромисса.