[u] Story 의 naming convention 을 Story 방식으로 변경함.

팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.

RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.

Work Item Hierarchy vs. Iteration Hierarchy

• Epic 은 Release Backlog 이상 레벨에만 존재한다. Product Backlog 는 당연히 이에 해당되며, Sprint(Iteration) Backlog 에 나타나면 안된다.
• Story 는 Sprint Backlog 에 할당된다.
• Story 가 한 Sprint 에 끝낼 수 없을만큼 크다면 타입을 Epic 으로 변경한다.
• 반대로, Epic 이 한 Sprint 에 끝날 수 있을만큼 작다면 Story 로 변경한다.
• Task 는 당연히 Sprint Backlog 에 할당된다.

덤으로..

• Epic/Story 에는 owner 를 할당하지 않는다. (Task 에만 owner 를 할당하라.)
• Task 의 크기는 4시간 이내가 적당하다. (이를 초과하면 두 개 이상의 더 작은 Task 로 분할하라.)
• Task 밑에 하위 Task 가 존재할 수 없다.

Work Item Hierarchy and Progress

• Backlog 진척도 = Backlog 안의 모든 Story 들의 Story Point 총합.
• Epic 진척도 = 모든 하위 Story 들의 Story Point 총합.
• Story 진척도 = 모든 하위 Task 들의 작업 시간 총합.

추가로..

• Story Point 는 Release Burndown 차트 생성의 기초 자료가 된다.
• 작업 시간은 Sprint Burndown 차트 생성의 기초 자료가 된다.

Work Item Naming Conventions

• Epic: 고수준 요구사항 – ‘명사’ 혹은 ‘명사구’.
• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + be able to..’.
• Task: 명령문 – ‘동사 + 목적어’.

스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.

1. 사용자와 고객의 관점에서 요구사항이 정리되므로, 커뮤니케이션 로드와 오해를 최소화시킨다.
2. 개발자에게는 구현 목적을 명확히 해준다. (이 기능이 고객에게 어떤 가치를 제공하는지 쉽게 알 수 있다.)
3. 고객에게 불필요한 요구사항이 포함되는 것을 최소화시킨다. (주로 엔지니어의 흥미나 욕심이 반영될 경우 발생한다.)
4. Story 그대로 사용자 테스트 항목이 되고 데모 시나리오가 된다.

혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.

• Story: 저수준 요구사항 – ‘주어 + { MUST | SHOULD | MAY } + 동사 + 목적어’.

새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].

최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.

그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.

• MBO 관리
  • 그룹장의 MBO 에서 각 사원의 세부 task 까지 한 눈에 확인 가능.
  • 자신이 하고 있는 일이 팀의 어떤 목표와 관련되어 있는지 항시 인지할 수 있다.
• 주간 보고 (Weekly Meeting)
  • Scrum 의 Sprint 주기를 1주로 하면 현행 주간 보고 시스템과 차이가 최소화된다.
  • 현 시스템을 대체하는 것으로 시작해 진입 장벽을 낮추고, 차차 개선시킨다.
  • 현 주간 보고 방식에 비해 context-awareness 가 월등히 높다.
• 일일 작업 관리 (개발자 관점)
  • 개발자 관점에서 매일매일 자신의 task 를 효율적으로 관리하는 방법을 보여준다.
• 일일 작업 관리 (리더 관점)
  • 리더 관점에서 팀의 업무 진행 상황을 빠르게 파악하여, 부하 분산, 우선 순위 조정, 이슈의 빠른 해결 등을 도와주는 방법을 보여준다.
• 실시간 리포팅 (Work Load, Progress, Risk, Open Issues and Defects, ..)
  • 팀원과 리더뿐 아니라  모든 stake holder 들이 별도의 보고 요청 없이 실시간으로 과제의 진행사항을 파악할 수 있는 방법을 다룬다.
• Review & Planning & Retrospective
  • RTC 활용으로 정보 공유가 원활해지므로, weekly meeting 을 현행 주단위 업무 보고 성격에서 스크럼 형태의 효율적 회의로 변화시킨다.
  • 이 과정에서 회고 (retrospective) 의 중요성을 강조한다.
• 요구사항부터 구체적 기능 태스크, 구현, 빌드, 검증까지..
  • 태스크와 그 구현에 따른 코드 변경, 빌드, 테스트, 결함 등록, 수정 완료 에 이르는 과정을 데모를 통해 보여준다.

기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.

---

References

1. IBM Rational Team Concert (jazz.net)
2. Choose Right Tools for Efficient Collaboration (wegra.org)