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

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