Я работаю скрам-мастером в месте, где у нас есть два разных продукта. И эти продукты имеют подмодули:
Product A: (The bigger product)
Submodule A.1
Submodule A.2
Submodule A.3
etc.
Product B: (The smaller product)
Submodule B.1
Submodule B.2
Submodule B.3
etc.
Сейчас у нас две команды. Команда продукта А (состоит из 12 разработчиков) и команда продукта Б (состоит из 3 разработчиков)
А также у нас есть два тестировщика, которые на самом деле не являются частью этих команд и имеют различный бэклог.
В наших командах есть процесс проверки кода, который выполняется до того, как проблема будет решена. Таким образом, код, который не проверен коллегой, не может быть помечен как выполненный.
Я знаю, что 12 разработчиков — это много для скрам-команды, а 3 разработчика — это мало для скрам-команды. Из-за этого и по некоторым другим причинам мы сталкиваемся с некоторыми проблемами.
1) Команда продукта Б движется медленными темпами и тратит слишком много времени на решение проблем. Проверка кода не проводится полностью, и коды с ошибками помечаются как выполненные. Команда Б на самом деле мало похожа на команду, у каждого свои цели. Это потому, что один разработчик всегда работает над основными функциями и на уровне операционной системы. Другой разработчик всегда работает над пользовательским интерфейсом (на самом деле он не дизайнер пользовательского интерфейса, а бэкенд-разработчик), а другой разработчик недавно присоединился к команде и работает над способами и проводит исследования того, как заставить продукт работать с большей спектакль.
Таким образом, разработчик, работающий на уровне операционной системы, просматривает коды пользовательского интерфейса. Разработчик пользовательского интерфейса просматривает коды уровня ОС. На самом деле у них нет опыта для проверки кода друг друга, и они на самом деле не знают или не очень заинтересованы в том, что делает другой.
2) Продукт. Команда — это большая команда, а продукт — огромный продукт. Он состоит из нескольких (порядка 10) подмодулей. Все подмодули являются отдельными модулями на стороне сервера (иногда они используют общие библиотеки и общие файлы конфигурации, модули и т. д., но, как правило, разные), но все они имеют один и тот же графический интерфейс (для управления всеми этими модулями используется приложение Java Swing). Таким образом, 2 разработчика всегда работают над графическим интерфейсом, некоторые разработчики работают над большинством модулей на стороне сервера. И некоторые разработчики всегда работают над одним и тем же подмодулем (например: подмодуль A.1 и подмодуль A.2). Таким образом, эти ребята хорошо разбираются в этом модуле, но мало знают об остальном продукте. В то время как другие разработчики знают большую часть продукта, за исключением этих подмодулей (подмодуль A.1 и подмодуль A.2)
На самом деле все наши разработчики — хорошие разработчики, которые справятся со всем, что бы вы им ни предложили. Но, конечно, некоторые из них лучше с точки зрения пользовательского интерфейса, тогда как некоторые из них лучше с точки зрения серверной части. Некоторые накопили большой опыт работы с конкретным модулем, поэтому работа над этим конкретным модулем всегда выполняется этим конкретным человеком. Это приводит к тому, что один человек показывает, что неудача и успех становятся его, а не командами.
Итак, мой главный вопрос: как нам формировать команды и бэклоги? Прямо сейчас у нас есть команды (команда продукта А и команда продукта Б) и два бэклога (бэклог продукта А и продукта Б). Должны ли мы сохранить это?
Мы планируем создать такие команды, как команда ОС, команда платформы, команда внешнего интерфейса, группа архитектуры, группа внедрения, команда тестирования, команда безопасности, команда документации. На самом деле я даже не знаю, как это произойдет, у нас даже нет столько разработчиков. Может быть, один человек будет в нескольких командах, я не знаю. И если мы создадим такие команды, как мы должны формировать бэклоги?
Но я думаю, что такая командная структура противоречит Scrum, потому что Scrum-команды должны быть кросс-функциональными. Все виды экспертизы должны быть в командах.
Или мы должны создавать новые команды в начале каждого спринта в соответствии с потребностями спринта. Но как это будет (кто и на каком собрании по планированию спринта будет присутствовать?)
PS: Разработчики продукта А и продукта Б достаточно опытны, чтобы работать над другим продуктом.
И в соответствии со структурой команды вы порекомендуете, сколько у нас должно быть скрам-мастеров. Достаточно ли одного скрам-мастера или в каждой команде должны быть свои скрам-мастера?
Вы задаете много вопросов здесь:
Компонентные команды (платформа, внешний интерфейс...): Вы правы, это противоречит Scrum. Если вы хотите потерять время при передаче, сделайте это :-)
общие члены команды также идут против Scrum. Многозадачность замедляет людей, заставляет их терять концентрацию. Хорошо для плохого качества :-)
Как работать с очень большой и очень маленькой командой? Очевидное решение — сменить членов команды. Просто сделайте, а не заказывайте. Решите проблему с командами. Может быть, кто-то из большой команды хотел бы помочь маленькой команде. Это может быть ограниченное количество спринтов или постоянное. Это может быть своего рода творческий отпуск.
Некоторые люди все время работают над одним и тем же: помните Т-образный рабочий? Ничего страшного, если некоторые члены команды действительно хороши в чем-то одном и делают это много. Но если делать это исключительно, вы столкнетесь с узкими местами. Вдохновите специалиста на обучение и поделитесь своим ноу-хау. Они останутся специалистами, но другие могут и должны помочь.
Сколько отставаний? Максимум один на продукт, независимо от количества команд.
Новая структура команды для каждого спринта: Было такое, но не работает. Команде нужно время, чтобы сформироваться. Создание новых команд в каждом спринте приводит к очень плохим командам. Дополнительным эффектом является то, что через некоторое время все видят всего понемногу, но не имеют более глубокого понимания чего-либо.
Сколько скрам-мастеров: при этом может возникнуть необходимость в скрам-мастере на команду.
Очень поздний ответ. Вам это не поможет, но может кому-то другому.
Команда продукта А (состоит из 12 разработчиков) и команда продукта Б (состоит из 3 разработчиков)
Команда А слишком велика для эффективного общения. Теоретически команда Б могла бы работать, но она очень мала.
потому что один разработчик всегда работает над основными функциями и на уровне операционной системы
У вас не должно быть «основной функции». Ваши функции должны приносить пользу конечному пользователю. Любая «основная функция», для которой необходимы «функции пользовательского интерфейса», не приносит пользы. Это техническое задание, а не фича.
В идеале ваши разработчики должны работать вместе над одной и той же функцией и, как правило, со своей точки зрения (ядро, пользовательский интерфейс), но с одной и той же пользовательской ценностью.
В вашем случае я бы смешал команды. Во-первых, бэклог должен содержать пользовательские истории (доставлять пользу пользователю); не «создавайте эту функцию пользовательского интерфейса, которая по-прежнему требует сборки XYZ, прежде чем она заработает».
Я бы назвал их вместе (все 15); рассказать им об отставании; и попросите их организовать вокруг работы. * Сами сформируйте команды * Никто не останется позади * Ни одна команда не меньше 4 или больше 7 * Каждая команда должна иметь возможности для выполнения работы.
В итоге вы получите 3 команды, и у каждой может быть своя сфера деятельности. Команда 1 может сосредоточиться на продукте A, а команды 2 и 3 могут работать над продуктом A + B одновременно.