Владение кодом с несколькими командами Scrum

Если две команды Scrum используют один и тот же программный компонент, кто отвечает за обеспечение четкого архитектурного видения этого компонента и поддерживает / развивает это видение по мере развития базы кода? В Scrum у вас должно быть коллективное владение кодом, так как сделать так, чтобы разработка, выполняемая командой A, не мешала разработке, выполняемой командой B?

Я не эксперт по Scrum, но «коллективное владение кодом» AFAIK предназначено для каждой команды и для каждого продукта (и я думаю, что ваш вопрос не относится к Scrum, его можно применить к любому процессу разработки «общего кода»).

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

Однако, если у обоих продуктов A и B есть много «требований к вождению» для C, вы должны управлять C как совершенно отдельным продуктом с собственным управлением версиями, управлением выпусками, управлением изменениями, юнит-тестами и т. Д., А также отдельной командой, которая имеет ответственность за этот компонент. Эта команда может быть просто «виртуальной командой», состоящей из отдельных разработчиков из команды A, B или обоих. У этой команды есть «владение общим кодом» для C и ответственность за «архитектурное видение». Просто подумайте о том, что C является компонентом, поставляемым сторонним поставщиком.

В Scrum или Agile нет понятия «четкое архитектурное видение»!

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

Что необходимо, так это иметь архитектуру, которая достаточно адаптируется к меняющимся требованиям. Другими словами, все меняется, и архитектура меняется - я не защищаю «мягкую» архитектуру, которую можно изменить. Я говорю о том, чтобы признать, что имеющаяся у нас архитектура скоро устареет и ее нужно будет изменить, поэтому никто не должен «жениться» на ней.

Коллективное владение кодом означает, что каждый должен - теоретически - иметь возможность что-либо изменить. Это следует понимать как «противоположность силосов». Другими словами, может существовать барьер навыков, который является нормальным и ожидаемым - не каждый является опытным администратором баз данных, который может точно настроить запросы SQL, чтобы привести пример - но из этого не следует, что только администратор баз данных может рука оптимизирует запросы. Будет «эксперт в области функциональных возможностей», который может помочь другим людям овладеть навыками, но задачи все равно должны ложиться на каждого.

Например: если я эксперт по предметной области для функции «A», то я все еще ожидаю, что кто-то еще будет работать над функцией «A», но, вероятно, меня проконсультируют, когда произойдут серьезные изменения или если людям понадобится помощь. Функция «А», безусловно, не будет моей особенностью. Это будет особенность, которую я хорошо знаю. Мне будет интересно узнать много других функций, а также интерес других людей, чтобы узнать эту функцию.

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

Например, spotify использует роль с именем «Владелец системы» для решения проблемы непосредственно из документа:

Технически, любому разрешено редактировать любую систему. Поскольку отряды по сути являются функциональными командами, им обычно необходимо обновить несколько систем, чтобы запустить новую функцию в производство. Риск этой модели заключается в том, что архитектура системы испортится, если никто не сосредоточится на целостности системы в целом.

Чтобы снизить этот риск, у нас есть роль, которая называется «Владелец системы». У всех систем есть владелец системы или пара владельцев системы (мы рекомендуем создавать пары). Для систем, критически важных для эксплуатации, Владелец системы - это пара Dev-Ops, то есть один человек с точки зрения разработчика и один человек с точки зрения операций.

Владелец системы является лицом (лицами), обращающимися к специалисту по любым техническим или архитектурным вопросам, связанным с этой системой. Он является координатором и направляет людей, которые пишут в этой системе, чтобы они не споткнулись друг о друга. Он фокусируется на таких вещах, как качество, документация, технические долги, стабильность, масштабируемость и процесс выпуска.

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

Мне очень нравится эта идея, имея преимущества или коллективное владение кодом на уровне компании (не только на уровне команды), но владельцы этих систем пытаются обеспечить некоторую архитектурную целостность.

Ссылка на полный документ: https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf , это короткий, но очень, очень интересный документ, основанный на реальном опыте масштабирования agile.

Это сложная проблема, и она, конечно, не решена Scrum, которая является методологией управления проектами, а не методологией разработки.

Наиболее эффективное решение, которое я нашел, - это хорошее управление пакетами (nuget / gem / etc) и управление версиями. Никогда не применяйте изменения в другой команде, пока они не будут готовы ее использовать. Пусть они продолжают использовать старую сборку, а вы переходите на новую.

Убедитесь, что у вас есть стратегия управления версиями, которая проясняет, какие изменения нарушают, а какие - расширения.

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

И, когда все становится действительно грязным; когда одна команда должна внести изменение и не может легко использовать другое изменение (это ДОЛЖНО быть очень редким случаем), выполните ветвление кода, сделайте его совершенно другим пакетом, но сделайте приоритетным возвращение к общему коду, как только время позволяет.

Ответ, который не всегда так очевиден, как это может быть, состоит в том, чтобы позволить командам решить, как они собираются делиться каким-либо конкретным компонентом.

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

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

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

Я позволю себе предположить:

• приемочные испытания автоматизированы.
• Компонент использует хорошие принципы ООП: низкая связь и высокая когезия.

Если приведенные выше предположения верны, то должны быть случаи, когда две команды будут мешать друг другу. Они могут решить это, используя следующие способы:

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