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

Azure DevOps Services

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

Внимание

Эта статья относится только к модели процесса наследования в Azure DevOps Services. Сведения о настройке локальных проектов или обновлении XML-файлов определений см. в разделе "Размещенная модель XML-процесса " и "Настройка размещенного XML-процесса".

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

В этой статье представлен обзор способов настройки унаследованных процессов. Сведения об ограничениях на количество полей, WIT, уровней невыполненной работы и других объектов, которые можно настроить, см. в разделе "Отслеживание работы", "Процесс" и "Ограничения проекта".

Примечание.

Вы можете просмотреть изменения, внесенные в унаследованный процесс, с помощью журнала аудита и функций аудита. Дополнительные сведения см. в статьях "Доступ", "Экспорт" и "Фильтрация журналов аудита".

Системные и унаследованные процессы

Системные процессыAgile, Basic, Scrum и интеграция модели зрелости возможностей (CMMI) заблокированы, и пользователи не могут их изменить. Корпорация Майкрософт периодически владеет этими системными процессами и периодически обновляет их.

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

Все проекты в организации могут совместно использовать все процессы. Вы настраиваете этот процесс вместо настройки отдельных проектов.

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

В следующем примере показан список проектов в организации fabrikamprime и процесс использования каждого проекта. Чтобы изменить настройки проекта Fabrikam Fiber, измените процесс My Agile, который наследует от процесса системы Agile. Изменения, внесенные в процесс My Agile, также обновляют проект Agile by Design, который использует этот процесс. Чтобы настроить другие проекты, необходимо изменить их для использования унаследованных процессов.

Снимок экрана: проекты и используемые процессы.

Изменение процесса существующего проекта

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

Следуя общим рекомендациям в перечисленных статьях, вы можете внести другие изменения, такие как переход от CMMI к Agile или от Agile к CMMI. Перед изменением процесса проекта ознакомьтесь с процессом, на который вы меняетесь. Дополнительные сведения см. в разделе "Сведения о процессах и шаблонах процессов".

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

Изменение или переименование унаследованного процесса

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

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

Имена процессов

Имена процессов имеют следующие требования:

  • Должен быть уникальным в организации
  • Должен содержать 128 символов Юникода или меньше
  • Не может содержать ни одного из следующих символов: .,;':~\/*|?"&%$!+=()[]{}<>

Унаследованные и настраиваемые объекты

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

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

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

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

В этом разделе описываются поля рабочих элементов.

Поля и ссылки на поля

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

Для описания и использования каждого поля, определенного для основных процессов системы Scrum, Agile и модели зрелости возможностей (CMMI), см. Индекс полей рабочих элементов.

Имена полей

Имя поля рабочего элемента однозначно определяет каждое поле рабочего элемента. Убедитесь, что имена полей соответствуют следующим требованиям:

  • Должен быть уникальным в пределах организации или коллекции проектов.
  • Должно быть 128 символов Юникода или меньше
  • Должен содержать по крайней мере один алфавитный символ
  • Не должно содержать начальных или конечных пробелов, а также двух или более подряд идущих пробелов
  • Не может содержать ни одного из следующих символов: .,;':~\/*|?"&%$!+=()[]{}<>

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

Настройки полей

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

Вы можете добавить любое настраиваемое поле, определенное для WIT в одном процессе, в любой WIT, определенный для другого процесса. Вы также можете добавить существующее поле в другой WIT в рамках того же процесса. Например, можно добавить дату сдачи в User Story или в Баг WITs.

Настройка полей и элементов управления

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

Унаследованные поля

Настраиваемые поля

Пользовательский элемент управления

Удаление или восстановление удаленных полей

Вы можете удалить поле и позже восстановить его. При удалении поля удаляются все данные, связанные с этим полем, включая исторические значения. После удаления вы можете восстановить только поле и данные с помощью REST API Fields - Update.

Вместо удаления поля можно скрыть или удалить поле из формы рабочего элемента. Дополнительные сведения см. в разделе "Показать", "Скрыть" или "Удалить поле".

Ограничения

  • Не удается изменить имя поля или тип данных после его определения. Однако вы можете изменить метку, которая отображается для поля в форме рабочего элемента на вкладке "Макет ". При выборе поля в запросе необходимо использовать имя поля, а не метку поля.
  • Не удается изменить серую область в форме, содержащей поля пути состояния, причины, области и пути итерации .
  • Списки выбора путей области и путей итерации настраиваются для каждого проекта и не могут быть изменены через унаследованный процесс.
  • Списки выбора, связанные с полями идентификации пользователя, например Назначено и Изменено кем, заполняются на основе пользователей, добавленных в проект или команду.
  • Для каждого WIT можно определить не более 64 полей, а для каждого процесса можно определить не более 512 полей.
  • Невозможно импортировать или определить глобальный список, поддерживаемый моделями процессов РАЗМЕЩЕННОГО XML и локального XML.

Пользовательские правила и системные правила

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

Например, несколько правил копируют текущее удостоверение пользователя в поле "Изменено" при изменении рабочего элемента или в поле "Закрыто", когда состояние рабочего процесса изменяется на "Закрыто" или "Готово". Предопределенные системные правила имеют приоритет над любыми пользовательскими правилами, которые перезаписывают их.

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

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

  • Если для параметра Priority определено значение, сделайте обязательным полем риска .
  • При изменении значения Release очистите значение Milestone.
  • При внесении изменений в значение оставшейся работы сделайте поле "Завершенная работа " обязательным полем.
  • Если значение Утверждено равно True, сделайте Кем утверждено обязательным полем.
  • При создании истории пользователя необходимо указать поля "Приоритет", " Риск" и " Усилия ".

Дополнительные сведения об определении настраиваемых правил см. в статье "Добавление правила в тип рабочего элемента (процесс наследования)".

Совет

Невозможно определить формулу с помощью правила. Однако с помощью Power Automate вы можете найти решение, которое соответствует вашим потребностям. Дополнительные сведения см. в разделе "Сводка работы и других полей".

Ограничение изменения полей выбора для выбранных групп пользователей

С помощью условий current user is a member of a group... или current user is not a member of a group... можно требовать или настраивать выбранные поля для пользователей, которые являются участниками или не участниками группы или группы безопасности. Например, можно сделать заголовок или поле "Состояние " только для чтения для выбранных пользователей или групп.

Ограничить возможность изменения рабочих элементов в зависимости от пути области

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

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

Настройки типов рабочих элементов

В следующих ресурсах описаны параметры настройки для наследуемого и настраиваемого WIT.

Унаследованные типы рабочих элементов

Пользовательские типы рабочих задач

Изменение WIT по умолчанию для невыполненной работы приводит к отображению WIT по умолчанию на панели быстрого добавления. Например, Custom Story по умолчанию отображается на следующей панели быстрого добавления для бэклога продукта.

Снимок экрана: панель быстрого добавления с типом пользовательского рабочего элемента по умолчанию.

Ограничения

  • Невозможно добавить или удалить унаследованный WIT из бэклога.
  • Невозможно изменить положение унаследованного поля в макете формы. Однако вы можете скрыть поле в одной области формы и добавить его в другое место в форме.
  • Вы не можете изменить имя пользовательского WIT после его определения.

Настройки формы рабочего элемента

Вы можете настроить следующие настройки в форме WIT:

Унаследованные группы

Пользовательские группы

Унаследованные страницы

Пользовательские страницы

Макет и изменение размера

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

Иллюстрация макета страницы с тремя столбцами для формы рабочего элемента.

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

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

По мере уменьшения ширины отображения столбцы изменяются пропорционально следующим образом:

  • Для трех столбцов: 50%, 25 %, а также 25 %
  • Для двух столбцов: 66% и 33%
  • Для одного столбца: 100%

Настройки рабочего процесса

Рабочий процесс любого типа рабочего элемента (WIT) можно настроить, скрывая унаследованные состояния или добавляя пользовательские состояния. Унаследованные состояния зависят от системного процесса, используемого для создания пользовательского процесса: Agile, Basic, Scrum или интеграции модели зрелости возможностей (CMMI). Дополнительные сведения см. в разделе "Состояния рабочего процесса", "Переходы" и "Причины".

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

  • Прямые и обратные переходы между каждым состоянием. Например, базовый процесс WIT Задача включает три состояния: "Делать", "В процессе", и "Готово".
  • Причины по умолчанию для каждого перехода состояния.

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

  • Определите по крайней мере два состояния рабочего процесса.
  • Определите хотя бы одно состояние для категорий предлагаемых иливыполняемых состояний.
  • Определите не более 32 состояний рабочего процесса на тип рабочего элемента.

Примечание.

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

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

Унаследованные состояния

Пользовательские состояния

Ограничения

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

Настройки журнала задач и доски

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

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

Унаследованные невыполненные работы

Невыполненные работы с пользовательским портфелем

Ограничения

  • Нельзя удалить унаследованный уровень портфеля из продукта. Вы можете переименовать уровень или отключить WIT, чтобы предотвратить создание рабочих элементов этих типов командами.
  • Вы не можете вставить новый настраиваемый уровень невыполненной работы в существующем наборе определенных невыполненных операций. Стандартные уровни невыполненной работы обычно зафиксированы, например Epics, Features, User stories и Tasks.
  • Вы не можете переупорядочивать уровни бэклога. Обычно они следуют предопределенной иерархии, и изменение порядка не поддерживается.
  • Невозможно добавить WIT на два разных уровня невыполненной работы. Каждый WIT может принадлежать только одному уровню невыполненной работы.
  • Вы не можете создать настраиваемый уровень невыполненной работы для конкретной задачи, но вы по-прежнему можете добавить настраиваемые WIT в невыполненную итерацию. Например, можно создать пользовательский WIT с именем "Усовершенствование " или "Обслуживание" и связать его с невыполненной итерацией.
  • Ошибка WIT не относится к определенному уровню невыполненной работы по умолчанию. Каждая команда может решить, как они хотят управлять ошибками. Вы можете выбрать, отображать ли ошибки в списках невыполненных задач и на досках или обрабатывать их отдельно. Дополнительные сведения см. в разделе "Отображение ошибок в невыполненных работах".

Связанный контент

  • Last updated on