|
|
 |
|
| WIT로 완벽하게 태스크 관리하기 |
| |
| [ 노규남(IT테크라이터) 2005/10/21] |
| |
이번에 알아볼 내용은 Work Item Tracking(이하 WIT)이다. 사실 Work Item이라는 이름은 좀 생소하지만 'Issue Tracker'라고 하면 어떤 것인지 금방 알아듣는 독자들도 적지 않을 것이다. 프로젝트가 간단하다면 개선사항, 버그리포트 등을 프린트한 문서로 전달하는 방법도 나쁘지 않으나 현대에 있어서 점점 규모가 커지는 프로젝트는 이런 이슈를 체계적으로 관리할 필요성이 크게 대두되고 있다.
Issue Tracker의 유용성은 이미 큰 프로젝트 여러 가지에 적용되어 입증되어 왔는데 대표적인 것으로 Mozilla Project에 사용되었던 BugZilla나 최근에 급부상한 TRAC을 들 수 있다. VSTS에서도 팀시스템을 도입하면서 이번에 드디어 Issue Tracker를 채용하게 되었는데 그 기본은 기존의 Issue Tracker와 크게 다르지 않다.
즉, 이슈를 제기하고, 제기된 이슈의 히스토리를 추적함으로써 효율적인 프로젝트 관리를 꾀하는 것이 Issue Tracker의 목적이라면, WIT도 비슷한 목적을 가지고 있다. 하지만 Issue Tracker와 WIT는 비슷한 점만큼이나 다른 점도 많다.
MSF Agile의 Work Item
백문이 불여일견이라고 실제 테스트를 통해 WIT가 어떻게 작동하는지 알아보자. 일단 새 프로젝트가 만들어지면 Team Explorer에서 기본적으로 "Work Item" 폴더를 찾을 수 있는데 이 폴더가 Work Item에 대한 것이다. template에 따라 다르지만 여기에는 프로젝트가 만들어질때 처리해야 하는 Work Item들이 디폴트로 만들어져 있으므로 이 Work Item들을 참조하면 어떻게 사용하는지 금방 익힐 수 있다.
 | | Work Item을 연 화면 |
필자가 선택한 ‘MSF for Agile Development'(이하 MSF Agile)의 경우를 예로 설명하겠다. Work Items - Project Queries - All Work Items를 선택해보면 현재 프로젝트에 존재하는 모든 Work Item이 리스팅되며 여기서 자동으로 만들어진 Work Item이 27개 있는 것을 확인할 수 있다.
이 27개의 Work Item은 현재 Active한 상태로, 이들은 project template에서 규정한 ‘의무적으로 처리해야 하는 업무’라고 보면 된다. 그중에 첫 번째 아이템을 보면 ‘Setup : Set Permissions'라고 되어 있는데 그 내용을 보면 프로젝트를 시작해서 맨 처음 해야 하는 일이 참여하는 사람들에게 적절한 권한을 부여하는 것이라는 사실을 알 수 있다. 이 일은 프로젝트의 관리자가 해야 하는 일이므로, 관리자 계정으로 로그인한 후 Team - Team Foundation Server Settings - Permissions에서 권한을 부여하면 된다.
그 결과 프로젝트 참여자 모두에게 작업 가능한 권한이 주어졌다면 이 Work Item은 해결된 것으로 간주하여 ‘Closed’로 상태를 바꿀 수 있다. 타입에 따라 의미는 다르지만 이 상태는 더 이상 이 Work Item에 대해 수행할 작업이 없다는 사실을 명시하는 것이다.
이런 식으로 만들어진 Work Item을 차례대로 처리해나가는 것이 VSTS의 프로젝트 진행방식이다. 권한이 있는 어떤 개발자라도 Work Item을 더할 수 있고, 또 상태를 변경할 수 있다.
Work Item = Issue?
그러면 WIT가 Issue Tracker와 비슷하다고 했으니 Work Item은 Issue인가? Work Item은 분명히 Issue와 유사한 부분이 많다. 누군가가 제시하고, 이에 대해 의견을 공유할 수 있으며, 해결될 때까지 수명이 지속된다. 하지만 Issue는 통상 ‘버그’나 ‘개선요망’ 등 완성된 프로젝트에 무언가를 제기한다는 느낌인데 반해 Work Item은 그보다는 오히려 Project의 Task에 가깝다고 할 수 있다.
통상의 Issue Tracker와 비교하여 WIT가 나은 점은 이런 것이다. 즉, 제품의 버그나 품질을 관리하는 것뿐만 아니라, 프로젝트의 작업과 그에 관계된 일정을 관리하는데도 같은 방법을 사용하고 똑같이 관리할 수 있다는 것이다. 관리자 입장에서 본다면 개발중에는 Task를 관리하는 방식으로 일정을 체크하고 진행할 수 있으며 개발이 어느 정도 끝난 후에는 버그리포트를 받는 방식으로 제품의 품질을 관리할 수 있다.
또한 Work Item은 앞서의 TFSC에서 설명한 것처럼 ChangeSet과 연동시킬 수 있으므로 프로젝트를 통합적으로 관리하는데 좀더 유리하다. 또 뒤에 설명하겠지만 VSTS는 프로젝트를 시작할 때 자동적으로 만들어지는 관리용의 MS Project 파일(*.mpp)나 체크리스트(*.xls)파일등을 열어서 Work Item을 다운로드받고 수정한 후 이를 다시 TFS에 Work Item으로 Publishing하는 것이 가능하다. 다시 말해 프로젝트를 관리하기 위해 MS Project에서 Task를 정의했다면 이를 다시 Work Item에 수동으로 더할 필요없이 양쪽의 내용을 완전동기화할 수 있다는 장점이 있다.
정리하자면 프로젝트내의 ‘해야하는 모든 일’들은 Work Item으로 간주된다. 그래서 단순히 제기된 것(Issue)이 아닌 Work Item이라는 이름은 더욱 적절하다. ‘내가 무엇을 해야 하는가?’부터 ‘팀이 무슨 일을 해야 하는가?’를 전부 규정한 것이 이 Work Item이라는 것이다. 나의 할당된 작업이 무엇인지, 관리자 입장이라면 저 사람이 해야 할 일은 무엇이고, 해결된 일은 무엇인지, 새롭게 어떤 해야할 일들이 제시되었는지를 모두 한눈에 파악할 수 있는 도구가 바로 WIT이다.
Work Item의 종류
그러면 어떤 Work Item들이 있는지에 대해서 알아보자. 사용가능한 Work Item의 종류는 project template에서 정의하게 되어 있는데 TFS의 디폴트 template인 MSF Agile의 경우 TFS beta2 기준하여 Task, Bug, Senario, Quality of Service Requirement 의 네 가지를 지정할 수 있게 되어 있다. 이 타입들은 사용자의 요구에 따라서 project template가 변경되면 추가될 수도 있고 그 의미가 바뀔 수도 있다. 하지만 이하에 언급하는 타입들은 앞으로도 대부분의 project template에서 비슷하게 사용될 것 같다. 현재 각 타입의 의미는 다음과 같다.
Task : 수행해야 하는 작업. 가장 WIT에서 일반적으로 많이 쓰인다. 작업이 끝나면 Closed로 상태가 바뀌어야 한다.
Senario : 시스템에서 예상되는 사용자와의 상호작용을 정의한다. UML식으로 말하자면 ‘Use Case’이다. 한 Senario가 Completed되었다는 것은 ‘개발팀에서 이 Senario에 대한 코드를 완성했다’라는 의미이다. 그렇게 되면 이 Senario는 Tester에게 할당되어 테스트를 진행하게 되며, 테스트에서 아무런 문제가 없으면 Closed된다.
Quality of Service requirement : 제품의 QoS를 보장하기 위한 Work Item으로, ‘시스템이 이러저러 해야 한다’라는 제약(constraint)의 형태가 되는 경우가 많다. 가장 흔한 예를 들자면 성능에 대한 제약으로, 최종적인 제품이 이 정도 이상의 성능을 내야 개발이 완료되었다고 간주하는 것이다. 이 Work Item이 Completed된 것은 Senario와 마찬가지로 이를 충족하는 코드가 완성되었다는 의미이다. Tester는 이 제약에 맞는지 코드를 테스트하고, 원하는 조건을 갖추었다면 비로소 Closed되어 수명을 다하게 된다.
Bug : 시스템에 발생한 문제를 의미한다. 이 버그를 수정한 코드가 Check In되면 상태가 Fixed로 바뀐다.
이제 MSF Agile에서 팀원들이 어떤 ‘할일’을 수행해야하는지 명확해졌을 것이다. Work Item을 프로젝트에 더하고 싶을 때는 Team Explorer의 Work Items에서 오른쪽 마우스 버튼을 누르면 언제든지 추가가 가능하다. MSF Agile에는 지정 가능한 Work Item이 이렇게 네 개 뿐이어서 좀 부족하다고 느낄지도 모르겠는데 이 타입은 선택한 project template에 의해 결정되는 것이므로 향후 MS가 발표하는 project template중에 자신의 조직에 맞는 것을 선택하면 얼마든지 복잡한 프로젝트도 관리할 수 있다. 원한다면 대부분 xml 파일로 만들어진 project template을 직접 수정해도 된다. 이전에 언급한대로 이 template는 5~20명 규모의 조직에서 사용함을 가정한 것인데 그 정도 크기의 조직에서 수행하는 일반적인 프로젝트라면 이 Work Item들만으로도 충분히 관리가 가능하다고 여겨진다.
Add Query
Work Items - Project Queries에 나타나 있는 리스트들은 모두 전체 Work Item에서 특정한 아이템만을 골라내는 쿼리를 지정한 것이다. 예를 들어 ‘나에게 할당된 Work Item만을 보고 싶다’라는 쿼리가 있을 수 있고, ‘만들어진지 1주일이 되었는데 해결되지 않은 아이템들을 리스트해라’는 쿼리도 있을 수 있다.
앞서의 메뉴에서 보여 지는 쿼리들은 모두 빌트인으로 프로젝트가 만들어질 때 같이 만들어지는 아주 기본적인 쿼리이며 여기에 자신이 원하는 대로 쿼리를 추가해서 프로젝트 진행에 도움이 되게 할 수 있다. 이를 위해 Project Queries외에 처음에는 비어있는 My Queries 폴더가 있는데 양쪽 폴더 어느 쪽에서도 새로운 쿼리를 추가할 수 있다. 이 쿼리는 Field, Operator, Value의 값을 지정하여 조건을 And/Or해나가면서 원하는 결과가 나오게끔 조정하게 한다.
이렇게 해서 쿼리를 저장하게 한 이후 Team Explorer에서 더블클릭하면 하면 원하는 결과셋을 바로 찾아주게 되는 것이다. 초기에는 디폴트로 만들어진 쿼리셋만으로도 크게 문제가 없겠지만 프로젝트를 진행하면서 Work Item의 숫자가 늘어나게 되면 효율적으로 관리하기 위해 이런 쿼리의 추가는 반드시 필요할 것 같다.
 | | Add Query |
Work with Excel / Project
Excel은 VSTS에서 사용되지 않더라도 이미 일정관리, 프로젝트 관리등에 널리 사용되고 있다. Excel의 차트와 자동계산식은 이런 종류의 작업에 매우 적합한데 Excel 2003을 설치하게 되면 새로 만들어지는 ‘Work Item' 툴바를 통해서 TFS에 접속하고 Work Item을 받아올 수 있다. Project의 기능도 Excel과 크게 다르지 않으나 Excel이 Work Item의 형태로 리스트를 관리한다면 Project는 Task의 형태로 보여준다는 점이 다르다. 이것은 두 프로그램의 기본 타입이 다른 차이점으로 봐야 할 것이다.
실제 프로젝트에서 사용할때는 VSTS에서 새 Team Project를 만들게 되면 Document Library(프로젝트명-Documents)의 Project Management 폴더밑에 “Development Project Plan.mpp”나 “QoS Requirements.xls” 같은 Project/Excel 파일들이 생성된다. 이 파일들은 TFS에 저장되는 것이므로 공유하여 프로젝트 관리에 사용할 목적으로 만들어진 것인데 앞서 얘기했던대로 ‘Work Item' 툴바로 TFS에 접속해 Work Item 목록을 받아오고 수정한 후 이를 서버에 Publish 하면 프로젝트 파일이나 Document Library의 Excel파일과 TFS의 Work Item 목록은 완벽하게 연동된다.
사실 WIT가 Task관리를 해주지만 아무래도 일정 관련한 기능은 Project의 다양한 차트형식과 리포트를 따라올 수 없다. WIT에서 하나씩 Work Item으로 Task를 입력하는 것보다는 Project에서 Gantt Chart를 보면서 전체 일정을 잡는 쪽이 훨씬 편하지 않은가. MSF Agile의 기본문서중에 Excel이나 Project 파일이 포함되어 있다는 사실은 '어떤 부분에서는 Excel이나 Project를 사용하는 것을 권장한다’라는 의미이며, 이를 좀더 편하고 효율적으로 사용할 수 있게 하기 위해 TFS와 동기화하는 기능이 추가되었다고 생각할 수 있을 것이다.
WIT는 TFS 선택의 이유
이렇게 해서 TFS의 Task Management 기능이라 할 수 있는 WIT에 대해서 알아보았다. 사실 어느 정도 규모가 있는 업체가 아니면 프로젝트 일정 및 작업의 일관된 관리가 어려운 상황에서 TFS에 일반적인 것부터 버그, QoS 요구까지 모든 작업을 처리할 수 있는 도구를 포함시켰다는 것은 대단히 고무적이다.
또한 Project나 Excel과 WIT는 Work Item List를 서로 연동할 수 있으므로 기존에 사용하던 형식이나 도구와 호환할 수 있다는 점도 훌륭하다. 다만 제대로 사용하려면 Excel 2003이나 Project 2003이 필요하다는 것과 아직까지 한글화가 전혀 되어 있지 않은 점은 필드에서의 확산에 걸림돌이 될 수 있다.
어쨌거나 이런 점들을 고려하고라도 WIT는 충분히 비용을 지불하고 사용할만한 가치가 있는 좋은 솔루션이므로 개발자들이 TFS를 선택할만한 또 하나의 이유가 될 수 있을 것이다.
필자 노규남님은 게임개발에 주력하고 있으며, 오랫동안 각종 플랫폼에서 사용되는 개발도구를 사용한 경험이 풍부하다. |
 |
|
|
 |
 |
|
|
|
