Поделиться через

Настройка процесса и наследуемые процессы

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Внимание

Сведения о настройке локального проекта или обновлении XML-файлов определений для поддержки настройки см . в локальной модели xml-процессов. Эта статья относится только к Azure DevOps Services и Azure DevOps Server 2019.

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

Примечание.

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

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

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

Вы увидите два типа процессов:

  • Значок блокировки Системные процессы —Agile, Basic, Scrum и CMMI, которые заблокированы от изменения.
  • наследуемый значок Унаследованные процессы, которые можно настроить и наследовать определения из системного процесса, из которого они были созданы. Системные процессы принадлежат и периодически обновляются корпорацией Майкрософт. Любые обновления, внесенные в системный процесс, автоматически вызывают обновление унаследованных процессов и дочерних унаследованных процессов. Обновления процессов описаны в заметках о выпуске для Azure DevOps Server.

Примечание.

Базовый процесс доступен в Azure DevOps Server 2019 с обновлением 1 и более поздними версиями.

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

Например, как показано на следующем рисунке, вы увидите список проектов, определенных для организации fabrikam . Второй столбец показывает процесс, используемый каждым проектом. Чтобы изменить настройки проекта Fabrikam Fibre, необходимо изменить процесс MyScrum (который наследует от процесса системы Scrum). Любые изменения, внесенные в процесс MyScrum , также обновляют другие проекты, использующие этот процесс. С другой стороны, вы не можете настроить тестовый проект запроса, пока не измените его на процесс, наследующий от Agile.

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

Ограничения имени процесса

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

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

Изменение ссылочного процесса проекта

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

Следуя инструкциям, приведенным в приведенных выше статьях, вы также можете внести дополнительные изменения, например из CMMI в Agile или Agile в CMMI.

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

Рекомендации при внесении изменений

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

Унаследованные объекты и пользовательские объекты

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

Концептуальное изображение иерархии рабочих элементов гибкого процесса.

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

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

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

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

Тип поля

Поддержка настройки

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

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

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

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

  • Для каждого WIT можно определить не более 64 полей.
  • Можно определить не более 512 полей для каждого процесса.

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

Что нельзя настроить

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

Примечание.

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

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

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

Списки выбора, связанные с полями "Имя пользователя", например "Назначено" и "Изменено", управляются на основе пользователей , добавляемых в проект или команду.

Можно ли переименовать поле или изменить его тип данных?

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

Можно ли удалить или восстановить удаленное поле?

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

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

Что такое поле? Как используются имена полей?

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

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

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

Имена полей

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

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

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

Примечание.

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

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

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

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

Например, для копирования текущего удостоверения пользователя существует несколько правил в следующих условиях:

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

Внимание

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

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

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

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

Совет

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

Дополнительные сведения об определении настраиваемых правил см. в разделе "Правила" и "Оценка правил".

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

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

  • current user is a member of a group...
  • current user is not a member of a group...

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

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

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

Настройки типа рабочего элемента (WIT)

Ниже приведены параметры настройки для наследуемого и настраиваемого WIT.

Тип рабочего элемента

Поддержка настройки

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

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

Что нельзя настроить

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

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

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

Тип группы или страницы

Поддержка настройки

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

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

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

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

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

Макет веб-формы организован на три столбца, как показано на рисунке ниже.

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

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

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

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

Если ширина отображения не будет соответствовать всем столбцам, столбцы отображаются в столбце слева.

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

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

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

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

Типы состояний

Поддерживаемые настройки

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

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

Состояния рабочего процесса должны соответствовать следующим правилам.

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

    Примечание.

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

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

Неподдерживаемые настройки рабочего процесса

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

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

Невыполненные работы и доски являются важными инструментами Agile для создания и управления работой для команды. Стандартная невыполненная работа (продукт, итерация и портфель), унаследованные от системного процесса, является полностью настраиваемой. Кроме того, добавить пользовательские невыполненные работы портфеля (до пяти штук).

Типы невыполненных работ

Поддержка настройки

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

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

Неподдерживаемые настройки:

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

Примечание.

Для некоторых функций требуется установка обновления Azure DevOps Server 2020.1. Дополнительные сведения см. в заметках о выпуске Azure DevOps Server 2020 с обновлением 1 RC1, досках.

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

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

Ограничения на объекты

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