1. LeSS Framework
  2. Координация и Интеграция

Координация и Интеграция

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

Просто поговорите

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

Коммуникация в коде

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

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

Отправьте наблюдателей на Ежедневный Скрам

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

Сообщества и менторы компонентов

Люди, работающие над одними и теми же компонентами в одно и то же время, должны знать друг о друге, чтобы они могли обсуждать вопросы и делать проверку кода друг друга. Делайте это путём создания Сообществ практик (Сообщества) которые будут взаимодействовать через списки рассылки, чаты, спонтанные встречи и различные каналы удалённой коммуникации.

Эти сообщества часто организуются “ментором компонента”, который обычно является членом кросс-функциональной команды и который взял на себя некоторые дополнительные обязанности, такие как (1) выступать в роли учителя, объясняющего как работает компонент, (2) отслеживать “состояние здоровья” компонента в долгосрочной перспективе, (3) организовывать сообщество по компоненту, (4) организовывать архитектурные обсуждения и (5) выполнять ревизию кода.

Ментор компонента не производит рецензирование кода для утверждения его перед слиянием. Он учитель и попечитель компонента, а не его привратник.

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

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

Скрам над Скрамом (Scrum of Scrums)

Скрам над Скрамом встречи - это похожие на Ежедневный Скрам между командами, обычно проводимые два или три раза в неделю.

Обычно это формат трёх вопросов, похожий на Ежедневный Скрам:

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

Естественно, используйте и вырабатывайте такие вопросы, которые ваша группа посчитает полезными.

Предупреждение: Желание проводить Скрам над Скрамом может быть сигналом о проблемах с излишними зависимостями или координацией, вызванными монофункциональными группами и компонентными командами, или командами, которые не могут или не хотят выявлять и выполнять совместную работу.

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

Многокомандные встречи

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

Путешественники для расширения и устранения узких мест и развития навыков

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

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

Ведущая команда

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

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

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

Перевод статьи осуществлен Романом Лапаевым и Сергеем Господчиковым