Как обрабатывается процесс развертывания в методологии Scrum?

Question

Мы разрабатываем сложную систему с использованием методологии scrum с 1-недельными спринтами и командой из 6 разработчиков.

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

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

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

Работаем ли мы против правил Scrum? Где находится процесс развертывания по методологии Scrum? Скрам подходит для этого проекта?

Answer 1

процесс развертывания медленный, жесткий и деликатный.

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

Этот негативный цикл работает против Agile, поскольку означает, что организации пытаются реагировать на изменения.

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

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

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

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

Answer 2

Барнаби имеет идеальный ответ. Между тем, одна возможность состоит в том, чтобы иметь повторяющуюся историю в каждом спринте, чтобы выпустить утвержденные истории из предыдущего спринта. В соответствии с Scrum Guide , команда предоставляет только «потенциально выпускаемый Прирост продукта (а)« Готово »в конце каждого Спринта». Ключевое слово «потенциально». В дополнение к проблеме, с которой вы сталкиваетесь, я был в компаниях, которые выпускались только раз в квартал, потому что именно этого хотели клиенты. Если ваш клиент хочет выпускать каждый спринт, прекрасно, но ничто в руководстве не требует, чтобы это происходило в том же спринте, в котором принимаются истории.