Если вкратце: старайтесь этого не делать.

Недавно я разговаривал с одним клиентом, и ближе к концу дня мы стали общаться более неформально. Один из архитекторов вскользь упомянул: «Мы начали внедрять подход SAFe (Scaled agile framework)...»

«Да...?» подхватил я в надежде, что он расскажет об этом подробнее.

Но видимо, я бываю излишне деликатен, когда общаюсь с людьми лицом к лицу, поэтому мне так и не удалось узнать, как у них проходит внедрение SAFe. Вместо этого разговор перешёл на смежную тему — о том, как координировать работу независимых команд.

На мой взгляд, лучший способ координации независимых команд — это не координировать их вовсе. Я не помню, как именно я продолжил мысль, но, вероятно, я сказал что-то в том духе, что считаю координационные встречи между командами признаком проблемы в архитектуре. То, что возникает необходимость обсуждать вопросы с другими командами, свидетельствует о слишком тесной взаимосвязанности команд.

Архитектор ответил: «Мне не нравятся идея изолированности.

Что вы на это сказали бы?

Автономные команды

Я не утверждаю, что разобщённость — это здорово. Во-первых, это звучит не убедительно. Во-вторых, этот аргумент был бы уместен разве что в детском саду. 

Я почувствовал себя в тупике, но после короткой паузы мне удалось сообразить, и я ответил: «Наоборот, я поощряю общение между людьми, но не думаю, что командам нужно сильно координировать свои действия. Скорее, представьте каждую команду как организм в саванне. Они взаимодействуют, и то, что они делают, влияет на других, но в конечном итоге они остаются автономными формами жизни. Я считаю, что работа архитектора похожа на работу лесничего. Вы не можете контролировать растения или животных, но вы можете поддерживать экосистему, направляя её в благоприятном направлении».

Эта метафора с лесничими — давняя моя идея, возникшая из одной из моих самых недооцененных статей: Смотрители зоопарка должны стать лесничими». Она тесно связана с более популярной метафорой архитектуры программного обеспечения как садоводства, но мне больше нравится вариант с дикими животными, потому что он подчеркивает ещё более свободный подход. Он избавляет от иллюзии, что вы можете контролировать по сути непредсказуемый процесс, заменяя её обнадеживающим акцентом на управлении и заботе.

Как процветают экосистемы? Архитектор программного обеспечения (или лесничий) должен взращивать устойчивость в каждой подсистеме, подобно тому как эволюция способствовала развитию способности растений и животных выживать в различных непредвиденных обстоятельствах: при наводнении, засухе, пожаре, хищниках, отсутствии добычи, болезнях и так далее.

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

Параллельная работа

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

В чем проблема с координацией? Разве это не своего рода сотрудничество? Разве мы не считаем это полезным?

Я не утверждаю, что команды должны быть враждебны друг к другу. Как и в случае с любыми метафорами, с метафорой саванны нужно быть осторожным и не заходить слишком далеко. Я не представляю, что одна команда состоит из львов, хищников — убивающих и пожирающих другие команды.

Причина, по которой я настороженно отношусь к координации, заключается в том, что она кажется синонимом синхронизации.

В книге Code That Fits in Your Head я уже рассказывал о том, что хорошие практики непрерывной интеграции похожи на уроки оптимистичного параллелизма. Недавно меня осенило, что параллельную командную работу можно сравнить с параллельными вычислениями.

Уже несколько десятилетий мы знаем, что чем меньше синхронизации, тем быстрее работает параллельный код. Синхронизация требует больших затрат.

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

Если работа не распределена идеально равномерно, команда А может закончить работу раньше команды Б. Чтобы скоординировать действия, команда А должна некоторое время посидеть без дела, дожидаясь, пока Б догонит её. (В компаниях, занимающихся разработкой, безделье практически невозможно, поэтому на практике команда А приступает к работе над следующей задачей, что влечет за собой последствия, которые я уже описал).

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

Мне кажется, что в организации команд есть прямой аналог. Чем больше команд нуждается в координации, тем меньше выигрыш от наличия нескольких команд.

Но на самом деле Фред Брукс мог бы сказать вам об этом ещё в 1975 году.

Версионирование

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

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

По моему опыту, это происходит по нескольким причинам. Одна из них заключается в том, что команды могут быть разделены по неправильным линиям; это социотехническая проблема. Другая, более техническая, причина заключается в том, что смотрители зоопарка редко задумываются о версионировании или о том, как избежать ломающих изменений. Представьте, что команда A нуждается в команде B для разработки новой функции. Эта новая функция подразумевает разрывное изменение, поэтому командам придется координировать свои действия.

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

Заключение

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

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

Как работать с сопротивлением во время изменений в компании? Обсудим 19 августа на открытом уроке. После занятия вы будете знать:

• по каким причинам могут возникнуть сопротивлении при внедрении изменений в процессы компании;

• какие могут быть риски при возникновении подобных сопротивлений, если с ними не работать;

• некоторые фреймворки работы с сопротивлением.

Записаться на урок можно на странице курса "DevOps Lead".