[지디넷코리아]효율적인 협업은(Collaboration) 현재의 IT 환경에서 가장 큰 이슈가 되고 있는 문제 중의 하나다. 비즈니스가 복잡해지고 규모가 커지면서 다양한 이해 관계자와의 협업의 중요성이 매우 커졌기 때문이다.

이미 시장에는 수 많은 협업 솔루션 들이 나와 있다. 단순한 메일 서버에서부터 어마어마하게 비싸고 복잡한 솔루션까지 그 종류는 매우 다양하다. 또한 수 많은 방법론이 저마다 이렇게 해야 한다며 목소리를 높이고 있다. CMMI, Software Six Sigma. SPICE, Rational Unified Process등의 프로세스 관리론 및 개발 방법론도 점차 그 세를 넓히고 있는 상태다. 이렇게 혼란스러운 현 상태를 협업이라는 주제가 얼마나 어려운지를 반영하는 증거라고 볼 수도 있겠다.

독자 분들도 이미 아시다시피 팀 파운데이션 서버는 애플리케이션 생애주기(Application Lifecycle)에서의 협업을 지원한다. 그리고 MSF for Agile Software Development와 MSF for CMMI Process Improvement의 두 가지 템플릿을 제시하고 있다.

하지만 소프트웨어 개발에서의 협업이란 매우 복잡하며 또한 다양하다. 개발 인력의 규모, 조직의 문화, 프로젝트의 성격 등 다양한 요소로 인해 차이가 발생하며, 어떠한 한 가지 모범 답안으로 해결 할 수 없는 특성을 가지고 있다. MS가 아무리 고민하여 팀 파운데이션 서버를 만들고 템플릿을 제공한다 하더라도 모든 조직에 그대로 적용 될 수 있는 것은 아니다.

이는 모든 기성복이 내 몸에 딱 맞지는 않는 것과 같다. 이러한 문제를 해결하기 위해 팀 파운데이션 서버는 사용자가 커스터마이즈 할 수 있는 다양한 기능을 제공한다. 이번에는 그 중 중요한 두 가지에 대해 알아 보도록 하자.

작업 항목(Work Item)의 유형 추가 및 변경
팀 파운데이션 서버는 버그, 품질 요구 사항, 작업, 위험 요인, 시나리오의 5가지 유형의 작업 항목을 기본적으로 제공하고 있다. 하지만 추가적인 유형이 필요 한 경우가 있다. 예를 들어 조직의 정책상 1주일에 한 번은 코드 리뷰를 해야 할 수도 있을 것이며, 이러한 항목도 팀 파운데이션 서버를 통해 통합적으로 관리 되면 좋을 것이다.

이러한 항목을 팀 파운데이션 서버에서 같이 관리하기 위해서는 새로운 유형의 작업 항목을 등록 할 수 있어야 하고, 팀 파운데이션 서버는 이미 이러한 기능을 제공하고 있다.

비주얼 스튜디오를 기본 폴더에 설치하였다면 "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies" 에 witexport.exe와 witimport.exe가 있는 것을 확인 할 수 있을 것이다. 이 프로그램들을 이용하여 사용자는 팀 파운데이션 서버에 새로운 작업 항목의 유형을 등록하고, 기존 작업 항목을 추출 할 수 있다.

작업 항목의 추출 예

위의 그림에 보여지는 예는 "Task" 작업 항목의 구성을 추출하여 "New Task.xml" 이라는 파일에 저장하도록 하는 것이다. 이 명령이 정상적으로 수행되면 그림에서와 같은 메시지가 출력 된다.

이 파일을 열어 보면 XML로 구성되어 있으며, 대부분의 내용은 쉽게 파악 할 수 있다. 이러한 XML 파일의 스키마를 파악하기 위해서는 비주얼 스튜디오 2005 SDK의 "Authoring Work Item Types.doc" 파일을 참조해야 한다. 비주얼 스튜디오 2005 SDK는 현재 베타 버전으로 VSIP (Visual Studio Industry Partners)로 등록 되어 있어야 받을 수 있다.

이제 사용자는 필요에 맞게 내용을 수정하여 사용 할 수 있다. 예를 들어 기본적으로 Bug는 Active와 Closed의 값을 가지게 되어 있다. 하지만 조직에 따라 이보다 더 다양한 항목이 필요 할 수 있다.

예를 들어 테스트 엔지니어가 버그를 등록하면 Active이고, 프로그래머가 해결하면 Resolved 상태로 바뀐다. 하지만 테스트 엔지니어가 그 내용을 확인 했을 때 완전히 해결 된 것이 아니라면 Reactivate 할 수 있고, 최종적으로 해결 된 것을 확인 하면 Closed로 설정 할 수도 있을 것이다. (이 예는 Joel on software의 "Painless Bug Tracking" 에서 인용 한 것이다. 이 글은 버그 트래킹이 어떻게 진행 되어야 하는지에 대한 좋은 예를 보여 주고 있으므로 관심 있는 독자 분은 읽어 보시길 권한다.)

또한 추가적인 항목이 필요 한 경우 추가 할 수도 있다. 예를 들어 Error Sequence 라는 항목을 만들어 오류를 재현하기 위한 조작 순서를 기입하게 하도록 할 수 있다.

XML의 파일을 수정 한 후 witimport.exe 프로그램으로 팀 파운데이션 서버에 임포트 하면 이러한 변경 사항들이 반영 된다.

작업 항목 XML 파일의 예

프로젝트 템플릿의 변경
최근 소프트웨어 개발의 프로세스에 대한 관심이 상당히 높아지고 있다. IBM은 RUP (Rational Unified Process)를 오픈 소스 프로젝트들에 적용 하기 위하여 많은 노력을 기울이고 있으며, CMMI (Capability Maturity Model Integration)와 같은 프로세스 인증 역시 대기업을 중심으로 확산 되어 가고 있다.

앞서도 언급 한 바와 같이 팀 파운데이션 서버는 애플리케이션 개발 과정에서의 프로세스 지원을 위해 두 가지의 템플릿을 기본 제공하고 있다. 이러한 템플릿들은 프로세스의 안내 자료와 필요 문서의 템플릿 등으로 구성되어 있다.

하지만 이러한 문서들은 조직마다 모두 다를 수 밖에 없다. 조직 내부에서 사용중인 프로세스가 기본 제공 되지 않을 수도 있으며, 설사 제공된다 하더라도 구체적인 부분에 있어서는 제공 되는 템플릿과는 차이가 있을 수 있다. 이러한 프로세스는 도입하는 조직의 현재 상태에 맞게 최적화 (Tailoring)되기 때문이다. 문서 서식 역시 조직에서 사양하는 문서 서식을 적용해야 할 것이다. 최소한 영어로 제공 되는 문서 템플릿의 한글화라도 해야 하지 않겠는가?

팀 파운데이션 서버는 프로세스 템플릿 매니저를 통해 새로운 템플릿을 추가하고, 기존 템플릿을 수정하여 사용 할 수 있는 방법을 제공한다.

템플릿 매니저

Download 기능을 이용하여 선택 된 템플릿의 파일들을 로컬 폴더로 받을 수 있다. 템플릿은 다양한 XML 파일들과 문서 파일들, 그리고 프로젝트 포탈에 계시 될 프로세스 안내 페이지 등으로 구성 된다.

이제 사용자는 문서의 서식을 변경/추가하고, 안내 페이지를 커스터마이즈하여 개발 관계자들에게 제공 할 수 있다. ProcessTemplate.xml 파일을 수정하여 해당 템플릿의 주요 항목을 변경 할 수 있고, 앞서 설명한 작업 항목 유형의 추가나 작업 항목의 변경 등도 함께 처리 할 수 있다. 즉, 완전히 커스터마이즈 된 프로세스 템플릿을 사용 할 수 있게 된다.

사용자 템플릿이 추가 된 모습

하지만 한 가지 문제가 있다. 현재의 영문 버전에서는 한글로 XML 파일의 내용을 변경 하였을 경우, 정상적으로 Upload가 되지 않는다는 것이다. 한글이 들어갈 경우 XML 구조상 전혀 문제가 없음에도 불구하고 에러를 내고 Upload가 중단된다. 이 문제는 한글 버전이 출시되면 해결 될 것으로 보이지만 좀 의아한 부분이다.

마치며
지금까지 작업 항목과 프로세스 템플릿의 커스터마이즈에 대해 살펴 보았다. 이러한 기능을 통하여 사용자는 자신의 조직에 맞게 여러 항목들을 맞춰 나갈 수 있게 된다. 더욱 중요한 것은 이러한 작업을 처리 할 수 있도록 팀 파운데이션 서버가 설계되어 있다는 것이다.

비주얼 스튜디오 2005 SDK의 문서를 보면 지금까지 살펴 본 XML 수정 방식 외에도, 클래스 구조를 제공하여 애플리케이션을 통한 접근을 가능하게 해 주고 있다. 이러한 근간이 마련 되어 있다는 것은 팀 파운데이션 서버를 위한 다양한 써드 파티 애플리케이션이 만들어 질 수 있다는 것을 의미한다. 이미 몇몇 제품이 출시 되어 있으며, VSIP 프로그램을 통해 다양한 애플리케이션이 개발 중이다. (참고 : http://msdn.microsoft.com/vstudio/extend/default.aspx )

작업 항목(Work Item)의 클래스 구조

하지만 현재의 상황만으로 본다면 너무 부족한 것이 사실이다. XML 파일을 직접 열어 내용을 분석해야 하며, 스키마에 맞게 정확하게 변경해야 하기 때문에 작업이 너무 어렵고 복잡하다. 유니코드 인코딩을 지원하면서도 한글 지원에 문제가 있다는 것도 아쉬운 일이다. (물론 한글판에서는 해결 되어 있으리라고 믿는다)

어려운 일이기는 해도, 프로세스의 테일러링은 아주 중요하다. 어설프게 적용한 프로세스는 개발 팀원들을 복잡한 절차와 문서의 홍수에 휩쓸리게 하여 익사시켜 버릴 것이기 때문이다. 필자는 얼마 전 CMMI 레벨 3를 적용한 프로젝트의 문서 수를 보고 경악 한 적이 있다. 6개월 정도의 기간 동안 진행 되었고, 실제 구현은 2개월 남짓 기간이 소요된 프로젝트였는데 무려 3800여 개의 문서가 작성 되어 있었다.

이러한 경우는 분명히 본말이 전도된 경우라 할 수 있겠다. 프로젝트의 진행을 잘 하기 위해 문서를 만드는 것이지, 문서를 만들기 위해 프로젝트를 하는 것은 아니지 않은가?

프로세스 그 자체는 너무나도 복잡한 소프트웨어 프로젝트를 구원 할 힘을 가지고 있지 않다. 프로세스를 어떻게 사용하느냐가 중요한 것이며 조직의 상황에 맞게 적용 해야 하는 것이다. 아직은 좀 부족하다고 느껴 지지만, 팀 파운데이션 서버의 커스터마이즈 지원 기능을 가능한 이용하여 최적화 된 프로세스를 구축 하시기를 기원한다.

필자 이병철님은 CISA, PMP, MCSD .Net, SCJP로 10년에 걸친 소프트웨어 실무 경험을 가지고 있으며, 생산성을 높여 줄 수 있는 개발 툴에 대한 관심이 높다.