Скорость команды разработки – свойство системы, а не скорость самого быстрого ковбоя на Диком Западе

Wait 5 sec.

Скорость команды часто пытаются измерить количеством сильных разработчиков. Но самый быстрый человек в хаотичной системе обычно не ускоряет команду. Он просто первым начинает компенсировать её проблемы.В большом проекте скорость чаще теряется не в коде, а между мыслью «надо поменять вот это» и моментом, когда изменение можно будет увидеть, обсудить, проверить и выпустить.Представьте: большое iOS приложение для широкой аудитории, несколько рынков, которые собираются из одного проекта, часто обновляющиеся данные и экраны, которые product хочет менять быстрее, чем новый релиз успевает дойти до пользователей.В такой среде архитектура нужна не для красивой схемы. Она нужна, чтобы изменения были дешёвыми.Запускать модули отдельноОдна из самых дорогих операций в большом проекте – дождаться полной сборки.Разработчик может прийти поправить один экран, изменить несколько строк и затем ждать, пока соберётся весь продукт: соседние модули, ресурсы, зависимости и части, которые не имеют отношения к задаче.А если сделать так, чтобы крупные разделы можно было запускать отдельно – только с нужной функциональностью?Это даёт простой эффект: изменение быстрее видно, его не страшно переделать. Можно изолированно проверить несколько связанных экранов, а новому разработчику не нужно сначала разобраться во всём проекте, чтобы принести пользу в одном разделе.Если результат долго ждать, люди начинают гадать, но если его можно увидеть быстро – проверяют гипотезы.Экраны отдельно, но не приложенияНо отдельный запуск разделов не значит, что каждый экран становится отдельным приложением. Читать далее