Доски (и журналы невыполненных заданий) предназначены для команд по области
Если вы хотите иметь другое «представление» рабочих элементов в невыполненном задании между teamA и teamB, тогда ответ - ДА.В этом случае у вас будут элементы в общем резерве, а затем разделите его на разделы, используя области, что позволит каждой команде создавать свои собственные спринты под этим общим резервом.
Иллюстрации из нашей установки
Наша конфигурация проекта такова:
Вы заметитечто DEV и MOAB имеют видимость (почти) всех других областей, но другие команды видят только свою область.Это делается для того, чтобы команды «владельца продукта» могли создавать и расставлять приоритеты в своей области в своем списке заданий и просматривать ход их работы.Конечно, они могут перемещать эти элементы в разные столбцы доски и, возможно, что-то испортить, но именно тогда мы начинаем публично стыдить их, используя массовую электронную почту и инструмент обвинения (читай: история рабочих элементов) (jk).Доски для этих команд используются только для наглядности.
Конфигурации нашей команды:
DEV (и MOAB >> Mother ofНастройки области «Все журналы» более сложны, потому что мы хотим, чтобы область оставалась в представлении команд владельцев продуктов для целей запросов и чтобы они могли видеть, как их элементы перемещаются по доске (если они смотрят).По этой причине область DEV (и MOAB) по умолчанию является корневой, и DEV имеет доступ ко всем другим групповым областям и подобластям.
<Edit>
Команды DEV выбирают представление того, что является видимым для MOAB, с помощью "Итерации по бэклогу" .На иллюстрациях вы увидите, что у DEV есть путь итерации отставания SYB\Backlog\Planned, где у MOAB есть root SYB.
Таким образом, для DEV на его платах видны только элементы, которые имеют в или менее SYB\Backlog\Planned пути итерации, где MOAB видит все.Мы добавили итерацию SYB\Backlog\Planned в настройки MOAB, чтобы члены команды MOAB (администраторы планирования) могли перетаскивать элементы с приоритетом перетаскивания из журнала (не доски) MOAB в журнал команды разработчиков (DEV).
Имея 2 команды разработчиков, вы, вероятно, будете использовать отдельные итерации бэклога (т. Е. SYB\Backlog\d1_Planned и SYB\Backlog\d2_Planned) и добавите эти итерации как видимые для MOAB для функции drag-n-drop.
Эта настройка позволяет планировать администраторов и типы BA, чтобы вытащить их из журнала невыполненных работ и заполнить список команд, в то время как руководители группы могут планировать спринты из журнала команд.
SYB
+--+ Backlog -> _product owners prioritize their backlog based on the area_
|
+--+ d1_Planned -> _team1 leads plan sprints from here_
| |
| +---\ s1 (sprint)
| |
| +---\ s2 (sprint)
|
+--+ d2_Planned -> _team2 leads plan sprints from here_
|
+---\ s1 (stprint)
</Edit>
Единственная причина, по которой мы не используем «включающие подобласти» на корневом уровне для DEV и MOAB, заключается в том, что мы имеемобласть, которую не видит ни одна команда и предназначена только для запросов:Перемещение элементов в эту область после итерации сохраняет закрытую колонку обрезки доски.
Подзоны могут добавить дополнительную категоризацию / фильтрацию к видимости доски, например, по теме или проекту, и позволить дополнительные диаграммыдля запросов по проектам, потому что запросы результатов не должны быть «иерархическими», если они запрашивают по соглашению области.