티켓 주도 개발(ticket-driven development; TiDD)

이번 포스팅은 위키피디아 일본어판의  티켓 주도 개발 설명에 기초하여 작성되었음을 밝혀둔다.

티켓 주도 개발이란?

티켓 주도 개발(ticket-driven development; TiDD)이란 일본발 소프트웨어 개발 방식중 하나로 개발 과정 발생하는 테스크를 분할한 후에 이를 Track, Redmine과 같은 이슈 트래킹 시스템에 등록하여 관리해 나가는 개발 스타일을 지칭한다.  WBS(Working Breakdown Structure)를 기반으로 하는 기존의 폭포수 개발방식은 물론이고 XP나Scrum, Kanban과 같은 애자일 개발과도 궁합이 좋다.  같은 이니셜을 지니게 되는 테스트 주도 개발(TDD)과 구분하여 TiDD라는 약칭을 사용한다.

프로젝트 룰

기본적으로 티켓 주도 개발에 있어서 룰은 단 한가지다.

No Ticket, No Commit! (티켓 없이는 커밋도 없다!)

Subversion이나 Git를 이용하는 형상관리상, 커밋이란 개인이 관리하는 소스가 공동관리하에 들어간다는 것을 의미한다.  룰은 단순하지만 이슈트래커에 모든 테스크가 관리됨에 따라 개개인의 작업에 대한 파악이 간편해지고 성과물의 갱신이 반드시 티켓과 연관지어지게 됨에 따라 변경이유가 명확해지는것이 이 티켓 주도 개발의 매리트이다.

개발 사이클

티켓 주도 개발은 일반적으로 다음과 같은 PDCA(Plan/Do/Check/Action)사이클의 반복이다.

• 큰규모의 릴리즈 계획을 작성한다
• 작업을 작은 단위의 테스크로 분할하여 이슈 트래커에 등록한다.(티켓 등록)
• 이터레이션 단위로 테스크를 모아 이터레이셔계획을 작성한다.
• 테스크를 선택하여 실시한다.
• 결과물을 커밋하고 종료한다.(티켓 클로즈)
• 이터레이션에 포함된 모든 테스크가 종료되면 릴리즈를 실시한다.
• 릴리즈후에 작업에 대한 회고를 진행한다. 
• 다음 이터레이션계획에 고객의 요구사항과 회고의 내용을 반영한다.

이점

티켓 주도 개발의 이점은 다음과 같다.

• 언제나 누구든지 티켓을 참조하는것이 가능해져, 커뮤니케이션이 쉬워진다.
• 돌발적인 테스크 변경에도 티켓 속성의변경이 간단하므로 변화대응이 쉽다.
• 이터레이션 작업량을 일정하게 하는것으로 작업의 리듬을 만들어 나갈 수 있다.
• 티켓을 이터레이션 단위로 관리해 나가기 때문에,  빈번한 릴리즈를 가능하게 한다.
• 티켓이 소스코드,요건,테스트케이스와 연관지어지므로 상호 추적이 가능해진다.
• 이러한 티켓중심의 워크플로는 버그관리뿐만 아니라 요건관리를 포함해 소프트웨어 개발 전 과정에서 응용 가능하다.  
• 진척관리면에서 모든 작업 진행상황이 투명해 지므로 프로젝트 현황의 파악이 대단히 용이해진다.

성공을 위한 팁

끝으로 필자가 티켓 주도 개발에 참여하며 느낀점을 간단히 정리해 보았다.

• 무엇보다 팀원 개개인이 프로젝트의 주체로서 능동적으로 행동해 나간다는 의식이 TiDD 성공의 열쇠이다. 역으로 티켓 주도 개발의 큰 장점중 하나는 이러한 의식을 뿌리 내리게 하는데 도움을 준다는 점이다. 처음 도입시에는 여러가지 어려움이 많으므로 적절한 외부 코칭이나 기존에 시행하고 있는 팀과의 노하우 공유가 큰 도움이 된다.
• 티켓의 할당은 개개인이 선택하는것이 바람직하며 데일리 미팅등을 통해 팀원들과 진척사항을 공유해 나가야 한다. 
• 형상관리 시스템에 커밋시 특정 형식에 맞추어 번호를 기입하는 것 만으로도 이슈트래커가 티켓과 소스의 링크를 자동 생성해 주는 기능을 이용한다.

          Trac Links
          Redmine의 Subversion연동설정

• 최초 티켓 등록은 PM이나 팀 리더에 의해 이루어지 지지만 테스크 진행 결과 서브 테스크 분할이나 후속작업등이 필요하게 되는 경우에는 추가로 티켓을 발행한다.
• 티켓 분할은 일단위 작업이 될때까지 진행하는것을 권장한다.
• 타임 박싱 관리기법에 의해 릴리스 시기에 맞추지 못하게 된 우선순위가 낮은 티켓은 다음 릴리스로 이관한다.
• 이슈 트래커 툴의 선택에 있어서는 Trac과 Redmine을 추천하며 특히 Redmine의 경우 티켓간의 관계설정(전/후,부모/자식)이나 상태전이를 커스터마이징등의 기능들이 기본제공된다.
• 작업자들은 리팩터링이나 테스트케이스의 추가를 능동적으로 판단하여 티켓에 등록할 수 있어야 하고 PM과 우선순위와 일정등을 협의한다. (기술적 채무 관리에 크게 도움이 된다.)
• 프로젝트 관계자간에 적절한 정보공유와 커뮤니케이션이 이루어 질 수 있도록 위키와 게시판등을 병행하여 사용한다. 일반적으로 메일을 사용하는 경향이 있는데, 메일의 경우 보관이나 업데이트의 면에서 유지모델을 다루기엔 부적합하다. 
• Redmine의 경우 커뮤니케이션과 관련하여 풍부한 기능을 제공하고 있는데 모두 사용할 필요는 없다. 프로젝트의 규모와 성격, 팀 구성에 따라 적절하게 선택하여 사용한다.
• 태생이 일본이다 보니 TiDD와 관련된 노하우는 일본어로 된 정보가 풍부하다. 구글 번역기등을 이용하면 여러가지 실천적 노하우를 쉽게 찾아 볼 수 있다.

TiDD는 일본에서 다양한 소프트웨어 개발 프로젝트의 관리기법으로 선호되고 있으며 특히 빠른 릴리즈를 선호하는 모바일 어플리케이션 개발의 경우 보편적으로 사용되고 있다.