Добавление и изменение области и путей итерации

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

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

Добавление узла области или дочернего узла

1. Если вы не являетесь администратором проекта, станьте им. Необходимо быть администратором проекта, чтобы иметь возможность добавлять узлы в область команды, или иметь разрешения со значением Разрешить для операции Создать дочерние узлы для пути к области, как описано далее в разделе Ограничение доступа к рабочим элементам, назначенным области или итерации.

2. На странице командного проекта в Team Web Access (TWA) откройте страницу администрирования.

   

   Дополнительные сведения о подключении к TWA см. здесь.

3. Откройте раздел Области. Большинство команд связаны с путем к области по умолчанию.

   

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

4. Добавьте дочерний узел в выбранную область. Для ограничений по именованию перейдите сюда.

   

Добавление дочернего узла итерации и задание дат итерации

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

1. На странице Итерации можно добавить и выбрать итерации, которые будут активными для команды. Добавьте узлы итераций таким же образом, как узлы областей.

   

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

3. Откройте спринт или итерацию, чтобы задать даты начала и окончания.

   

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

   Совет

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

Ограничение доступа к рабочим элементам, назначенным области или итерации

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

1. Откройте разрешения для узла, которым требуется управлять.

   

2. Выберите группу или члена команды и измените параметры разрешений. В следующем примере группа Disallow Access Group не имеет разрешений на просмотр, изменение или редактирование рабочих элементов либо разрешений в пути к области FabrikamFiber.

   

   Чтобы изменить разрешение, щелкните Не задано, Унаследованное разрешение, Разрешить или Запретить.

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

   Если сервер уровня приложений был обновлен до 2013.3 TFS, то разрешения на управление наборами тестов добавлены в модель безопасности пути области. Существующее разрешение Управление планами тестирования было ограничено только планами тестирования. Ранее она охватывала управление разрешениями как для планов тестирования, так и наборов тестов. Дополнительные сведения об этих разрешениях см. в вопросе Какие функции охватываются разрешениями на управление тестами?

   Описание дополнительных способов ограничить изменение рабочих элементов см. в разделе Ограничение прав на создание или изменение рабочего элемента.

Вопросы и ответы

Вопрос. Имеются ли ограничения по именованию и структурированию дочерних узлов?

О. Поля Область и Итерация представляют собой пути, состоящие из нескольких элементов узлов, разделенных символами обратной косой черты (\). Эти поля используют тип данных TreePath. Наилучшим способом является уменьшение имен узлов, необходимо принять в расчет эти ограничения при присвоении имени пути области и пути итерации:

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

Дополнительные сведения о поле ТипДерева см. в разделе Справочник по полям областей и итераций.

Вопрос. Существуют ли ограничения на применение правил поля к пути области и пути итерации?

Ответ. Да. Многие правила полей не могут быть определены для полей Система. XXX. Дополнительную информацию см. в разделе Применение правила поля.

В. Какие разрешения требуются для добавления или изменения пути к области и пути итерации?

Ответ. Для создания или изменения областей и итераций необходимо быть членом группы Администраторы проекта или иметь разрешения Создать и упорядочить дочерние узлы, Удалить этот узел и Изменить узел со значением Разрешить в отношении изменяемого узла области или итерации.

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

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

Кроме того, в следующих двух документах можно найти пошаговые инструкции по настройке команд, путей области и путей итераций для поддержки управления портфелем или крупных организаций: Управление портфелем Agile: использование TFS для поддержки невыполненной работы между несколькими командами и Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs.

В. Что произойдет, если переименовать или удалить узел области или итерации?

О. При переименовании области или итерации либо перемещении узла в древовидной иерархии необходимо вручную обновить рабочие элементы, ссылающиеся на существующий путь или пути. Можно выполнить массовое обновление с помощью TWA или Excel.

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

В. Какие средства зависят от пути к области или пути итерации?

О. Средства планирования Agile (Создание списка невыполненной работы и Работа в спринтах) создаются из запросов системы, которые ссылаются на путь к области команды. Чтобы просмотреть эти запросы, перейдите по ссылке Создать запрос, которая отображается на страницах этих средств. Однако изменить базовый запрос невозможно.

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

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

Встроенный график Скорости относится к определению итераций команды.

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

Вопрос. Какие функции управляются разрешениями на управления тестами?(Требуется TFS 2013.3)

Ответ. Разрешение на управление наборами тестов предоставляет следующие возможности:

• создание и изменение наборов тестов;

• добавление или удаление тестовых случаев в наборах тестов;

• изменение конфигураций тестов, связанных с использованием наборов тестов;

• изменение иерархии наборов тестов путем перемещения набора тестов.

Разрешение на управление планами тестирования предоставляет следующие возможности:

• создание и изменение планов тестирования;

• добавление или удаление наборов тестов в планах тестирования;

• изменение свойств плана тестирования, таких как параметры построения и тестирования.

Дополнительные разрешения на управление тестами назначаются на уровне командного проекта и включают право на создание, удаление и просмотр запусков тестов, а также на управление тестовыми конфигурациями и средами. См. раздел Разрешения уровня проекта.

В. Какие и сколько узлов областей должна определить команда?

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

• Определяйте области в соответствии со своими требованиями к трассировке и безопасности.

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

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

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

• Создайте области, к которым требуется ограничить доступ.

В. Сколько узлов итераций должна определить команда?

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

• Используйте итерации для представления спринтов, вех или времени циклов для проекта.

• Определите продолжительность цикла, соответствующую командным процессам, и определяйте итерации в соответствии с этим циклом.

• Создайте отдельную итерацию, например, с подписью "Будущие" для рабочих элементов, которые вы еще не готовы назначить целевому циклу выпуска.

• Общие сведения о планировании спринта с помощью итераций см. в разделе Работа в спринтах.

В следующем примере для командного проекта MyApplication определены итерации "Невыполненная работа", "Бета 1", "Бета 2", "Выпуск 1.0" и "Выпуск 2.0". Все рабочие элементы, еще не запланированные к работе или не включенные в какой-либо выпуск, можно назначать итерации "Невыполненная работа".

MyApplication Невыполненная работа Бета 1 Бета 2 Выпуск 1.0 Выпуск 2,0

Создавая невыполненную работу по функциям продукта и задачам, можно начать назначать их вехам, к которым команда должна закончить работу над той или иной функцией или задачей. По мере изменения потребностей можно добавлять события внутри каждой основной вехи, отражающие график работы и успеваемость команды. Как показано в следующем примере, итерация "Бета 1" теперь содержит пять дочерних узлов — по одному для каждого спринта в период времени, отведенный на работу над бета-версией 1.

MyApplication Невыполненная работа    Бета 1 Спринт 1 Спринт 2 Спринт 3 Спринт 4 Спринт 5    Бета 2    Выпуск 1.0    Выпуск 2,0

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

В. Существует ли способ отделить команду от пути к области команды?

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

В. Можно ли экспортировать путь к области и путь итерации?

О. Нет. Экспортировать древовидную структуру путей для одного командного проекта с целью использования с другим командным проектом невозможно.