До релиза две недели. Разработчик закончил фичу раньше срока. "Давай добавим в этот релиз?" Конечно, почему нет.
А потом еще один разработчик начинает новую задачу на main. И теперь первая фича не может уехать без второй. Третий разработчик берет следующую задачу - и вот уже три фичи блокируют друг друга.
Кто-то говорит: "Ну, следующий релиз все равно не скоро - давайте просто сдвинем и выпустим все вместе."
Поздравляю. Двухнедельный релиз только что превратился в двухмесячный.
Это не проблема дисциплины. Это проблема системы
Я видел эту ситуацию в каждой компании, которая делает большие релизы. Паттерн всегда один и тот же.
Когда стоимость релиза высокая - ручное тестирование, ручной деплой, сложная координация между командами - каждый релиз превращается в "редкую возможность". А редкие возможности создают давление: "Надо впихнуть побольше, когда еще получится."
Это замкнутый круг. Чем больше фич запихиваешь в релиз, тем дольше тестирование. Чем дольше тестирование, тем больше соблазн добавить еще что-то. Потому что следующий релиз - через три месяца.
Почему "давай добавим еще одну фичу" - самая дорогая фраза в разработке
Допустим, у тебя команда из 5 разработчиков. Релизный цикл - раз в квартал. Между релизами накапливается 30-40 задач.
Теперь представь: одна из этих задач ломает что-то в продакшене. Где искать проблему? В 40 изменениях? Удачи.
А теперь представь, что ты релизишь каждый день. В продакшен уезжают 1-2 изменения. Что-то сломалось? Ты точно знаешь, где смотреть. Фикс занимает час, а не неделю. Клиент может даже не заметить.
Дело не в инструментах. Дело в одном правиле
Компании, с которыми я работал, не начинали с автоматизации. Они начинали с одного принципа: поезд отправляется по расписанию.
Твоя фича не готова? Она поедет следующим поездом. Завтра. Не через три месяца - завтра.
Когда деплой занимает 10 минут вместо двух дней, никто не говорит "давай впихнем еще одну штуку". Нет смысла. Следующий релиз - завтра.
Что меняется, когда релизы становятся дешевыми
Перестает работать логика "редкой возможности". Фичи перестают блокировать друг друга. Тестирование упрощается, потому что ты проверяешь 2 изменения, а не 40. Баги находятся за минуты, а не за дни.
И самое неочевидное - растет доверие. Клиенты видят, что продукт развивается. Менеджеры видят реальный прогресс на борде, а не бесконечное "в процессе".
Автоматизация, пайплайны, тесты - все это приходит естественно, когда команда приняла правило: ничто не блокирует поезд.
Какой у тебя сейчас релизный цикл? И он становится длиннее со временем?
#Разработка #DevOps #IT