@jsunderhood Добрый вечер! Расскажите, пожалуйста, подробнее о том, как удается при таком серьезном продукте и большом количестве команд сохранять то самое "общее владение кодом"?
У каждой команды свой продакт (1 продакт может быть заказчиком у нескольких команд). И у каждой команды свой беклог.
Если сделать полностью "раздельную ответственность", то команде А, чтобы добавить новый параметр в поиск придется ждать команду Поиск. twitter.com/a_ganichev/sta…
У команды Поиск свой беклог, и когда она сможет взять задачу команды А — непонятно. Это бы сделало выход фичей непрогнозируемым.
Вместо этого у нас единый набор технологий на большей части проектов. Где-то есть специфика (например поисковой движок).
Общее владение кодом реализуется вот так: команде А нужно внедрить новый параметр в поиск. Она сама пишет код и дает на ревью ребятам из поиска.
Тестирует задачу, пишет автотесты (иногда автотесты делаем после выхода задачи) Во время и после выхода релиза у нас очень много систем мониторинга. Большинство проблем мы отлавливаем даже до того момента, как релиз полностью выйдет. Это позволяет добиться определенной надежности
Большое количество фичей выходит под настройкой (переключателем). Если что-то идет не так, то команде достаточно переключить триггер. Все триггеры умеют раскатываться на часть пользователей. Если есть опасения можно выпустить задачу на 5% пользователей и понаблюдать за динамикой.
Если все же баг случился через некоторое время после выхода задачи, то по blame видим, какая команда и назначаем на нее ошибку. Если код старый, то у каждой команды закреплена "зона ответственности" — это набор фичей, страниц.
И если проблема произошла на странице поиск — баг летит в команду поиск. Они, в свою очередь, могут определить чей это баг или поправить сами.