Длина спринта - 2 недели против 30 дней [закрыто]
Я хочу реализовать Scrum, но я не могу решить длину спринта. Кен Швабер, кажется, связывает, что 30 дней это defacto... но я не могу представить себе ожидание 30 дней без возможности изменения направления или переориентации.
наши проекты обычно длятся всего 1-3 месяца с использованием метода водопада и переход на Scrum, вероятно, будет означать меньше возможностей для тонкой настройки.
Я думал о 1 недельных спринтах, но это похоже на Scrum Micro Управление.
наличие 2-недельных спринтов, вероятно, было бы идеальным, но я хочу знать, смогли ли другие успешно реализовать это. Какие есть минусы? Это больше работы/меньше работы / то же самое о работе, чтобы управлять командой с более короткими спринтами?
кстати... 3 недельные спринты кажутся мне странными, кто делает 3 недельный спринт? Почему бы просто не сделать это 4 недели. ;)
8 ответов
Я работал над командами, выполняющими 1, 2 и 4 недельные спринты. Это действительно зависит от вашей организации. Я предпочитаю 1 или 2 недели спринты. Текущая команда, которую я запускаю, находится в 4-недельных спринтах, потому что мы координируем усилия 12 различных продуктов. Я ищу, чтобы переместить их на 2-недельные итерации в ближайшее время.
ключевая вещь для определения длины-это "готово, сделано". Для некоторых команд это означает в производстве. Для других, оно может значить подтверженный делом для того чтобы отвечать их потребностямы используя внутренний релиз. Я бы начал с определения done, done, а затем посмотрел, как структурировать ваши спринты вокруг этого. В идеале все истории заканчиваются в конце спринта - и вы не просто делаете Scrummerfall.
Мне нравится две недели. Это заставляет коробку разумного времени на проблемы, но позволяет видеть результаты в усиливающем темпе. 30 дней-это навсегда. Одна неделя может легко быть правильным ритмом для быстро движущегося продукта, такого как веб-сайт.
Я работал на 1,2,3 и 4 недели спринты. 1 неделя спринта слишком коротка, чтобы выполнить обязательства команды, 2 сделано идеально, когда я пытался реализовать 3 или 4 недели спринта мы не можем эффективно использовать команду QA. (QA будет иметь больше времени слабины в первую неделю)
product owner должен всегда иметь возможность менять приоритеты и направления. Одна из целей SCRUM-охватить изменения и позволить владельцу продукта нести ответственность за приоритет, глядя на бизнес-потребности и команду разработчиков, ответственную за своевременную доставку.
поэтому, даже если у вас есть 3-недельный спринт, не означает ли это, что владелец продукта должен ждать 3 недели, если он узнает что-то, что (возможно) собирается сломать спринт.
в некоторых редких случаях вам нужно остановить спринт посередине и создать новый из-за новой информации или новых предварительных условий.
Я думал о спринтах 1 недели, но это похоже на управление Scrum Micro.
да, но это заставит вас делать больше Scrum: вы будете делать планирование спринта, демонстрацию итерации и ретроспективу каждую неделю. Недостатком является накладные расходы, однако вы тратите меньше времени на планирование, демонтаж и "переосмысление" одной недельной итерации, чем на одну месячную итерацию.
чем короче итерация, тем быстрее команда изучает процесс.
теперь, в зависимости от типа проекта, может быть трудно достичь чего-то ценного за одну неделю задержки.
прежде чем я забыл, я не делаю три недели итерации: o)
Если вы идете с четырехнедельными итерациями, у вас также есть возможность заменить задачи которые не были запущены С задачами, оцененными за то же время.
2 недели (10 стандартных рабочих дней, если вы экипировка м-ф или 12 Если вы экипировка м-с) половина месяца (месяц типично имеет грубо 20 рабочих дней в ем, дает или принимает). Кроме того, неделя более расплывчата, чем день, но менее расплывчата, чем месяц, поэтому она делает единицу измерения в неделях лучше для более гибких (больше дают/берут) проектов развития.
однако в последний раз, когда я делал что-то вроде scrum, это было на школьном проекте, и это был не настоящий scrum. Так было и 7 день недели 10-недельный квартал. Мне очень понравился 2-недельный блок для этой ситуации. Я чувствовал, что могу многое сделать, но мы можем часто корректировать сроки и планы.
прямо сейчас мы делаем 30-дневные спринты и получаем сваи. Одна из причин того, что 30-дневные спринты хорошо работают для нас, заключается в том, что наше планирование и оценка обычно занимают 2 дня (сбор и решение, какие задачи высокого уровня взять из отставания, принимая задачи высокого уровня и разлагая их, ставя оценки по разложенным задачам, а затем назначая их). Мы также выделили 2-3 дня для исправления ошибок и тестирования.
мы уже на 5 дней, так что делаем 2 неделю спринты будет только оставить нас 5 дней НИОКР 30 дней был отличный баланс для нас до сих пор.
длина спринта может варьироваться от проекта к проекту, но должна оставаться постоянной на протяжении всего проекта. Лучшее, что можно сделать, это попытаться найти наиболее удобную длину спринта для вашей команды, я использую Scrum в течение двух лет, и теперь мы договорились о двадцати рабочих днях спринтов.
мой опыт говорит мне, что в проектах, которые нуждаются в быстрых результатах и относительно простом программировании (операции CRUD, простые сетки и формы и т. д.), разумнее использовать более короткие спринты, такие как две недели. Для вещей с более высокой сложностью (например, фреймворков), вероятно, лучше пойти на более длинные спринты, такие как четыре недели спринтов. Мой текущий проект склоняется к последнему варианту.
но важно выбрать длину confortable как для команды, так и для владельца продукта.