작업 항목 유형에 대한 워크플로 변경

아티클
04/04/2024

Azure DevOps Server 2022 - Azure DevOps Server 2019

비즈니스 및 팀 프로세스를 지원하도록 WIT(작업 항목 유형)에 대한 워크플로를 변경할 수 있습니다. WIT는 소프트웨어 개발을 지원하기 위해 모든 유형의 작업(요구 사항, 작업, 코드 결함)을 추적하도록 지원합니다.

워크플로는 팀 구성원이 수행할 작업의 논리적 진행 및 회귀를 결정합니다. 또한 상태 및 이유 필드의 드롭다운 메뉴에 표시되는 값을 지정합니다. 자세한 내용은 프로세스 및 프로세스 템플릿 정보를 참조 하세요.

제품 백로그 항목 워크플로(스크럼 프로세스 템플릿)

제품 백로그 항목 워크플로, 스크럼 프로세스

참고 항목

이 문서에서는 워크플로 상태를 사용자 지정하는 방법을 설명합니다. 대신 특정 작업 항목에 할당된 상태를 변경하려면 Kanban 보드, 진행 중인 작업 추적 또는 작업 보드, 업데이트 작업 상태 문서 중 하나를 참조하세요. 많은 작업 항목에 대해 상태 대량 업데이트를 수행할 수도 있습니다.

빌드 파이프라인 워크플로에 대한 자세한 내용은 CI/CD 시작을 참조하세요.

작업 항목 형식에 대한 XML 정의 업데이트

WIT 사용자 지정을 새로 사용하는 경우 다음 사항에 유의하세요.

작업 항목 형식의 모든 측면을 사용자 지정하려면 해당 XML 정의를 업데이트해야 합니다. XML 정의는 모든 WITD XML 요소 참조에 설명되어 있습니다.
새 작업 항목 환경을 사용하는 웹 양식을 사용자 지정하는 경우 WebLayout 및 Control 요소를 참조 해야 합니다.
Visual Studio에서 사용할 클라이언트 양식을 사용자 지정하는 경우 Layout XML 요소 참조를 참조해야 합니다.
작업 항목 추적 웹 양식 사용자 지정에 설명된 단계의 순서를 따릅니다.

워크플로를 사용자 지정하려면 다음 두 단계를 수행합니다.

이 항목에 WORKFLOW 설명된 대로 WIT 정의 섹션을 수정합니다.
프로세스 구성을 수정하여 새 워크플로 상태를 메타스테이션에 매핑합니다.

이 두 번째 단계는 Agile 도구 페이지에 표시되는 WIT에 대한 워크플로를 변경하는 경우에 필요합니다. 이러한 WIT는 요구 사항 또는 작업 범주에 속합니다. 상태 범주에 대한 자세한 내용은 워크플로 상태 및 상태 범주를 참조 하세요.

워크플로 디자인 지침

먼저 상태와 해당 상태 간의 유효한 전환을 식별하여 워크플로를 정의합니다. WIT 정의 섹션은 WORKFLOW 팀 구성원이 작업 항목의 상태를 변경할 때 수행할 유효한 상태, 전환, 전환 이유 및 선택적 작업을 지정합니다.

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

예를 들어 테스터가 기본 Agile 프로세스를 기반으로 하는 새 버그를 열면 상태가 새로 설정됩니다. 개발자는 버그를 수정할 때 상태를 활성으로 변경하고, 수정되면 개발자는 상태를 해결됨으로 변경하고 이유 필드의 값을 고정으로 설정합니다. 수정 사항을 확인한 후 테스터는 버그의 상태를 닫힘으로 변경하고 이유 필드는 확인됨으로 변경합니다. 테스터가 개발자가 버그를 수정하지 않은 것으로 확인되면 테스터는 버그의 상태를 활성으로 변경하고 이유를 수정되지 않음 또는 테스트 실패로 지정합니다.

워크플로를 디자인하거나 수정할 때 다음 지침을 고려합니다.

STATE 요소를 사용하여 작업 항목에 대해 특정 작업을 수행할 각 팀 구성원 역할에 대한 고유 상태를 정의합니다. 정의한 상태가 많을수록 더 많은 전환을 정의해야 합니다. 상태를 정의하는 시퀀스에 관계없이 상태 필드의 드롭다운 메뉴에 영숫자 순서로 나열됩니다.

웹 포털의 백로그 또는 보드 페이지에 표시되는 작업 항목 유형에 상태를 추가하는 경우 상태 범주에도 상태를 매핑해야 합니다. 자세한 내용은 워크플로 상태 및 상태 범주를 검토 하세요.
TRANSITION 요소를 사용하여 한 상태에서 다른 상태로의 유효한 각 진행 및 회귀에 대한 전환을 정의합니다.

최소한 각 상태에 대해 하나의 전환을 정의하고 null 상태에서 초기 상태로 전환해야 합니다.

할당되지 않은(null)에서 초기 상태로의 전환은 하나만 정의할 수 있습니다. 새 작업 항목을 저장하면 초기 상태에 자동으로 할당됩니다.

팀 구성원이 작업 항목의 상태를 변경하면 선택한 상태 및 전환에 대해 수행되도록 정의한 전환 및 작업이 트리거됩니다. 사용자는 현재 상태에 대해 정의한 전환에 따라 유효한 상태만 지정할 수 있습니다. 또한 ACTION 자식 요소인 요소는 TRANSITION작업 항목의 상태를 변경할 수 있습니다.
각 전환에 대해 요소를 사용하여 기본 이유를 정의합니다 DEFAULTREASON . 요소를 사용하여 원하는 만큼 선택적 이유를 정의할 REASON 수 있습니다. 이러한 값은 이유 필드의 드롭다운 메뉴에 표시됩니다.
작업 항목이 상태를 변경하거나 전환할 때 또는 사용자가 특정 이유를 선택할 때 적용되는 규칙을 지정할 수 있습니다. 이러한 규칙의 대부분은 정의 아래 섹션의 필드를 정의할 때 적용할 수 있는 FIELDS 조건부 규칙을 보완합니다 WORKITEMTYPE . 자세한 내용은 이 항목의 뒷부분에 있는 워크플로 변경 중에 필드 업데이트를 참조하세요.
상태 및 이유에 할당하는 이름은 대/소문자를 구분하지 않습니다.

작업 항목 폼 또는 쿼리 편집기 내의 상태 및 이유 필드에 대한 드롭다운 메뉴에는 작업 항목 유형의 섹션에 WORKFLOW 할당된 값이 표시됩니다.

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

다음 코드 예제에서는 Agile 프로세스 템플릿에 대한 버그 WIT 정의에 대해 보여줍니다 WORKFLOW . 이 예제에서는 세 가지 상태와 5개의 전환을 정의합니다. 요소는 STATE 활성, 해결됨 및 닫힌 상태를 지정합니다. 진행 및 회귀 전환에 대해 가능한 모든 조합은 1을 제외한 세 가지 상태에 대해 정의됩니다. 닫힘에서 해결됨으로의 전환이 정의되지 않았습니다. 따라서 작업 항목이 닫힌 경우 팀 구성원은 이 유형의 작업 항목을 확인할 수 없습니다.

이 예제에서는 , REASONACTION및 FIELD에 대한 DEFAULTREASON모든 요소를 나열하지 않습니다.

워크플로 상태 다이어그램 예제 - Agile Bug WIT

버그 워크플로 상태, Agile 프로세스 템플릿

<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
제안됨	프로젝트 관리자	누구나 기능 작업 항목을 만들 수 있습니다. 그러나 프로젝트 관리자만 작업 항목을 승인하거나 거부할 수 있습니다. 프로젝트 관리자가 기능을 승인하면 프로젝트 관리자가 작업 항목의 상태 활성으로 변경하고, 그렇지 않으면 팀 구성원이 해당 기능을 닫습니다.
활성화	개발 책임자	개발 책임자는 기능 개발을 감독합니다. 기능이 완료되면 개발 책임자가 기능 작업 항목의 상태 검토로 변경합니다.
검토	프로젝트 관리자	프로젝트 관리자는 팀이 구현한 기능을 검토하고 구현이 만족스러운 경우 작업 항목의 상태 Closed로 변경합니다.
닫힘	프로젝트 관리자	닫힌 작업 항목에 대해 추가 작업이 발생하지 않을 것으로 예상됩니다. 이러한 항목은 보관 및 보고 목적으로 데이터베이스에 다시 기본.

참고 항목

지정한 시퀀스에 관계없이 모든 상태는 특정 형식의 작업 항목에 대한 양식 목록의 사전순으로 표시됩니다.

전환 정의

유효한 상태 진행률 및 회귀를 정의하는 경우 팀 구성원이 작업 항목을 변경할 수 있는 상태를 제어합니다. 한 상태에서 다른 상태로의 전환을 정의하지 않으면 팀 구성원은 특정 유형의 작업 항목을 특정 상태에서 다른 특정 상태로 변경할 수 없습니다.

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

State(상태)	상태로 전환	기본 이유
제안됨	활성(진행)	개발 승인
	닫힘(진행)	승인되지 않음
활성화	검토(진행)	수락 기준 충족
검토	닫힘(진행)	기능 완료
	활성(회귀)	요구 사항을 충족하지 않음
닫힘	제안됨(회귀)	승인 다시 고려
	활성(회귀)	오류로 닫힘

요소의 TRANSITION 특성이 아닌 for 를 사용하여 한 상태에서 다른 상태로 전환할 수 있는 사용자를 제한할 수 있습니다. 다음 예제와 같이 테스터는 버그를 다시 열 수 있지만 개발자는 다시 열 수 없습니다.

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

Microsoft Visual Studio 애플리케이션 수명 주기 관리 또는 Visual Studio 애플리케이션 수명 주기 관리 외부에서 이벤트가 발생할 때(예: 호출을 추적하는 도구에서) 요소를 사용하여 ACTION 특정 형식의 작업 항목 상태를 자동으로 변경할 수 있습니다. 자세한 내용은 ACTION을 참조하세요.

워크플로 변경 중 필드 업데이트

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

모든 전환 및 해당 상태를 입력하는 이유에 대해 규칙을 적용하려는 경우 필드 규칙을 STATE 할당합니다.
해당 전환에 규칙을 TRANSITION 적용하고 해당 전환을 만드는 모든 이유를 적용하려는 경우 필드 규칙을 할당합니다.
특정 이유로만 규칙을 적용하려는 경우 또는 REASON 그 아래에 DEFAULTREASON 필드 규칙을 할당합니다.

필드에 항상 동일한 값이 포함되어야 하는 경우 해당 필드를 정의하는 요소 아래에 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>

다른 필드의 값이 변경되면 필드 값 지우기

작업 항목의 상태 필드 값이 활성으로 설정되고 작업 항목이 저장되면 다음 예제와 같이 요소를 사용하는 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에서 상태 모델 시각화 확장을 설치하여 사용자가 워크플로를 시각화하도록 지원할 수 있습니다.

작업 항목 유형에 대한 워크플로 변경

작업 항목 형식에 대한 XML 정의 업데이트

워크플로 디자인 지침

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

상태의 수 및 유형 확인

전환 정의

이유 지정

작업 지정

워크플로 변경 중 필드 업데이트

상태가 변경되면 필드 값 변경

다른 필드의 값이 변경되면 필드 값 지우기

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

도구 지원

피드백

피드백

추가 리소스

작업 항목 유형에 대한 워크플로 변경

작업 항목 형식에 대한 XML 정의 업데이트

워크플로 디자인 지침

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

상태의 수 및 유형 확인

전환 정의

이유 지정

작업 지정

워크플로 변경 중 필드 업데이트

상태가 변경되면 필드 값 변경

다른 필드의 값이 변경되면 필드 값 지우기

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

관련된 문서

도구 지원

피드백

피드백

추가 리소스