IBM Rational Team Concert와 Jazz 플랫폼으로 스크럼 프로젝트 관리 방법을 사용하는 방법

완벽한 계획, 작업, 관리를 위해 IDE로 Jazz와 애자일 개발 결합하기

애자일 계획 도구를 IBM？？ Rational？？ Team Concert 와 Jazz로 통합하면 단일 플랫폼에 더 나은 가시화, 협업 기회, 추적성 및 프로세스 인식을 가져옴으로써 개발 생산성이 향상됩니다.

I

BM 펠로우인 Grady Booch는 IBM？？ Rational？？ Team Concert와 IBM？？ Rational？？ Jazz 플랫폼이 "팀이 매일 해야 하는 활동들을 제거하거나 자동화함으로써 편안한 개발 환경"을 만들어준다고 말했다. Rational Team Concert와 Scrum Process 템플릿이 출시되면서 마찰이 완화된 것 중 하나는 개발 작업에 애자일 계획 및 추적을 통합하는 것이다. 최근까지도 인기있는 애자일 계획 도구를 사용할 때는 도구와 IDE(integrated development environment)를 맞춰 수행하는 작업을 위치짓고 완성한 후 진행 상태를 보고해야 했다. 이러한 활동을 통합함으로써 Rational Team Concert와 Jazz는 프로세스 인식뿐만 아니라 더 나은 가시성, 협업 기회, 추적성을 제공하는데, 이 모든 것이 단일 개발 생산성과 소프트웨어 전달을 개선하기 위해 단일 플랫폼에 모여 있다.

스크럼(scrum) 이라는 용어는 럭비 게임의 스크럼 짜기( scrummage 또는 scrimmage )를 줄인 말이다. 소프트웨어 개발이라는 맥락에서 스크럼은 애자일 개발 프로세스의 프로젝트 관리 방법으로 최고의 비즈니스 가치를 가능한 짧은 시간에 주주에게 제공하는 데 초점을 맞춘다. 스크럼 프로세스는 가장 가치있는 특성을 다음 개발에 사용할 수 있도록 하고 출시할 수 있는 때에 맞춰 작업이 항상 끝난다는 것을 강조한다. 작업은 2주에서 4주 사이의 스프린트(sprints) 또는 반복에 끝나도록 구성돼 있으며 각 스프린트 끝에 소프트웨어가 생산될 수 있도록 한다.

프로젝트 설정 과정과 첫 반복을 작업하면서 Rational Team Concert의 Scrum Process 템플릿을 사용하는 방법을 배우게 된다. 샘플 프로젝트의 데이터는 Mike Cohn의 Agile Estimating and Planning(Prentice Hall, 2005년)에서 확장된 예제로 Bomb Shelter Studios의 스크럼 팀이 Havannah라는 새 컴퓨터 게임을 작업하는 것을 설명한다. 예제의 데이터는 "Rational Team Concert Scrum 샘플 데이터"( 다운로드 를 보자)에 있다.

이 글은 독자들이 jazz.net에 등록했으며 거기서 소개하는 대로 소프트웨어를 다운로드하고 설치했다는 가정 하에 썼다. 사용하는 Rational Team Concert 클라이언트가 Jazz 저장소에 연결될 수 있는 부분까지 이해해야 할 것이다. 스크럼 프로세스에 대한 간단한 소개 후 Rational Team Concert Scrum 기반 프로젝트를 만들게 될 것이다.

스크럼 프로세스 개요

스크럼 프레임워크는 다음과 같은 상호 관련된 부분으로 이뤄져 있다.

• 역할
  
  • 제품 소유자
    
  • 스크럼 마스터(ScrumMaster)
    
  • 팀 구성원
• 행위(모임이나 미팅)
  
  • 스프린트 계획
    
  • 스프린트 점검
    
  • 스프린트 회고
    
  • 매일의 스크럼
• 산출물
  
  • 제품 백로그
    
  • 스프린트 백로그
    
  • 번다운(burndown) 차트
    
  • 장애 목록

스크럼 프로젝트에 필요한 것은 제품 백로그(Product Backlog) 의 아이템들로 이는 스크럼 프로젝트의 가장 중요한 산출물 중 하나인데 프로젝트의 모든 원하는 작업이나 기능을 우선순위대로 나열한 목록이다. 제품 소유자(Product Owner) 는 이 목록을 유지하고 프로젝트 진행이나 비즈니스 환경 변화에 따라 아이템의 우선순위를 변경하는 업무를 담당한다. 이상적인 것은 제품 백로그의 아이템이 비즈니스 가치를 주주들에게 알려줄 수 있는 것이다.

제품 소유자는 제품의 성공을 책임진다. 제품의 기능과 출시 일정을 정의하고 다양한 기능의 비즈니스 가치를 결정해야 한다. 제품 소유자는 지속적으로 제품 백로그를 다듬고 우선순위를 재조정해야 한다.

스크럼 마스터 는 스크럼이 제대로 실행되는지 확인하고 스크럼의 가치를 팀 구성원들이 이해하도록 함으로써 스크럼 프로세스를 관리한다. 스크럼 마스터는 장애를 제거함으로써 팀의 생산성을 높이고 외부 환경으로부터 팀을 보호해야 한다(적어도 스프린트 중에는).

스크럼 팀은 프로젝트를 끝낼 수 있는 적절한 기술을 여러 방면으로 가져야 한다(예: 개발자, 테스터, 인터랙션 디자이너, 작성자). 팀 구성원(team members) 은 스크럼 팀에 전념해야 한다.

팀은 각 스프린트 시작에 스프린트 계획(Sprint Planning) 미팅을 잡는다. 이 미팅에서 제품 소유자는 다음 스프린트를 대비해 가장 요구되는 기능을 소개하고 이를 설명함으로써 팀이 제품에 요구되는 것이 무엇인지 제대로 알 수 있게 해야 한다. 제품 소유자와 팀은 스프린트의 목표(본질적으로 다음 2주에서 4주의 작업에 초점을 맞춘 비전)에 합의해야 한다. 그리고 나서 팀은 스프린트 목표(Sprint Goal) 를 어떻게 달성할지 결정하고 필요한 작업에 맞게 기능을 나눈다.

이 작업 목록이 스프린트 백로그(Sprint Backlog) 가 된다. 스프린트 백로그의 아이템은 몇 시간이 걸리기 때문에 아이템이 언제 완성되는지 팀이 결정할 수 있다. 시간이 충분하지 않다면 스프린트 백로그에서 기능이 사라져 제품 백로그로 반환될 수 있다. 팀의 수행에 따라 평가가 완성되는데 이는 스크럼 마스터나 제품 소유자에 의해 결정되지 않는다.

매일의 스크럼문에 답한다.

이 미팅은 상태를 확인하는 미팅이 아니라 계획과 약속을 확인하는 미팅으로 15분을 넘겨선 안 된다. 모든 이들이 무엇을 하는지와 어떤 어려움이 있는지에 관한 이 정기적인 미팅을 통해 다른 미팅을 잡을 필요가 없고 팀 구성원들이 더 효율적으로 협업할 수 있도록 돕는다.

각 스프린트의 말미에 스프린트 점검(Sprint Review) 미팅을 통해 팀은 지금까지 완성한 작업에 대해 발표한다. 이는 간단하고 비공식적인 미팅으로 관심있는 모든 사람이 참여할 수 있다. 이 미팅의 목적은 작업하고 있는 소프트웨어(또는 기본적인 제품 아키텍처의 개요와 같은 다른 가치있는 산출물)를 보여줌으로써 미팅 참여자와 주주들로부터 피드백을 받는 것이다.

스프린트 점검 후 스프린트 회고(Sprint Retrospective ; 가끔 반성이라고도 한다)의 시간을 갖는다. 이 미팅에서 프로젝트와 진행에 있어 어떤 것이 제대로 됐는지와 안 됐는지에 대해 이야기할 것이다. 이 미팅을 통해 다음 스프린트에서 지속적으로 효율성을 높일 수 있는 작업이 무엇인지, 이를 위해 무엇을 변경할 것인지가 결과물로 나와야 한다.

제품 백로그에서 완성에 필요한 아이템이 선정되면 이는 스프린트 백로그의 부분이 된다. 스프린트 백로그는 제품 백로그의 기능과 관련된 특정 작업을 포함한다. 스프린트 중에 스프린트 백로그의 작업 아이템 상태는 매일 업데이트된다. 업데이트된 상태로 스프린트 번다운(Sprint Burndown) 차트를 만들 수 있다. 번다운 차트는 프로젝트의 남아있는 작업양을 그래프로 보여준다. 또한 스프린트 시작에서 끝까지 작업의 부드러운 진행을 표시하는 "아이디어(idea)" 행이 있는 것이 일반적이다.

진행에 방해나 장애가 있을 때 스크럼 마스터는 추가적 스크럼 산출물로 방해 목록(Impediments List 또는 장애 목록(Blocks List) )을 만든다. 모든 스크럼 산출물은 팀 구성원 모두가 볼 수 있는 곳에 있어야 한다.

Jazz Scrum Process 템플릿은 모든 중요한 스크럼 역할, 활동, 산출물을 지원한다. Rational Team Concert에서는 이클립스(Eclipse™) 기반의 리치 클라이언트 UI와 웹 UI 모두를 통해 이 기능들과 많은 다른 것들에 쉽게 접근할 수 있다.

예제 프로젝트 설정하기

Rational Team Concert와 Jazz Scrum Process 템플릿이 스크럼 팀을 어떻게 지원하는지 보기 전에 기본적으로 프로젝트를 설정해야 한다. 여기에서는 Rational Team Concert Beta 3과 Jazz, 그리고 Scrum Process 템플릿의 초기 접근 버전을 사용해 이 화면 캡처들을 만들었기 때문에 출시된 제품과 매우 비슷하게 보여야 한다.

Project Area 만들기

Jazz 서버가 가동됐는지, 즉 Rational Team Concert 클라이언트가 열리고 Repository Connection에 로그인했는지 확인하자.
새 Project Area를 만들려면 Team Artifacts 뷰(그림 1)의 Repository Connection 을 오른쪽 클릭하고 New > Project Area 순으로 선택한다.
그림 1. 새 Jazz Project Area 만들기

새 Project Area 마법사에는 창이 두 개 있다(그림 2).

첫 창에 프로젝트 이름(본 예에서는 Havannah )을 입력하고 Next 를 클릭한다.
Available Process Templates 하에서 Scrum 템플릿을 선택하고 Finish 를 선택한다(이 출시된 소프트웨어에서 Scrum Process 템플릿 이름에는 "(Early Draft)" 접미사가 없을 것이다).
그림 2. Project Area 만들기 마법사 단계

Project Area가 서버에서 초기화되는 데는 몇 분이 걸릴 수 있다. 초기화되면 그림 3과 같은 화면을 볼 수 있을 것이다.

그림 3. 이제 All Team Areas에 Havannah 프로젝트가 보인다.

Team Artifacts 뷰의 왼쪽 행에서 Builds, Reports, Streams(소스 컨트롤), Work Items(질의), Plans(본 글에서 중점으로 다루는 영역이기도 하다) 폴더와 함께 새 프로젝트 영역을 볼 수 있다. Project Area 편집기에는 프로젝트를 설명할 수 있는 공간이 있다. 아래 오른쪽 구석에 첨부 사항을 추가할 수 있는 섹션을 볼 수 있다. 이는 Scrum Process 템플릿을 지원하기 위함이지, 프로젝트 첨부 사항을 놓는 곳이 아니다 .

구성원 추가와 역할 지정하기

Project Area를 만든 사람으로 이제는 최초의 관리자(Administrator, Admin)다. 하지만 Scrum Process 템플릿 내의 프로젝트 구조를 수정하는 권한은 대부분 스크럼 마스터나 제품 소유자에게 있다. 그러므로 관리자로서 처음 해야 할 일 중 하나는 프로젝트에 구성원을 추가하고 그들의 역할을 설정하는 것이다(적어도 스크럼 마스터와 제품 소유자). 일반적으로 Project Area 멤버십은 관리 업무를 담당하는 구성원들에게 주어진다. 다른 팀 구성원들은 나중에 팀 영역에 추가될 것이다.

Jazz를 외부 사용자 저장소(회사 LDAP 서버 같은)에 구성한다면 사용자 엔트리를 만들지 않고 임포트하면 된다. 하지만 기본 톰캣 애플리케이션 서버를 사용하고 프로젝트 영역 내에 사용자를 만들어야 한다고 가정하자.

Create (그림 4)를 클릭하여 New Member 마법사를 시작하자.
그림 4. Members 뷰

Create a new user (그림 5)를 선택하고 Next 를 클릭한다. \
그림 5. 새 사용자 만들기

사용자 정보를 입력하고 사진이 있다면 사진을 추가한다(그림 6을 보자). Jazz가 팀 활동에 대해 이메일로 보고를 하기 때문에 이메일 주소는 필수 입력 필드다.
그림 6. User Information 뷰

Jazz Users 는 Project Area의 기본 권한을 가지고 있다. 이 권한으로 Work items를 만들고 추가할 수 있고 기록을 볼 수 있고 프로젝트 보안 설정으로 정의된 다른 기능을 사용할 수 있다.
Jazz Admins 는 추가 Project Areas 만들기 등 Jazz 서버와 프로젝트에 관련된 다양한 설정에 접근할 수 있다.
그림 7. Repository Groups 뷰

Developer 라이선스는 코드를 작성하고 빌드를 작동하는 팀 구성원에게 적당하다.
예를 들어 Build 와 ClearCase Connector 라이선스는 일반적으로 관리 업무를 담당하는 사용자에게만 부여된다.
Contributor 라이선스는 모든 다른 사용자에게 적당하다.
그림 8. Client Access License 옵션

Finish 를 클릭한다.
이제 Members 영역에 구성원이 있으므로 Members 목록에서 Sasha 를 선택하면 Process Roles 버튼(이전엔 작동하지 않았으나 보이는)이 작동된다.
Process Roles(그림 9)를 클릭하고 ScrumMaster role을 선택하여 이를 Assigned Roles 목록에 추가한 후 Finish 를 클릭한다.
그림 9. 역할 선택, 추가하기

그림 10은 샘플 프로젝트의 완성된 Members 목록을 보여주고 권한이 나뉠 때를 대비해 스크럼 마스터도 보여준다.

주의:
스크럼 마스터는 필요한 팀 구성원은 아니다.

그림 10. 완성된 Team Members 목록

변경 사항을 저장하면 새 팀 구성원 목록이 보일 것이고 이들에게 초청 이메일을 보낼 것인지 물을 것이다. 이메일 지원(서버를 설정할 때)을 구성했다면 프로젝트 구성원들에게 환영의 이메일 메시지와 관련 프로젝트의 링크와 정보를 보낼 것이다.

기본 카테고리 이름 변경하기

Scrum Process 템플릿을 사용하려면 필요한 또 다른 설정 아이템이 있는데 이는 스크럼 마스터나 제품 소유자가 아닌 관리자로 할 수 있는 일이다.

카테고리는 또한 기능, 업무, 결함 등을 정리하는 데 사용된다. 예를 들어 제품 정리가 가능하다면 다양한 UI 컴포넌트와 서비스용 카테고리가 있을 수 있고 웹 UI용의 다른 카테고리가 있을 수 있다. 하지만 지금은 제품 백로그가 이 업무를 담당한다.

그림 11. 카테고리 이름을 제품 백로그로 변경하기

Team Area에 구성원과 그들의 역할 추가하기

Jazz 모델에서는 큰 규모의 팀과 다중의 개발 라인 및 하위팀(subteams)을 지원할 수 있다(그림 12). Project Areas 내에는 팀 구성원을 정리할 수 있는 Team Areas가 있다. Team Areas 구성원에게만 팀과 관련된 작업을 부여할 수 있다. 예제에는 하나의 팀만 있어도 구성원들로 파퓰레이트되야만 한다.

왼쪽 창에서 Team Organization 탭을 클릭한다(그림 12). 열리지 않으면 Window > Show View > Team Organization 을 사용해 연다.
Havannah Team 폴더를 더블 클릭하여(Project Area가 만들어질 때 자동으로 만들어진다) Team Area 편집기를 연다.
편집기 창에서 Add 를 클릭해 Project Area 구성원을 선택할 수 있는 마법사를 열어 이 팀을 추가한다.
그림 12. Havannah Team의 편집기 뷰

사용자 이름 텍스트 영역에 s (글자 S )를 입력해 이름을 검색한다(그림 13).
Select 를 선택해 Sasha를 Selected Users 목록에 옮긴다.
Next 를 클릭해 스크럼 마스터에게 팀 소유자의 역할을 부여한다.
Finish 를 클릭한다.
그림 13. Add Team Members 뷰

최종 Members 목록은 그림 14처럼 보여야 한다.

그림 14. 업데이트된 Members 목록

"스프린트"라 불리는 반복 설정하기

실제 프로젝트를 계획하려면 스크럼 마스터나 제품 소유자로 로그인해야 한다. 계획 수정이라는 권한은 이들에게만 부여되기 때문이다. 출시(Release)와 반복(Iteration) 계획을 수정하려 하기 전에 이를 행하지 않으면 변경 사항을 저장하려 할 때 권한-누락(permission-denied) 오류가 생길 것이다. 자신의 프로젝트를 설정할 때 (이 예제 말고) 스크럼 마스터나 제품 소유자라면 로그아웃해 다시 로그인하는 단계를 밟을 필요가 없다.

Repository Connection(그림 15에서 볼 수 있는)의 드롭다운 메뉴에서 로그아웃/로그인을 선택할 수 있다.

그림 15. 다른 사용자로 로그아웃/로그인하기

로그아웃했던 같은 드롭다운 메뉴를 사용해 Sasha (사용자 ID와 같은 값의 비밀번호이므로 변경되지 않는 한 비밀번호도 Sasha 다)로 로그인한다. Project Area가 톱 레벨 노드이므로 이의 드롭다운 메뉴(그림 16)를 사용해 Open 을 선택(더블 클릭하면 창이 커지거나 작아지기만 한다)해야 한다.
그림 16. 프로젝트 영역 열기

Project Area 편집기가 다시 열리면 Project Area를 만들었을 때 설정한 프로세스 템플릿인 기본 위치 저장자 반복을 볼 수 있다(그림 17).

Process Iterations 하에서 Release 1.0 을 선택하고 Edit Properties 를 클릭한다.
그림 17. 출시 속성 편집하기

주의:
작업 추적은 시간이 중요하기 때문에 날짜는 이 예제를 작업하는 시점을 기반으로 해야 한다. 출시 및 첫 반복을 오늘 또는 가까운 미래로 시작하자. 출시 끝 날짜는 적어도 6주 후로 설정하자. 각 반복은 적어도 2주 안에 끝나야 한다(일반적으로 작업하지 않는 날은 빼고 월요일에 시작해 그 다음 주 금요일에 끝나는 것으로 한다).

Release 1.0 아이콘과 Sprint 1 아이콘에 있는 작은 파란색의 삼각형 모양은 현재 출시와 반복을 나타낸다.

반복을 추가하려면 Create Iteration 을 클릭해 새 반복을 추가하거나 기본 반복을 선택하고 Duplicate 을 클릭한다(그림 18). identifier와 나타난 이름을 유지하려면 복제 접근을 사용할 수 있다.
본 예제에서 제품의 세 번째 반복을 만들려면 Sprint 2 를 클릭하고 난 후 Duplicate 을 선택한다.
그림 18. 반복 복제하기

제품 백로그 기록 만들기

스크럼 방법의 가장 중요한 산출물 중 하나는 제품 백로그다.

팁:
Release 1.0 반복을 보려면 하나나 그 이상의 트리 노드를 열어야 할 것이다. 추가적인 출시와 스프린트 계획(있다면)은 개발 라인 하에 있지만(이 경우에는 Main Development) 현재 출시와 스프린트는 더 쉬운 접근을 위해 Plans 수준에서 볼 수 있다.

그림 19. 제품 백로그 만들기

제품 백로그 반복 계획용 다중 페이지 편집기가 열릴 것이다(그림 20).

Overview 페이지(아래의 탭을 보자)에서 위키 스타일 포맷을 사용해 제품 정보를 입력할 수 있다. 이는 웹 UI에서 프로젝트 웹 페이지의 부분으로 보일 것이다.
편집기 뷰 아래 쪽의 Attachments 영역은 이 출시에 필수조건이나 다른 일반적인 문서를 추가하는 좋은 공간으로 모든 팀 구성원이 볼 수 있다.
그림 20. 반복 계획 편집하기

Mike Cohn은 스토리(stories) 또는 사용자 스토리(User Stories) 가 "시스템이나 소프트웨어 사용자 또는 소비자에게 가치있을 기능을 설명한다. 스토리 포인트 는 프로젝트의 부분으로 다른 스토리와 관계있는 주어진 사용자 스토리의 크기나 복잡성을 나타낸다"라고 말한다.

각 스토리는 이 상세 내역 모두를 완성해야 한다. 곧 작업해야 하는 높은 우선순위의 스토리는 스프린트 계획 미팅 전에 가능한 빠르고 정확하게 이 상세 내역을 완성해야 한다.

Planned Items 탭을 클릭해 백로그 아이템을 추가하기 시작한다.
오른쪽 창의 드롭다운 메뉴에서 Group by 를 사용해(그림 21) Folders 뷰로 바꾼다(아직 선택되지 않은 뷰라면). 많은 새 스토리 를 추가할 때 가장 쉬운 작업이다.
그림 21. Folders 뷰로 바꾸기

원한다면 폴더(그리고 기본 폴더 이름을 바꿀 수 있다)를 추가할 수 있다. 이는 작업 아이템을 정리하는 간단한 메커니즘이다. 본 예제에서 모든 제품 백로그 아이템을 스토리로 Top Items 폴더에 추가할 것이다.

Top Items 폴더를 오른쪽 클릭하고 Add Work Item (그림 22) 다음 Story를 선택해 첫 아이템을 추가한다.
그림 22. 제품 아이템을 스토리로 추가하기

새 아이템이 폴더에 추가되고 텍스트 영역이 열려 Story Summary를 입력한다(그림 23).

그림 23. Story Summary 입력하기

이는 새 스토리를 입력하기 위한 쉬운 방법이다.

스토리가 추가되면 우선순위를 설정한다. 현재 1~10까지의 우선순위가 있다. 시스템은 사용자가 끌어다놓기(drag-and-drop)로 작업한 것을 기억한다(또는 Alt+Cursor Up and Down을 사용한다). 그러므로 이런 식으로 우선순위 내에서 정렬하려면 Group by 드롭다운 메뉴에서 User defined order 를 선택할 때마다 정렬한 방식을 볼 수 있을 것이다. 그림 24에서 보여주는 것처럼 목록 아이템에 있는 드롭다운 메뉴를 사용해 우선순위를 쉽게 부여할 수 있다.

그림 24. 스토리 우선순위 정하기

모두가 가지고 있는 것이 Story Summary라면 제품 백로그의 업무는 아니다.

스토리를 더블 클릭해 편집기를 연다(본 예제에서 "As a player, I can play against a weak engine that recognizes rings"라 설명한 스토리는 그림 25에 있다).
그림 25. 스토리 편집하기

팁:
목록을 만드는 중에 상세 내역을 추가하는 또 다른 좋은 방법은 반복 계획 편집기의 Preview 모드를 켜는 것이다. 툴바의 안경 아이콘(그림 26)을 클릭하면 편집기에는 Iteration plan과 현재 선택된 아이템이 나란히 보일 것이다.

그림 26. 스토리 미리보기

반복 계획하기

앞서 스크럼 프로세스 개요 절에서 논의했듯이 각 반복 또는 스프린트 는 제품 백로그에서 아이템을 꺼내 반복에 넣고 팀이 완성해야 하는 작업의 스프린트 백로그를 개발하는 것으로 시작한다.

스프린트 백로그 반복 계획 만들기

제품 백로그의 반복 아이템을 만드는 것과 같은 식으로 Team Artifacts 뷰의 Plans 노드에서 Sprint 1 (1.0) 을 오른쪽 클릭하고 New 를 선택한 후 Iteration Plan 을 선택한다.
마법사에서 이름에 Sprint Backlog 를 입력한다.
제품 백로그 창을 열고 원하는 스토리를 선택하고 오른쪽 클릭한 후 Plan For 를 선택하고 Sprint 1.0 을 선택한다.
그림 27. 반복 계획 만들기

이렇게 하면 스토리가 Sprint Backlog 탭으로 옮겨질 것이다. 일단 왼쪽 가장자리에 옮겨질 것을 기다린다는 표시의 작은 화살표가 보일 것이다.

작업 추가하기

이제 스토리에 작업을 추가하자.

먼저 쇼트컷을 설정해 이를 쉽게 해결하자. 첫 스토리를 오른쪽 클릭해 Work Item을 추가하는(스토리를 추가하는 것과 비슷한 방법이다) 대신 드롭다운 메뉴에서 Set Default 옵션(그림 28)을 선택한다.
그림 28. 업무 추가하기

그림 29와 같은 대화상자가 생기므로 Ctrl+Enter를 누를 때마다 기본 유형에 아이템을 자동으로 추가할 것이다. 이 대화상자는 이후 기본 Work Item 유형을 제거하거나 재부여할 때 사용할 수 있다.

그림 29. 기본 Work Item 유형 설정하기

이제 OK 를 클릭한다.

선택된 스토리 아래에 업무가 만들어질 것이다. 하지만 이는 스토리와 같은 들여쓰기 수준을 가짐에 유의하자(그림 30).

주의:
Rational Team Concert에서는 작업을 Summary 필드에 아직 입력되지 않은 작업으로 표시하겠지만 summary가 추가되면 경고문은 사라질 것이다. 원한다면 Summary를 먼저 입력해 경고를 피할 수 있다.

그림 30. 작업 들여쓰기

이 스토리에 추가된 업무는 자동으로 자식 또는 하위 스토리가 된다.

일반적인 스프린트 계획 미팅에서 팀 구성원은 이를 끝나지 않은 작업으로 인식할 것이다. 아직은 기록된 정도의 수준으로도 충분하다. 시간 예측과 부여는 미팅 끝무렵에 나올 것이다.

팁:
예측이 만들어지면 팀 구성원들의 워크로드를 추적해야 하므로 한 번에 한 스토리를 작업하자. 해야 할 시간 외의 다른 작업을 계획할 필요가 없다.

시간 예측 추가하기

첫 스토리의 업무가 결정되면 예측을 추가한다.

팀의 워크로드 계산을 정확히 하려면 팀 구성원의 가용성을 조정하자. 팀 구성원 중에는 팀 작업 외의 다른 작업을 수행해야 하는 경우도 있고 휴가 계획이 잡혀있을 수도 있다. 이는 사용자 페이지에서 조정하면 된다.

Team Artifacts 뷰에서 My Team Areas 노드를 열고 Havannah Team 폴더를 연다.
Rose 라는 이름을 더블 클릭해 상세 내역을 연다(그림 31).
그림 31. 팀 로드 조정하기

Rose는 75% 정도 시간만 팀에 할애할 수 있다.

하단의 Work Environment 탭을 클릭한 후 Work Assignment 절에서 Havannah Team 행을 클릭하고 Change 버튼을 클릭한다(그림 32).
그림 32. 부여 수준 변경하기

이렇게 하면 Rose가 작업을 수행하는 시간이 조정될 것이다. 휴가 계획 또한 잡혀있음에 유의하자.

Scheduled Absences 탭으로 바꿔 목록 오른쪽의 New 를 클릭한 후 Rose의 휴가 날짜를 입력한다(그림 33).
OK 와 Save 를 클릭해 Rose의 상세 내역을 업데이트한다.
그림 33. 부재 추가하기

Rose는 반복 시간 동안 떠나있을 유일한 팀 구성원이므로 이제 작업 예측을 시작할 수 돌아온다(필요하다면 Plans 노드를 열어 스프린트 백로그를 더블 클릭한다).

팀이 필요한 예측을 결정함에 따라 그림 34에서 볼 수 있는 작은 clock icon 을 클릭하면 나오는 드롭다운 메뉴를 사용해 쉽게 작업을 지정할 수 있다(각 작업을 더블 클릭해 열 수도 있지만 이 방법이 더 쉽다). 시간 예측이 드롭다운 메뉴에 없다면 More 를 선택한다. 그러면 작은 입력 대화상자가 떠 예측 시간을 입력할 수 있다. 예측 시간은 날짜와 시로 입력한다. 예를 들어 10 h 나 2 d 처럼 말이다.
그림 34. 시간 예측 입력하기

팁:
일반적으로 스크럼 팀 구성원은 업무를 신청함과 동시에 업무가 부여된다. 작업 완료에 따르는 시간이 팀 구성원에 따라 다르므로 작업 없이 시간 예측만 결정하는 것은 말이 안 된다. 그러므로 드롭다운 메뉴에 Havannah 팀이 된 구성원 목록이 있다.

그림 35. 작업에 사용자 부여하기

팀 워크로드는 작업이 예측되는 것처럼 모니터될 수 있다. 가장 쉬운 방법은 Team Organization 뷰(그림 36)를 보이게 만들어 예측이 만들어지는 대로 업데이트되게 하는 것이다. 이 뷰는 스프린트 백로그 뷰와 함께 계속 열려있을 것이다.

그림 36. Team Organization 뷰

Rose는 한정된 가용성과 휴가일 때문에 작업 시간이 54시간 밖에 되지 않음에 주의하자. 팀 구성원들에게 시간을 모두 부여할 때까지 계속 업무를 예측하자. 스크럼 팀의 성공을 위해 모든 구성원의 워크로드를 느슨하게 설정해 조정이 가능할 수 있도록 하자.

주의:
Team Load 뷰가 비었거나 "Not Connected, you need to configure it"라고 표시되면 Team Load 뷰 오른쪽의 아래로 향한 하얀 삼각형을 클릭해 드롭다운 메뉴(그림 37)를 사용하고 Configure 를 선택한다.

그림 37. Team Load 뷰 구성하기

다음 대화상자에서 Project Area 를 선택하고(Havannah가 이미 보일 것이다) Team Area (Havannah Team) 를 선택한다.
OK 를 두 번 클릭하면 팀 구성원의 워크로드가 그림 38처럼 보여야 한다.
그림 38. 팀 구성원을 Load 뷰에 추가하기

작업하기

팀 구성원이 자신의 업무를 추적하는 가장 쉬운 방법은 왼쪽 창에 기본으로 열리는 My Work 뷰를 사용하는 것이다. 이 뷰를 사용하려면 먼저 구성해야 한다. 구성하는 방법은 다음과 같다. 먼저 Prasad로 로그인했고 뷰를 파퓰레이트하는 단계를 설명한 캡처된 다음 세 가지 화면(그림 39, 40, 41)이 있다고 가정하자.

이렇게 하면 작업은 Current Work 창으로 이동된다.

그림 39. MyWork 뷰 구성하기

현재 작업 창(그림 40)은 작업이 "아직 완벽히 계획되지 않았(Imprecisely Planned)"지만 앞으로 몇 시간 안에 누군가에게 부여된다는 것을 나타낸다.

그림 40. 부여된 작업 수락하기

이렇게 하면 무작위의 작업 목록 대신 My Work 뷰가 팀 구성원이 끝내기로 한 작업 순서로 아이템을 보여줄 것이다. 또한 작업이 Planned Time 뷰로 Iteration Plan의 그룹에서 보일 때 미뤄진 작업의 스케쥴이 모든 사용자에게 보일 것이다.

그림 41은 부여된 작업을 보는 다른 두 가지 방법을 보여준다.

Work Item 폴더 하에서 Shared Queries 와 Predefined 폴더를 열고 Open assigned to me 질의를 더블 클릭한다. 그림 41과 같은 질의 뷰를 열 것이다.
또한 Sprint Backlog 뷰에서 오른쪽 창의 Group By 드롭다운 메뉴를 Group by Owner 로 변경할 수 있다. 이렇게 하면 각 사용자와 관련된 스토리를 보여주고 스토리가 열릴 때 스토리와 관련된 사용자의 업무를 보여줄 것이다.
그림 41. 나에게 부여된 업무의 두 가지 뷰

Query 뷰에서든 My Work 뷰에서든 드롭다운 메뉴로 아이템 작업을 시작할 수 있다. 또한 업무를 열어 상태를 변경할 수 있다(그림 42를 보자).

그림 42. 업무 작업하기

진행 상황 추적 및 기록하기

팀 구성원은 업무 작업을 시작하고 여기에 드는 시간을 기록하고 이를 해결해야 한다. 주어진 스크럼 방법이 작업 완성이 아니라 시작에 중점을 둔다면 다음 아이템으로 넘어가기 전에 작업 아이템을 시작해 완성하는 것이 좋다. 이렇게 하면 팀이 더 신속하게 스토리를 끝내고 "스프린트 점검 가능(Ready for Sprint Review)" 상태가 될 수 있다. 팀 구성원들이 예측된 업무 기록과 성공을 추적하도록 하려면 Time Spent는 사람들이 매일 작업했던 업무에 대해 기록돼야 한다(그림 43). Time Spent는 간단한 텍스트 필드이므로 며칠 동안 업무가 진행되면 각 팀 구성원은 매일 Time Spent 필드를 업데이트해 이전 값과 추가 시간을 포함시켜야 한다.

그림 43. 사용된 시간 기록하기

Discussion 기능을 사용해 진행 상황을 기록하거나 업무에 관해 배운 정보를 캡처한다. 어떤 팀 구성원이든 이 필드에 정보를 업데이트할 수 있고 이는 작업 아이템의 기록을 캡처할 수 있는 훌륭한 방법이다.

스토리 진행 상황은 작업 시작으로 추적돼야 한다. 가끔 팀 구성원 중 누군가가 스토리 전체를 담당한다고 설정하므로 스토리 하의 업무가 완료되면 매일의 스크럼 미팅 동안 스크럼 마스터는 스토리를 "스프린트 점검 가능" 상태로 설정할 수 있다(그림 44를 보자). 이 스토리 상태는 Project Area Dashboard 에 기록된다.