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

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

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

Важно!

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

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

Примечание

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

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

Примечание

Рекомендации по настройке и настройке проекта и команд для поддержки бизнес-потребностей см. в разделе "Конфигурация и настройка Azure Boards".

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Наследуемые объекты и пользовательские объекты

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

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

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

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

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

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


Тип поля

Список участников


Наследуемые поля


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


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


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

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

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

Не удается настроить

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Имена полей

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

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

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

Примечание

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

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

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

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

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

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

Важно!

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

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

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

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

Совет

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

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

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

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

  • 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 состояний рабочего процесса на тип рабочего элемента.

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

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

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

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


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

Список участников


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


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


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

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

Примечание

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

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

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

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

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