Является ли частью спринта релиз в production?

Отношение релиза в production к спринту в Scrum

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

Основные модели и подходы

В классическом Scrum спринт — это ограниченный по времени итерационный цикл (time-box), результатом которого является инкремент потенциально готового к релизу продукта (Potentially Shippable Product Increment). Ключевое слово — "потенциально".

1. Модель "Релиз в конце каждого спринта" (Release Every Sprint)

    *   **Является частью спринта.** Целью спринта явно становится не только разработка, но и развертывание в production.
    *   **Требует высочайшего уровня зрелости:**
        *   Полная **CI/CD** (Continuous Integration / Continuous Deployment) автоматизация.
        *   **Прочное покрытие автотестами** (unit, integration, e2e).
        *   Культура **DevOps**, где команда сама отвечает за деплой и мониторинг.
        *   Согласованные с бизнесом и легальные **подходы к dark launches, feature toggles и canary-развертываниям**.
    *   **Преимущества:** Максимальная обратная связь от реальных пользователей, быстрая доставка ценности, снижение рисков за счет небольших изменений.
    *   **Риски:** Без должной автоматизации и процессов превращается в хаос и "ад по четвергам".

1. Модель "Релиз по готовности" (Release on Demand / Cadenced Releases)

    *   **Не является обязательной частью каждого спринта.** Команда производит инкременты каждый спринт, но решение о релизе в production принимается на основе внешних факторов: маркетингового календаря, накопления достаточного объема изменений, готовности других команд.
    *   Это наиболее **распространенная модель** в компаниях, переходящих от waterfall к agile.
    *   Релиз становится отдельным проектом или фазой, которому предшествуют **стабилизационные спринты, финальное тестирование и ручные процедуры деплоя**.
    *   **Недостатки:** Накапливается "деплой-долг", откладывается ценность, возрастают риски из-за большого объема изменений за один раз.

Практические соображения для Project Manager

Как PM, я оцениваю контекст и помогаю команде и стейкхолдерам определить оптимальную модель.

• Технический долг и инфраструктура: Если нет автоматизации тестирования и деплоя, принудительный релиз каждый спринт — это путь к выгоранию команды и низкому качеству.
• Бизнес-требования: Некоторые отрасли (финансы, медицина) имеют жесткие регуляторные циклы релизов, не совместимые со спринтами в 2 недели.
• Масштаб продукта: Для монолитного приложения с ручным деплоем релиз раз в квартал может быть реалистичнее. Для микросервисной архитектуры — несколько раз в день.

Моя роль заключается в том, чтобы:

• Фасилитировать обсуждение и сформировать прозрачное соглашение о релизной политике внутри команды и с заказчиком.
• Обеспечить, чтобы Definition of Done (DoD) команды явно включало или не включало пункт "развернуто в production". Пример DoD для модели с релизом каждый спринт:

### Definition of Done для нашего инкремента:
- [ ] Код завершен и проходит code review.
- [ ] Все автоматические тесты (unit, integration) пройдены.
- [ ] Покрытие кода не ниже установленного порога.
- [ ] Документация обновлена.
- [ ] Код развернут на staging-среде и прошел smoke-тесты.
- [ ] **Изменения развернуты в production (для запланированных функциональностей).** <!-- Ключевой пункт -->
- [ ] Проведен базовый мониторинг после деплоя.
- [ ] Product Owner принял инкремент.

• Выстраивать процессы и устранять препятствия, мешающие движению к более частым и безопасным релизам (например, лоббировать инвестиции в инструменты CI/CD).
• Коммуницировать график и содержание релизов всем заинтересованным сторонам, чтобы управлять ожиданиями.

Заключение

Таким образом, релиз в production может быть частью спринта, но не обязан ею быть. В идеале, к чему стоит стремиться, — это состояние, где команда способна доставлять ценность пользователям безопасно и быстро в любой момент, что технически делает каждый завершенный инкремент в конце спринта релизным кандидатом. Задача Project Manager — не навязывать одну модель, а создать условия для осознанного выбора и эволюции процессов в сторону большей скорости и надежности доставки.