Если вкратце: старайтесь этого не делать.
Недавно я разговаривал с одним клиентом, и ближе к концу дня мы стали общаться более неформально. Один из архитекторов вскользь упомянул: «Мы начали внедрять подход SAFe (Scaled agile framework)...»
«Да...?» подхватил я в надежде, что он расскажет об этом подробнее.
Но видимо, я бываю излишне деликатен, когда общаюсь с людьми лицом к лицу, поэтому мне так и не удалось узнать, как у них проходит внедрение SAFe. Вместо этого разговор перешёл на смежную тему — о том, как координировать работу независимых команд.
На мой взгляд, лучший способ координации независимых команд — это не координировать их вовсе. Я не помню, как именно я продолжил мысль, но, вероятно, я сказал что-то в том духе, что считаю координационные встречи между командами признаком проблемы в архитектуре. То, что возникает необходимость обсуждать вопросы с другими командами, свидетельствует о слишком тесной взаимосвязанности команд.
Архитектор ответил: «Мне не нравятся идея изолированности.
Что вы на это сказали бы?
Автономные команды
Я не утверждаю, что разобщённость — это здорово. Во-первых, это звучит не убедительно. Во-вторых, этот аргумент был бы уместен разве что в детском саду.
Я почувствовал себя в тупике, но после короткой паузы мне удалось сообразить, и я ответил: «Наоборот, я поощряю общение между людьми, но не думаю, что командам нужно сильно координировать свои действия. Скорее, представьте каждую команду как организм в саванне. Они взаимодействуют, и то, что они делают, влияет на других, но в конечном итоге они остаются автономными формами жизни. Я считаю, что работа архитектора похожа на работу лесничего. Вы не можете контролировать растения или животных, но вы можете поддерживать экосистему, направляя её в благоприятном направлении».
![Газели и дикие кабаны в Национальном заповеднике Самбуру, Кения. Gazelles and warthogs in Samburu National Reserve, Kenya.](https://habrastorage.org/getpro/habr/upload_files/677/f0c/9d1/677f0c9d16bc1187b6f42096911b5a49.jpeg)
Эта метафора с лесничими — давняя моя идея, возникшая из одной из моих самых недооцененных статей: Смотрители зоопарка должны стать лесничими». Она тесно связана с более популярной метафорой архитектуры программного обеспечения как садоводства, но мне больше нравится вариант с дикими животными, потому что он подчеркивает ещё более свободный подход. Он избавляет от иллюзии, что вы можете контролировать по сути непредсказуемый процесс, заменяя её обнадеживающим акцентом на управлении и заботе.
Как процветают экосистемы? Архитектор программного обеспечения (или лесничий) должен взращивать устойчивость в каждой подсистеме, подобно тому как эволюция способствовала развитию способности растений и животных выживать в различных непредвиденных обстоятельствах: при наводнении, засухе, пожаре, хищниках, отсутствии добычи, болезнях и так далее.
Вы хотите, чтобы команды работали независимо друг от друга. Это не значит, что они работают в изоляции, скорее, они могут действовать в соответствии со своими способностями и пониманием ситуации. Архитектор может помочь им понять более широкую экосистему и, скажем так, предсказать погоду на завтра, но команда должна оставаться самостоятельной.
Параллельная работа
Я исхожу из того, что в организации есть несколько команд, потому что предполагается, что они должны работать одновременно. Пока команда А занимается одной задачей, команда Б делает что-то другое. Можно попытаться направить их в одном общем направлении, но будьте осторожны с чрезмерной координацией.
В чем проблема с координацией? Разве это не своего рода сотрудничество? Разве мы не считаем это полезным?
Я не утверждаю, что команды должны быть враждебны друг к другу. Как и в случае с любыми метафорами, с метафорой саванны нужно быть осторожным и не заходить слишком далеко. Я не представляю, что одна команда состоит из львов, хищников — убивающих и пожирающих другие команды.
Причина, по которой я настороженно отношусь к координации, заключается в том, что она кажется синонимом синхронизации.
В книге Code That Fits in Your Head я уже рассказывал о том, что хорошие практики непрерывной интеграции похожи на уроки оптимистичного параллелизма. Недавно меня осенило, что параллельную командную работу можно сравнить с параллельными вычислениями.
Уже несколько десятилетий мы знаем, что чем меньше синхронизации, тем быстрее работает параллельный код. Синхронизация требует больших затрат.
В командной работе координация похожа на синхронизацию потоков. Вместо того чтобы выполнять работу, вы останавливаетесь, чтобы скоординировать действия. Это означает, что одному потоку или команде приходится ждать, пока другой догонит его.
![Два горизонтальных отрезка представляют два процесса, A и B. A короче B, что указывает на то, что он завершается первым. Two horizontal bars presenting two processes, A and B. A is shorter than B, indicating that it finishes first.](https://habrastorage.org/getpro/habr/upload_files/7d2/499/cc5/7d2499cc5c901c71fc6cfd5c20760bab.png)
Если работа не распределена идеально равномерно, команда А может закончить работу раньше команды Б. Чтобы скоординировать действия, команда А должна некоторое время посидеть без дела, дожидаясь, пока Б догонит её. (В компаниях, занимающихся разработкой, безделье практически невозможно, поэтому на практике команда А приступает к работе над следующей задачей, что влечет за собой последствия, которые я уже описал).
Если у вас больше двух команд, это явление только усугубляется, и у вас появится больше свободного времени. Это напоминает мне о законе Амдала. Если описать его вкратце, то существует предел того, насколько сильно можно повысить скорость работы за счёт параллельной работы. Этот предел связан с процентом работы, которую нельзя распараллелить. Чем больше необходимость синхронизировать работу, тем ниже предел. И наоборот, чем больше вы можете позволить параллельным процессам работать без координации, тем больше вы получаете от распараллеливания.
Мне кажется, что в организации команд есть прямой аналог. Чем больше команд нуждается в координации, тем меньше выигрыш от наличия нескольких команд.
Но на самом деле Фред Брукс мог бы сказать вам об этом ещё в 1975 году.
Версионирование
Небольшая команда разработчиков может организовать работу неформально. Работу можно разделить по «естественным» линиям, и каждый разработчик берёт на себя задачи, наиболее подходящие для его или её способностей. Если вы работаете в кодовой базе с общим правом собственности, одному разработчику не нужно ждать, пока его работу выполнит другой. Вместо этого разработчик может выполнить необходимую работу индивидуально или вместе с коллегой. Координация происходит, но неформально и часто.
По мере роста организации разработчиков формируются команды. Предполагается, что отдельные команды работают независимо друг от друга, но на практике они часто друг от друга зависят. Команде А может понадобиться, чтобы команда Б внесла изменения, прежде чем они смогут продолжить свою работу. Возникает ощущаемая необходимость координировать деятельность команды.
По моему опыту, это происходит по нескольким причинам. Одна из них заключается в том, что команды могут быть разделены по неправильным линиям; это социотехническая проблема. Другая, более техническая, причина заключается в том, что смотрители зоопарка редко задумываются о версионировании или о том, как избежать ломающих изменений. Представьте, что команда A нуждается в команде B для разработки новой функции. Эта новая функция подразумевает разрывное изменение, поэтому командам придется координировать свои действия.
Вместо этого команда B должна разработать новую фичу таким образом, чтобы это не сказалось на существующих клиентах. Если ничего не получится, новая фича должна существовать бок о бок со старым способом выполнения задач. При непрерывном развёртывании новая фича становится доступной, когда она готова. Команде A всё ещё приходится ждать, когда фича станет доступной, но синхронизации не требуется.
Заключение
Ещё один урок о безопасности потоков и параллельных транзакциях, похоже, применим к людям и процессам. Параллельные процессы должны быть автономными, с как можно меньшей синхронизацией. Чем больше вы координируете команды разработчиков, тем сильнее вы ограничиваете скорость общей работы. Это наводит на мысль, что закон Амдала может быть в какой-то степени применим и к организациям разработчиков.
Вместо того чтобы координировать команды, поощряйте их существование в качестве автономных образований, но оргнизуйте всё так, чтобы не нарушать совместимость — это главная цель для каждой команды.
Как работать с сопротивлением во время изменений в компании? Обсудим 19 августа на открытом уроке. После занятия вы будете знать:
по каким причинам могут возникнуть сопротивлении при внедрении изменений в процессы компании;
какие могут быть риски при возникновении подобных сопротивлений, если с ними не работать;
некоторые фреймворки работы с сопротивлением.
Записаться на урок можно на странице курса "DevOps Lead".
By-Lazarev
Кажется, что даже в рамках одной команды полезно уменьшать синхронизации. Живой пример, у нас есть команда из 2 фронтендеров и 2 бекендеров, можно было бы каждый день синхронизировать статусы задач что бы за спринт успеть сделать все задачи максимально эффективно. Но достаточно просто в спринт для фронтенда брать задачи связанные с уже готовым(в прошлых иттерациях) функционалом бекенда. Получается что одна команда может быть быстрее другой и ждать им никого не нужно. Конечно пользователи тогда будут получать функционал с задержкой, но в долгосрочной перспективе это гораздо выгоднее и позволяет масштабировать работу.