워크플로 사용자 지정(상속 프로세스)

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

고유한 비즈니스 프로세스를 반영하도록 작업 항목 워크플로를 사용자 지정하여 팀의 생산성을 최적화합니다. 각 WIT(작업 항목 유형)에는 만들기에서 완료까지 작업 상태를 추적하는 미리 정의된 워크플로가 포함되어 있습니다. 사용자 지정 상태를 사용하면 Azure DevOps 워크플로를 설정된 팀 사례, 규정 요구 사항 및 조직 표준에 맞출 수 있습니다.

일반적인 워크플로 사용자 지정:

• 버그 관리: Triaged, Investigating 또는 Customer Verified와 같은 상태 추가
• 기능 개발: 디자인 검토, 개발, 코드 검토 또는 관련자 승인 포함
• 준수 워크플로: 보안 검토, 법적 검토 또는 감사 완료 상태 추가

이 문서에서는 Triaged 상태를 포함하도록 버그 작업 항목 유형을 사용자 지정하는 방법을 보여 줍니다. 작업 항목 양식 머리글에 상태 및 이유 필드가 눈에 띄게 표시되어 쉽게 액세스하고 상태를 명확하게 표시할 수 있습니다.

팁 (조언)

DevOps 워크플로 빌드 및 릴리스는 YAML 및 클래식 파이프라인을 참조하세요.

지원되는 사용자 지정

상속된 상태를 숨기거나 사용자 지정 상태를 추가하여 WIT(작업 항목 형식)의 워크플로를 사용자 지정할 수 있습니다. 상속된 상태는 사용자 지정 프로세스를 만드는 데 사용되는 시스템 프로세스(Agile, Basic, Scrum 또는 CMMI(Capability Maturity Model Integration))에 따라 달라집니다. 자세한 내용은 워크플로 상태, 전환 및 이유를 참조 하세요.

각 WIT의 기본 워크플로는 2~4개의 상태를 정의하고 다음 워크플로 작업을 지정합니다.

• 각 상태 간의 앞뒤 전환. 예를 들어 기본 프로세스 문제 WIT에는 할 일, 수행 및 완료의 세 가지 상태가 포함됩니다.
• 각 상태 전환에 대한 기본 이유입니다.

상속된 워크플로와 사용자 지정 워크플로는 다음 규칙을 준수해야 합니다.

• 둘 이상의 워크플로 상태를 정의합니다.
• 제안됨 또는 진행 중 상태 범주에 대해 하나 이상의 상태를 정의합니다.
• 작업 항목 유형당 최대 32개 워크플로 상태를 정의합니다.

참고

사용자 지정 워크플로 상태를 추가하기 전에 백로그 및 보드의 워크플로 상태 정보에서 워크플로 상태가 범주에 매핑되는 방법을 알아봅니다.

상속된 워크플로 상태 및 사용자 지정 워크플로 상태에 대한 사용자 지정은 다음 리소스를 참조하세요.

상속된 상태

• 상태 숨기기 또는 보이기
• 워크플로 상태를 변경할 때 규칙 추가

사용자 지정 상태

• 워크플로 상태 추가
• 워크플로 상태 편집
• 워크플로 상태 제거
• 워크플로 상태를 변경할 때 규칙 추가

제한점

• 상속된 상태의 이름, 색 또는 범주는 변경할 수 없지만 표시하지 않으려면 숨길 수 있습니다.
• 사용자 지정 상태의 이름은 한 번 정의하면 변경할 수 없습니다.
• 기본 상태 범주 이름을 변경하거나 사용자 지정할 수 없습니다.
• 완료된 상태 범주에는 하나의 상태만 있을 수 있습니다. 이 범주에 사용자 지정 상태를 추가하면 해당 범주의 다른 상태가 제거되거나 숨겨지게 됩니다.
• 상태 전환에 대한 사용자 지정 이유를 지정할 수 없습니다. 기본 이유를 사용하여, 예를 들어 Triaged 상태로 이동 및 Triaged 상태에서 벗어남과 같이 적용해 보세요.
• 작업 항목 양식에서 상태 및 이유 필드의 배치를 변경할 수 없습니다.

상태 조직 및 동작 이해

상태 범주 및 워크플로우 진행 상황

Azure DevOps는 상태를 워크플로 동작을 정의하는 네 가지 기능 범주로 구성합니다.

범주	목적	예시	행동
제안	초기 작업 단계, 계획	신규, 승인됨, 심사	새 작업 항목의 시작점
진행 중	활성 작업 단계	활성, 커밋됨, 조사 중	작업이 진행 중임을 나타냅니다.
해결됨	확인을 기다리는 완료된 작업	해결됨, 수정됨, 테스트 준비 완료	작업 완료, 대기 중인 유효성 검사
완료됨	완료된 작업의 최종 상태	완료, 닫힘, 제거됨	터미널 상태, 완전히 완료된 작업

상태 드롭다운 메뉴 시퀀스

상태는 각 범주 내에서 정의한 순서에 따라 드롭다운 메뉴에 표시됩니다. 제안된 범주의 첫 번째 상태는 새 작업 항목의 기본값이 됩니다.

상태 순서 지정 원칙:

• 논리적 진행: 팀이 일반적으로 따르는 순서대로 상태를 정렬합니다.
• 사용 빈도: 목록에서 일반적으로 사용되는 상태를 더 높게 배치합니다.
• 시각적 명확성: 상태 순서가 사용자 환경에 미치는 영향 고려

다음 예제에서는 상태 시퀀스 구성이 사용자 인터페이스에 미치는 영향을 보여 줍니다.

상태 관리 기능:

• 위로 이동 또는 아래로 이동을 사용하여 범주 내에서 사용자 지정 상태 순서 다시 지정
• 시스템(상속됨) 상태를 다시 정렬할 수 없습니다.
• 변경 내용은 프로세스 템플릿을 사용하는 모든 팀에 영향을 미칩니다.

워크플로 변경의 효과 관리

워크플로 수정이 팀에 미치는 영향을 이해하면 구현을 계획하고 업데이트를 효과적으로 조정하는 데 도움이 됩니다.

보드 구성 요구 사항

이러한 사용자 지정을 수행할 때 팀은 보드 구성을 업데이트해야 합니다.

보드 업데이트가 필요한 상태 관련 변경 내용

변경 유형	영향	필요한 작업
사용자 지정 상태 추가	보드에 필요한 새 열	열 매핑 구성
상태 범주 변경	상태 동작 변경	테이블 열 검토 및 조정
상속된 상태 숨기기	열이 유효하지 않게 될 수 있습니다.	열 다시 매핑
백로그에 WIT 추가	새 작업 항목이 보드에 표시	보드 설정을 구성하세요

자세한 지침은 백로그 및 보드 사용자 지정을 참조하세요.

스프린트 및 태스크보드 고려 사항

작업 작업 항목 변경 내용:

• 작업 WIT에 상태를 추가하면 새 작업 보드 열이 만들어집니다.
• 변경 내용은 스프린트 계획 및 일별 스탠드업 워크플로에 영향을 줍니다.
• 팀 속도 추적 및 보고에 미치는 영향 고려

버그 추적 통합:

• 작업으로 버그를 추적하는 경우 버그 WIT 상태 변경이 작업 보드에 영향을 미칩니다.
• 버그 및 작업 상태를 정렬하면 보드 복잡성이 최소화됩니다.
• 일관된 상태는 작업 항목 간 보고를 개선합니다.

변경 관리 모범 사례

구현 전 계획:

• 관련자 맞춤: 영향을 받는 팀과 워크플로 변경 확인
• 평가 변경: 프로세스를 사용하여 모든 팀 및 프로젝트 식별
• 타임라인 조정: 활동량이 적은 기간 동안 변경 계획
• 통신 전략: 명확한 변경 알림 개발

구현 후 지원:

• 설명서 업데이트: 팀 프로세스 설명서 수정
• 교육 제공: 팀이 새로운 워크플로 옵션을 이해하는 데 도움이 됩니다.
• 모니터링 및 피드백: 채택 추적 및 개선 제안 수집
• 문제 해결: 구성 문제를 즉시 해결

롤백 준비:

• 변경 전 현재 상태 문서화
• 필요한 롤백을 위한 커뮤니케이션 계획 수립
• 이전 구성의 백업 설명서 유지 관리

필수 조건

특정 비즈니스 요구 사항에 맞게 Azure Boards를 조정하는 방법에 대한 지침은 Azure Boards 구성 및 사용자 지정을 참조하세요.

범주	요구 사항
사용 권한	- 프로세스를 만들거나, 삭제하거나, 편집하려면: 프로젝트 컬렉션 관리자 그룹 구성원이거나 특정 컬렉션 수준 사용 권한 프로세스만들기, 프로세스삭제, 프로세스편집이 있어야 하며, 또는 조직에서 필드 삭제가 허용으로 설정되어 있어야 합니다. 자세한 내용은 상속된 프로세스 사용자 지정을 참조하세요. - 보드를 업데이트하려면 팀 관리자 또는 프로젝트 관리자 그룹의 구성원입니다.
접근	- 기본 또는 낮은 액세스 권한이 있더라도 다른 사용자가 권한을 부여한 경우에도 프로세스를 변경할 수 있습니다. - 기존 작업 항목의 형식을 업데이트하고 변경하려면: 프로젝트의 멤버입니다.
프로젝트 프로세스 모델	- 프로젝트를 포함하는 프로젝트 컬렉션에 대해 상속 프로세스 모델이 있어야 합니다. - Azure DevOps Services로 데이터를 마이그레이션하려면 Team Foundation Server 데이터베이스 가져오기 서비스를 사용합니다.
지식	- 사용자 지정 및 프로세스 모델에 대해 잘 알고 있습니다.

조직 프로세스 설정 열기

1. 조직에 로그인합니다(https://dev.azure.com/{yourorganization}).

2. 조직 설정을 선택합니다.

   

3. 프로세스를 선택합니다.

   

참고

상속된 프로세스를 사용자 지정하면 프로세스를 사용하는 모든 프로젝트에는 사용자 지정이 자동으로 반영됩니다. 원활한 전환을 위해 조직 전체에서 사용자 지정을 구현하기 전에 테스트 프로세스 및 프로젝트를 만들어 사용자 지정을 테스트하는 것이 좋습니다. 자세한 내용은 상속된 프로세스 만들기 및 관리를 참조 하세요.

워크플로 상태 추가

팀의 고유한 프로세스 단계를 반영하는 사용자 지정 상태로 작업 항목 유형을 확장합니다. 상태를 추가하면 더 나은 추적, 더 명확한 상태 시각화 및 비즈니스 요구 사항에 맞게 워크플로 맞춤이 향상됩니다.

새로운 주에 대한 전략적 기획

상태를 추가하기 전에 팀의 워크플로 요구 사항을 고려합니다.

기존 격차 평가:

• 현재 상태로 표시되지 않는 프로세스의 단계 식별
• 새 상태를 추가하는 대신 기존 상태의 용도를 변경할 수 있는지 확인
• 새 상태가 설정된 팀 사례와 통합되는 방법 고려

계획 상태 특성:

• 명명 규칙: 팀에서 이해하는 명확한 작업 지향 이름 사용
• 범주 맞춤: 상태의 워크플로 목적과 일치하는 범주 선택
• 시각적 구분: 워크플로 선명도를 향상시키는 색 선택

상태 통합 및 자동 전환

상태를 추가하는 경우:

• 드롭다운 가용성: 상태가 작업 항목 양식 및 쿼리 편집기 전체의 상태 필드에 표시됩니다.
• 자동 전환: 모든 기존 상태와 양방향 전환이 자동으로 생성됩니다.
• 기본 이유: [StateName]으로 이동 및 상태 외부로 이동 [StateName]과 같은 시스템 생성 전환 이유

사용자 지정 워크플로 상태 추가

1. 상태 구성으로 이동합니다. 작업 항목 유형 페이지에서 수정할 작업 항목 유형을 선택하고 상태를 선택한 다음 새 상태를 선택합니다.

   

   팁 (조언)

   새 상태 옵션을 사용하지 않도록 설정한 경우 프로세스를 편집하는 데 필요한 권한이 없습니다. 상속된 프로세스 사용자 지정을 참조 하세요.

2. 상태 속성 구성: 상태 세부 정보를 신중하게 입력합니다.

   • 이름: 명확하고 설명적인 이름 사용(예: "코드 검토", "테스트", "고객 승인")
   • 범주: 적절한 워크플로 스테이지 선택(자세한 설명은 상태 범주 참조)
   • 색: 팀 워크플로 시각화를 향상시키는 색 선택

   

   중요함

   진행 중 또는 해결된 범주에 상태를 추가하면 작업 항목이 이러한 범주로 전환되거나 그 외부로 전환될 때/로 활성화되고 해결된/ 날짜 필드가 자동으로 업데이트 됩니다. 자세한 내용은 활성화 기준/날짜 및 해결 기준/날짜 필드를 참조하세요.

3. 구성 저장: 저장 을 선택하여 상태를 만듭니다. 지정된 색은 작업 항목 양식, 백로그, 보드 및 쿼리 결과를 포함하여 플랫폼 전체에 나타납니다.

4. 상태 시퀀스 최적화 (선택 사항): 드롭다운 메뉴에서 사용자 환경을 개선하려면 상태 순서를 조정합니다.

   • 상황에 맞는 메뉴 아이콘 선택
   • 위로 이동 또는 아래로 이동하여 해당 범주 내에서 상태를 적절하게 배치합니다.

   

5. 구현 확인: 새 상태를 철저히 테스트합니다.

   • 변경 내용이 로드되도록 브라우저 새로 고침
   • 사용자 지정된 형식의 작업 항목 열기
   • 올바른 색 및 위치 지정을 사용하여 드롭다운 메뉴에 상태가 표시되는지 확인합니다.

   상태가 "분류됨" 상태인 상태 드롭다운 메뉴의 예:

   

구현 후 유효성 검사

• 테스트 상태 전환: 작업 항목이 예상대로 새 상태로 이동할 수 있는지 확인합니다.
• 보고 효과 확인: 쿼리, 대시보드 및 보고서가 새 상태로 올바르게 작동하는지 확인
• 채택 모니터링: 팀이 새 상태를 사용하는 방법 추적 및 최적화를 위한 피드백 수집

참고

보드를 사용하는 팀은 백로그 수준과 연결된 작업 항목 유형에 상태를 추가할 때 열 설정을 업데이트해야 합니다. 포괄적인 변경 관리 지침은 효과 관리 섹션 을 참조하세요.

상태 편집

사용자 지정 워크플로 상태를 미세 조정하여 팀 생산성을 최적화하고 명확한 시각적 조직을 유지합니다. 기존 상태를 편집하면 설정된 프로세스를 방해하지 않고 워크플로를 개선하는 비용 효율적인 방법이 제공됩니다.

편집 시기 및 새 상태 만들기

다음과 같은 경우 기존 상태를 편집합니다.

• 현재 상태 이름은 워크플로 단계를 정확하게 나타냅니다.
• 프로세스에서 상태가 동작하는 방식을 조정해야 합니다(범주 변경).
• 시각적 표현은 더 명확하게 하기 위해 업데이트해야 합니다.
• 기존 작업 항목을 중단하지 않고 상태 기능을 다시 정렬하려고 합니다.

다음과 같은 경우 새 상태를 만듭니다.

• 기존 상태 이름이 워크플로 용어와 일치하지 않습니다.
• 프로세스에 더 많은 세분성이 필요합니다.
• 현재 상태는 필요한 모든 워크플로 단계를 다루지 않습니다.

편집 가능한 속성

재산	Description	영향
상태 범주	워크플로의 상태 동작 및 위치 결정	보드, 쿼리 및 보고에서 상태가 작동하는 방식을 변경합니다.
상태 색	플랫폼 전체의 시각적 식별자	모든 Azure DevOps 인터페이스의 모양을 업데이트합니다.

게시할 수 없는 속성

• 상태 이름: 한 번 만든 영구(초기 생성 시 상태 용도 고려)
• 시스템 상태: 기본 Azure DevOps 상태는 수정할 수 없으며 숨겨진 상태만

사용자 지정 상태 편집

1. 상태로 이동합니다. 작업 항목 유형 페이지에서 작업 항목 유형을 선택한 다음 상태를 선택합니다.

2. 편집 대화 상자 열기: ...에서 편집 선택 대상 상태에 대한 상황에 맞는 메뉴입니다.

   

3. 속성 구성:

   • 범주: 적절한 워크플로 스테이지 선택(자세한 내용은 상태 범주 참조)
   • 색: 팀의 시각적 규칙에 맞는 색 선택

4. 변경 내용 적용: 저장 을 선택하여 수정 내용을 구현합니다.

5. 변경 내용을 테스트합니다.

   • 수정된 형식의 작업 항목 열기
   • 상태가 올바른 색 및 범주 동작으로 표시되는지 확인합니다.
   • 상태 전환이 예상대로 작동하는지 확인

변경 효과 관리

즉각적인 작업 필요

범주를 변경하려면 다음이 필요합니다.

• 영향을 받는 모든 팀에 대한 보드 열 구성 업데이트
• 팀 구성원 및 관련자에게 변경 내용 전달
• 자동화된 프로세스가 여전히 제대로 작동하는지 확인합니다.

색을 변경하려면 다음이 필요합니다.

• 색 코딩을 참조하는 팀 설명서 업데이트
• 새 시각적 표현에 대해 사용자에게 알릴 수 있습니다.
• 새 색으로 대시보드 및 보고서 명확성 확인

기타 고려 사항

• 범주 변경: 롤백이 필요한 경우 이전 보드 구성을 복원해야 할 수 있습니다.
• 색 변경: 워크플로 효과 없이 쉽게 되돌릴 수 있습니다.
• 설명서: 이전 색 또는 범주를 참조하는 팀 설명서 업데이트

팁 (조언)

최적의 결과를 위해 앞에서 설명한 포괄적인 변경 관리 모범 사례를 따릅니다.

사용자 지정 상태 숨기기 또는 제거

상태를 숨기거나 제거하기 전에 기존 작업 항목 및 팀 워크플로에 미치는 영향을 이해합니다.

상태를 숨기거나 제거한 결과

상태를 숨기거나 제거하는 경우:

• 상태 드롭다운: 작업 항목 유형의 상태 드롭다운 메뉴에 상태가 더 이상 표시되지 않음
• 작업 항목 기록: 기존 작업 항목 기록 레코드가 변경되지 않음
• 기존 작업 항목: 숨김/제거된 상태의 작업 항목은 유효하지 않지만 해당 상태 값은 유지됩니다.
• 향후 편집: 영향을 받는 작업 항목을 변경하기 전에 상태 값을 업데이트해야 합니다.

영향을 받는 작업 항목 처리

상태를 숨기거나 제거하기 전에:

• 영향을 받는 항목 식별: 쿼리를 만들어 숨기거나 제거하려는 상태의 모든 작업 항목을 찾습니다.
• 전환 계획: 이러한 작업 항목이 이동해야 할 적절한 상태 결정
• 대량 업데이트: 대량 편집 을 사용하여 영향을 받는 모든 작업 항목을 유효한 상태로 이동
• 변경 내용 확인: 모든 작업 항목이 성공적으로 업데이트되었는지 확인

복구 옵션

• 복원 상태: 숨김/제거된 상태를 작업 항목 유형에 다시 추가하면 영향을 받는 작업 항목이 자동으로 유효한 상태로 되돌아갑니다.
• 팀 조정: 작업 항목 업데이트 중 혼동을 방지하기 위해 상태 변경에 대해 팀에 알립니다.

상속된 상태 숨기기 또는 표시하기

프로세스에 맞지 않는 상속된 상태를 숨기면 팀의 워크플로를 간소화할 수 있습니다. 이 방법은 시스템 기능을 유지하면서 드롭다운 메뉴에서 사용되지 않는 상태를 제거합니다.

상속된 상태를 숨기는 경우

다음과 같은 경우 상속된 상태를 숨깁니다.

• 팀의 워크플로는 특정 기본 상태를 사용하지 않습니다.
• 드롭다운 메뉴에서 상태 선택을 간소화하려고 합니다.
• 특정 상태는 혼동을 일으키거나 프로세스 용어와 일치하지 않습니다.

중요한 제약 조건

상태를 숨기기 전에 다음을 확인합니다.

• 범주 적용 범위 유지: 각 범주에 대해 하나 이상의 상태 유지(제안됨, 진행 중, 해결됨, 완료됨)
• 기존 작업 항목 확인: 현재 숨기려는 상태를 사용하는 작업 항목이 있는지 검토합니다.
• 팀과의 조정: 영향을 받는 보드를 사용하여 팀에 예정된 변경 내용에 대해 알립니다.

상속된 상태 숨기기

1. ...를 엽니다. 숨기려는 상태의 상황에 맞는 메뉴이며 숨기기 옵션을 선택합니다.

   다음은 버그 WIT의 해결됨 상태를 숨기는 예제입니다.

   

   중요함

   보드에서 추적되는 작업 항목 유형에 대한 상태를 숨기는 경우 팀은 열 설정을 업데이트해야 합니다. 효과 관리를 참조하세요.

2. 숨겨진 상태가 작업 항목 양식 드롭다운 메뉴에 더 이상 표시되지 않는지 확인하여 변경 사항을 확인합니다.

상속된 상태 숨기기 취소

숨겨진 상태를 복원해야 하는 경우:

1. ...를 엽니다. 숨겨진 상태에 대한 상황에 맞는 메뉴를 선택하고 숨기기 취소 옵션을 선택합니다.
2. 상태가 드롭다운 메뉴에 다시 나타나고 사용할 수 있는지 확인합니다.
3. 복원된 상태를 포함하도록 필요한 경우 팀 보드 구성을 업데이트합니다.

사용자 지정 상태 제거

1. ...를 엽니다. 제거할 상태의 상황에 맞는 메뉴를 선택하고 제거를 선택합니다. 사용자 지정 상태만 제거할 수 있습니다.

2. Remove State 대화 상자에서 제거를 선택합니다.

   

상태 워크플로 모델 보기

상태 모델 시각화 Marketplace 확장을 사용하여 사용자 지정 워크플로 상태 및 전환을 시각화합니다. 이 확장은 작업 항목 유형 워크플로의 그래픽 표현을 제공합니다.

확장 설치 및 액세스

1. Visual Studio Marketplace에서 상태 모델 시각화 확장을 설치합니다.
2. Azure DevOps 프로젝트에서 Boards>상태 시각화 도우미 로 이동합니다.
3. 작업 항목 유형을 선택하여 워크플로 상태 모델을 표시합니다.

기능

상태 시각화 도우미는 다음과 같은 기능을 제공합니다.

• 시각적 워크플로 다이어그램: 모든 상태 및 허용되는 전환 보기
• 대화형 탐색: 다이어그램 확대, 축소 및 이동
• 사용자 지정 가능한 레이아웃: 최적의 보기를 위해 상태 노드 끌어서 위치 변경
• 상태 전환 세부 정보: 가능한 모든 상태 전환을 한눈에 보기

예를 들어, 분류 상태를 포함하도록 버그 워크플로를 사용자 지정하는 경우, 시각화 도구는 모든 상태가 어떻게 서로 전환할 수 있는지를 보여 주어, 워크플로 디자인에 대한 명확한 개요를 제공합니다.

참고

Azure Boards 및 제품 팀은 상태 모델 시각화 확장을 지원하지 않습니다. 질문, 제안 또는 문제는 확장 페이지를 방문하세요.

다음 단계

감사 로그를 통해 상속된 프로세스에 대한 변경 내용 검토

관련 콘텐츠

• 백로그 및 보드의 워크플로 상태에 대해 알아보기
• 필드 추가 및 관리
• 보드에서 열 관리하기