Разработка рабочего процесса

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

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

Например, состояние Активно задается, когда тестер открывает новую ошибку, основанную на шаблоне процесса для Microsoft Solutions Framework (MSF) для гибкой разработки программного обеспечения версии 5.0. После исправления ошибки разработчик меняет ее состояние на Разрешено и задает в поле "Причина" значение "Исправлено". После проверки исправления тестер изменяет состояние ошибки на Закрыто, оставляя в поле "Причина" значение "Исправлено". Если тестер обнаруживает, что разработчик не исправил ошибку, он меняет состояние ошибки на Активно и указывает в поле "Причина" значение "Разрешение отклонено" или "Тест не пройден".

Примечание

Создавать и изменять определения типов рабочих элементов и других объектов для отслеживания рабочих элементов можно с помощью редактора процессов, мощного средства для Visual Studio.Это средство не поддерживается.Дополнительные сведения см. на следующей странице веб-сайта Майкрософт: Team Foundation Server Power Tools April 2010 (на английском языке).

Содержание раздела

• Правила разработки рабочих процессов

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

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

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

  • Указание причин

  • Указание действий

• Обновление поля при изменении состояния

  • Определение поля при изменении состояния

  • Очистка значения поля

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

• Просмотр диаграммы состояния рабочего процесса

Правила разработки рабочих процессов

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

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

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

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

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

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

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

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

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

• В названиях, назначаемых состояниям и причинам, учитывается регистр.

К началу

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

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

Примечание

В этом примере не указаны элементы для DEFAULTREASON, REASON, ACTION и FIELD.

<WORKFLOW> <STATES>   <STATE value="Active">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Resolved">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Closed" /> </STATES> <TRANSITIONS>   <TRANSITION from="" to="Active">     <REASONS>       <DEFAULTREASON value="New" />     </REASONS>     <FIELDS> . . . </FIELDS>   </TRANSITION>   <TRANSITION from="Active" to="Resolved">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Closed">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Closed ">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active">     <REASONS> . . . </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 Application Lifecycle Management или вне Visual Studio Application Lifecycle Management (например, в средстве отслеживания вызовов). Дополнительные сведения см. в разделе Автоматизация назначений полей на основе состояния, перехода или причины.

К началу

Обновление поля

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

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

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

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

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

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

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

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

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

К началу

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

Когда в поле Состояние рабочего элемента задано значение "Активно" и рабочий элемент сохраняется, в полях Кем активирован и Кому назначено автоматически задается имя текущего пользователя. Этот пользователь должен быть членом группы "Допустимые пользователи 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>

К началу

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

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

Совет

Можно также просмотреть определяемую вами диаграмму состояния рабочего процесса с помощью редактора процессов, мощного средства для Visual Studio.Это средство не поддерживается.Дополнительные сведения см. на следующей странице веб-сайта Майкрософт: Team Foundation Server Power Tools April 2010 (на английском языке).

К началу

См. также

Другие ресурсы

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

Журнал изменений

Дата	Журнал	Причина
Январь 2011	Таблица элементов WORKFLOW перенесена в новый раздел Справка по всем XML-элементам WORKFLOW.	Улучшение информации.
Июль 2010	Полностью переписано с целью предоставить больше информации, примеров и сводки по всем элементам WORKFLOW и атрибутам.	Улучшение информации.