У нас есть «набор продуктов», состоящий из 3 основных продуктов с отдельными кодовыми базами, 2 проектов на C и 1 Java.
Инженеры были помещены в одну и ту же скрам-команду во имя кросс-функциональной команды, поскольку три продукта составляют полный набор продуктов.
Однако инженеры не могут пересекать кодовые базы. Это было бы слишком, каждая кодовая база имеет свою архитектуру и предназначение.
Это создает ситуацию, когда инженеры не могут работать роем или работать в команде.
Кроме того, большинство историй относятся к конкретному продукту. Однако иногда встречаются истории, которые «объединяют» стек из трех продуктов.
Должна ли Скрам-команда состоять из инженеров из разных кодовых баз? За и против?
В первую очередь здравый смысл. Я имею в виду, что вы можете заставить разработчиков C, которые впервые в жизни видят Java, писать код на Java, точно так же, как вы можете заставить меня писать ваш код на C. Имеет ли это смысл? Зависит от цели. Если цель состоит в том, чтобы научить их новым технологиям, это может быть идеальным случаем. Если цель состоит в том, чтобы выполнить работу, не так много.
Более того, идея, стоящая за кросс-функциональной командой, заключается не в том, чтобы заставить разработчиков с разных ролей обмениваться друг с другом, а в том, чтобы собрать в одной команде разные проектные роли, например, разработчиков, инженеров по качеству, менеджеров/владельцев продукта, релиз-менеджеров и т.д.
В этом случае мой вопрос будет таким: что вы на самом деле получаете в долгосрочной перспективе от того, что разработчики из разных миров работают в одной команде? Вы хотите, чтобы они переключились только на одну технологию. Или, может быть, мы обсуждаем команду из 3 человек, где сложно обмениваться людьми, когда кто-то берет выходной? Или он и так нормально работает? Если верно последнее, не пытайтесь навязывать изменения.
Другой способ заключается в том, стоит ли объединять их в одну команду. На самом деле я бы сказал, что это скорее так, чем нет. Это не потому, что вы хотите, чтобы они случайным образом брали задания друг у друга. Что вы получаете, собирая их в одну команду, так это то, что вы на самом деле улучшаете общение между ними, что особенно важно, когда они работают над одним стеком программного обеспечения.
Примечание: это не должно автоматически означать, что они копаются в своих задачах или парной программе. Они все еще могут быть командой. На самом деле определение команды — это не «они могут роиться» или что-то в этом роде. Специализация — это не плохо. Если это имеет смысл, позвольте людям сосредоточиться на задачах, с которыми они бегло справляются. Вы все еще можете организовать их в одну команду.
У нас очень похожая ситуация, когда есть 4 проекта, которые все независимы, но должны легко интегрироваться вместе в конце проектов. И это что-то вроде кошмара в управлении! :-)
Ключевым моментом здесь является разделение проектов/продуктов и отдельное беспокойство об историях интеграции. Если большинство ваших историй посвящены конкретным продуктам, то объединение разработчиков в единую «команду» вряд ли принесет пользу. Держите их отдельно и сосредоточьтесь на своих продуктах.
Далее, как поступить с историями о зависимостях между продуктами... это более сложно. Что мы делаем, так это добавляем историю для каждой кросс-продуктовой истории в один «владелец» проекта. Для нас это тот, кто больше всего инвестирует в функцию или логически владеет этой функцией, не обязательно тот, над которым больше всего работы. Например, если история состоит в том, чтобы интегрировать функциональность X из продукта A в продукт B, чтобы покупатель продукта B мог чего-то достичь, тогда продукт B будет владеть историей, потому что ему нужно продемонстрировать эту функцию в своем продукте, даже если большая часть интеграции работа может быть с продуктом А. Имеет ли это смысл? Как только история попала в проект, нам нужно отслеживать ее в других проектах, чтобы она не забылась. Для этого мы добавляем технические истории в другие проекты, чтобы они не потерялись.
Чтобы отслеживать это, у нас есть еженедельная встреча руководителей проекта (похожая на Scrum of Scrums) для обсуждения прогресса и препятствий.
Кажется, это работает довольно хорошо.
«Однако инженеры не могут пересекать кодовые базы. Это было бы слишком, каждая кодовая база имеет свою собственную архитектуру и назначение».
Я бы поставил под сомнение идею о том, что это означает, что инженеры не могут работать в толпе или работать в команде. Я работал с командами разработчиков, обладающих очень разрозненными навыками — каждый из которых знает определенную систему, написанную на определенном языке, — и которые все еще очень эффективно работают для достижения одной цели.
В основном они делают это, выясняя, что нужно нижестоящему сервису от вышестоящего; совместная работа над интерфейсами (интерфейс службы, приложения или библиотеки), изменение предоставляемой или обрабатываемой информации и общение друг с другом .
Я увидел, что команда собралась вместе, когда один продемонстрировал работу заинтересованным сторонам, сказав:
«На прошлой неделе вы видели работу Y над этим приложением. Я также показал вам, как мой сервис будет сохранять вашу информацию. На этой неделе я хотел бы показать вам, как они работают вместе».
Команду создают не технологии или их понимание. Это стремление к тому, чтобы работа каждого человека вносила свой вклад в работу других, создавая единое целое.
Однако это сработало, потому что им нужно было решить конкретную проблему. Вы не можете создать команду, просто объединив людей с разными способностями и опытом; вместо этого соберите команду, обладающую соответствующими навыками для проблемы, которую они пытаются решить, и позвольте им учиться или обращаться за помощью, если они в ней нуждаются.
Если вы делаете это хорошо, это не вопрос помещения их в одну команду. Они одна и та же команда, как только вы позволяете им быть.
Если члены всей команды работают как одна команда, это может принести существенные выгоды. Если вы сможете заставить их эффективно работать в команде, интерфейсы между уровнями стека будут работать лучше.
Некоторые проекты имеют простую архитектуру, и наличие полностью кросс-функциональной команды может быть более реальным. У вас будут и должны быть люди в команде, к которым можно обратиться по конкретным вопросам. Иметь одну резервную копию для них хорошо, две или более — это рай.
В таком проекте, как ваш, вы не получите столько кросс-функциональности, как в других. Вы должны стремиться к тому, чтобы члены команды по обе стороны интерфейса между слоями понимали интерфейсы. Для двух проектов C участники должны понимать код по обе стороны интерфейса. Аналогично, для интерфейса между базами кода C и Java. C и Java достаточно похожи, чтобы инженеры с обеих сторон могли следовать коду.
ПЛЮСЫ:
МИНУСЫ: