Кросс-функциональные команды и выявление зависимостей
Кросс-функциональные команды являются основой Скрама. Но скрытые зависимости часто замедляют их работу. Их выявление требует осознанных усилий и четкой коммуникации.
Скрам-команды являются кросс-функциональными. Это означает, что у них есть все необходимые навыки для создания ценности в каждом Спринте. Они не зависят от людей вне команды для выполнения основной работы по разработке. Такая структура направлена на сокращение передач и внешних задержек. Но даже хорошо сформированные кросс-функциональные команды могут сталкиваться со скрытыми зависимостями. Это связи или требования, которые не очевидны на первый взгляд, но могут значительно повлиять на способность команды к поставке.
Что такое скрытые зависимости?
Скрытая зависимость, это любое невысказанное или непризнанное требование для завершения задачи. Это может быть специфическая среда, одобрение от неожиданного заинтересованного лица, доступ к определенной системе или часть информации, которой владеет только один человек. Они являются «скрытыми», потому что не являются частью явного декомпозиции работы или первоначального планирования. Часто они проявляются поздно в Спринте, вызывая задержки и разочарование. Они подрывают способность команды эффективно прогнозировать и планировать.
Почему кросс-функциональные команды все еще сталкиваются с ними
Даже обладая широким спектром навыков, команда может не обладать всеми знаниями или доступом, необходимыми для каждой задачи. Например, команда может быть кросс-функциональной для создания программного обеспечения, но новая функция может потребовать юридической экспертизы, которую член команды не может выполнить, или интеграции с устаревшей системой, чьи особенности известны только давно ушедшему архитектору. Это не пробелы в навыках в обычном смысле, а скорее внешние ограничения или специализированные информационные хранилища. У команды может быть «как», но не «доступ» или «разрешение».
Влияние скрытых зависимостей
Последствия предсказуемы. Спринты срываются. Обязательства не выполняются. Моральный дух команды страдает, поскольку они постоянно натыкаются на неожиданные препятствия. Владелец Продукта с трудом управляет ожиданиями заинтересованных сторон. Разработчики теряют уверенность в своей способности планировать. В конечном итоге поток ценности для клиентов значительно замедляется. Это прямая атака на эмпиризм, поскольку способность команды к инспекции и адаптации постоянно подрывается непредвиденными проблемами.
Раннее выявление зависимостей
Лучший способ справиться со скрытыми зависимостями, сделать их видимыми как можно раньше. Это требует осознанных усилий во время Уточнения Бэклога Продукта и Планирования Спринта. Вся Скрам-команда, особенно Разработчики, должна активно искать эти связи. Спрашивайте: «Что еще должно быть истинным, чтобы это было сделано?» и «Кому еще это может быть интересно?»
Некоторые практические подходы включают:
- Картирование зависимостей: Визуально отображайте известные и потенциальные зависимости для более крупных Элементов Бэклога Продукта.
- Технические спайки: Используйте короткие, ограниченные по времени исследования для изучения неизвестных и потенциальных точек интеграции.
- Раннее вовлечение заинтересованных сторон: Привлекайте соответствующих заинтересованных сторон, даже если это просто для быстрого разговора, во время уточнения сложных элементов.
- Расширение Definition of Done: Явно включайте проверки общих внешних зависимостей в Definition of Done, таких как проверки безопасности или доступность конкретной среды.
Устранение обнаруженных зависимостей
Как только зависимость выявлена, команда может ее устранить. Если она находится под контролем команды, они могут назначить Разработчика для ее решения. Если она внешняя, команда должна решить, как ею управлять. Это может означать корректировку объема Элемента Бэклога Продукта, координацию с внешней группой или эскалацию ее как препятствия для Скрам-Мастера. Цель состоит в том, чтобы либо устранить зависимость, либо сделать ее явной и управляемой, вместо того чтобы позволить ей удивить команду позже.