Длина спринта - 2 недели против 30 дней

Question

Я хочу реализовать Scrum, но я не могу определить длину спринта. Кен Швабер, кажется, считает, что 30 дней это дефакто ... но я не могу себе представить, что вы ожидаете 30 дней без возможности изменения направления или переориентации.

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

Я думал о 1-недельном спринте, но это похоже на Scrum Micro Management.

Имея 2-недельные спринты, вероятно, будет идеальным, но я хочу знать, смогли ли другие люди реализовать это успешно. Каковы недостатки? Является ли это больше работы/меньше работы/того же самого о работе по управлению командой с более короткими спринтами?

BTW ... 3-недельные спринты кажутся мне странными, кто делает 3-недельный спринт? Почему бы просто не сделать это 4 недели. ;)

Answer 1

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

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

Answer 2

2 недели (10 стандартных рабочих дней, если вы являетесь снаряжением M-F или 12, если вы являетесь снаряжением M-S) составляет полмесяца (в течение месяца у него обычно около 20 рабочих дней, дайте или возьмите). Кроме того, неделя более неопределенная, чем день, но менее расплывчатая, чем месяц, поэтому она делает единицу измерения за несколько недель лучше для более гибких (более отдаленных) проектов развития.

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

Answer 3

Мне нравятся две недели. Это заставляет разумный промежуток времени решать проблемы, но позволяет вам видеть результаты в ускоренном темпе. 30 дней навсегда. Одна неделя может легко быть правильным ритмом для быстро движущегося продукта, такого как веб-сайт.

Answer 4

Прямо сейчас мы делаем 30-дневные спринты и получаем завершенные свай. Одна из причин того, что 30-дневный спринт хорошо работает для нас, заключается в том, что наше планирование и оценка обычно занимают 2 дня (сбор и принятие решения о том, какие задачи высокого уровня необходимо взять из отставания, выполнять задачи высокого уровня и разлагать их, оценивать разложенные задачи, а затем их назначение). Мы также откладываем 2-3 дня для исправления ошибок и тестирования.

У нас уже есть 5 дней, поэтому 2-недельные спринты оставят нас только с 5 днями R & D. 30 дней для нас был отличным балансом.

Answer 5

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

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

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

Answer 6

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

Так что, даже если у вас есть 3-недельный спринт, не мешает владельцу продукта ждать 3 недели, если он узнает что-то, что (возможно) сломает спринт.

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

Answer 7

Я думал о 1-недельном спринте, но это похоже на Scrum Micro Management.

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

Чем короче итерация, тем быстрее команда узнает об этом процессе.

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

Прежде чем я забыл, я не делаю три недели итерации: о)

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

Answer 8

Я работал на спринте 1,2,3 и 4 недели. 1-недельный спринт слишком короткий, чтобы выполнить командные обязательства, 2 сделаны идеально, когда я пытался реализовать 3 или 4-недельный спринт, мы не можем эффективно использовать команду QA. (QA будет иметь более медленное время в первую неделю)