Сведения о путях к области и путях итерации (спринт)

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Вы определяете области и пути итерации для проекта. Затем Teams может выбрать, какие пути используются для поддержки невыполненной работы и других инструментов Agile. Сведения о том, как средства Agile используют области и пути итерации, см. в статье "Гибкие инструменты", использующие области и итерации.

Примечание.

Пути к областям и пути итерации также называются узлами классификации. Их можно управлять программным способом с помощью узлов классификации (REST API) или команды Azure DevOps CLI az boards итерации.

Примечание.

Пути к областям и пути итерации также называются узлами классификации. Их можно управлять программным способом с помощью узлов классификации (REST API).

Области и итерации, которые вы видите, зависят от процесса, используемого для создания проекта. Здесь показаны значения по умолчанию, определенные для процесса Scrum. Даты не заданы. Вы задаете даты, соответствующие расписанию спринта или выпуска.

Итерации Области
Итерации по умолчанию, процесс Scrum Набор примеров путей к области

Внимание

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

Определение и назначение путей к областям

Если вы не знакомы с управлением проектами и командами, самая прямая последовательность настройки проекта и команд выглядит следующим образом.

  1. Определите число и имена путей области, которые требуется поддерживать для классификации вашей работы. По крайней мере добавьте один путь к области для каждой группы, которую вы определяете.
  2. Определите число и имена команд, которые требуется поддерживать. Дополнительные сведения см. в разделе "О командах" и средствах Agile.
  3. Откройте конфигурацию проекта параметров проекта и определите пути области для поддержки > шагов 1 и 2 на уровне проекта. Выполните действия, описанные далее в этой статье: открытие Параметры проекта, конфигурация проекта и пути к областям.
  4. Определите команды, необходимые для поддержки шага 2. Инструкции см. в разделе "Добавление команды", переход с одной команды по умолчанию на несколько команд.
  5. Откройте конфигурацию команды и назначьте путь по умолчанию и дополнительные пути к области для каждой команды. Выполните действия, описанные далее в этой статье: откройте параметры команды и задайте путь к области группы по умолчанию.
  6. Назначьте путь к области рабочих элементов определенному пути области. Используйте массовое изменение для одновременного изменения нескольких рабочих элементов.

Примечание.

Проекты ограничены определением не более 10 000 путей области и назначением не более 300 путей к областям одной команде. Дополнительные сведения см. в разделе "Отслеживание работы", "Процесс" и "Ограничения проекта".

Кроме того, хотя вы можете назначить один и тот же путь к области нескольким командам, это может вызвать проблемы, если две команды утверждают владение одним набором рабочих элементов. Дополнительные сведения см. в разделе "О досках и Канбане", ограничениях многокомандатных представлений канбанов.

По мере необходимости можно выполнять следующие действия в любое время:

  • Добавление дополнительных дочерних узлов
  • Переименуйте путь к области (кроме пути к корневой области)
  • Перемещение дочернего узла под другим узлом
  • Удаление дочернего узла
  • Переименование команды
  • Изменение назначений пути к области, сделанных команде

См. также инструкции по настройке иерархии команд.

Сколько областей должно определить команда?

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

Добавьте области, если у вас есть следующие требования:

  • Фильтрация запросов на основе области продукта или компонента
  • Упорядочение или группирование рабочих элементов по командам или вложенным элементам
  • Ограничение доступа к рабочим элементам на основе их области.

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

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

Определение и назначение путей итерации

Используйте следующее руководство, чтобы настроить пути итерации для проекта и команд:

  1. Сначала определите пути к областям и командам, приведенным в руководстве по определению путей к областям, и назначьте команде.
  2. Определите длину итерации, которую требуется поддерживать. Рекомендуется, чтобы все команды использовали один и тот же спринт.
  3. Определите, требуется ли плоская структура или иерархия спринтов и выпусков.
  4. Откройте конфигурацию проекта параметров > проекта и определите пути итерации для поддержки шагов 2 и 3 на уровне проекта. Выполните действия, описанные далее в этой статье: откройте project Параметры, конфигурацию проекта и добавьте итерации и задайте даты итерации.
  5. Откройте конфигурацию команды и назначьте путь по умолчанию, невыполненную работу и дополнительные пути итерации для каждой команды. Выполните действия, описанные далее в этой статье: откройте параметры команды и задайте пути итерации команды по умолчанию.
  6. Каждая команда должна назначить путь итерации своим рабочим элементам, которые попадают под путь итерации невыполненной работы . Эти рабочие элементы будут отображаться на их невыполненных продуктах и досках. Используйте массовое изменение для одновременного изменения нескольких рабочих элементов. См. также назначение элементов невыполненной работы с спринту.

Примечание.

Проекты ограничены определением не более 10 000 путей итерации и назначением не более 300 путей итерации одной команде. Дополнительные сведения см. в разделе "Отслеживание работы", "Процесс" и "Ограничения проекта".

По мере необходимости можно выполнять следующие действия в любое время:

  • Добавление дополнительных дочерних итерации узлов
  • Переименуйте путь итерации (за исключением корневого пути)
  • Перемещение дочернего пути итерации под другим узлом
  • Удаление пути итерации дочернего элемента
  • Измените значения по умолчанию и выбранные пути итерации, назначенные команде

Сколько итераций должно определить команда?

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

Добавьте итерации для поддержки этих требований:

  • Определение спринтов, используемых командами Scrum для планирования и выполнения их спринтов
  • Настройка более сложных циклов спринта и нескольких выпусков
  • Фильтрация запросов на основе спринтов, вех или времени цикла для проекта
  • Поддержка будущих работ, которые вы не готовы назначить целевому циклу выпуска.

В следующем примере для проекта MyApplication определены бета-версия 1, бета-версия 2, выпуск 1.0 и выпуск 2.0.

Иерархия неструктурированных итераций

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

Как показано в следующем примере, итерация бета-версии 1 теперь содержит три дочерних узла, по одному для каждого спринта в период времени бета-версии 1.

Иерархия иерархической итерации

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

Ограничения для имен

Поля пути к области и пути итерации, тип данных=TreePath, состоят из нескольких элементов узла, разделенных символом обратной косой черты (\). Сведите к минимуму имена узлов и убедитесь, что при добавлении дочерних узлов соответствуют приведенным ниже ограничениям.

Тип ограничения Ограничение
Длина узла Не должно содержать более 255 символов.
Зарезервированные имена — не должно состоять только из периода . или двух периодов ...
— не должно быть системным зарезервированным именем, таким как PRN, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM10, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, NUL, CON или AUX. Дополнительные сведения о зарезервированных именах см. в разделе "Имена файлов", "Пути" и "Пространства имен".
Специальные символы для узлов — не должен содержать символы элемента управления Юникода.
— не должен содержать один из следующих символов: \ / : * ? " < > | # $ * +
— не должен содержать символы, запрещенные локальной файловой системой. Дополнительные сведения об ограничениях символов Windows см. в разделе Именование файлов, путей и пространств имен.
Длина пути Не должно содержать более 4000 символов Юникода.
Глубина иерархии пути Должно быть меньше 14 уровней глубины.

Как видно, области и итерации играют важную роль в поддержке инструментов Agile и управления рабочими элементами. Дополнительные сведения о работе с этими полями см. в следующих статьях.