Настройка интерфейса отслеживания работы

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

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

В этой статье приведены общие сведения о доступных настройках и их разности в трех моделях процессов. Конкретные рекомендации по настройке для поддержки бизнес-решений см. в статье "Настройка и настройка досок Azure". Дополнительные сведения см. в статье "Что такое Azure Boards?" и "Сведения о рабочих элементах".

Общие сведения о уровнях настройки

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

• Общие ресурсы на уровне проекта: определение областей и путей итерации, которые команды выбирают для настройки журналов задач и досок. Общие запросы и теги рабочих элементов — это другие объекты, которые после определения можно совместно использовать в проекте.
• Ресурсы команды или инструменты: каждая команда может настроить свои собственные инструменты, такие как бэклоги, доски и панели мониторинга. Дополнительные сведения см. в разделе "О командах и средствах Agile".
• Разрешения на уровне проекта и объектов: управление доступом к средствам отслеживания работы, включая настройку разрешений для объектов и проекта и назначение пользователей или групп определенным уровням доступа.
• Настройка процесса на уровне организации: настройка полей, типов рабочих элементов, заданий в очереди и досок, доступных всем командам.

Область настройки и влияние

Понимание области каждого уровня настройки помогает принимать обоснованные решения:

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

Общие ресурсы уровня проекта

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

Основные общие ресурсы

Следующие общие ресурсы формируют основу отслеживания работы в проекте:

• Пути к областям: организация рабочих элементов по функциональной области или области ответственности команды
• Пути итерации: определение спринтов и выпусков для планирования и отслеживания
• Общие запросы: создание повторно используемых запросов, к которым могут получить доступ все участники команды.
• Теги рабочих элементов: добавление метаданных для классификации и фильтрации
• Группы безопасности. Управление разрешениями на доступ в проекте

Дополнительные сведения см. в следующих статьях:

• Сведения о областях и путях итерации
• Установка путей областей
• Изменение списка выбора для пути итерации
• Создание и изменение запросов
• Добавление тегов в рабочие элементы

Лучшие практики для совместных ресурсов

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

Поля выбора людей и идентификации

Функция выбора пользователей поддерживает поля идентификации во всех компонентах Azure DevOps.

• Поле "Назначенный кому" и другие идентификационные поля используют функцию 'Выбор участников'.
• Активация: При выборе поля Назначенный кому в форме рабочего элемента средство выбора пользователей активируется автоматически.
• Выбор пользователя. Чтобы выбрать пользователя, начните вводить свое имя и поиск, пока не найдете совпадение.
• Последние выборы. Ранее выбранные пользователи автоматически отображаются в списке для быстрого доступа.
• Интеграция каталогов: для организаций с помощью идентификатора Microsoft Entra или Active Directory пользователи могут выполнять поиск всех пользователей и групп, добавленных в каталог (а не только тех, которые добавлены в конкретный проект).
• Ограничение области действия: Чтобы ограничить область идентификаторов, доступных для выбора пользователям, принадлежащим к проекту, используйте группу Project-Scoped Users.
• Настраиваемые ограничения: Индивидуальные правила могут дополнительно ограничить доступные значения для полей идентификации в рабочем элементе.

Конфигурация поля идентификаций

Поля удостоверений можно настроить несколькими способами:

• Пользователи с проектным доступом: ограничение выбора идентификаторов только участникам проекта
• Пользовательские правила. Реализация бизнес-правил, ограничивающих значения полей
• Ограничения, основанные на группах: Используйте группы Azure AD для управления доступными удостоверениями
• Разрешения на уровне поля: Установка прав для пользователей, которые могут изменять поля удостоверений.

Дополнительные сведения см. в следующих статьях:

• Добавьте пользователей или групп Active Directory / Microsoft Entra в встроенную группу безопасности.

• Ограничение поиска личностей.

Настройка процесса на уровне организации

Проект определяет типы рабочих элементов (WIT), доступные для отслеживания работы и настраивает средства Agile. Он задает пользовательские истории, задачи, ошибки и поля данных, используемые для сбора информации. Настраиваемые объекты совместно используются между командами в проекте.

Примечание.

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

• Наследование: поддерживается WYSIWYG-настройка, доступная в Azure DevOps Services, Azure DevOps Server 2019 и Azure DevOps Server 2020.
• Размещенный XML: поддерживает настройку с помощью импорта и экспорта шаблонов процессов, доступных для выбранного количества клиентов Azure DevOps Services, которые выбрали эту модель.
• Локальный XML: поддерживает настройку путем импорта и экспорта файлов определения XML для объектов отслеживания работы и доступен для всех локальных развертываний.

Сравнение моделей процессов

В следующей таблице перечислены различия между тремя поддерживаемыми моделями процессов. Для определения основных объектов отслеживания работы см. глоссарий Agile. Ссылки на статьи по настройке см. в кратком справочнике по параметрам Azure Boards.

---

Функция

Наследование

XML на хостинге

Локальный XML

---

Редактирование в режиме визуального редактора (WYSIWYG)

✔️

---

Создание унаследованных пользовательских процессов, наследование изменений в системных процессах (Agile, Basic, Scrum, CMMI)

✔️

---

Создание пользовательских шаблонов процессов (см. примечание 1)

✔️

✔️

---

Обновленные изменения процесса автоматически применяются ко всем проектам, ссылающимся на процесс.

✔️

✔️

---

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

✔️

✔️

✔️

---

Поддержка настройки типов ссылок, полей группы, глобального рабочего процесса и конфигурации процессов (см. примечание 3).

✔️

---

Начальная конфигурация областей, сценариев итерации, запросов рабочих элементов, групп безопасности и разрешений (см. примечание 3).

✔️

✔️

---

Глобальные списки

Списки выбора

(см. примечание 2)

✔️

---

Использование az boards средств командной строки для редактирования проектов и команд и сведений о списке

✔️

✔️

✔️

---

Используйте инструменты командной строкиwitadmin для перечисления и экспорта сведений о процессе

✔️

✔️

✔️

---

REST API (чтение)

✔️

✔️

✔️

---

REST API (запись)

✔️

✔️

(см. примечание 5)

---

Руководство по выбору модели обработки

Выберите модель процесса в зависимости от потребностей вашей организации:

Модель процесса наследования (рекомендуется)

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

Модель XML-процесса на размещённом сервере

• Лучше всего: организации с сложными требованиями к процессу
• Преимущества: полный контроль над шаблоном процесса, широкие возможности настройки
• Используйте, когда: вам нужна расширенная настройка процесса, но при этом необходимо размещение в облаке

Локальная модель XML-процесса

• Лучше всего: локальные развертывания с требованиями полного управления
• Преимущества: полная гибкость настройки, корпоративная интеграция
• Используйте, когда: вам нужен максимальный контроль и управление локальной инфраструктурой

Примечания:

1. Процесс определяет строительные блоки, используемые для отслеживания работы. Шаблон процесса задает взаимозависимый набор xml-файлов определений, которые предоставляют стандартные блоки и начальную конфигурацию для отслеживания работы и других функциональных областей.
2. Настройка размещенного XML даёт возможность добавления и обновления глобальных списков в ходе обновления процесса (при условии соблюдения ограничения максимального размера каждого списка). Дополнительные сведения см. в разделе "Ограничения объектов отслеживания работы".
3. Модель наследуемого процесса не поддерживает настройку следующих функций, доступных при настройке шаблонов процессов. Вместо этого вы настраиваете эти области на веб-портале для каждого проекта отдельно.
   • Пути областей и итераций
   • Запросы рабочих элементов
   • Группы безопасности и разрешения
   • Разрешения и доступ к функциональным областям, таким как управление версиями и сборка
   Кроме того, можно использовать REST API или инструмент командной строки Azure DevOps.
4. Используйте REST API для импорта и экспорта шаблонов процессов.

Настройка тестового интерфейса

Несколько типов рабочих элементов поддерживают тестовый интерфейс на страницах веб-портала Test и клиенте Test Manager.

Настройка процесса наследования

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

• План тестирования: упорядочение наборов тестов и управление ими
• Test Suite: группировать связанные тестовые случаи
• Тестовый случай. Определение отдельных сценариев тестирования

Настройка локального XML

Для локального XML-процесса можно настроить все типы рабочих элементов, связанных с тестом, в том числе:

• План тестирования: высокоуровневая тестовая организация
• Test Suite: группирование вариантов тестирования
• Тестовый случай: отдельные определения тестов
• Общие шаги. Повторно используемые процедуры тестирования
• Общие параметры: параметризованные тестовые данные

Проверка связей рабочих элементов

В следующем примере показаны поддерживаемые связи между тестируемыми типами рабочих элементов:

Тестовые сценарии настройки

Ниже представлены распространенные настройки тестового интерфейса.

• Настраиваемые поля тестирования: добавление метаданных теста для конкретной организации
• Состояния тестового рабочего процесса: определение пользовательских состояний выполнения теста
• Отслеживание результатов теста: настройка отчетов о результатах теста
• Поля интеграции: связывание тестов с требованиями и дефектами

Менее распространенные настройки

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

Ограничения списка задач и доски задач (размещенный XML, локальный XML)

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

Это значение можно увеличить до 1500, указав значение для workItemCountLimit атрибута элемента TaskBacklog . Дополнительные сведения см. в справочнике по элементу XML-конфигурации процесса.

<TaskBacklog category="Microsoft.TaskCategory" pluralName="Tasks" singularName="Task" workItemCountLimit="800" >
    . . .
</TaskBacklog>

Аспекты производительности в контексте ограничений системной платы

При настройке ограничений доски следует учитывать:

• Влияние времени загрузки: более высокие ограничения могут увеличить время загрузки страницы
• Взаимодействие с пользователем: балансировка функциональности с производительностью
• Ограничения браузера. Некоторые браузеры обрабатывают большие наборы данных по-разному
• Пропускная способность сети: учтите участников команды с более медленными подключениями

Изменение назначений полей (размещенный XML, локальный XML)

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

Например, если вы измените назначение параметров refname на type="Activity", то необходимо включить то же поле в определение WIT, назначенное для категории задач, которая собирает информацию о деятельности. Дополнительные сведения см. в справочнике по элементу XML-конфигурации процесса.

Средства, использующие распределение полей

Назначенные поля используются следующими средствами:

Инструмент	Тип поля	Цель
Доска задач, инструменты для расчета емкости, сгорание спринта	Оставшаяся работа	Отслеживание завершения работы
Невыполненные работы по продуктам и портфелям	Приоритет невыполненной работы	Заказ рабочих элементов
Скорость и прогноз	Усилия (сопоставляется с точками истории, усилиями или размером)	Оценка размера работы
Инструменты управления емкостью	Действие (действие задачи или дисциплина)	Планирование возможностей команды

Рекомендации по назначению полей

• Обеспечение согласованности. Убедитесь, что назначения полей соответствуют определениям типов рабочих элементов
• Проверка изменений. Проверка правильности работы средств после переназначения полей
• Настройки документа: Запишите изменения назначения полей для будущего использования
• Рассмотрим влияние: понять, как изменения влияют на существующие данные и отчеты

Управление доступом к средствам отслеживания работы

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

Структура разрешений по умолчанию

Система разрешений работает с этими принципами:

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

Ограничения группы участников

Группа участников не позволяет пользователям автоматически выполнять следующие действия.

• Создание общих запросов: требуются дополнительные разрешения запроса
• Добавление путей области или итерации: необходимы административные разрешения на уровне проекта.
• Изменение параметров безопасности. Требуется административный доступ
• Настройка параметров группы: требуется роль администратора команды

Подход к управлению разрешениями

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

1. Начните с значений по умолчанию: используйте встроенные группы в качестве основы
2. Предоставление определенных разрешений: добавление разрешений для конкретных потребностей
3. Использование групп безопасности. Использование групп Azure AD для упрощения управления
4. Регулярные проверки: периодически проверяйте разрешения на предмет их уместности
5. Документирование решений: ведение записей о предоставленных разрешениях и обосновании

Упрощенный обзор распространенных разрешений по умолчанию и назначений доступа см. в разделе "Разрешения и доступ".

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

Определенные области разрешений

Сведения об управлении доступом к определенным функциям см. в следующих статьях:

---

Управление доступом

• Об уровнях доступа
• Добавление участников группы (Azure DevOps Services)
• Изменение уровней доступа (локальные развертывания)
• Добавление участников группы (локальные развертывания)

Разрешения

• Разрешения на уровне области
• Разрешения доступа
• Запросы рабочих элементов и разрешения папок
• Разрешения панели мониторинга
• Разрешения плана доставки
• Разрешения на добавление тегов
• Тестовые разрешения

Общие ресурсы

• Оповещения
• Областные пути
• Пути итерации
• Запросы
• Теги

---

Дополнительные параметры настройки

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

Расширения Маркетплейса

• Обзор решений. Ознакомьтесь с расширениями Marketplace , чтобы узнать, есть ли средство, доступное для ваших целей
• Популярные категории: поиск расширений в отслеживании работы, отчетах и управлении проектами
• Вклад сообщества. Преимущества решений, разработанных сообществом Azure DevOps

Настраиваемые параметры разработки

• Создание расширений: Разработка собственного расширения для конкретных потребностей организации
• Средства интеграции. Создание пользовательских интеграции с помощью REST API
• Перехватчики служб: Узнайте, соответствуют ли перехватчики служб вашим потребностям в автоматизации.

Взаимодействие с сообществом

• Запросы функций: добавление запроса функции на страницу сообщества разработчиков
• Отзывы пользователей. Поделитесь своими возможностями и предложениями с командой по продукту
• Рекомендации. Изучение подходов к настройке других организаций

Планирование стратегии настройки

Прежде чем реализовывать настройки, рассмотрите:

1. Бизнес-требования. Четко определите, что вы хотите достичь
2. Оценка влияния. Понимание того, как изменения влияют на существующие рабочие процессы
3. Затраты на обслуживание: учитывайте долгосрочные затраты на обслуживание настроек
4. Альтернативные решения. Оцените, соответствуют ли существующие функции вашим потребностям
5. Путь миграции. Планирование будущих обновлений и миграций

Следующие шаги

Настройка и кастомизация Azure Boards

Связанные статьи

• Индекс поля рабочего элемента
• Средство командной строки witAdmin
• Управление шаблонами процессов
• Общие сведения о шаблонах процессов
• Ограничения для отслеживания хода выполнения работы, процесса и проекта
• Краткий справочный индекс для параметров Azure Boards