작업 항목 형식의 워크플로 변경
비즈니스 및 팀 프로세스를 지원하도록 WIT(작업 항목 형식)에 대한 워크플로 변경합니다. WIT는 TFS(Team Foundation Server)를 사용하는 소프트웨어 개발을 지원하기 위해 모든 형식의 작업(요구 사항, 작업, 코드 결함)을 추적할 수 있도록 합니다.
워크플로는 팀 멤버가 수행하는 작업의 논리적 진행 및 재발을 결정합니다. 또한 상태 및 이유 필드의 드롭다운 메뉴에 나타나는 값을 지정합니다.
제품 백로그 항목의 워크플로(스크럼 프로세스 템플릿)
.png "제품 백로그 항목 워크플로, Scrum 프로세스")
TFS에서 제공하는 기본 프로세스 템플릿에서 지원되는 기본 워크플로 상태를 대략적으로 이해하려면 팀 프로젝트 아티팩트 작업, 프로세스 템플릿 선택을 참조하세요. 빌드 정의 워크플로에 대한 자세한 내용은 빌드 프로세스 템플릿 사용자 지정을 참조하세요.
워크플로 디자인 지침
먼저 상태와 상태 간의 유효한 전환을 파악하여 워크플로를 정의합니다. WIT 정의의 WORKFLOW 섹션은 유효한 상태, 전환, 전환 이유, 팀 멤버가 작업 항목의 상태를 변경할 때 수행되는 선택적 작업을 지정합니다.
일반적으로 각 상태를 팀 멤버 역할에 연결하고 해당 역할의 사용자가 상태를 변경하기 전에 작업 항목을 처리하기 위해 수행해야 하는 작업에도 연결합니다. 전환은 상태 간의 유효한 진행 및 재발을 정의합니다. 이유는 팀 멤버가 작업 항목을 하나의 상태에서 다른 상태로 변경하는 이유를 나타내고, 작업은 워크플로의 특정 지점에서 작업 항목의 전환 자동화를 지원합니다.
예를 들어 테스터가 TFS(Team Foundation Server)가 제공하는 기본 Agile 프로세스 템플릿을 기반으로 하는 새 버그를 열면 상태가 신규로 설정됩니다. 개발자는 버그를 수정할 때 상태를 활성으로 변경하고, 버그가 수정되면 개발자는 해당 상태를 해결됨으로 변경한 다음 이유 필드의 값을 수정됨으로 설정합니다. 테스터는 수정을 확인한 후에 버그의 상태를 닫힘으로 변경하고 이유 필드를 확인됨으로 변경합니다. 개발자가 버그를 해결하지 않았다는 사실을 확인하면 테스터는 버그의 상태를 활성으로 변경하고 이유를 수정되지 않음 또는 테스트 실패로 지정합니다.
워크플로를 디자인하거나 수정할 때는 다음 지침을 고려하세요.
STATE 요소를 사용하여 작업 항목에 대해 특정 작업을 수행하는 각 팀 멤버 역할의 고유한 상태를 정의합니다. 상태를 더 많이 정의할수록 전환도 더 많이 정의해야 합니다. 상태를 정의하는 순서에 관계없이 상태 필드의 드롭다운 메뉴에 영숫자 순서로 나열됩니다.
Team Web Access에서 백로그 또는 보드 페이지에 나타나는 작업 항목 형식에 상태를 추가할 경우 상태를 Metastate에도 매핑해야 합니다. 프로세스 구성 XML 요소 참조을 참조하세요.
TRANSITION 요소를 사용하여 한 상태에서 다른 상태로의 유효한 각 진행 및 재발에 대한 전환을 정의합니다.
최소한 상태별로 하나의 전환을 정의해야 하며 null 상태에서 초기 상태로의 전환도 정의해야 합니다.
할당되지 않은(null) 상태에서 초기 상태로의 전환은 하나만 정의할 수 있습니다. 새 작업 항목을 저장하면 자동으로 초기 상태로 할당됩니다.
팀 멤버가 작업 항목의 상태를 변경하면 이로 인해 선택된 상태 및 전환에 대해 수행되도록 정의한 작업과 전환이 트리거됩니다. 사용자는 현재 상태에 대해 정의한 전환을 기준으로 유효한 상태만 지정할 수 있습니다. 또한 TRANSITION의 자식 요소인 ACTION 요소는 작업 항목의 상태를 변경할 수 있습니다.
각 전환에 대해 DEFAULTREASON 요소를 사용하여 기본 이유를 정의합니다. REASON 요소를 사용하여 선택적 이유를 원하는 수만큼 정의할 수 있습니다. 이러한 값은 이유 필드의 드롭다운 메뉴에 나타납니다.
작업 항목의 상태가 변경되거나 작업 항목이 전환되거나 사용자가 특정 이유를 선택할 때 적용되는 규칙을 지정할 수 있습니다. 이러한 많은 규칙은 WORKITEMTYPE 정의 아래의 FIELDS 섹션에서 필드를 정의할 때 적용할 수 있는 조건부 규칙을 보완합니다. 자세한 내용은 이 항목 뒷부분의 워크플로 변경 중 필드 업데이트를 참조하세요.
상태 및 이유에 할당하는 이름은 대/소문자를 구분합니다.
작업 항목 폼 또는 쿼리 편집기 내의 상태 및 이유 필드에 대한 드롭다운 메뉴에는 작업 항목 형식의 WORKFLOW 섹션에 할당된 값이 표시됩니다.
워크플로 다이어그램 및 코드 예
다음 코드 예에서는 Agile 프로세스 템플릿의 버그 WIT 정의에 대한 WORKFLOW를 보여 줍니다. 이 예에서는 3개의 상태와 5개의 전환을 정의합니다. STATE 요소는 활성, 해결됨 및 닫힘 상태를 지정합니다. 진행 및 재발 전환에 대한 가능한 모든 조합(한 가지 제외)이 3개의 상태에 대해 정의되어 있습니다. 닫힘에서 해결됨으로의 전환은 정의되어 있지 않습니다. 따라서 팀 멤버는 작업 항목이 닫힐 경우 이 형식의 작업 항목을 해결할 수 없습니다.
이 예에서 DEFAULTREASON, REASON, ACTION 및 FIELD의 모든 요소를 나열하지는 않습니다.
|
예제 워크플로 상태 다이어그램 – Agile 버그 WIT .png "버그 워크플로 상태, Agile 프로세스 템플릿") |
상태의 수 및 형식 결정
해당 형식의 작업 항목이 존재하도록 할 고유한 논리적 상태의 수에 따라 유효한 상태의 수와 형식을 결정합니다. 또한 팀 멤버마다 다른 작업을 수행하는 경우 멤버 역할에 따라 상태를 정의하는 것을 고려할 수 있습니다. 각 상태는 팀 멤버가 다음 상태로 이동하기 위해 작업 항목에 수행해야 하는 작업에 해당합니다. 각 상태에 대해 특정 작업 및 이러한 작업을 수행할 수 있는 팀 멤버를 정의해야 합니다.
다음 테이블에서는 기능의 진행 상태와 지정된 작업을 수행해야 하는 유효한 사용자를 추적하도록 정의된 상태 4개의 예를 제공합니다.
상태 |
유효한 사용자 |
수행할 작업 |
|---|---|---|
제안됨 |
프로젝트 관리자 |
누구나 기능 작업 항목을 만들 수 있습니다. 그러나 프로젝트 관리자만 작업 항목을 승인하거나 승인을 취소할 수 있습니다. 프로젝트 관리자는 기능을 승인하는 경우 작업 항목의 상태를 활성으로 변경합니다. 그렇지 않은 경우 팀 멤버가 해당 작업 항목을 닫습니다. |
활성 |
개발 리드 |
개발 리드는 기능의 개발을 감독합니다. 기능이 완료되면 개발 리드가 기능 작업 항목의 상태를 검토로 변경합니다. |
검토 |
프로젝트 관리자 |
프로젝트 관리자는 팀이 구현한 기능을 검토하고 구현이 만족스러운 경우 작업 항목의 상태를 닫힘으로 변경합니다. |
닫힘 |
프로젝트 관리자 |
닫힌 작업 항목에 대해서는 추가 작업이 수행되지 않습니다. 이러한 항목은 보관 및 보고를 위해 데이터베이스에 남겨집니다. |
참고
모든 상태는 지정된 순서에 관계없이 특정 형식의 작업 항목 폼에 사전순으로 표시됩니다.
전환 정의
유효한 상태 진행 및 재발을 정의할 경우 팀 멤버가 작업 항목을 변경할 수 있는 상태를 제어합니다. 하나의 상태에서 다른 상태로의 전환을 정의하지 않으면 팀 멤버는 특정 형식의 작업 항목을 하나의 특정 상태에서 다른 특정 상태로 변경할 수 없습니다.
다음 테이블에서는 이 항목의 앞부분에 설명된 4개의 각 상태에 대한 유효한 전환과 각 전환의 기본 이유를 정의합니다.
상태 |
전환되는 상태 |
기본 이유 |
|---|---|---|
제안됨 |
활성(진행) |
개발이 승인됨 |
닫힘(진행) |
승인되지 않음 |
|
활성 |
검토(진행) |
승인 기준 충족 |
검토 |
닫힘(진행) |
기능 완성 |
활성(재발) |
요구 사항을 충족하지 않음 |
|
닫힘 |
제안됨(재발) |
승인 재고 |
활성(재발) |
오류로 닫힘 |
TRANSITION 요소의 for 및 not 특성을 사용하여 한 상태에서 다른 상태로 전환할 수 있는 사용자를 제한할 수 있습니다. 다음 예에 표시된 것처럼 테스터는 버그를 다시 열 수 있지만 개발자는 다시 열 수 없습니다.
<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 Application Lifecycle Management 외부(예: 호출을 추적하는 도구)에서 이벤트가 발생할 때 특정 형식의 작업 항목 상태를 자동으로 변경할 수 있습니다. 자세한 내용은 상태, 전환 또는 이유를 기반으로 필드 할당 자동화을 참조하십시오.
워크플로 변경 중에 필드 업데이트
다음 이벤트가 발생할 때마다 필드를 업데이트하는 규칙을 정의할 수 있습니다.
해당 상태로의 모든 전환 및 전환 이유에 해당 규칙을 적용하려는 경우 STATE에서 필드 규칙을 할당합니다.
해당 전환 및 해당 전환을 수행하는 모든 이유에 해당 규칙을 적용하려는 경우 TRANSITION에서 필드 규칙을 할당합니다.
해당 특정 이유에만 규칙을 적용하려는 경우 DEFAULTREASON 또는 REASON에서 필드 규칙을 할당합니다.
필드가 항상 같은 값을 포함하는 경우 해당 필드를 정의하는 FIELD 요소에서 규칙을 정의합니다. 규칙 사용에 대한 자세한 내용은 작업 항목 필드에 규칙 적용을 참조하세요.
한 형식의 작업 항목에 대해 정의하는 조건 수를 최소화하는 것이 좋습니다. 각 조건부 규칙을 추가할 때마다 팀 멤버가 작업 항목을 저장할 때 발생하는 유효성 검사 프로세스가 복잡해집니다. 규칙 집합이 복잡하면 작업 항목을 저장하는 데 필요한 시간이 늘어날 수 있습니다.
다음 예에서는 MSF Agile Software Development 2013에 대한 프로세스 템플릿의 시스템 필드에 적용되는 규칙 중 일부를 보여 줍니다.
상태가 변경될 때 필드 값 변경
작업 항목에 대한 상태 필드의 값이 활성으로 설정되고 작업 항목이 저장되면 활성화한 사람 및 담당자 필드의 값이 자동으로 현재 사용자의 이름으로 설정됩니다. 해당 사용자는 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>
다른 필드의 값이 변경될 때 필드 값 선택 취소
작업 항목에 대한 상태 필드의 값이 활성으로 설정되고 작업 항목이 저장되면 닫힌 날짜 및 닫은 사람 필드는 자동으로 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>
Q & A
Q: 워크플로를 변경하거나 워크플로 상태 다이어그램을 보기 위한 도구가 있나요?
A: 예. 강력한 Visual Studio용 도구인 프로세스 편집기를 사용하여, 정의하는 워크플로를 변경하거나 워크플로 상태 다이어그램을 볼 수 있습니다. 자세한 내용은 Microsoft 웹 사이트의 Team Foundation Server Power Tools 페이지를 참조하세요.
Q: WIT 정의 XML 요소의 개요는 어디에서 볼 수 있나요?
A: 모든 WITD XML 요소 참조를 참조하십시오.