Если вы уже выпускаете непрерывно, каковы преимущества Scrum Sprint постоянной длины?

Спринт : произвольный период времени, в течение которого вы внедряете и выпускаете функции программного обеспечения.

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

Но в веб-продукте, где я являюсь владельцем (конечным пользователем является клиент), и мы сообщаем о небольших улучшениях сразу после их внесения, а не ждем окончания некоторого спринта, и клиент получает новые функции сразу же, как только они реализованы, каковы преимущества «завершения» спринта ?
(кроме вскрытия, которое мы не делаем)

Возможно, это элемент улучшения процесса, который вы должны обсудить со своей командой на ретроспективе?
@NathanCooper, похоже, команда OP не проводит ретроспективы. (хотя я бы настоятельно рекомендовал начать)
Если у вас нет Ретроспективы, то это немного более серьезная проблема, чем задавать вопросы о ценности Спринта IMO, но, похоже, на этот вопрос был дан ответ.
Вы пытаетесь подобрать инструмент для решения проблемы, о которой не знаете, - возможно, использование Sprint станет очень хорошим и мощным молотком... для ваших шурупов.

Ответы (3)

TL;DR

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

Спринт — это контейнер для планирования!

Хотя в Руководстве по Scrum говорится, что вы должны предоставлять работающее программное обеспечение не реже одного раза в 30 дней, ничто не мешает вам делать это чаще. По моему опыту, непрерывная поставка и Scrum действительно хорошо сочетаются друг с другом.

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

  1. Планирование спринта — проверьте невыполненную работу и адаптируйте план для следующего спринта.
  2. Ежедневный скрам — проверяйте прогресс и адаптируйте план на следующие 24 часа.
  3. Обзор спринта — проверьте инкремент и адаптируйте невыполненную работу
  4. Ретроспектива Спринта . Осмотрите Спринт и адаптируйте процесс.

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

Коммуникация и согласование

Дополнительным преимуществом спринта является то, что он дает ритм, которому ваше руководство и другие зависимые команды могут легко следовать. Если вы координируете работу, то общая система взглядов, Спринт 231, поможет в общении.

Создает предсказуемость

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

Я бы сказал, что в спринте есть большая ценность.

Короче говоря, он устанавливает темп и ритм вашей работы. ++
Руководство по Scrum совсем этого не говорит. В нем говорится: «Приращение — это сумма всех элементов Бэклога Продукта, выполненных во время Спринта, и значение приращений всех предыдущих Спринтов. В конце Спринта новое Приращение должно быть «Готово», что означает, что оно должно быть в пригодном для использования состоянии и соответствуют определению «Готово», данному Скрам-командой. Он должен быть в пригодном для использования состоянии, независимо от того, решит ли Владелец Продукта выпустить его». Нигде не сказано, что программное обеспечение ДОЛЖНО выпускаться каждые 30 дней. В некоторых поставках (например, автомобильной или аэрокосмической) это было бы невозможно.
Пожалуйста, отредактируйте свой ответ, чтобы отразить фактическое руководство по Scrum. Все остальное было совершенно в силе.
В Руководстве по Scrum действительно говорится: «Сердцем Scrum является Спринт, временной интервал в один месяц или меньше, в течение которого создается «Готово», пригодный для использования и потенциально готовый к выпуску Инкремент продукта». <-- Месяц или меньше...
... вы намеренно пропускаете "потенциально" часть? И просто напрочь игнорируя реальную цитату из Scrum Guide V3, которую я опубликовал.
И нигде в моем ответе я не сказал, что его нужно «выпустить», отсюда и мое замешательство. «Руководство по Scrum говорит, что вы должны предоставлять работающее программное обеспечение не реже одного раза в 30 дней, ничто не мешает вам делать это чаще».
+1 к @MrHinsh и Venture2099 по поводу «выпускаемого». Самое важное различие в руководстве Scrum относительно Инкремента Продукта заключается в том, что менее чем за 30 дней он должен быть готов к выпуску. Это позволяет выпуску стать бизнес-решением, а не техническим решением, т.е. можем ли мы выпустить это>

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

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

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

Нет, это не @MrHinsch. Перестаньте нести эту чушь. Вот официальное заявление. Приращение — это сумма всех элементов Бэклога Продукта, выполненных во время Спринта, и значение приращений всех предыдущих Спринтов. В конце Спринта новый Инкремент должен быть «Готово», что означает, что он должен быть в пригодном для использования состоянии и соответствовать определению «Готово», данному Скрам-командой. Он должен быть в пригодном для использования состоянии независимо от того, решит ли Владелец Продукта выпустить его. Источник: Руководство по скраму, версия 3.

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

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

Не существует такой вещи, как точная скорость, это заблуждение, а погоня за ней — пустая трата времени. Руководство по Scrum предусматривает, что вы должны предоставлять работающее программное обеспечение своим клиентам не реже одного раза в 30 дней.
@MrHinsh Точность и аккуратность очень разные. Невозможно получить точную оценку, основанную на скорости, но, безусловно, можно получить точную оценку, основанную на скорости. Можно легко использовать скорость, чтобы оценить, что веха будет достигнута через 9-12 месяцев (точно) по сравнению с определенной датой (точно).
Я не согласен; поскольку стандартное отклонение скорости большинства команд, спринт за спринтом, настолько велико, что среднее (среднее) слишком далеко от реальности, чтобы его можно было реально использовать.
@MrHinsh, возможно, «полезная скорость» будет лучшим термином, чтобы избежать этой путаницы. Обновлено.
@MrHinsh хорошо, я думаю, мне следует выбросить все доказательства моей команды, показывающие стабильную скорость. Анекдот — это не множественное число данных. То, что вы не видели стабильной скорости, не означает, что ее не существует и что это не устремление. Я также никогда не видел, чтобы военная операция шла по плану, но мы не прекращаем планирование. Скорость также полезна только как мера с течением времени. Таким образом, по этому стандарту скорость ВСЕГДА точна. Точно так же, как среднее количество голов, забитых за игру, полезно только в течение сезона. Это помогает принимать решения, но мы не используем его в качестве фиксированной точки.
Я смиренно предлагаю вам применить немного более гибкое мышление к абсолютным заявлениям, которые вы делаете. Это полная противоположность Scrum (и Agile-ценностям), и я могу доказать, что ваше утверждение абсолютно неверно, на одном конкретном примере.
Полезное намного лучше, чем точное.
Классификатор вообще не нужен. Скорость есть скорость, и она может быть точной.
@MrHinsh, поскольку скорость - это запаздывающая мера, она всегда точна. Является ли это полезным индикатором будущей производительности, это совсем другой вопрос ... IME это не так.
@RubberDuck Я могу с этим согласиться. Хотя точность обычно сопровождается оговоркой «с точностью до…?» что... Я пытался намекнуть, что степень точности настолько широка, что делает ее совершенно бесполезной в качестве меры.
Если вы уже выпускаете непрерывно, каковы преимущества Scrum Sprint постоянной длины?
СпросиСетьПолитика конфиденциальности1y, 0v