День 2188. #УрокиРазработки
Уроки 50 Лет Разработки ПО

Урок 40. Неформальные подходы, используемые небольшими сплоченными командами, плохо масштабируются

Гейтс и Аллен, Джобс и Возняк, Хьюлетт и Паккард. Скорее всего, ни у кого из них не было письменных инструкций для их ранних проектов. Двум гениям, работающим бок о бок, не нужна документация. Но это трудно масштабировать во времени и пространстве, когда этих разумов сотни и при этом они думают на разных языках и погружены в разные культуры. Большие задачи требуют соответствующих подходов.

Процессы и инструменты
По мере роста команд, проектов и организаций возникает потребность в совершенствовании процессов. Люди могут осознать необходимость в этом, только столкнувшись с проблемой. Может случиться, что две команды выполнят одну и ту же работу или какая-то задача будет пропущена, поскольку все думали, что её сделает кто-то другой. Эти проблемы требуют более чёткого планирования, координации и коммуникации между членами команды и группами. По мере вовлечения в работу все большего количества людей, особенно если они находятся в разных местах, появляются все новые источники разногласия и задержек.

Более крупные проекты требуют письменного оформления большего объёма информации, чтобы другие участники знали, что происходит и что ждёт впереди. Сохранение требований, решений, бизнес-правил, оценок и метрик в групповом хранилище начинает приносить всё большую пользу. Чем дальше друг от друга члены команды, тем больше внимания нужно уделять организации процесса и тем больше люди вынуждены полагаться на инструменты удалённой совместной работы.

Командам, расположенным в разных местах, нужны инструменты управления задачами, моделирования, тестирования, непрерывной интеграции и особенно управления кодом. ПО с открытым кодом — яркий пример распределённой разработки. Как отмечает Эндрю Леонард: «Ни одно нововведение не было столь же важным для разработки ПО распределенными командами, как появление систем управления версиями.»

Необходимость специализации
Работая над проектом в одиночку, вы поочередно выполняете все роли участников проекта. В каждый конкретный момент вы можете действовать как бизнес-аналитик, дизайнер, программист, тестировщик, составитель документации, руководитель проекта или специалист по сопровождению.

Нереально ожидать, что каждый член команды будет в полной мере владеть всеми этими ролями. По мере роста проектов и команд специализация некоторых навыков становится естественной и полезной. В какой-то момент даже Билл Гейтс и Пол Аллен решили, что им нужно нанять людей, обладающих навыками, отличными от программирования, чтобы обеспечить рост своей молодой компании: технического писателя, математика, руководителя проекта и т.д. Я слышал, у них это сработало.

Коммуникационные конфликты
По мере увеличения группы количество коммуникационных каналов растёт экспоненциально. Участникам проекта нужны механизмы, позволяющие быстро и точно обмениваться информацией. При этом люди инстинктивно выбирают способы общения, наиболее удобные для них, но не удобные для другой стороны. В проектах с участием нескольких команд важно заранее заложить основу для общения, используя те способы, которые будут эффективно работать для всех. Кроме того, команды могут по-разному принимать решения. Участникам следует обсудить, как будут приниматься совместные решения до того, как все столкнутся с первой серьезной проблемой.

Успешные организации растут и берутся за всё более сложные задачи. Не стоит ожидать, что методы, эффективные для нескольких человек в гараже, подойдут и для больших распределённых команд. Они могут избежать некоторых трудностей, заранее предусмотрев процессы и инструменты, необходимые для интеграции различных команд. Если участники будут иметь возможность общаться и понимать коллег, работающих удалённо, на ранних этапах проекта, это поможет избежать культурных конфликтов. Потратив время на то, чтобы заложить эти основы, можно предотвратить много неприятностей в будущем.

Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 5.