Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Оптимизируйте производительность команды, настроив рабочие процессы рабочих элементов в соответствии с вашими уникальными бизнес-процессами. Каждый тип рабочего элемента (WIT) включает предопределенный рабочий процесс, который отслеживает состояние работы от создания до завершения. Пользовательские состояния позволяют согласовать рабочие процессы Azure DevOps с установленными практиками команды, нормативными требованиями и стандартами организации.
Распространенные настройки рабочего процесса:
- Управление ошибками: добавление таких состояний, как Рассмотрено, В процессе исследования, или Подтверждено клиентом
- Разработка функций: включение проверки дизайна, разработки, проверки кода или утверждения заинтересованных лиц
- Рабочие процессы соответствия требованиям: добавление проверки безопасности, юридической проверки или завершения аудита
В этой статье показано, как настроить тип рабочего элемента ошибки, чтобы включить триажное состояние. Поля состояния и причины отображаются в заголовке формы рабочего элемента для простого доступа и видимости состояния.
Подсказка
См. YAML против классических конвейеров для ознакомления с рабочими процессами DevOps по сборке и релизу.
Внимание
Модель процесса наследования доступна для проектов, настроенных для поддержки типа модели. Если вы используете старую коллекцию, проверьте совместимость модели процесса. Если локальная коллекция настроена на использование локальной модели xml-процессов, можно использовать только эту модель процесса для настройки интерфейса отслеживания работы. Дополнительные сведения см. в разделе "Настройка процесса на уровне организации".
Поддерживаемые настройки
Рабочий процесс любого типа рабочего элемента (WIT) можно настроить, скрывая унаследованные состояния или добавляя пользовательские состояния. Унаследованные состояния зависят от системного процесса, используемого для создания пользовательского процесса: Agile, Basic, Scrum или Capability Maturity Model Integration (CMMI). Дополнительные сведения см. в разделе "Состояния рабочего процесса", "Переходы" и "Причины".
Рабочий процесс по умолчанию для каждого WIT определяет между двумя и четырьмя состояниями и задает следующие операции рабочего процесса:
- Переходы вперед и назад между каждым из состояний. Например, основной процесс Issue WIT включает три состояния: Делать, Делать, и Готово.
- Причины по умолчанию для каждого перехода состояния.
Унаследованные и пользовательские рабочие процессы должны соответствовать следующим правилам:
- Определите по крайней мере два состояния рабочего процесса.
- Определите хотя бы одно состояние для категорий предлагаемых иливыполняемых состояний.
- Определите не более 32 состояний рабочего процесса на тип рабочего элемента.
Примечание.
Перед добавлением настраиваемого состояния рабочего процесса см. сведения о состояниях рабочего процесса в бэклогах и на досках, чтобы узнать, как состояния рабочего процесса сопоставляются с категориями.
Сведения о настройке наследуемого и настраиваемого состояния рабочего процесса см. в следующих ресурсах:
Унаследованные состояния
Пользовательские состояния
- Добавление состояния рабочего процесса
- Изменение состояния рабочего процесса
- Удаление состояния рабочего процесса
- Добавление правил при изменении состояния рабочего процесса
Ограничения
- Вы не можете изменить имя, цвет или категорию унаследованных состояний, но их можно скрыть, если вы не хотите, чтобы они отображались.
- Невозможно изменить имена пользовательских состояний после их определения.
- Невозможно изменить или настроить имена категорий состояний по умолчанию.
- В категории завершенных состояний может существовать только одно состояние. Добавление настраиваемого состояния в эту категорию удаляет или скрывает любое другое состояние в этой категории.
- Нельзя указать настраиваемые причины для переходов состояния. Используйте причины по умолчанию, такие как перемещение в состояние Triaged и перемещение из состояния Triaged.
- Невозможно изменить размещение полей "Состояние и причина " в форме рабочего элемента.
Понимание организации и поведения состояния
Категории состояний и прогрессирование рабочих процессов
Azure DevOps упорядочивает состояния в четыре функциональные категории, определяющие поведение рабочего процесса:
| Категория | Цель | Примеры | Поведение |
|---|---|---|---|
| Предложено | Начальные этапы работы, планирование | Новое, Утверждено, Сортировано | Отправная точка для новых рабочих элементов |
| В процессе | Активные этапы работы | Активный, зафиксировано, расследуется | Указывает, что ведется работа |
| Решено | Завершенная работа ожидает проверки | Разрешено, исправлено, готово к тестированию | Завершение работы, ожидание проверки |
| Завершено | Окончательные состояния для готовой работы | Готово, закрыто, удалено | Состояния терминала, работа полностью завершена |
Последовательность выпадающего меню "Состояние".
Состояния отображаются в раскрывающихся меню в соответствии с порядком, заданным в каждой категории. Первое состояние в предлагаемой категории автоматически становится значением по умолчанию для новых рабочих элементов.
Принципы упорядочивания состояния:
- Логическая последовательность: расположите состояния в порядке, которому обычно следуют команды.
- Частота использования: более часто используемые состояния располагаются выше в списке
- Визуальная ясность: Рассмотрим, как порядок состояния влияет на пользовательский опыт
В следующем примере показано, как конфигурация последовательности состояний влияет на пользовательский интерфейс:
Возможности управления состояниями:
- Изменение порядка настраиваемых состояний в категориях с помощью перемещения вверх или перемещения вниз
- Не удается изменить порядок системных (унаследованных) состояний
- Изменения влияют на все команды, использующие шаблон процесса.
Управление эффектами изменений рабочего процесса
Понимание того, как изменения рабочих процессов влияют на команды, помогают эффективно планировать реализацию и координировать обновления.
Требования к конфигурации платы
Необходимо обновить конфигурации досок в Teams при выполнении этих настроек:
Изменения, связанные с государством, требующие обновления совета директоров
| Тип изменения | Эффект | Требуемое действие |
|---|---|---|
| Добавление настраиваемого состояния | Новый столбец, необходимый на досках | Настройка сопоставления столбцов |
| Изменение категории состояния | Изменения поведения состояния | Просмотр и настройка столбцов |
| Скрыть унаследованное состояние | Столбец может стать неверным | Переназначение столбцов |
| Добавьте WIT в бэклог | Новые рабочие элементы отображаются на досках | Настройка параметров доски |
Подробные инструкции см. в разделе Настройка бэклогов и досок.
Рекомендации по спринту и доске задач
Изменения рабочего элемента задачи:
- Добавление состояний в Task WIT создает новые столбцы панели задач
- Изменения влияют на планирование спринтов и ежедневные совещания.
- Рассмотрите влияние на отслеживание и отчетность скорости команды
Интеграция отслеживания ошибок:
- При отслеживании ошибок с задачами изменения состояния WIT влияют на панель задач
- Согласование состояний ошибок и задач минимизирует сложность доски
- Согласованные состояния улучшают отчеты по рабочим элементам
Рекомендации по управлению изменениями
Планирование предварительной реализации:
- Согласование с заинтересованными сторонами: Утверждение изменений рабочего процесса с затронутыми командами
- Оценка изменений: определение всех команд и проектов с помощью процесса
- Координация временной шкалы: планирование изменений в периоды низкой активности
- Стратегия коммуникации. Разработка четких уведомлений об изменениях
Поддержка после реализации:
- Пересмотр документации: обновление документации процесса команды
- Подготовка к обучению: помощь командам понять новые варианты рабочего процесса
- Мониторинг и обратная связь. Отслеживание внедрения и сбор предложений по улучшению
- Устранение проблем: быстро устранять проблемы конфигурации
Подготовка отката:
- Документируйте текущее состояние перед изменениями
- Планирование взаимодействия для любых необходимых откатов
- Поддержка документации по резервному копированию предыдущих конфигураций
Подсказка
Вы можете использовать ИИ, чтобы помочь с этой задачей позже в этой статье или ознакомиться с включение помощи ИИ в Azure DevOps MCP Server, чтобы начать работу.
Предварительные условия
Рекомендации по настройке Azure Boards для соответствия конкретным бизнес-требованиям см. в разделе Configure и настройка Azure Boards.
| Категория | Требования |
|---|---|
| Права доступа | — Для создания, удаления или изменения процесса: член группы администраторов коллекции проектов или наличие определенных разрешений на уровне коллекции, таких как "Создание процесса", "Удаление процесса", "Редактирование процесса"или "Удаление поля из организации", установленные на "Разрешить". Дополнительные сведения см. в разделе "Настройка наследуемого процесса". — Чтобы обновить доски: администратор команды или участник группы администраторов проектов. |
| Доступ | — Даже если у вас есть базовый или низкий доступ, вы все равно можете изменить процесс, если кто-то дает вам разрешение. — Чтобы участник проекта мог обновить и изменить тип существующих рабочих элементов. |
| Модель процесса проекта | — Иметь модель процесса наследования для коллекции проектов, содержащей проект. — Чтобы перенести данные в службы Azure DevOps, используйте службу импорта базы данных Team Foundation Server Import Service. |
| знания | — знакомство с моделями настройки и обработки. |
Открытие параметров процесса организации
Войдите в свою организацию (
https://dev.azure.com/{yourorganization}).Выберите
Параметры организации.
Выберите Обработать.
Войдите в свою коллекцию (
https://dev.azure.com/{Your_Collection}).Выберите параметры коллекции или параметры администратора.
Выберите Обработать.
Примечание.
При настройке унаследованного процесса все проекты, использующие процесс, автоматически отражают настройки. Чтобы обеспечить плавный переход, рекомендуется создать тестовый процесс и проект для тестирования настроек перед их реализацией на уровне организации. Дополнительные сведения см. в разделе "Создание унаследованных процессов и управление ими".
Добавление состояния рабочего процесса
Расширьте типы рабочих элементов с настраиваемыми состояниями, которые отражают уникальные этапы процесса вашей команды. Добавление состояний позволяет лучше отслеживать, очищать визуализацию состояния и улучшать выравнивание рабочих процессов с бизнес-требованиями.
Стратегическое планирование новых государств
Прежде чем добавлять состояния, рассмотрите потребности рабочего процесса вашей команды:
Оцените существующие пробелы:
- Определите этапы процесса, которые не отражены текущими состояниями
- Определите, могут ли существующие состояния быть перепрофилированы вместо добавления новых.
- Рассмотрим, как новые состояния интегрируются в установленные практики команды
Характеристики состояния плана:
- Принципы именования: используйте понятные имена, ориентированные на действия, которые понимают команды
- Выравнивание категорий: выберите категории, соответствующие цели рабочего процесса штата.
- Различие визуальных элементов: выбор цветов, которые повышают четкость рабочего процесса
Интеграция состояний и автоматические переходы
При добавлении состояния:
- Доступность выпадающего списка: состояние отображается в поле "Состояния" в формах рабочих элементов и в редакторе запросов
- Автоматические переходы: двунаправленные переходы в все существующие состояния создаются автоматически.
- Причины по умолчанию: системные причины перехода, такие как перемещение в состояние [StateName] и перемещение из состояния [StateName]
Добавление пользовательского состояния рабочего процесса
Перейдите к конфигурации состояния. На странице "Типы рабочих элементов" выберите тип рабочего элемента, который нужно изменить, выберите "Состояния" и выберите "Создать состояние".
Подсказка
Если параметр "Создать состояние" отключен, у вас нет необходимых разрешений для изменения процесса. См. раздел "Настройка наследуемого процесса".
Настройте свойства состояния: введите подробные сведения о состоянии:
- Имя: используйте четкие, описательные имена (например, "Проверка кода", "Тестирование", "Утверждение клиента")
- Категория. Выберите соответствующий этап рабочего процесса (см. статью "Категории состояния " для подробных описаний)
- Цвет: выбор цветов, которые улучшают визуализацию рабочего процесса команды
Внимание
Добавление состояний в категории «Выполняется» или «Разрешено» автоматически обновляет поля Активировано кем/Дата активации и Разрешено кем/Дата разрешения при перемещении рабочих элементов в эти категории или из них. Дополнительные сведения см. в разделах «Активировано/По дате» и «Разрешено/По дате».
Сохраните конфигурацию: нажмите кнопку "Сохранить", чтобы создать состояние. Указанный цвет отображается на платформе, включая формы рабочих элементов, невыполненные работы, доски и результаты запроса.
Оптимизация последовательности состояний (необязательно): чтобы улучшить взаимодействие с пользователем в раскрывающихся меню, настройте порядок состояния:
- Выберите значок контекстного
меню - Выберите "Переместить вверх" или "Переместить вниз", чтобы поместить состояние соответствующим образом в ее категорию
- Выберите значок контекстного
Проверьте реализацию: тщательно проверьте новое состояние:
- Обновите браузер, чтобы убедиться, что изменения загружены
- Открытие рабочего элемента настраиваемого типа
- Убедитесь, что состояние отображается в раскрывающемся меню с правильным цветом и расположением
Пример раскрывающегося меню "Состояние" с состоянием Triaged:
Проверка после реализации
- Убедитесь в переходах состояний: рабочие элементы должны перемещаться в новое состояние и из него должным образом, как и ожидалось.
- Проверка эффектов отчетов: убедитесь, что запросы, панели мониторинга и отчеты работают правильно с новым состоянием
- Мониторинг внедрения. Отслеживание использования нового состояния командами и сбор отзывов для оптимизации
Примечание.
Команды, использующие доски, должны обновлять параметры столбца при добавлении состояний в типы рабочих элементов, связанные с уровнями невыполненной работы. Подробные рекомендации по управлению изменениями см. в разделе "Управление эффектами ".
Изменение состояния
Точно настройте пользовательские состояния рабочего процесса для оптимизации производительности команды и поддержания четкой визуальной организации. Изменение существующих состояний обеспечивает экономичный способ улучшения рабочего процесса без нарушения установленных процессов.
Когда редактировать и когда создавать новые состояния
Измените существующее состояние, когда:
- Текущее имя состояния точно представляет этап рабочего процесса
- Необходимо настроить, как ведет себя состояние в вашем процессе (изменение категории)
- Визуальное представление должно обновляться для повышения четкости
- Вы хотите перенастроить функционал состояния, не нарушая существующие элементы работы
Создайте новое состояние, когда:
- Существующее имя состояния не соответствует терминологии рабочего процесса
- Вам нужен более детализированный уровень в вашем процессе.
- Текущие состояния не охватывают все этапы, необходимые для рабочего процесса
Редактируемые свойства
| Недвижимость | Description | Эффект |
|---|---|---|
| Категория штата | Определяет поведение и положение состояния в рабочем процессе | Изменение функций состояния в досках, запросах и отчетах |
| Цвет состояния системы | Визуальный идентификатор на платформе | Обновление внешнего вида во всех интерфейсах Azure DevOps |
Неизменяемые свойства
- Имя состояния: постоянный после создания (учитывайте назначение состояния во время первоначального создания)
- Системные состояния: не удается изменить состояния Azure DevOps по умолчанию, только скрытые
Изменение настраиваемого состояния
Перейдите к состоянию: на странице "Типы рабочих элементов" выберите тип рабочего элемента, а затем выберите "Состояния".
Открыть диалоговое окно редактирования: выберите "Изменить" в ... контекстное меню для целевого состояния.
Настройка свойств:
- Категория: выберите соответствующий этап рабочего процесса (дополнительные сведения см. в разделе "Категории состояния ")
- Цвет: выберите цвета, которые соответствуют визуальным соглашениям вашей команды
Применить изменения: нажмите кнопку "Сохранить", чтобы реализовать изменения.
Проверьте изменения:
- Открытие рабочего элемента измененного типа
- Проверьте отображение состояния с правильными цветом и категорией.
- Убедитесь, что переходы состояния работают должным образом
Управление эффектами изменений
Немедленные действия, необходимые
Для изменений категорий требуется:
- Обновление конфигураций столбцов доски для всех затронутых команд
- Обмен данными об изменениях для участников группы и заинтересованных лиц
- Убедитесь, что автоматизированные процессы по-прежнему работают правильно
Требуются изменения цвета:
- Обновление документации группы, которая ссылается на цветовую кодировку
- Сообщите пользователям о новом визуальном представлении
- Проверка ясности панели мониторинга и отчета с новыми цветами
Другие вопросы
- Изменения категорий: может потребоваться восстановление предыдущих конфигураций платы при необходимости отката системы
- Изменения цвета: легко обратимо без эффекта рабочего процесса
- Документация. Обновление любой документации команды, ссылающейся на старый цвет или категорию
Подсказка
Следуйте рекомендациям по управлению комплексными изменениями , описанными ранее, чтобы обеспечить оптимальные результаты.
Скрытие или удаление настраиваемого состояния
Прежде чем скрывать или удалять состояние, ознакомьтесь с последствиями существующих рабочих элементов и рабочих процессов команды.
Последствия скрытия или удаления состояний
При скрытии или удалении состояния:
- Выпадающее меню состояния: состояние больше не отображается в меню "Состояние" для типа рабочего элемента
- Журнал рабочих элементов: изменения в существующих записях журнала рабочих элементов не происходят
- Существующие рабочие элементы: рабочие элементы в скрытом или удаленном состоянии становятся недействительными, но сохраняют их значение состояния
- Будущие изменения: перед внесением изменений в затронутые рабочие элементы необходимо обновить значение состояния.
Обработка затронутых рабочих элементов
Перед скрытием или удалением состояния:
- Определение затронутых элементов: создайте запрос, чтобы найти все рабочие элементы в текущем состоянии, которое вы планируете скрыть или удалить
- Планируйте переходы: определите, в какое допустимое состояние следует перемещать эти рабочие элементы
- Массовое обновление: используйте массовое изменение, чтобы переместить все затронутые рабочие элементы в допустимое состояние.
- Проверка изменений. Подтверждение успешного обновления всех рабочих элементов
Варианты восстановления
- Состояние восстановления. При добавлении скрытого или удаленного состояния обратно в тип рабочего элемента затронутые рабочие элементы автоматически возвращаются к допустимому состоянию.
- Координация группы: уведомлять команды о изменениях состояния, чтобы предотвратить путаницу во время обновлений рабочих элементов
Скрытие или отмена наследуемого состояния
Оптимизируйте рабочий процесс вашей команды, скрывая унаследованные состояния, которые не соответствуют процессу вашей команды. Этот подход удаляет неиспользуемые состояния из раскрывающихся меню при сохранении системных функций.
Когда следует скрывать унаследованные состояния
Скрытие унаследованных состояний, когда:
- Рабочий процесс вашей команды не использует определенные состояния по умолчанию
- Вы хотите упростить выбор состояния в раскрывающихся меню
- Некоторые состояния создают путаницу или не соответствуют терминологии процесса
Важные ограничения
Перед скрытием состояний убедитесь, что вы:
- Обеспечение покрытия категорий: сохраняйте как минимум одно состояние для каждой категории (предлагается, в работе, решено, завершено)
- Проверьте существующие рабочие элементы: уточните, используют ли какие-либо рабочие элементы состояние, которое вы планируете скрыть.
- Координация с командами: уведомление команд с помощью затронутых досок о предстоящих изменениях
Скрытие унаследованного состояния
Откройте ... контекстное меню для состояния, которое вы хотите скрыть, и выберите параметр "Скрыть".
В этом примере скрыто состояние "Разрешено" для багов типа WIT.
Внимание
Если вы скрываете состояния для типов рабочих элементов, отслеживаемых на досках, команды должны обновить параметры столбца. См. инструкции по управлению эффектами .
Проверьте изменение, проверив, что скрытое состояние больше не отображается в раскрывающихся меню формы рабочего элемента.
Отмена наследуемого состояния
Если необходимо восстановить скрытое состояние:
- Откройте ... контекстное меню для скрытого состояния и выберите параметр Unhide.
- Убедитесь, что состояние снова появится в раскрывающихся меню и доступно для использования.
- При необходимости обновите настройки командной доски, чтобы включить восстановленное состояние.
Удаление настраиваемого состояния
Откройте ... контекстное меню для состояния, которое нужно удалить, и нажмите кнопку "Удалить". Вы можете удалить только настраиваемое состояние.
В диалоговом окне "Удалить состояние" нажмите кнопку "Удалить".
Просмотрите модель состояния рабочего процесса
Визуализируйте пользовательские состояния рабочего процесса и переходы с помощью расширения Marketplace Визуализация модели состояния. Это расширение предоставляет графическое представление рабочих процессов для типов элементов работы.
Установка и доступ к расширению
- Установите расширение визуализации модели состояния из Visual Studio Marketplace.
- ** Перейдите к визуализатору состояния досок > в проекте Azure DevOps.
- Выберите тип рабочего элемента, чтобы отобразить модель состояния рабочего процесса.
Функции
Визуализатор состояния предоставляет следующие возможности:
- Схема визуального рабочего процесса: просмотр всех состояний и разрешенных переходов
- Интерактивная навигация: увеличение, уменьшение масштаба и панорамирование по диаграмме
- Настраиваемый макет: перетаскивание и изменение положения узлов состояния для оптимального просмотра
- Сведения о переходе состояния: просмотрите все возможные переходы состояния в одном месте
Например, если вы настраиваете рабочий процесс для багов, чтобы включить состояние 'Триаж', визуализатор показывает, как все состояния могут переходить друг в друга и возвращаться, предоставляя четкий обзор вашего проектирования рабочего процесса.
Примечание.
Azure Boards и команда разработчиков не поддерживают расширение визуализации модели состояния. Для вопросов, предложений или проблем посетите страницу расширения.
Использование искусственного интеллекта для настройки рабочих процессов
Подсказка
Вы можете использовать ИИ, чтобы помочь с этой задачей позже в этой статье или ознакомиться с включение помощи ИИ в Azure DevOps MCP Server, чтобы начать работу.
Если вы используете GitHub Copilot, Azure DevOps MCP Server поможет вам разработать, добавить и управлять состояниями рабочих процессов для унаследованных процессов с помощью запросов естественного языка.
Примеры запросов на настройку рабочего процесса
| задачи | Пример запроса |
|---|---|
| Разработка пользовательского рабочего процесса | Design a workflow for my Bug work item type that adds 'Triaged', 'In Code Review', and 'Ready for Test' states between New and Closed. Map each to the correct state category and explain the board column impact |
| Добавление шлюза качества обслуживания в рабочий процесс | Add a 'QA Approved' state to my User Story work item type in the Resolved category. Configure it so stories must pass through QA Approved before they can move to Done, and explain how this affects my Kanban board |
| Скрытие устаревших состояний | We no longer use the 'On Hold' state for Tasks but have historical data in that state. Walk me through hiding the state so it doesn't appear as an option while preserving existing work items |
| Перенос рабочих процессов между процессами | I customized the Bug workflow in my 'TeamAlpha-Agile' process and want the same states in my 'TeamBeta-Agile' process. List the states I added and the steps to recreate them in the second process |
| Визуализация модели состояния | Show me all the states and transitions for the User Story work item type in my inherited process, organized by state category. Include which transitions are allowed and which are restricted by rules |
| Устранение неполадок несовпадения столбцов доски | My Kanban board columns don't match my workflow states after I added custom states. Help me understand the relationship between state categories and board columns, and fix the mapping |
Подсказка
Для получения наилучших результатов используйте эти запросы в режиме агента с подключенным сервером MCP Azure DevOps. Настройте запросы с определенным именем процесса, типами рабочих элементов или требованиями к рабочему процессу.