Кросс-функциональные команды и скрытые зависимости
Узнайте, почему кросс-функциональные команды все еще страдают от скрытых зависимостей и как Scrum-командам устранить внешние передачи работы, чтобы поставлять готовый Инкремент в каждом Спринте.
Большинство IT-компаний утверждают, что работают кросс-функциональными командами. На бумаге в каждой из них есть несколько программистов, тестировщик и, возможно, дизайнер. На деле же работа еженедельно встает на паузу, потому что специалист со стороны должен проверить миграцию базы данных, настроить облачный кластер или одобрить релиз. Руководство по Scrum 2020 года определяет кросс-функциональные команды как команды, члены которых обладают всеми навыками, необходимыми для создания ценности в каждом Спринте. Если команда не может выпустить продукт без ожидания внешних контролеров, кросс-функциональность остается лишь формальной организационной вывеской, а не операционной реальностью.
Иллюзорный комфорт штатного расписания
Типичная ошибка заключается в формировании команд по должностям, а не по цепочке создания ценности. Руководители собирают в одной комнате пять бэкендеров, одного фронтендера и инженера по качеству, объявляя их кросс-функциональной командой. Однако если этой группе по-прежнему нужна отдельная служба безопасности для поиска уязвимостей или централизованная команда эксплуатации для развертывания кода на тестовом сервере, она фундаментально зависит от остальной части компании.
Подобные передачи задач порождают очереди, а очереди разрушают поток работы. Разработчик завершает фичу за два дня, после чего она шесть дней ждет внешней проверки. Объем незавершенной работы растет, контекст теряется, и к моменту, когда внешняя сторона просит внести правки, автор кода уже переключился на другую задачу. То, что казалось автономной командой, на самом деле оказывается лишь одним из этапов сборочного конвейера.
Где зарождаются скрытые зависимости
Зависимости редко заявляют о себе во время Планирования Спринта. Они прячутся в негласных предположениях о том, как устроена работа. Чаще всего их можно обнаружить там, где движение задач прекращается:
- Инфраструктура и пайплайны развертывания контролируются исключительно отдельной платформенной командой или отделом DevOps.
- Архитектурный комитет собирается раз в две недели, чтобы утверждать изменения схемы данных или выбор технологий.
- Специализированные общие сервисы, такие как безопасность, комплаенс или локализация, служат обязательными контрольными точками перед релизом.
- Общие кодовые базы, где репозиторий принадлежит другой команде, которая должна одобрить пулл-реквесты до слияния вашего кода.
Зависимости под маской корпоративного управления
Многие зависимости сохраняются из-за того, что компании путают управление с тотальным контролем. Служба безопасности стремится защитить код и потому требует ручного аудита перед каждым релизом. Администратор баз данных хочет избежать медленных запросов и настаивает на том, чтобы писать все продуктовые миграции самостоятельно. Такие правила продиктованы благими намерениями, но они парализуют скорость поставки.
Настоящая кросс-функциональность не означает отказ от стандартов. Она означает переход от ручных проверок к автоматизированным ограничениям. Вместо того чтобы требовать от внешнего инженера проверки каждого пулл-реквеста, команда безопасности может предоставить автоматические сканеры и библиотеки, встроенные прямо в пайплайн команды. Когда команда получает инструменты и полномочия самостоятельно соблюдать стандарты компании, зависимость исчезает.
Как построить подлинную автономность
Если вы хотите, чтобы команды поставляли готовый к использованию Инкремент, отвечающий Definition of Done, в каждом Спринте, вам необходимо методично устранять внешние барьеры. Начните с картирования каждого шага, необходимого для пути идеи от формулировки до продакшена. Каждый раз, когда этот путь выходит за пределы Scrum-команды, вы сталкиваетесь с зависимостью, угрожающей предсказуемости.
После этого у вас есть два пути. Можно включить нужную компетенцию в состав команды, обучив текущих участников или наняв профильного специалиста, либо автоматизировать внешнюю проверку, чтобы команда выполняла ее самостоятельно. Кросс-функциональные команды создаются не перерисовкой структуры компании. Они рождаются в процессе ликвидации промежуточных передач работы, мешающих людям доводить начатое до конца.