Изменение рабочего процесса для типа рабочего элемента

Azure DevOps Server | Azure DevOps Server 2022

Измените рабочий процесс для типа элемента работы (WIT), чтобы поддержать ваши бизнес-процессы и процессы команды. WiT поддерживает отслеживание всех типов работы — требований, задач, дефектов кода — для поддержки разработки программного обеспечения.

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

Рабочий процесс для элемента бэклога продукта (Шаблон процесса Scrum)

Примечание.

В этой статье описывается настройка состояния рабочего процесса. Чтобы изменить состояние , назначенное конкретному рабочему элементу, см. одну из следующих статей: Board, Track work in progress, or Task Board, Update task status. Вы также можете выполнить массовое обновление состояния для многих рабочих элементов.

Сведения о рабочих процессах конвейера сборки см. в статье "Начало работы с CI/CD".

Обновление определения XML для типа рабочего элемента

Если вы не знакомы с настройкой WIT, обратите внимание на следующее:

• Чтобы настроить любой аспект типа рабочего элемента, обновите его xml-определение. Дополнительные сведения см. в справочнике по всем XML-элементам WITD.
• Если вы настраиваете веб-форму, которая использует новую систему работы с рабочими элементами, см. элементы WebLayout и Control.
• Если вы настраиваете клиентскую форму для использования с Visual Studio, см. справочник по элементу Layout XML.
• Выполните последовательность шагов, описанных в разделе "Настройка веб-формы отслеживания рабочих элементов".

Чтобы настроить рабочий процесс, выполните следующие два действия.

1. Измените WORKFLOW раздел определения WIT, как описано в этом разделе.

2. Измените конфигурацию процесса, чтобы сопоставить новые состояния рабочего процесса с метасостояниями.

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

Рекомендации по проектированию рабочих процессов

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

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

Например, задайте для состояния новое значение, когда тестировщик открывает новую ошибку, основанную на процессе гибкой обработки по умолчанию. Разработчик изменяет состояние "Активный " при исправлении ошибки и после исправления разработчик изменяет состояние на "Разрешено " и задает значение поля "Причина" на "Исправлено". После проверки исправления средство тестирования изменяет состояние ошибки на "Закрыто ", а поле "Причина" изменяется на "Проверено". Если средство тестирования определило, что разработчик не исправил ошибку, средство-тестировщик изменяет состояние ошибки на "Активный " и указывает причину как не исправленную или тестовую ошибку.

При разработке или изменении рабочего процесса рассмотрите следующие рекомендации:

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

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

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

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

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

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

• Для каждого перехода определите причину по умолчанию с помощью DEFAULTREASON элемента. Можно определить столько необязательных причин, сколько требуется, с помощью REASON элемента. Эти значения отображаются в раскрывающемся меню поля "Причина ".

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

• Присвоенные состояниям и причинам имена являются нечувствительными к регистру.

  Раскрывающиеся меню полей "Состояние и причина" в форме рабочего элемента или редакторе запросов отображают значения, назначенные в WORKFLOW разделе типа рабочего элемента.

Пример схемы рабочего процесса и кода

В следующем примере кода показано WORKFLOW определение ошибки WIT для шаблона процесса Agile. В этом примере определяются три состояния и пять переходов. Элементы STATE указывают состояния "Активный", "Решено" и "Закрыто". Все возможные сочетания переходов прогрессии и отката определены для трех состояний, кроме одного. Переход с "Закрыто" на "Решено" не определен. Поэтому участники группы не могут завершить рабочий элемент этого типа, если он закрыт.

В этом примере не перечислены все элементы для DEFAULTREASON, REASONи ACTIONFIELD.

Пример схемы состояния рабочего процесса — гибкая ошибка WIT

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Определение количества и типов состояний

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

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

Штат	Допустимый пользователь	Действие для выполнения
Предложено	Руководитель проекта	Любой пользователь может создать рабочий элемент функции. Однако только руководители проектов могут утвердить или отклонить рабочий элемент. Если менеджер проекта утверждает функцию, руководитель проекта изменяет состояние рабочего элемента на активный; в противном случае член команды закрывает его.
Активно	Руководитель разработки	Руководитель разработки контролирует разработку этой функции. После завершения функционала ведущий разработки изменяет состояние элемента работы по функционалу на проверку.
Отзыв	Руководитель проекта	Руководитель проекта проверяет функцию, реализованную командой, и изменяет состояние рабочего элемента на закрытое, если реализация удовлетворительна.
Закрытые	Руководитель проекта	Для рабочих элементов, закрытых, не ожидается никаких дополнительных действий. Эти элементы остаются в базе данных для архивации и создания отчетов.

Примечание.

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

Определение переходов

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

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

Штат	Переход к состоянию	Причина по умолчанию
Предложено	Активный (прогрессия)	Утверждено для разработки
	Закрыто (прогрессия)	Не утверждено
Активно	Проверка (прогрессия)	Критерии принятия выполнены
Отзыв	Закрыто (прогрессия)	Полностью укомплектован функциями
	Активный (регрессия)	Не соответствует требованиям
Закрытые	Предложено (регресс)	Пересмотреть для одобрения
	Активный (регрессия)	Закрыто по ошибке

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

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>  

Укажите причины

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

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

Примечание.

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

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

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>  

Определите действия

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

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>  

ACTION Используйте элемент для автоматического изменения состояния рабочих элементов определенного типа, когда события происходят в другом месте управления жизненным циклом приложений Microsoft Visual Studio или за пределами управления жизненным циклом приложений Visual Studio (например, из средства, отслеживающего вызовы). Дополнительные сведения см. в разделе ACTION.

Обновление поля во время изменения рабочего процесса

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

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

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

• Назначьте правило поля под DEFAULTREASON или REASON, если требуется, чтобы правила применялись только по этой конкретной причине.

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

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

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

Изменение значения поля при изменении состояния

При установке значения поля Состояние для рабочего элемента в "Активный" и сохранении рабочего элемента, значения полей Активировано и Назначено автоматически устанавливаются на имя текущего пользователя. Этот пользователь должен быть членом группы допустимых пользователей Team Foundation Server. Значение поля "Активированная дата " также устанавливается автоматически. В следующем примере показаны элементы, которые применяют это правило:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>  

Очистка значения поля при изменении значения другого поля

При установке значения поля State для рабочего элемента в "Активный" и сохранении рабочего элемента элемент EMPTY автоматически устанавливает для полей "Дата закрытия" и "Закрыт пользователем" значение NULL и делает их недоступными для изменения, как показано в следующем примере.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>  

Определение поля на основе содержимого другого поля

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

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>  

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

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

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

Чтобы помочь пользователям визуализировать рабочий процесс, установите расширение визуализации модели состояния из Visual Studio Marketplace.