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

Изменение рабочих процессов для типов рабочих элементов (WIT) для поддержки бизнес-процессов и командных процессов. WITs поддерживают отслеживание всех типов работ — требований, задач, дефектов кода — для поддержки разработки ПО при помощи Team Foundation Server (TFS).

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

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

Для обзора состояний рабочего процесса по умолчанию в шаблонах процесса по умолчанию, которые предоставляет TFS, см. раздел Работа с артефактами командного проекта, выбор шаблона процесса. Дополнительную информацию о построении определения рабочего процесса, см. раздел Настройка шаблона процесса сборки.

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

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

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

Например, состояние устанавливается на Новый, когда тестировщик обнаружил новую ошибку, которая основана на шаблоне процесса Agile по умолчанию, который предоставляет Team Foundation Server (TFS). Разработчик изменяет состояние на Активный, когда исправляет ошибку, и после исправления разработчик меняет состояние на Решенный и устанавливает значение Причины на Исправлено. После проверки исправления тестировщик меняет состояние ошибки на Закрыто, а поле Причина изменяется на Проверено. Если тестировщик определил, что разработчик не исправил ошибку, то он изменит состояние ошибки на Активный и укажет Причину Не исправлено или Не удалось выполнить тест.

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

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

  Если добавить состояние к типу рабочего элемента на страницах невыполненной работы или досок в Team Web Access, необходимо также перевести состояние в метасостояние. См. раздел Справочник по XML-элементам конфигурации процесса.

• С помощью элемента TRANSITION можно определить переход для каждой прогрессии или регрессии из одного состояния в другое.

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

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

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

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

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

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

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

Диаграмма рабочего процесса и пример кода

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

Пример не перечисляет элементы для DEFAULTREASON, REASON, ACTION, и FIELD.

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

Пример диаграммы состояния рабочего процесса — Agile Bug WIT

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

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

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

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

Примечание

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

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

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

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

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

Можно разделить тех, кому разрешено делать переход из одного состояние в другое при помощи атрибутов 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 Application Lifecycle Management или вне Visual Studio Application Lifecycle Management (например, из средства, которое отслеживает вызовы). Для получения дополнительной информации см. Автоматизация назначений полей на основе состояния, перехода или причины.

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

Можно определить правила, которые обновят поля, когда бы ни случились следующие события:

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

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

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

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

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

Следующие примеры показывают некоторые правила, которые применяются к системным полям в шаблоне процесса для MSF Agile Software Development 2013.

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

Когда значение поля Состояние для рабочего элемента установлено в режим Активный и рабочий элемент сохранен, полям Активирован (кем) и Назначен (кому) автоматически присваивается имя текущего пользователя Этот пользователь должен быть членом группы Действительных Пользователей 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. Дополнительные сведения см. в следующей статье: Team Foundation Server Power Tools.

В. Где можно найти обзор XML-элементов определений типов рабочих элементов?

О. См. раздел Справочник по всем XML-элементам WITD.