Категории зависимостей
Зависимость (анг. Dependency) — это потенциальное препятствие, которое тормозит, либо блокирует работу Scrum Команды.
Выделяют три основных категории зависимостей, с которыми сталкивается Scrum Команда. И каждая категория зависимостей отличается своей сложностью.
Внутрикомандные зависимости
Наименее сложный сценарий зависимости — это когда одна команда обладает всеми навыками, необходимыми для создания завершенного и потенциально готового к развертыванию элемента бэклога продукта (PBI). У команды нет внешних зависимостей. Тем не менее, члены команды все еще могут столкнуться либо с:
- Элементами бэклога продукта (PBI), которые зависят друг от друга, и/или,
- С задачами в спринте, которые зависят друг от друга.
В любом случае, самоуправляемая команда со Скрам Мастером (Scrum Master), обладающим отличными навыками фасилитации, должна быть в состоянии понять эту зависимость самостоятельно. В случае выявления таких зависимостей разработчики разъясняют Владельцу Продукта (PO) технические зависимости, и Владелец Продукта использует эту информацию для переупорядочения продуктового бэклога. Что касается зависимостей между задачами в спринте, то разработчики несут ответственность за координацию действий по этим задачам.
Что может помочь:
- Переработайте и декомпозируйте элементы бэклога таким образом, чтобы они были более независимыми друг от друга. Это лучше всего сделать до планирования спринта, во время Рефайнмента (Refinement), но также можно сделать и во время планирования спринта.
- При планировании спринта важно понять потенциальные риски, создаваемые зависимостями, и договориться том, как они будут решаться. Например, возможность выбора между Путем A или B для Элемента 2 не может быть реализована до тех пор, пока Элемент 1 не будет завершен. Следует внимательно следить за этими зависимостями во время спринта.
Межкомандные зависимости
Следующей, более сложной категорией является межкомандная зависимость, которая рождается в многокомандной среде, где над одним и тем же продуктом работает более одной команды. Каждая команда может брать и доставлять элементы бэклога продукта по мере их завершения, однако может потребоваться контроль над последовательностью доставки или техническая координация между командами.
Тут можно начать с простого - с координацией между самоуправляемыми командами.
Что может помочь:
- Чтобы свести к минимуму противоречащую информацию, у вас должен быть только один Владелец Продукта.
- Нужно убедиться, что Владелец Продукта работает с командами и понимает, как распределять работу. Например, если передать все задачи с высоким приоритетом команде А, а задачи с более низким приоритетом — команде Б, то это может привести к получению меньшей ценности, если команда А потерпит неудачу, по сравнению с ситуацией, когда обе команды, работают над задачами с одинаковым приоритетом.
- Выберите одного или двух представителей от каждой из зависимых команд в качестве представителей своих команд. Эти представители будут отвечать за координацию с представителями из других команд. Данная деятельность будет осуществляться в рамках Scrum of Scrums – регулярной встречей, целью которой является обмен информации и решение вопросов, связанных с координацией действий между командами.
- Используя Scrum of Scrums, представители команд также могут координировать действия до и после планирования и Обзора Спринта (Sprint Review).
- Помните, что Обзор Спринта открыт для любой заинтересованной стороны, и на нем могут присутствовать заинтересованы члены зависимых команд. Не забудьте их пригласить.
Внекомандные зависимости
Это самый сложный случай — когда Скрам Команда не может выполнить всю работу, необходимую для доставки элемента бэклога спринта. Им нужна помощь или поддержка со стороны:
- Другой скрам-команды,
- Другого отдела или,
- Внешнего поставщика.
Практикуют ли внешние стороны, от которых зависит команда, Agile подход и практикуют ли они Скрам?
Если да, то они понимают какие от них ожидания, и вы можете согласовать с ними планы работ на уровне бэклога продукта.
Если же нет, и вы пока не можете этого изменить, то Скрам Команде придется планировать свою работу в соответствии с графиками внешней стороны. Нужно убедиться, что задачи по мониторингу и работе с этими зависимостями учтены в Капасити (Capacity) команды.
Что может помочь:
- Запросите подтверждения по доставке от внешних сторон. Получите информацию по объемам работ и конкретные даты.
- Контролируйте ситуацию. Приглашайте внешних представителей на ежедневные встречи команды – Daily Scrum. Регулярно проверяйте согласованный график поставки. Вместо того, чтобы проверять ход выполнения работ, лучше периодически спрашивать: «Есть ли какие-либо причины, по которым вы не сможете выполнить свои обязательства?»
- Проводите Ретроспективу производительности внешней стороны. Были ли они надежными? Можете бы вы рассчитывать на то, что они доставят то, что обещали в срок? Если нет, что вы сделаете по-другому в следующий раз, чтобы снизить риски?
- Наконец, не добавляйте задачу в спринт, если есть внешняя зависимость без определенных обязательств по доставке. Поскольку это бизнес-вопрос, Владельцы Продукта должны быть полностью вовлечены и обязаны оказывать любую помощь, необходимую для управления внешней стороной или другим отделом в вашей организации. У Владельцев Продукта есть полномочия и рычаги, которые могут быть очень эффективными, если их правильно использовать.
Помните, что зависимости могут разрушить постоянную доставку ценностей. Не думайте, что зависимости — это просто то, как обстоят дела, но вместо этого рассматривайте их как потенциальные препятствия и приложите усилия, чтобы устранить или смягчить их влияние.
Комментировать