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

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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

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

Примечание

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

Примечание

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

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

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

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

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

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

Примечание

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

Примечание

Хотя вы можете назначить один и тот же путь к области нескольким командам, это может вызвать проблемы, если две команды утверждают, что владелец одного набора рабочих элементов. Дополнительные сведения см. в разделе About boards and Kanban, Limitations of multi-team Kanban board views.

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

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

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

Вы добавляете области для поддержки требований к трассировки и безопасности вашей команды. Создайте области, представляющие логические или физические компоненты, а затем дочерние области, представляющие определенные возможности.

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Плоская иерархия итерации

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

Как показано в следующем примере, итерация Beta 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, or AUX. Дополнительные сведения о зарезервированных именах см. в разделе "Имена файлов", "Пути" и "Пространства имен".

Специальные символы для узлов

  • Не должны содержать управляющие символы Юникода
  • Не должен содержать ни одного из следующих символов: \ / $ ? * : " & > < # % | +
  • Не должны содержать символы, запрещенные локальной файловой системой. Дополнительные сведения об ограничениях символов Windows см. в разделе Именование файлов, путей и пространств имен.

Длина пути

  • Не должен содержать более 4000 символов Юникода

Глубина пути иерархии

  • Не более 14 уровней в глубину

Поддерживаемые правила полей

Можно указать только небольшое подмножество правил, например HELPTEXTREADONLY System.XXX поля.

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