Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs

아티클
06/10/2015

Visual Studio 2013

대기업 고객은 개별 Agile 팀의 장점을 보아 왔습니다. 그러나 이러한 방법을 여러 팀으로 확장 적용하고 엔터프라이즈 수준에서 민첩성을 구현하면 여러 가지 문제가 나타납니다. SAFe™(Scaled Agile Framework®)는 이러한 문제를 처리하고 민첩성을 확장하는 방법에 대한 로드맵을 제공합니다. TFS 2013을 온-프레미스로 배포한 경우 SAFe를 사용할 수 있습니다.

유용한 TFS 프로세스 템플릿으로 만든 팀 프로젝트를 사용하여 SAFe 기준을 추적할 수 있습니다. 이 문서에서는 SAFe 개념을 TFS에 매핑하는 방법, TFS에서 SAFe 프로젝트를 계획 및 추적하는 방법, SAFe를 지원하도록 TFS를 구성하고 사용자 지정하는 방법을 안내합니다.

TFS에서 SAFe 사용 단계

Scrum은 익숙하지만 SAFe는 잘 모르는 경우 Inbar Oren이 제공하는 Scaled Agile Framework Foundations의 비디오 Lean Samurai에서 유용한 정보를 확인할 수 있습니다.

TFS 개념에 SAFe 개념 매핑

SAFe는 여러 Agile 팀의 포트폴리오 뷰를 지원합니다. SAFe는 각자 자신만의 고유한 목표를 갖는 계층 구조를 가진 팀이 포트폴리오 비전을 충족하는 방법을 보여 줍니다. 이 프레임워크는 에픽을 기능과 스토리로 분할하며, 팀은 스프린트 동안 작업하고 PI(프로그램 증가) 및 릴리스 트레인을 통해 전달합니다. 또한 포트폴리오 백로그는 결과물이 전략적 테마 및 관련 예산에 매핑되는 방식을 추적할 수 있습니다.

SAFe 아키텍처 개요 ⓒ D. Leffing..

이미지 출처: Leffingwell, LLC.

이 백서의 예에서는 에픽 WIT 및 백로그를 추가하고, 세 수준의 팀 계층 구조를 구성하고, 팀을 해당 영역 및 반복 경로에 매핑하는 방법을 보여 줍니다. 이 예는 TFS Agile 프로세스 템플릿에서 빌드됩니다. 그러나 변경 내용은 모든 TFS 프로세스 템플릿에 적용될 수 있습니다.

SAFe를 지원하는 TFS 구조

SAFe 포트폴리오, 프로그램 및 팀을 TFS 팀 프로젝트 및 팀에 매핑

TFS는 계층적 팀 구조를 지원하므로 각 팀은 팀 계층 구조 내에서 다음 수준으로 롤업되는 작업에 대해 각자만의 관점을 가지고 있습니다.

TFS 팀에 대한 SAFe 역할

SAFe 팀을 지원하려면 기본 팀을 에픽을 관리하는 포트폴리오 팀으로 다시 구성할 수 있습니다. 그런 다음 프로그램 수준 작업 및 팀 수준 작업을 맡을 하위 팀을 만듭니다. 작업은 여러 팀, 여러 수준에 걸쳐 추적될 수 있습니다.

SAFe 백로그를 TFS 백로그에 매핑

기본적으로 TFS는 스토리 및 기능 백로그 수준을 지원합니다. 세 번째 수준을 쉽게 추가하여 에픽을 추적할 수 있습니다. 사용자 스토리를 기능에 매핑할 수 있고, 다시 기능을 에픽에 매핑할 수 있습니다. 백로그의 계층 구조 뷰는 사용자 스토리의 진행 상황이 에픽에 미치는 영향을 보여 줍니다.

계층적 백로그: 에픽, 기능 및 스토리

SAFe 릴리스, 반복 및 스프린트를 TFS 반복에 매핑

SAFe 릴리스 트레인, 릴리스, 반복, PI(프로그램 증가) 및 스프린트는 TFS 반복 경로에 쉽게 매핑됩니다. 팀 계층 구조 내에서 반복을 공유하여 릴리스를 상호 연관된 방식으로 관리합니다.

TFS 반복으로 SAFe 릴리스 트레인 매핑

포트폴리오 팀은 여러 릴리스 트레인 또는 PI에 걸칠 수 있는 에픽을 추적합니다. 프로그램 팀은 PI와 함께 제공되는 기능 결과물을 추적합니다. 또한 기능 팀은 스프린트에서 작업하여 여러 스토리를 완료합니다. TFS를 사용하여 각 팀은 팀 결과물에 대한 추적을 지원할 반복을 선택합니다.

반복을 사용하여 팀 트랙 전달 가능

SAFe 전략적 테마 및 예산을 TFS 태그 및 필드에 매핑

태그를 사용하여 에픽을 전략적 테마 또는 관련 예산에 매핑할 수 있습니다.

태그가 값 스트림 또는 관련된 예산을 추적할 수 있음

TFS에서 태그를 검색 및 쿼리할 수 있고 태그를 사용하여 다시 사용할 수 있는 쿼리 및 보고서를 만들 수 있습니다.

작업을 전략적 테마 및 예산에 보다 강력하게 매핑하기 위해 작업 항목에 필드를 추가하여 각 에픽, 기능 또는 스토리가 지원하는 테마 또는 예산을 추적할 수 있습니다.

요구 사항 유형이 비즈니스 또는 아키텍처 추적

SAFe 메트릭 및 TFS 보고서

보고서를 추가하거나 사용자 지정하여 SAFe 메트릭을 볼 수 있습니다. 예를 들어 스토리 개요 보고서와 비슷한 기능 진행률 보고서에는 곧 완료될 예정인 기능과 막 시작한 기능이 표시됩니다. 팀이 기능에 연결된 스토리를 작업할 때는 진행률 표시줄이 표시됩니다. 이 표시줄에는 지정된 기능의 완료 백분율(%)이 표시됩니다. 이해 관계자는 범위, 리소스 및 우선 순위 관리를 위해 실행 가능한 데이터를 보유하고 있습니다.

진행률 보고서 기능

기능 진행률 보고서의 다운로드 가능 버전에 대해서는 Agile 및 SAFe TFS 보고서 확대를 참조하세요.

TFS에서 SAFe 프로젝트 계획/추적

SAFe를 지원하도록 TFS를 구성한 후 스토리에서 에픽에 이르는 추적 관계를 만듭니다. 또한 포트폴리오, 프로그램 및 기능 팀 수준에서 진행률을 확인할 수 있습니다.

기능을 에픽에, 스토리를 기능에 매핑

프로그램 팀은 매핑 창을 사용하여 기능을 에픽에 매핑할 수 있습니다. 기능 팀은 동일한 환경에서 해당 스토리를 기능에 매핑할 수 있습니다.

에픽으로 기능 매핑

포트폴리오 팀의 진행률 뷰

여러 릴리스에 걸쳐 있는 에픽의 진행 상태를 추적할 수 있게 포트폴리오 팀의 백로그에 에픽이 표시됩니다. 각 에픽을 확장하여 해당 에픽을 지원하는 기능 및 사용자 스토리를 표시할 수 있습니다.

에픽, 기능 및 스토리의 계층 구조

포트폴리오 팀도 해당 Kanban 보드에서 에픽 진행 상태를 볼 수 있습니다.

에픽 Kanban 보드

프로그램 팀의 진행률 뷰

주로 릴리스 트레인과 관련된 프로그램 팀은 백로그에서 기능 및 해당 기능에 연결된 PI를 볼 수 있습니다.

기능 및 스토리의 프로그램 팀 백로그

포트폴리오 팀과 마찬가지로 프로그램 팀도 뷰를 전환하여 기능이 지원하는 에픽, 기능을 지원하는 사용자 스토리 또는 둘 모두를 볼 수 있습니다.

프로그램 팀에서 사용할 수 있는 또 다른 뷰에는 배송 스프린트 중에 릴리스 트레인 진행률, 백로그 항목 또는 활성 작업에 대한 쿼리 기반 그래프가 표시됩니다. 각 팀에서는 사용자 지정 가능 홈 페이지 뷰를 사용할 수 있습니다.

홈 페이지, 팀 즐겨찾기

프로그램 팀의 많은 작업이 PI 및 릴리스 트레인을 중심으로 진행되므로 예약된 배송 날짜와 지정된 트레인에 포함되기로 예약된 작업을 나타내는 사용자 지정 보고서가 유용할 수 있습니다. 또한 TFS 배포에 SQL Server Reporting Services 또는 Project Server와의 통합이 포함될 경우 이러한 서비스가 제공해야 하는 다양한 보고 옵션과 기본 제공 보고서를 활용할 수 있습니다.

기능 팀의 진행률 뷰

개별 기능 팀의 경우 해당 백로그 뷰에 작업 중인 스토리가 표시됩니다.

스토리의 기능 팀 백로그 마이그레이션

기능 팀이 에픽 또는 기능을 소유하는 것이 아니므로 기능 팀의 수준 백로그 뷰에는 에픽 및 기능이 나타나지 않습니다. 그러나 팀이 스토리가 지원하는 에픽 및 기능을 알려는 경우 백로그에서 해당 뷰를 설정할 수 있습니다.

에픽으로 스토리의 팀 백로그 마이그레이션

또한 여러 개의 작업으로 나누고 작업 보드를 사용하여 특정 스프린트 동안 문제없이 진행되도록 할 수 있습니다.

팀 스프린트 3 작업 보드 마이그레이션

쿼리의 차트 뷰는 IP(혁신 및 계획) 스프린트에 매우 유용합니다. 이 스프린트 중에 기능 팀은 함께 협력하여 릴리스가 예약된 기능을 안정화합니다.

버그 차트

그 밖의 모든 경우는 개별 기능 팀에게 아주 일상적입니다. 일상적인 작업 리듬에 따라 스프린트할 수 있습니다. Kanban 보드 및 작업 보드를 사용하여 진행 상황을 추적하고 작업을 관리하기 쉬운 청크로 세분화할 수 있습니다.

그러나 이제 개별 스토리에 대한 진행 상황을 프로그램 및 포트폴리오 관리 팀에서 볼 수 있습니다. 관리 뷰에는 수행하는 작업이 표시됩니다.

SAFe를 지원하도록 TFS 구성

이 섹션에서는 "Fabrikam”이라는 하나의 프로젝트와 해당 프로젝트 이름을 공유하는 하나의 팀부터 세 개의 수준과 아홉 개의 팀으로 구성된 다음 구조까지 살펴봅니다. 영역 경로 계층 구조와 각 팀의 영역 경로를 구성하는 방식은 각 팀의 백로그 뷰와 계층 구조 내에서의 뷰 롤업을 지원합니다.

계층적 영역에서 9개 팀의 3개 수준 지원

TFS의 각 프로젝트에는 기본 팀이 있습니다. 프로그램 수준 및 기능 팀 수준의 작업을 위해 추가 팀을 구성할 수 있습니다. 또한 기본 팀을 에픽을 관리하는 포트폴리오 팀으로 다시 정의할 수도 있습니다.

이러한 방식으로 모든 팀은 해당 작업이 포트폴리오 팀의 백로그에서 관리되는 해당 에픽을 지원하는 방식을 명확히 이해하면서 자신의 작업 부하 및 우선 순위를 관리할 수 있습니다. 동시에 포트폴리오 팀은 자체 Kanban 보드에서 해당 백로그의 진행률을 모니터링하고 백로그에서 항목 우선 순위를 지정하며 릴리스 트레인 간 진행 상태를 확인할 수 있습니다.

이러한 상황이 복잡하게 보일 수 있지만 실제로는 팀을 설정하고 작업을 시작하기 위해 필요한 구성 작업이 거의 없습니다.

처음에는 하나의 기본 팀, 영역 및 반복 집합이 있는 하나의 프로젝트부터 시작합니다. 먼저 원하는 팀의 계층 구조를 지원하도록 영역 경로 구조를 구성합니다. 그런 다음 반복 경로가 원하는 릴리스 구조와 사용할 프로그램 및 기능 팀을 지원하는지 확인합니다. 마지막으로 팀의 멤버 자격을 만들고 구성하고 채웁니다.

TFS를 구성하고 사용자 지정하려면 Project Administrators 그룹의 멤버여야 합니다.

팀 계층 구조를 지원하기 위한 영역 만들기

SAFe를 지원하도록 구성할 팀 프로젝트에 연결하고 기어 아이콘 을 사용하여 기본 팀의 관리 페이지를 엽니다.
영역 페이지에서 최상위 영역 경로 아래에 자식을 만들고 만들 프로그램 팀 중 하나에 해당하는 이름을 지정합니다.
다음에는 동일한 자식 수준에 두 번째 영역을 만들고 두 번째 프로그램 팀 이름을 따서 이름을 지정합니다.
각 프로그램 영역 아래에 해당 프로그램 팀을 지원할 각 기능 팀의 자식 영역을 만듭니다. 3수준 영역 경로 계층 구조로 끝나야 합니다.

릴리스 트레인 및 스프린트를 지원하는 반복 만들기

릴리스로의 진행 상태를 추적하려면 반복 경로 구조를 만듭니다. 영역 경로와 달리, 여러 팀이 동일한 반복 경로 구조를 공유할 수 있습니다. 반복 구조를 공유하면 여러 팀이 동일한 릴리스 트레인으로 진행되는 동일한 스프린트 작업 리듬에 따라 작업할 수 있습니다.

기본 팀에 대한 반복이 이미 있는 경우 이름을 바꿀 수 있습니다. 단지 한 팀만이 아니라 전체 팀 구조를 지원하는 반복 구조를 만들려고 합니다.

프로젝트와 동일한 이름을 공유하는 기본 반복 아래에 첫 번째 PI(프로그램 증가)를 나타내는 자식 반복을 만듭니다. 필요에 따라 PI에 대한 시작 및 종료 날짜를 추가하지만, 반복은 스프린트로 좀 더 세분화될 것입니다.
다음으로 PI 내에 각 스프린트에 대한 자식 반복을 만듭니다. 이러한 스프린트에 대한 날짜를 기능 팀의 작업 리듬에 맞게 설정합니다.

팀 만들기 및 구성

이 섹션에서는 이전에 만든 계층적 영역 경로에 매핑될 계층적 팀 구조를 구성합니다.

이 구조는 다음 SAFe 팀을 TFS 팀에 매핑합니다.

포트포리오 팀 -> 기본 최상위 팀, Fabrikam 팀
프로그램 팀 -> 두 번째 수준 팀, Fiber Suite 및 Service Suite
기능 팀 -> Fiber Suite 및 Service Suite 아래로 정의된 세 번째 수준 팀

좀 더 자세한 지침이 필요한 경우 Agile 포트폴리오 관리: TFS를 사용하여 여러 팀에서 백로그 지원을 참조하세요.

이러한 작업을 수행하려면 TFS의 프로젝트 관리자여야 합니다.

각 프로그램 팀 만들기 및 구성

팀 프로젝트에 대한 개요 페이지에서 새 팀을 만듭니다. 팀 이름을 사용하여 영역 경로를 만듭니다. 확인란의 선택을 취소합니다.
목록에서 팀을 선택하고 영역 페이지로 이동한 다음 해당 팀에 대해 이전에 만든 영역 경로 옆의 확인란을 선택합니다.
상황에 맞는 메뉴를 사용하여 하위 영역을 제외합니다. 하위 영역을 제외하면 팀의 백로그에는 영역 경로가 팀의 기본 영역 경로와 일치하는 항목만 포함됩니다.
다음으로 프로그램 팀에 대해 활성화될 반복을 구성합니다. 이 예에서는 각각 2주 스프린트를 5개 포함하는 3개의 PI를 구성했습니다. 스프린트 중 4개는 일반 스프린트이고 마지막 스프린트는 IP(혁신 및 계획) 스프린트입니다.

Fiber Suite 프로그램 팀은 릴리스 트레인과 관련되어 있으므로 PI 1, 2 및 3을 선택하지 개별 스프린트를 선택하지는 않습니다.
팀에 대해 활성화된 반복을 선택한 경우 새 팀에 사용자를 추가합니다. 이상적으로는 각 기능 팀에 대한 스크럼 마스터, 제품 소유자는 물론 RTE(릴리스 트레인 엔지니어)를 Fiber Suite와 같은 프로그램 팀에 추가할 수 있습니다.
프로그램 수준에 둘 이상의 팀이 있는 경우 각 프로그램 팀에 대해 1~5 단계를 반복합니다.

각 기능 팀 만들기 및 구성

다음으로 팀 계층 구조의 세 번째 수준에서 작업을 완료할 기능 팀을 일부 만듭니다. 각 기능 팀은 PI로 롤업되는 스프린트 작업에 참여합니다. 만드는 팀의 수는 조직의 규모에 따라 달라집니다.

원래 팀의 관리 페이지에서 새 팀을 만들고 팀 이름을 지정합니다. 이전과 마찬가지로 팀 이름을 사용하여 영역 경로를 만듭니다. 옆의 확인란을 선택 취소합니다.
목록에서 팀을 선택하고 영역 페이지로 이동한 다음 해당 팀에 대해 이전에 만든 영역 경로 옆의 확인란을 선택합니다.
PI 및 이전에 만든 스프린트를 사용하여 팀이 수행할 반복을 구성합니다. 프로그램 팀과 달리, 이번에는 개별 스프린트를 기능 팀에 대한 작업 반복으로 선택합니다.
팀의 개발자, 테스터 및 스크럼 마스터에 대한 계정을 추가합니다. TFS에서는 스크럼 마스터를 여러 팀에 할당할 수 있습니다. 스크럼 마스터는 여러 팀에서 작업을 추적할 수 있습니다.
조직의 각 기능 팀에 대해 1~4단계를 반복합니다. 팀에 대해 구성한 기본 영역 경로가 해당 프로그램 수준 영역 경로 아래에 있는 하위 영역 경로인지 확인합니다. 이렇게 하면 기능 팀에서 프로그램 팀으로 롤업됩니다.

포트폴리오 팀 구성

하위 팀 구조를 구성했으므로 기본 팀을 포트폴리오 팀 역할로 다시 구성합니다. 이 팀이 프로젝트의 이름을 계속 가지게 되지만 이 최상위 팀에서 수행한 변경은 최고 수준에서 여러 PI의 에픽을 효과적으로 추적하는 데 도움이 됩니다.

하위 영역이 포함 되지 않도록 팀 프로젝트의 영역 페이지에서 설정을 변경합니다. 기본 팀인 Fabrikam이 아닌 팀 프로젝트를 선택해야 합니다.
반복 페이지에서 지울 수 없는 루트 수준을 제외한 모든 반복 옆에 있는 확인란의 선택을 취소합니다. 포트폴리오 팀은 여러 PI에 걸쳐 있는 에픽만 상관하므로 PI 또는 스프린트가 아닌 루트 반복만 사용합니다. 포트폴리오 팀은 스프린트에서 작업하지 않습니다.
이 수준에 해당하는 포트폴리오 팀에서 사용자를 추가 및 제거합니다. 개요 페이지에서 기본 팀을 선택합니다.

이 수준에서 포트폴리오 관리자, 엔터프라이즈 수준 설계자 및 RTE(릴리스 트레인 엔지니어) 등의 가상 사용자를 추가하는 것을 고려하고 다른 모든 사용자는 제거합니다.

SAFe를 지원하도록 TFS 프로세스 사용자 지정

이 섹션에서는 에픽 WIT를 포트폴리오 백로그 계층 구조에 추가합니다. 또한 요구 사항 유형 필드를 세 개의 백로그 WIT 모두에 추가합니다. 아울러 일부 에픽을 만들고 기능을 에픽에 매핑할 것입니다.

TFS 백로그 개체 사용자 지정

에픽 백로그 수준을 추가한 후의 작업 결과에 더 관심이 있는 경우 지금 해당 위치로 이동합니다. 또한 이 섹션에 설명된 사용자 지정 단계를 직접 수행할 필요가 없는 경우 ALM Rangers에서 제공하는 블로그 게시물 및 샘플 PowerShell 스크립트를 사용할 수 있습니다. 이러한 자료에는 사용자 지정 내용을 프로젝트에 설치하는 방법이 잘 나와 있습니다.

포트폴리오 백로그에 에픽 추가

앞서 나온 것처럼 이러한 작업을 수행하려면 Project Administrators 그룹의 멤버여야 합니다.

먼저, 기존 WIT를 내보낸 후 해당 WIT을 사용하여 새 WIT을 만든 다음 에픽으로 지칭합니다. 또한 에픽 종류(아키텍처 또는 비즈니스)를 추적하기 위한 요구 사항 유형 필드도 추가합니다. 다음으로 에픽의 범주를 추가합니다. 그런 후 요구 사항 유형 필드를 포함하도록 기존 WIT(이름이 그렇게 지정되지는 않았더라도 기능 및 사용자 스토리)를 수정합니다. 요구 사항 유형 필드는 각 작업 항목이 지원하는 목표 종류를 추적합니다. 마지막으로 포트폴리오 팀 백로그에 에픽을 추가할 것입니다.

에픽 WIT 추가

WIT를 만드는 가장 쉬운 방법은 기존 항목을 복사해서 이름을 바꾼 후 편집하는 것입니다.

기능 WIT를 내보낸 후 해당 WIT를 에픽 WIT에 대한 기반으로 사용할 것입니다.

관리자 모드에서 명령 프롬프트 창을 엽니다. 디렉터리를 Visual Studio(또는 팀 탐색기)를 설치한 위치로 변경합니다.

cd %programfiles%\Microsoft Visual Studio 12.0\Common7\IDE

64비트 버전의 Windows에서는 %programfiles(x86)%를 사용합니다.
witadmin 도구를 사용하여 기능 WIT 정의를 다운로드한 후 Epic.xml로 저장합니다.

witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Epic.xml"

Epic.xml 파일을 열고 <WORKITEMTYPE name="Feature">를 <WORKITEMTYPE name="Epic">으로 바꾼 후 설명을 업데이트합니다.

<witd:WITD application="Work item type editor" version="1.0" xmlns:witd="https://schemas.microsoft.com/VisualStudio/2008/workitemtracking/typedef">
<WORKITEMTYPE name="Epic">
   <DESCRIPTION>Tracks an Epic that will span Releases. </DESCRIPTION>

<Tab Label="Implementation">을 편집하거나, CMMI의 경우 <Tab Label="Requirements"> 섹션에서 다음 줄을 <Filter WorkItemType="Feature" />로 바꿉니다.

Agile: <Filter WorkItemType="User Story" />
스크럼: <Filter WorkItemType="Product Backlog Item" />
CMMI: <Filter WorkItemType="Requirement" />

이렇게 변경하면 기능을 에픽의 자식 작업 항목으로 지원하도록 링크 컨트롤이 제한됩니다.

<Tab Label="Implementation">
   <Control Type="LinksControl" Name="Hierarchy" Label="" LabelPosition="Top">
      <LinksControlOptions>
          <WorkItemLinkFilters FilterType="include">
             <Filter LinkType="System.LinkTypes.Hierarchy" FilterOn="forwardname" />
          </WorkItemLinkFilters>
          <WorkItemTypeFilters FilterType="include">
             <Filter WorkItemType="Feature" />
          </WorkItemTypeFilters>
          <ExternalLinkFilters FilterType="excludeAll" />
          <LinkColumns>
             <LinkColumn RefName="System.ID" />
             <LinkColumn RefName="System.Title" />
             <LinkColumn RefName="System.AssignedTo" />
             <LinkColumn RefName="System.State" />
             <LinkColumn LinkAttribute="System.Links.Comment" />
          </LinkColumns>
       </LinksControlOptions>

에픽 WIT 정의에 요구 사항 유형 필드를 추가합니다. 이를 위해 기존 필드(처음에는 CMMI 프로젝트를 지원하기 위해 만들어졌지만 여기에서는 현재 작업에도 적합) Microsoft.VSTS.CMMI.RequirementType을 차용하고 에픽 FIELDS 섹션에 추가할 것입니다.

FIELDS 섹션을 찾은 후 다음 코드를 추가합니다.

<FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
   <REQUIRED />
   <ALLOWEDVALUES>
      <LISTITEM value="Architecture" />
      <LISTITEM value="Business" />
   </ALLOWEDVALUES>
   <DEFAULT from="value" value="Business" />
   <HELPTEXT>Indicates whether this supports business or architectural objectives.</HELPTEXT>
</FIELD>

다음으로 폼에 필드를 추가합니다. FORM 섹션 아래에서 업무에 가장 적합하다고 생각되는 위치에 필드를 추가합니다. 아래 예에서는 반복 필드 아래에 이 필드를 추가했습니다.

<Group Label="Classification">
   <Column PercentWidth="100">
      <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
      <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
      <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />

파일을 저장한 후 가져옵니다.

witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Epic.xml"

에픽 범주 추가

에픽 WIT가 있으므로 에픽에 대한 범주를 추가할 것입니다. TFS는 범주에 따라 백로그를 관리합니다.

범주 정의를 xml 파일로 내보냅니다.

witadmin exportcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"
파일을 열고 에픽 범주를 추가합니다. Microsoft를 회사 이름으로 바꾸어 사용자 지정했음을 나타낼 수 있습니다.
```
<CATEGORY name="Epic Category" refname="Microsoft.EpicCategory">
   <DEFAULTWORKITEMTYPE name="Epic" />
</CATEGORY>
```
이전과 마찬가지로 파일을 가져옵니다.

witadmin importcategories /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/categories.xml"

비즈니스/아키텍처 작업을 추적하기 위한 요구 사항 유형 필드 추가

다음으로 기능 및 백로그 항목의 세 번째 수준(사용자 스토리, 제품 백로그 항목 또는 경우에 따라 버그)에 요구 사항 유형 필드를 추가할 것입니다. 이미 기본 CMMI 정의에 포함되어 있으므로 요구 사항에 추가할 필요는 없습니다.

기능 WIT 정의를 내보냅니다.

witadmin exportwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /n:Feature /f:"DirectoryPath/Feature.xml"

에픽 WIT와 마찬가지로 요구 사항 유형 필드를 추가합니다. FIELDS 섹션을 찾아서 다음 코드를 추가합니다.

<FIELD name="Requirement Type" refname="Microsoft.VSTS.CMMI.RequirementType" type="String" reportable="dimension">
    <REQUIRED />
    <ALLOWEDVALUES>
        <LISTITEM value="Architecture" />
        <LISTITEM value="Business" />
    </ALLOWEDVALUES>
    <DEFAULT from="value" value="Business" />
     <HELPTEXT>Indicates whether this supports business or architectural objectives</HELPTEXT>
</FIELD>

폼에서 에픽에 추가했을 때와 동일한 위치에 필드를 추가합니다. 예를 들면 다음과 같습니다.

<Group Label="Classification">
   <Column PercentWidth="100">
      <Control FieldName="System.AreaPath" Type="WorkItemClassificationControl" Label="&amp;Area" LabelPosition="Left" />
      <Control FieldName="System.IterationPath" Type="WorkItemClassificationControl" Label="Ite&amp;ration" LabelPosition="Left" />
      <Control FieldName="Microsoft.VSTS.CMMI.RequirementType" Type="FieldControl" Label="Type" LabelPosition="Left" />
</Column>

파일을 저장한 후 가져옵니다.

witadmin importwitd /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/Feature.xml"
사용자 스토리 및 제품 백로그 항목 WIT 정의에 대해 1~4 단계를 반복합니다. 경우에 따라 버그가 지원하는 요구 사항을 추적하거나 백로그의 버그를 추적하는 경우 버그 WIT 정의를 편집합니다.

포트폴리오 백로그 계층 구조에 에픽 범주 추가

다음으로 백로그를 구성하는 작업 항목의 계층 구조에 에픽을 추가합니다.

프로세스 구성 XML 정의 파일을 내보냅니다.

witadmin exportprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

파일을 열고 에픽에 대한 PortfolioBacklog 섹션을 PortfolioBacklogs 섹션 내에 추가합니다. 동시에 에픽이 기능의 부모가 되도록 FeatureCategory에 대한 PortfolioBacklog 요소를 수정합니다.

필요에 따라 프로세스 템플릿을 기반으로 메타 상태 매핑을 수정합니다. 다음 예는 Agile 및 CMMI 프로젝트를 모두 지원합니다. 또한 요구 사항 유형 필드를 Columns 섹션에 추가합니다.

<PortfolioBacklogs>
  <PortfolioBacklog category="Microsoft.EpicCategory" pluralName="Epics" singularName="Epic">
      <States>
      <State value="New" type="Proposed" />
      <State value="Active" type="InProgress" />
      <State value="Resolved" type="InProgress" />
      <State value="Closed" type="Complete" />
      </States>
<Columns>
     <Column refname="System.WorkItemType" width="100"/>
     <Column refname="System.Title" width="400"/>
     <Column refname="System.State" width="100"/>
     <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
     <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
     <Column refname="System.Tags" width="200"/>
</Columns>
    . . .
</PortfolioBacklog>

스크럼 프로젝트에서는 신규, 진행 중 및 완료 워크플로 상태를 매핑해야 합니다. 이러한 상태는 기능 포트폴리오 백로그 항목에 대해 매핑되는 것과 동일한 상태입니다.

        <State type="Proposed" value="New" />
        <State type="InProgress" value="In Progress" />
        <State type="Complete" value="Done" />

또한 CMMI 프로젝트를 사용하려면 제안됨, 활성, 해결됨 및 닫힘 워크플로 상태를 매핑해야 합니다.

        <State value="Proposed" type="Proposed" />
        <State value="Active" type="InProgress" />
        <State value="Resolved" type="InProgress" />
        <State value="Closed" type="Complete" />

다음에는 PortfolioBacklog category="Microsoft.FeatureCategory"에 parent="Microsoft.EpicCategory"를 추가합니다. 또한 요구 사항 유형 필드를 Columns 섹션에 추가합니다.

<PortfolioBacklog category="Microsoft.FeatureCategory" parent="Microsoft.EpicCategory" pluralName="Features" singularName="Feature">
   . . .
<Columns>
     <Column refname="System.WorkItemType" width="100"/>
     <Column refname="System.Title" width="400"/>
     <Column refname="System.State" width="100"/>
     <Column refname="Microsoft.VSTS.Common.BusinessValue" width="50"/>
     <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
     <Column refname="System.Tags" width="200"/>
</Columns>
    . . .

</PortfolioBacklogs>

다음으로 요구 사항 유형 필드를 RequirementsBacklog 섹션의 Columns 섹션에 추가합니다.

<RequirementBacklog singularname="User Story" pluralName="User Stories" category="Microsoft.RequirementCategory">
   . . .
<Columns>
     <Column refname="System.WorkItemType" width="100"/>
     <Column refname="System.Title" width="400"/>
     <Column refname="System.State" width="100"/>
     <Column refname="Microsoft.VSTS.Scheduling.Effort" width="50"/>
     <Column refname="Microsoft.IterationPath" width="200"/>
     <Column refname="Microsoft.VSTS.CMMI.RequirementType" width="100"/>
     <Column refname="System.Tags" width="200"/>
</Columns>
   . . .
</RequirementBacklog>

에픽에 사용할 색을 WorkItemColors 섹션에 추가합니다. 원하는 어떤 색도 선택할 수 있지만 시스템에서 이미 사용 중인 색은 사용하지 않도록 합니다.

여기서 선택한 색은 주황색(16진수 색 코드=FF7B00)에 해당합니다. 16진수 색 코드 앞에 FF를 붙입니다.
```
<WorkItemColor primary="FFFF7B00" secondary="FFFFD7B5" name="Epic" />
```
파일을 저장한 후 가져옵니다.

witadmin importprocessconfig /collection:"https://ServerName:8080/tfs/CollectionName" /p:"ProjectName" /f:"DirectoryPath/ProcessConfiguration.xml"

기존 작업 항목의 영역 경로를 업데이트합니다.

모든 기존 작업 항목이 팀의 백로그에 표시되려면 각 작업 항목의 영역 경로를 팀의 기본 영역 경로에 업데이트해야 합니다. 웹 브라우저의 대량 편집 기능을 사용하거나 Excel을 사용할 수 있습니다.

편집하려는 작업 항목이 포함된 쿼리를 만들고 편집할 작업 항목을 선택한 후 선택된 항목 중 하나에서 상황에 맞는 메뉴를 엽니다.
팀의 기본 영역 경로에 해당하는 영역 경로를 선택합니다.
수정한 모든 작업 항목을 대량으로 저장합니다.

작업 항목의 대량 수정에 대한 자세한 내용을 보려면 여기로 이동하세요.

에픽을 추가하고 에픽을 기능에 매핑

이제 에픽 WIT를 추가했으므로 일부를 만들어봅니다. 이 프로세스는 다른 백로그 작업 항목을 만드는 것과 같습니다. 포트폴리오 팀의 에픽 백로그 페이지에서 에픽 백로그 항목을 추가합니다.

에픽 백로그, 빠른 추가 패널을 사용하여 에픽 추가

필요한 에픽을 모두 추가합니다. 항목을 중요도 순서로 나열하려면 목록 내에서 끌어옵니다.

에픽 백로그, 항목 순서 변경

에픽에 대한 기본 요구 사항 유형은 비즈니스이지만 에픽을 비즈니스에서 아키텍처로 변경할 수 있습니다.

에픽 작업 항목 폼

각 에픽이 지원하는 투자 테마를 추적하는 데 도움이 되도록 에픽에 태그를 추가할 수도 있습니다.

에픽 작업 항목 폼, 태그 추가

이제 Kanban 보드에서 에픽을 확인합니다. 이 뷰를 가져오려면 Kanban 열을 사용자 지정하여 이름을 바꾸고 중간 워크플로 상태를 추가해야 합니다. 이러한 상태에 대한 자세한 내용은 비즈니스 에픽 Kanban 요약을 참조하세요.

에픽 Kanban 보드

그러나 아직 그다지 흥미로워 보이지는 않습니다. 진행 중인 작업이 없으므로 드릴다운하여 에픽을 지원하는 기능을 확인할 수 없습니다. 방금 만든 에픽에 기존 기능을 매핑하고 사용자 스토리를 해당 기능에 아직 매핑하지 않았으면 매핑하려 합니다.

기존 백로그에 있는 경우 여러 항목 매핑

매핑 창을 사용하면 작업 항목을 쉽게 매핑할 수 있습니다. 기능 또는 스토리 백로그 페이지에서 매핑 창을 켭니다. 이 예에서는 Fiber Suite 팀을 선택하고 매핑 창과 뷰를 모두 설정하여 에픽에 매핑된 기능의 계층 구조를 확인합니다.

에픽으로 기능 매핑

모든 기능의 영역 경로를 이미 해당 프로그램 수준의 팀으로 변경한 경우 포트폴리오 팀에서 어떤 기능도 소유하지 않으므로 기능 목록이 비어 있게 됩니다. 이 경우 프로그램 팀 중 하나로 전환합니다.

백로그에서 항목을 부모로 연결하려는 항목으로 끌어옵니다. 에픽에는 기능만 매핑할 수 있습니다. 마찬가지로 백로그 항목의 세 번째 수준(사용자 스토리, 백로그 항목 또는 요구 사항)만 기능에 매핑할 수 있습니다.

원하는 계층 구조를 만들 때까지 각 백로그 수준에서 이 프로세스를 반복합니다.

에픽, 기능 및 스토리의 계층 구조

이미 진행 중인 기능의 경우는 어떻게 될까요? 이러한 기능은 포트폴리오 팀의 백로그에 나타나지 않습니다. 이러한 기능은 프로그램 팀의 책임이므로 해당 팀의 백로그에 나타납니다. 이것은 실제로 작업 항목에 대해 설정된 영역 경로의 기능입니다. 작업 항목을 해당 팀에 대해 만든 영역 경로에 할당한 경우에만 팀의 백로그에 표시됩니다. 해당 위치에서 작업 항목을 매핑할 수 있습니다.

또한 Microsoft Excel에서 작업 항목을 대량으로 편집하고 해당 계층을 관리할 수도 있습니다.

SAFe의 중요한 측면은 작업을 비즈니스 또는 아키텍처 목표에 매핑하는 것이므로 아키텍처 에픽에 매핑된 모든 기능에 대해 요구 사항 유형=아키텍처를 설정할 수 있습니다. 기본 선택 항목이 비즈니스이므로 비즈니스 에픽을 지원하는 항목의 유형은 변경할 필요가 없습니다. 또한 투자를 추적하기 위해 태그를 추가할 수도 있습니다.

동일한 원칙이 진행 중인 사용자 스토리에도 적용됩니다. 사용자 스토리를 기능에 매핑하고 아키텍처 에픽 지원을 위해 수행하는 작업의 요구 사항 유형을 아키텍처로 변경하며 테마 추적을 위한 태그를 추가할 수 있습니다.

사용자 스토리 작업 항목 폼

리소스

편리하게 참조할 수 있도록 이 백서에서 언급된 리소스와 추가 리소스가 여기에 나와 있습니다.

SAFe 사용 프로세스 템플릿: TFS가 제공하는 세 가지 프로세스 템플릿(스크럼, Agile 및 CMMI)의 다운로드에 대한 링크입니다. 이 백서에 설명된 사용자 지정 내용도 추가되었습니다.
PowerShell을 사용하여 TFS 2013 프로세스 템플릿 업그레이드/게시: Gordon Beeming이 작성한 블로그 게시물로, 이 백서에 설명된 변경 내용을 적용하는 데 사용할 수 있는 PowerShell 스크립트를 제공합니다.
Scaled Agile Framework: SAFe 리소스 사이트입니다.
SAFe 7분 동영상: Inbar Oren의 비디오 Lean Samurai
Scaling Agile 및 SAFe TFS 보고서: 온-프레미스 TFS 2012 및 2013 배포를 위한 스크럼 프로세스 템플릿을 사용하는 다운로드 가능한 기능 진행률 보고서입니다.
Agile 포트폴리오 관리: TFS를 사용하여 여러 팀에서 백로그 지원: 여러 팀 및 여러 백로그를 지원하도록 TFS를 구성하는 방법을 보여 주는 백서입니다.
쿼리를 사용하여 작업 항목 찾기(To Update): 부모의 모든 자식 작업 항목에 대한 선택 필드의 합산 값을 구하는 롤업을 지원하도록 TFS를 구성하는 방법을 설명합니다. TFS는 여러 수준의 중첩을 지원하므로 롤업을 수행할 때 값을 이중으로 계산하지 않도록 확인합니다.
유용한 보고서(SQL Server Reporting Services): TFS에서 진행률 및 코드 품질을 모니터링하기 위해 제공하는 보고서를 요약합니다.
Project Server와 Team Foundation Server 동기화: 프로젝트 관리자와 개발 팀이 원하는 도구를 사용하고 TFS의 작업 항목에서 Project Server의 엔터프라이즈 프로젝트 계획에 포함된 작업으로 데이터가 흐르도록 설정하여 투명하게 정보를 공유하는 방법에 대해 설명합니다.
둘 이상의 팀에 할당될 때 작업 추적: 개발자 또는 테스터가 둘 이상의 기능 팀을 지원할 때 작업을 추적하는 방법을 보여 줍니다.

작성자 정보

Gordon Beeming은 남아프리카 공화국, 더반시의 데리브코에 거주하는 소프트웨어 개발자입니다. 그는 Visual Studio로 작업을 하거나 가족과 함께 대부분의 시간을 보냅니다. 그는 블로그 31og.com을 운영하고 있으며 twitter.com/gordonbeeming에서 팔로우할 수 있습니다.

Brian Blackman은 Microsoft Premier Developer의 자문을 담당하여 ISV 파트너와 대기업이 엔지니어링 부문과 마켓플레이스에서 성과를 거둘 수 있도록 지원합니다. 그는 MBA를 취득했으며 CSM, CSP, MCSD(C++) 및 MCTS를 보유하고 있으며 Visual Studio ALM Ranger입니다. Ruck Master 역할을 수행하지 않고 Visual Studio ALM Ranger 프로젝트에 참여하지도 않고 있을 때는 코드를 작성하고 워크샵을 열어서 강연하고 다양한 방식으로 자문을 제공하는 데 시간을 보냅니다. 특히 조직의 비즈니스 민첩성 개발에 도움을 주고 있습니다.

Gregg Boer는 Microsoft의 주요 프로그램 관리자입니다. Gregg는 TFS의 Agile Management 환경에 대한 제품 소유자입니다.

Kathryn Elliott은 Microsoft 선임 기술 문서 작성자입니다.

Susan Ferrell은 선임 기술 문서 작성자이자 Visual Studio ALM Ranger입니다.

Willy-peter Schaub은 Microsoft 캐나다 개발 센터의 Visual Studio ALM Rangers에서 근무하는 프로그램 관리자입니다. 80년대 중반부터 소프트웨어 엔지니어링 분야에서 간편성과 유지 관리 편의성을 높이기 위해 노력해 왔습니다. 그의 블로그는 blogs.msdn.com/b/willy-peter_schaub이며 twitter.com/wpschaub에서 팔로우할 수 있습니다.

다음을 통해 공유