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

  • Статья

Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

Рабочий процесс для элемента невыполненной работы продукта (шаблон процесса scrum)

Рабочий процесс элемента невыполненной работы продукта, процесс Scrum

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Для каждого перехода определяется причина по умолчанию с помощью 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>

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

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

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

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

Примечание.

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

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

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

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

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

Вы можете ограничить, кто может переходить с одного состояния на другое, используя атрибуты 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>

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

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

<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.