Comments
Легче всего нарушить правило, если оно мешает тебе работать.

Это достойно отдельной страницы в цитатнике!
После этого мы распустили команду QA, и участники команды QA присоединились к командам разработки.

а команду по нагрузке вы тоже перевели к разработчикам?
Нет, команда нагрузки прекрасно себя чувствует и никаких планов ее распустить нет :)
тогда можно выдохнуть)
просто сейчас намечается какая-то странная тенденция, в погоне за скоростью релизов ( и куда все так спешат) ) делать из разработчиков суперменов, которые пишут код, покрывают его тестами, тестируют его функционально, нагрузочно и тд)
на бумаге это конечно приносит заметное сокращение кол. багов, вот только в реальности это сокращение скорее связано с тем, что качество тестирование упало…
Ок, команд много, как я понимаю, Stop The Line останавливает работу всех команд и фокусирует всех на текущем релизе? Но ведь, с большущей вероятностью, это выливается в простой некоторых членов некоторых команд за неимением реальной возможности повлиять на пуш релиза и неимением возможности продолжать работу над своей фичей, правильно? Убейте меня, но тут явно проблема на уровне организации CI/CD.
Все верно.
Нет смысла педалить фичи, если они все равно в ближайшее время не смогут выйти на прод из-за пробки в deployment pipeline. Лучше помочь чем можешь с самой пробкой, с причинами, вызвавшими пробку. Если не можешь помочь — лучше ничего не делать (!), как это на парадоксально. Учись. Покрывай тестами. Рефакторь. Но не пиши новый код.
Но когда она горит 3–4 дня подряд, становится не смешно....

Мы решили… и оставили… раздражающий мигающий свет. Так задумано.

первая мысль, да — лампочка — это забавно…
вторая мысль… «релиз в беде — поставим лампочку мигающую...» ага. пусть все нервничают еще больше. и пусть все видят что «мастер в тревоге и печали».
так задумано…
и не хотел я это писать… но напишу — пришел я както в свежеоткрытую додо-пиццу. и все хорошо вроде. симпатично. книжка даже возле кассы — про додо… франшиза, все дела… ну ок. рискну.
«мне вон ту пиццу и чай зеленый, с лимоном.....» упс. чай найдут… но вот лимона — не.
как так? нет лимона, свежего лимона к моему зеленому чаю?… <b>так задумано. это франшиза. да? ну нет!!! я развернулся и ушел, нашел другую пиццу где никто не задумал лишить меня лимона в зеленом чае! а потому что не для людей это «а я так вижу — пиццу едят без лимона в чае!». и в итоге — я оставил деньги там — где по человечески.
к чему я это… а вот эта «лампочка» — это то самое… «без лимона». это не для людей.
хотя вот в чем парадокс — люди и делают этот бизнес.
клиенты — оплачивая пиццу — дают доход с которого в том числе платят зарплату и тем кто решает — «без лимона!» (и я рад что я не дал своих денег тем кто лишил меня — моего свежего и кислого лимончика в чае), и программистам которые делают «продукт для продажи» и «мастерам которые лампочки включают».
но вот всегда найдутся те самые «мастера» — которые считают что «без лимона» — это нормально. и по ходу они же — вместо того что бы подумать что надо сделать чтобы усилить команду, да хотябы как то ее поддержать ну морально что ли… они вместо поддержки — включают лампочку. мигающую. ага. «без лимона!»

и в итоге — два риторических вопроса.
реально так сложно/невозможно дать клиенту ломтик свежего лимона?
реально так сложно/невозможно решить проблему не создавая раздражения в команде?
я думаю — эти два вопроса про одно и то же — про раздражение. про подход к решению проблемы.

вывод — я не клиент додо. и я рад этому.
Интересное совпадение: к нам вчера пришла разнарядка снизить продолжительность релизов.
В чем-то наши случай похож на описанный в статье (Антон, привет!) — есть монолит и пара десятков микросервисов. В случае микросервисов все относительно просто, у них в принципе может быть свой собственный короткий релизный цикл.
А вот с монолитом есть проблемы, которые пока неясно как решать:
1) Недостаточное количество автотестов и автоматизаторов, чтобы их написать. Идея «набрать команду крутых автоматизаторов» упирается как в ограничения бюджета, так и рынка труда.
2) Подход «карантина» — обновление выкатывается сначала в регионе с небольшим количеством клиентов, которые какое-то время работают как бета-тестеры. Если обнаружены ошибки, то выпускается хотфикс. Затем обновление с хотфиксами устанавливается в другие регионы. Отказаться от этого процесса и накатывать обновления на все сервера сразу — значит получить шквал обращений в саппорт и много недовольных клиентов.
3) Недостаточное количество DevOps (под которыми здесь подразумеваю людей способных полноценно автоматизировать CD)

По идее имея гугл-бюджет все эти проблемы решаются, но мы пока не Google.
Stop the line вряд ли поможет — разве что вся engineering team во время stop будет писать качественные авто-тесты, что не так уж и просто без опыта и знаний чем хорошие тесты отличаются от плохих.
Дима, привет! Рад тебя видеть/слышать :)

Для ускорения релиза придется вложиться в автоматизацию тестирования, без этого никуда.
Когда будут тесты, которым можно доверять — оптимизировать выкладку. Перечислите этапы, которые проходит продукт от мержа в ветку (development done) до попадания на прод. Замерьте время каждого этапа, можно просто экспертно оценить. Сфокусированно решайте самую большую проблему, то есть которая больше всего задерживает релиз. Может понадобиться сфокусированная работа одной или нескольких команд в течение пары спринтов, может быть больше. Но без фокуса проблема не решится.
Бизнес разработка замедлится, это тоже надо понимать и готовить к этому PO и кастомеров.
Only those users with full accounts are able to leave comments. Log in, please.