워크플로 디자인

아티클
08/10/2011

업데이트: 2011년 1월

작업 항목 형식에 대한 워크플로를 디자인하여 비즈니스 및 팀 프로세스를 지원합니다. 워크플로에 따라 수행할 작업의 논리적 진행과 작업을 수행할 사람이 결정됩니다. 먼저 상태를 식별하고 상태 간의 유효한 전환을 식별하여 워크플로를 정의합니다. 적업 항목 형식 정의의 WORKFLOW 섹션에서는 유효한 상태, 전환, 전환 이유 및 팀 멤버가 작업 항목 상태를 변경할 때 수행할 선택적 작업을 정의합니다. 형식 정의에 대한 자세한 내용은 모든 WITD XML 요소 참조을 참조하십시오.

일반적으로 각 상태를 팀 멤버 역할 및 해당 역할을 담당하는 사람이 상태를 변경하기 전에 작업 항목 처리를 위해 수행해야 하는 작업과 연결합니다. 전환은 상태 간의 유효한 진행과 회귀를 정의합니다. 이유는 팀 멤버가 작업 항목의 상태를 왜 변경하는지를 식별하며, 작업은 워크플로의 한 지점에서 작업 항목 전환 자동화를 지원합니다.

예를 들어 테스터가 MSF(Microsoft Solutions Framework) for Agile Software Development 5.0용 프로세스 템플릿을 기반으로 하는 새 버그를 열 때 상태는 Active로 설정됩니다. 버그를 수정한 후 개발자는 상태를 Resolved으로 변경하고 이유 필드의 값을 Fixed로 설정합니다. 수정을 확인한 후 테스터는 버그의 상태를 Closed로 변경하고 이유 필드의 값을 Fixed로 둡니다. 개발자가 버그를 수정하지 않았음을 테스터가 확인한 경우 테스터는 버그의 상태를 Active으로 변경하고 이유를 Resolution Denied 또는 Test Failed로 지정합니다.

참고

Visual Studio의 강력한 도구인 프로세스 편집기를 사용하여 작업 항목 형식의 정의와 작업 항목 추적을 위한 기타 개체를 만들고 수정할 수 있습니다. 이 도구는 지원되지 않습니다. 자세한 내용은 Microsoft 웹 사이트의 Team Foundation Server Power Tools April 2010 페이지를 참조하십시오.

항목 내용

워크플로 디자인 지침
워크플로 다이어그램 및 코드 예제
상태 수 및 형식 정의
전환 정의
- 이유 지정
- 작업 지정
상태가 변경될 때 필드 업데이트
- 상태가 변경될 때 필드 정의
- 필드의 값 지우기
- 다른 필드의 내용을 기반으로 필드 정의
워크플로 상태 다이어그램 보기

워크플로 디자인 지침

워크플로를 디자인하거나 수정할 때 다음과 같은 지침을 고려하십시오.

STATE 요소를 사용하여 작업 항목에서 특정 작업을 수행하는 각 팀 멤버 역할에 대해 고유한 상태를 정의합니다. 상태를 많이 정의할수록 더 많은 전환을 정의해야 합니다. 상태를 정의하는 순서와 상관없이 상태는 영숫자 순서로 상태 목록에 나열됩니다.
TRANSITION 요소를 사용하여 한 상태에서 다른 상태로의 유효한 각 진행 및 회귀에 대해 전환을 정의합니다.
최소한 각 상태에 대해 하나의 전환과 null 상태에서 초기 상태로의 전환을 정의해야 합니다.
DEFAULTREASON 요소를 사용하여 각 전환에 대한 기본 이유를 정의해야 합니다. REASON 요소를 사용하여 선택적 이유를 원하는 만큼 정의할 수 있습니다.
할당되지 않음(null) 상태에서 초기 상태로의 전환은 하나만 정의할 수 있습니다. 새 작업 항목을 저장하면 이 항목은 자동으로 초기 상태로 할당됩니다.
팀 멤버가 작업 항목의 상태를 변경하면 이에 따라 전환이 트리거되고 선택한 상태와 전환에 대해 수행되도록 정의한 작업이 트리거됩니다. 사용자는 현재 상태에 대해 정의하는 전환을 기반으로 유효한 상태만 지정할 수 있습니다. 또한 TRANSITION의 자식 요소인 ACTION 요소에 따라 작업 항목의 상태가 변경될 수 있습니다.
작업 항목 상태가 변경 또는 전환되거나 사용자가 특정 이유를 선택할 때 적용될 조건부 규칙을 모든 필드에 정의할 수 있습니다. 이러한 대부분의 규칙은 WORKITEMTYPE 정의 아래의 FIELDS 섹션에서 필드를 정의할 때 적용할 수 있는 조건부 규칙을 보완합니다. 자세한 내용은 이 항목 뒷부분에 있는 상태가 변경될 때 필드 업데이트를 참조하십시오.
작업 항목의 한 형식에 대해 정의하는 조건의 수를 최소화해야 합니다. 조건부 규칙을 추가할 때마다 팀 멤버가 각 작업 항목을 저장할 때 수행되는 유효성 검사 프로세스가 더 복잡해집니다. 복잡한 규칙 집합을 적용하면 작업 항목을 저장하는 데 필요한 시간이 늘어날 수 있습니다.
상태에 할당하는 이름과 이유는 대/소문자를 구분하지 않습니다.

맨 위로 이동

워크플로 다이어그램 및 코드 예제

다음 표에서는 코드 결함을 추적하는 작업 항목 형식에 대한 정의의 WORKFLOW 섹션과 이 섹션에서 정의하는 워크플로 상태 다이어그램을 보여 줍니다. 이 예제에서는 세 가지 상태, 여섯 가지 전환 및 아홉 가지 이유를 정의합니다. STATE 요소는 Active, Resolved 및 Closed 상태를 지정합니다. 하나를 제외하고 세 가지 상태에 대해 진행 및 회귀 전환에 가능한 모든 조합이 정의됩니다. Closed에서 Resolved로의 전환은 정의되지 않습니다. 따라서 작업 항목이 닫힌 경우 팀 멤버는 이 형식의 작업 항목을 해결할 수 없습니다.

참고

이 예제에는 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>

예제 워크플로 상태 다이어그램

상태 수 및 형식 정의

해당 형식의 작업 항목에 할당할 개별 논리적 상태의 수를 기반으로 유효한 상태의 수와 형식을 결정합니다. 팀 멤버마다 다른 작업을 수행할 경우 멤버 역할에 따라 상태를 정의하는 것도 고려할 수 있습니다. 각 상태는 팀 멤버가 작업 항목을 다음 상태로 이동하기 위해 작업 항목에 대해 수행해야 하는 작업과 대응합니다. 각 상태에 대해 특정 작업과 해당 작업을 수행하도록 허용되는 팀 멤버를 정의해야 합니다.

다음 표에서는 기능의 진행을 추적하기 위해 정의된 네 가지 상태와 표시된 작업을 수행해야 하는 유효한 사용자의 예를 보여 줍니다.

상태	유효한 사용자	수행할 작업
Proposed	프로젝트 관리자	모든 사람이 기능 작업 항목을 만들 수 있습니다. 하지만 프로젝트 관리자만 작업 항목을 승인하거나 반대할 수 있습니다. 프로젝트 관리자가 기능을 승인하면 프로젝트 관리자는 작업 항목의 상태를 Active로 변경합니다. 그렇지 않으면 팀 멤버가 항목을 닫습니다.
Active	개발 책임자	개발 책임자는 기능의 개발을 감독합니다. 기능이 완성되면 개발 책임자는 기능 작업 항목의 상태를 Review로 변경합니다.
Review	프로젝트 관리자	프로젝트 관리자는 팀이 구현한 기능을 검토하고 구현이 만족스러운 경우 작업 항목의 상태를 Closed로 변경합니다.
Closed	프로젝트 관리자	닫힌 작업 항목에는 발생할 것으로 예상되는 추가 작업이 없습니다. 이러한 항목은 보관 및 보고 용도로 데이터베이스에 유지됩니다.

참고

상태를 지정한 순서와 상관없이 모든 상태는 특정 형식의 작업 항목에 대한 폼의 목록에 사전순으로 나타납니다.

맨 위로 이동

전환 정의

유효한 상태 진행 및 회귀를 정의하여 팀 멤버가 작업 항목을 앞뒤로 변경할 수 있는 상태를 제어합니다. 한 상태에서 다른 상태로 전환을 정의하지 않으면 팀 멤버는 특정 형식의 작업 항목을 특정 상태에서 다른 특정 상태로 변경할 수 없습니다.

다음 표에서는 이 항목 앞부분에서 설명한 네 가지 상태 각각에 대해 유효한 전환을 정의하고 각 전환에 대한 기본 이유도 정의합니다.

상태	상태 전환	기본 이유
Proposed	Active(진행)	개발 승인됨
	Closed(진행)	승인되지 않음
Active	Review(진행)	수용 기준 일치됨
Review	Closed(진행)	기능 완성
	Active(회귀)	요구 사항과 일치하지 않음
Closed	Proposed(회귀)	승인 재고
	Active(회귀)	실수로 닫힘

TRANSITION 요소의 for 및 not 특성을 사용하여 한 상태에서 다른 상태로 전환하도록 허용되는 사람을 제한할 수 있습니다. 다음 예제에서 볼 수 있듯이, 테스터는 버그를 다시 열 수 있지만 개발자는 그렇게 할 수 없습니다.

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

맨 위로 이동

이유 지정

팀 멤버가 상태 필드를 변경하면 해당 사용자는 해당 전환에 대한 기본 이유를 유지하거나 추가 옵션을 정의한 경우 다른 이유를 지정할 수 있습니다. DEFAULTREASON 요소를 사용하여 기본 이유를 하나만 지정해야 합니다. 팀이 데이터를 추적하거나 보고하는 데 도움이 되는 경우에만 추가 이유를 지정해야 합니다.

예를 들어, 개발자는 버그를 해결할 때 Fixed(기본), Deferred, Duplicate, As Designed, Cannot Reproduce 또는 Obsolete 등의 이유 중 하나를 지정할 수 있습니다. 각 이유에 따라 테스터가 버그와 관련하여 수행할 특정 작업이 지정됩니다.

참고

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>

이벤트가 Microsoft Visual Studio Application Lifecycle Management 내의 다른 장소 또는 Visual Studio Application Lifecycle Management 외부(예: 호출을 추적하는 도구)에서 발생할 경우 ACTION 요소를 사용하여 특정 형식의 작업 항목 상태를 자동으로 변경할 수 있습니다. 자세한 내용은 상태, 전환 또는 이유를 기반으로 필드 할당 자동화를 참조하십시오.

맨 위로 이동

필드 업데이트

다음 이벤트가 발생할 때마다 필드를 업데이트하는 규칙을 정의할 수 있습니다.

특정 상태로의 모든 전환과 그 이유에 대해 규칙을 적용하려는 경우 STATE에서 필드 규칙을 할당합니다.
해당 전환과 그 이유에 대해 규칙을 적용하려는 경우 TRANSITION에서 필드 규칙을 할당합니다.
해당 특정 이유에 대해서만 규칙을 적용하려는 경우 DEFAULTREASON 또는 REASON에서 필드 규칙을 할당합니다.

필드에 항상 동일한 값이 포함되어야 하는 경우 해당 필드를 정의하는 FIELD 요소에서 규칙을 정의합니다. 자세한 내용은 작업 항목 필드에 대한 조건 설정를 참조하십시오.

다음 예제에서는 MSF Agile Software Development v5.0용 프로세스 템플릿에서 시스템 필드에 적용되는 몇 가지 규칙을 보여 줍니다.

상태가 변경될 때 필드의 값 변경
다른 필드의 값이 변경될 때 필드의 값 지우기
다른 필드의 내용을 기반으로 필드 정의

맨 위로 이동

상태가 변경될 때 필드의 값 변경

작업 항목에 대한 상태 필드의 값을 Active로 설정하고 작업 항목을 저장하면 활성화한 사람 및 담당자 필드의 값은 현재 사용자의 이름으로 자동으로 설정됩니다. 해당 사용자는 Team Foundation Server Valid Users 그룹의 멤버여야 합니다. 활성화된 날짜 필드의 값도 자동으로 설정됩니다. 다음 예제에서는 이 규칙을 적용하는 요소를 보여 줍니다.

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

맨 위로 이동

다른 필드의 값이 변경될 때 필드의 값 지우기

다음 예제에서 볼 수 있듯이, EMPTY 요소를 사용하는 경우 작업 항목에 대한 상태 필드의 값을 Active로 설정하고 작업 항목을 저장하면 닫힌 날짜 및 닫은 사람 필드는 자동으로 null로 설정되며 읽기 전용이 됩니다.

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

맨 위로 이동

다른 필드의 내용을 기반으로 필드 정의

작업 항목에 대한 상태 필드의 값을 Resolved로 변경하고 작업 항목을 저장하면 해결된 이유 필드의 값은 사용자가 이유 필드에 지정한 값으로 설정됩니다. 다음 예제에서는 이 규칙을 적용하는 요소를 보여 줍니다.

<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의 강력한 도구인 프로세스 편집기를 사용하여 정의하고 있는 워크플로 상태 다이어그램을 볼 수도 있습니다. 이 도구는 지원되지 않습니다. 자세한 내용은 Microsoft 웹 사이트의 Team Foundation Server Power Tools April 2010 페이지를 참조하십시오.

맨 위로 이동

참고 항목

기타 리소스

작업 항목 워크플로 정의 및 사용자 지정

변경 기록

날짜	변경 내용	이유
2011년 1월	WORKFLOW 요소 테이블이 새 항목인 모든 WORKFLOW XML 요소 참조로 이동되었습니다.	향상된 기능 관련 정보
2010년 7월	모든 WORKFLOW 요소와 특성에 대한 추가 정보, 예제 및 요약을 제공하도록 완전히 재작성되었습니다.	향상된 기능 관련 정보

2011년 1월

WORKFLOW 요소 테이블이 새 항목인 모든 WORKFLOW XML 요소 참조로 이동되었습니다.

향상된 기능 관련 정보

2010년 7월

모든 WORKFLOW 요소와 특성에 대한 추가 정보, 예제 및 요약을 제공하도록 완전히 재작성되었습니다.

향상된 기능 관련 정보

다음을 통해 공유

워크플로 디자인

워크플로 디자인 지침

워크플로 다이어그램 및 코드 예제

상태 수 및 형식 정의

전환 정의

이유 지정

작업 지정

필드 업데이트

상태가 변경될 때 필드의 값 변경

다른 필드의 값이 변경될 때 필드의 값 지우기

다른 필드의 내용을 기반으로 필드 정의

워크플로 상태 다이어그램 보기

참고 항목

기타 리소스

변경 기록

추가 리소스