Как часто выпускать в Scrum спринт

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

TL; DR: выпуск при необходимости

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

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

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

Выпуск может быть отдельным видом спринта, где вещи упакованы для выпуска.

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

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

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

То же самое верно и для выпусков с исправлениями дефектов - если есть смысл выпустить их, сделайте это.

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

Практически все наши выпуски включали в себя сочетание историй и дефектов (ошибок). Дефекты считаются «неидеальными часами»; в рабочем дне 5 идеальных часов, что означает простое кодирование новой точечной работы. Другие три-четыре часа в день - это встречи, дискуссии, дизайн, иногда «спайки» (целенаправленное исследование / разработка концепции) и работа с дефектами; материал, который способствует улучшению продукта и является необходимой частью процесса, но просто не может занять весь спринт всей команды. Единственный раз, когда мы делали выпуски только для дефектов, это когда в бэклоге не было доступной истории для IPM; Затем мы просто запланировали QR-спринт, где нас проинструктировали «убить как можно больше дефектов». Поскольку отсутствие требований, готовых к выполнению, ВСЕГДА является ошибкой ПО (и ПО работало для клиентов), мы могли бы просто оформить уведомление об изменении договора и работать с тем, что у нас было. Конечно, после того, как реальная работа над сюжетом была закончена, и мы приступили к разработке «гарантийных обязательств», дефекты были все, что было.

В хорошо управляемом Agile-проекте не должно быть никаких требований; в бэклоге всегда должна быть готова работа спринта. Но иногда ПО становится завален производственными требованиями; иногда БА / тестеры задерживают выпуск историй в отставание разработки по причинам, связанным с требованиями к качеству или конфликтами историй; иногда команда решает, что ей нужно «разобраться» с историей, которая не была четко определена или оценена, и нет ничего, что могло бы легко взять оставшиеся циклы. Короче, даже в Agile дерьмо случается.

Что вы подразумеваете под релизом? Если вы имеете в виду PSP - возможно, отправляемый товар у вас есть два варианта:

• Scrum by book (или Scrum level 2) у вас есть PSP в конце спринта, и это то, что вы показываете на ретроспективной встрече
• Я также встретился с термином Scrum level 3, где команда освоила свои инструменты, такие как контроль исходного кода и непрерывная интеграция, и перешла к непрерывной доставке. Такая команда может иметь PSP после каждой ночной сборки (или каждой сборки в лучшем случае). Наличие PSP после каждой сборки не означает, что вы показываете его клиенту после каждой сборки - это все еще только внутренний выпуск.

Основное различие между уровнем 2 и уровнем 3 заключается в том, что на уровне 2 вы должны приложить некоторые усилия, чтобы сделать окончательный PSP в конце спринта, но на уровне 3 вы изначально потратили немного денег и усилий на свои инструменты и конфигурации, и у вас была подготовлена ​​PSP. автоматически все время = нет ручного усилия. Полностью достижение уровня 3 редко.

В Scrum нет абсолютно никаких правил относительно того, когда могут быть развернуты новые функции. У каждой команды должно быть «определение выполненного», которое всегда должно включать некоторые критерии тестирования. Как только функция «готова», она готова к реальному миру, и если нет никаких других зависимостей или условий, которые должны быть выполнены, прежде чем она может быть развернута, то нет причин ждать окончания Спринта, чтобы развернуть его.

Ничто из этого не означает, что он не представлен на совещании по рассмотрению / планированию спринта. Концепция заключается в том, что все, что команда завершила, показывается в ПО (и в других МСП клиентов), чтобы они могли включить это в свое растущее понимание системы по мере ее развития.

Через пару недель мы нашли хорошее решение, которое соответствует нашим потребностям. Мы решили выпустить, когда захотим. Как мы это делаем:

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

Это оно. Мы используем git и maven в качестве системы CI, и у нас хорошее тестовое покрытие. Что является одной из причин, по которой мы можем так поступить.

Ответ на вопрос, которому почти 2 года, может быть немного излишним, но, надеюсь, для добавления ценности для тех, кто придет к этому вопросу, я хотел бы добавить 2 цента или около того. :)

Чтобы ответить на вопрос: Вы должны предпочтительно выпустить то, что было сделано в спринте, в конце этого спринта. Это связано со всеми другими частями / процессами / руководящими принципами Scrum, которые направлены на то, чтобы извлечь максимальную выгоду для бизнеса в нужное время.

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

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