«Самое сложное, что мы делаем, — это коммуникация между командами».

—Трой Магеннис

Сан-Франциско, 2012 год.

Крупная организация, проходящая третью Agile-трансформацию, пыталась справиться с проблемами координации с помощью таблиц [электронных]. Таблицы зависимостей начали циркулировать между некоторыми командами. Это означало, что некоторые команды были в курсе, а некоторые — нет. Главным ударом было то, что команды были командами распределенных сервисов, которые поддерживались несколькими подразделениями.

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

  1. Использовать кросс-функциональные стендапы команд для выявления зависимостей.
  2. Определить зависимости с помощью матрицы зависимостей.
  3. Внедрить ясные правила работы, перетекающей между канбан-досками разных команд.
  4. Создать ротационную роль разведчика зависимостей — архитектора системы на уровне предприятия, который знает систему вдоль и поперек.

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

Однако идея матрицы зависимостей имела реальную ценность. Один умный консультант создал матрицу зависимостей от пола до потолка, которая выглядела примерно как Рисунок 13, но намного больше.

Рисунок 13: Физическая матрица зависимостей

Рисунок 13: Физическая матрица зависимостей

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

Сколько времени тратится на координацию, когда у множества команд размером с "две пиццы" много зависимостей между собой? Да, правда, нам нравятся маленькие команды, потому что они могут быстро двигаться. Но просто осознайте, что, двигаясь быстро как отдельная команда, вы менее способны двигаться быстро на уровне организации из-за высоких затрат на координацию, вызванных большим количеством зависимостей.

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

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

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

Обратите внимание на последний столбец на доске в Рисунке 14 под названием “ARCH”, что означает ревью архитектуры. Цель ревью архитектуры — предоставить экспертное ведение и поддержку для обеспечения желаемой бизнес-функциональности. Это не должно быть моментом авторитетного согласования.