Насколько расслабленным (или нет) должен быть спринт?

Каким должно быть отношение к созданию историй, которые назначены на спринт? Очевидно, что вы хотите расставить приоритеты, выполняя их в спринте, но для меня весь смысл гибкого подхода заключается в том, чтобы быть динамичным: вы не хотите сознательно откладывать или делать «хорошо», чтобы пропустить завершение пользовательских историй в спринте, но в В то же время, когда возникают неожиданные вещи, и эти истории не заканчиваются и не переходят к следующему спринту, вы не хотите ощущать, что сделали что-то не так. Это не должно быть страшным или негативным опытом, не так ли?

Приемлемы ли негативные / страшные переживания для пропущенных спринтерских обязательств? Должны ли разработчики нести ответственность за невыполненные обязательства по спринту, когда возникают непредвиденные задачи, которые необходимо решить (например, поддержка производства)?

Вы должны абсолютно стремиться получить элементы сделаны в спринте.

Одним из главных преимуществ SCRUM является то, что он дает проекту «сердцебиение».

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

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

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

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

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

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

Эта причина должна быть чем-то большим, чем неясное "придуманное".

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

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

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

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

Расслабленные спринты означают, что у вас был недостаток.

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

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

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

Можно пропустить крайний срок для первого спринта (начало проекта), но вы УЧИТЕСЬ из того, что пошло не так (недооценка, незнание сильных сторон команды и т. Д.). Затем вы берете отзывы и передаете их на следующий спринт, и вы получаете более точную оценку.

По моему опыту, в моем новом гибком проекте прошло 11 месяцев, и мы редко пропускаем крайний срок, если вообще пропускаем его. Но мы пропустили крайний срок для первого спринта, потому что мы не знали темп и силу членов нашей команды.

Некоторые люди утверждают, что «выделяют» больше времени на первый спринт, чтобы преодолеть первую проблему спринта.

Интересно увидеть ответы / комментарии здесь. В каждом проворном (типовом) проекте, над которым я работал, основным преимуществом было распределение давления по срокам по многим мини-срокам, а не марш по срокам в конце проекта. ИМО, спринты должны быть приняты всерьез. Любые ошибки в крайнем сроке или предоставленной функциональности должны рассматриваться как потенциальные проблемы в управлении проектом или его разработке.

Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок. - Принципы, лежащие в основе Agile Manifesto

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

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

В идеале, какой бы ни была проблема, она поднимается во время ретроспективы и исправляется.

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

Это действительно зависит от вашей временной шкалы.

Иногда вам НУЖНО закончить все истории или, в любом случае, большинство из них. В то время как Agile обеспечивает некоторую гибкость, вам также нужно будет завершить проект, возможно, в сжатые сроки. Таким образом, выполнение большинства историй позволит вам выполнить ваш проект вовремя.

Тем не менее, с учетом всего вышесказанного произойдет что-то, что помешает вам закончить каждую историю, каждый спринт.

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

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

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

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

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

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