현재 내가 다니고 있는 회사는 Unity 기반의 메타버스 플랫폼을 개발하는 회사로서, 여러팀이 산재해 있다. 그 중 나 또한 하나의 팀의 PM으로서 팀장님과 함께 일을 하고 있는데, 이제 내가 프로젝트에 진입한지 한달 정도 되었다.
정말 프로젝트에 처음 진입했을 시 느낀 이 감정은.. 정말 여긴 '아무것도(시스템이) 없구나' 였다.
<진입 시 현 문제점>
- Jira를 쓰고 있으나 Git commit에는 티켓번호가 없다.
- Jira에 내용 요약이 한줄로 표기되어 있다.
- 왜 이 티켓을 진행하는지에 대한 내용이 없다.
- 문제의 원인 -> 해결 처리 내용 / 개발 배경 -> 개발 처리 내용 등의 인과가 없다.
- 이슈의 버젼 표기가 없다.
어떻게 이럴수가 있지?
내가 전에 했던 프로젝트의 PM님이 너무 FM이셔서 그랬는지 몰라도, 내게는 몸에 베어있는 개발주도 습관이 있었다. 사실 그 습관을 만드는데도 꽤나 오래걸렸는데, 그건 내가 Jira 와 이슈관리 툴들을 공부하는 계기가 되었다.
우선적으로 이슈 관리 툴을 쓰는 이유는,
- 업무와 목표를 한 곳(Jira) 에서 관리한다.
- 팀 효율성을 개선한다.
- 혼란을 줄이고 효율성을 높인다.
- 커뮤니케이션을 조율한다.
위로 인해서, 팀간의 업무 진행상황을 조율하기 원활하며 협업을 개선한다. 세부사항/파일/피드백등도 Jira를 통해서 일원화 하여 관리가 된다.
커뮤니케이션 조율은.. 정말 일을 하다보니 느낀건데 채팅창 메시지로 쌓여가는것들을 보면 정말 속이 어지럽다. 그 채팅들 후에 어떤 한 공간에 정리될 것이 필요하다. 심지어 우리 회사는 사내 메신저가 쓰레드형식도 아니기 때문에 메시지는 비효율적이다.
티켓 주도 개발
티켓 관리 시스템을 사용해서 티켓을 중심으로 개발 흐름을 만드는 것을 티켓 주도 개발(TiDD) 라고 한다. 이것은 원래 에자일 개발의 개발 방법 중 하나인 테스트 주도 개발인(Test Driven Development)에서 명칭을 따온 것이다. 티켓 개발을 실제 적용하는 데 필요한 규칙은 기본적으로 한가지밖에 없다. '티켓이 없는 커밋을 금지'한다는 것이다. 커밋 로그와 티켓을 반드시 일대일로 매칭해서 코드 변경 이유를 명확히 하는 것이 티켓 주도 개발의 목적이다. <출처: 성공으로 이끄는 팀 개발 실천기술>
위 책에서는 1Commit - 1Ticket를 추천한다.
--> Ticket link가 명시되지 않는 Commit은 진행하지 않음.
티켓 주도 개발의 장점
- 언제나 누구든지 티켓을 참조하는것이 가능해져, 커뮤니케이션이 쉬워진다.
- 돌발적인 테스크 변경에도 티켓 속성의변경이 간단하므로 변화대응이 쉽다.
- 이터레이션 작업량을 일정하게 하는것으로 작업의 리듬을 만들어 나갈 수 있다.
- 티켓을 이터레이션 단위로 관리해 나가기 때문에, 빈번한 릴리즈를 가능하게 한다.
- 티켓이 소스코드,요건,테스트케이스와 연관지어지므로 상호 추적이 가능해진다.
- 이러한 티켓중심의 워크플로는 버그관리뿐만 아니라 요건관리를 포함해 소프트웨어 개발 전 과정에서 응용 가능하다.
- 진척관리면에서 모든 작업 진행상황이 투명해 지므로 프로젝트 현황의 파악이 대단히 용이해진다.
<출처: MORE AGILE>
<출처:일본 위키피디아- 티켓 주도 개발>
티켓 주도 개발의 구체적인 순서
티켓 주도 개발은 신기능 개발이나 버그 수정 시마다 해당 내용이나 목적을 기입한 티켓을 발행(작성) 하는것으로부터 시작된다. 다음으로 ,티켓 내용에 따라 적절히 코드를 수정하여 커밋한다. 커밋로그에는 꼭 티켓번호를 넣는것이 중요하다. 티켓에도 커밋로그 번호를 기입한다. (티켓과 소스코드간의 상호 연계를 통한 코드 변경(수정,신규) 의 이유를 명확히 하며, 나중에 문제가 발생했을시에도 원인분석을 위한 추적이 쉬워진다.
- Jira에 티켓 하나만을 잘 작성하는것 만으로 가능한 것
- 어떤 팀에서
- 어떤 담당자가
- 어떤 일(이슈)을 진행하고 있고
- 진행 상황은 어떠하며
- 위 일(이슈)가 현재 목표하는 프로젝트에 어떤 영향을 미치는지 알 수 있다.
티켓 작성법에 대하여
티켓 작성은 간결하고 명확하게 한다. 중복되는 내용은 합치고, 설명이 길어지지 않게 작성한다.
<제목>
제목을 작성하는 것은 매우 중요하다. 전)의 제목을 읽었을때는 현상 수정이 필요한건 알겠는데 어떤걸 고쳐야되는지 명확하게 보여지지 않는다.
제목을 읽고 내용까지 읽으러 한번 들어가야 하는것이다. 또한 제목은 본문에 작성된 내용이 최대한 일치하도록 작성되어야 한다. 후)의 제목을 읽었을땐 어떤 기능을 수정해야할 지 눈에 보인다.
전)이 '발생하는 현상이 이런게 있습니다.' 라고 표현한것에 가깝다. 후)는 '수정하는 내용'에 가깝다.
수정 전) iOS의 메뉴에서 동물, 캐릭터가 보이지 않는 현상 수정 필요
수정 후) iOS의 메뉴에서의 콘텐츠 노출/ 비노출 조건을 변경
<내용>
티켓을 작성할때 프로젝트마다 성향이 다르겠지만, 서식이 있다면 Rule에 맞추어서 작성해주어야 한다. 본 진행중인 프로젝트는 서식이 정해져 있지 않다. 사내에도 실제로 지금 Jira에 대해서 이렇게 써주세요 라고만 가이드 문서 식으로 보냈지, 내용을 어떻게까지 써주세요 라는 형식은 따로 요구하지 않았다.
배경: 사람의 뇌는 '왜?' 라는 질문에 민감하게 반응한다. 왜요? 왜요? 왜요? 라고 계속 물어보게 되면 물어보는 사람이나 답하는 사람이나 속터진다.
※ 꼬리물기식 코드수정의 방지
개발도 똑같다. commit 메시지와 Jira의 작성을 대충하게 되면 '왜요?' 라는 질문의 지옥에 빠지게 될 것이다. 한번 잘 작성해두면 '아 그렇구나' 하고 넘어가게 된다. 아래의 전 후를 비교하여 잘 작성해보자. 티켓명을 보고, '왜 이걸 수정하지?' 라는 의문이 들었을 때 배경과 내용을 보고 팀원중 누군가가 더 좋은 의견을 줄 수도 있고, 관련된 다른 코드 부분을 수정하여 추가로 발생할 수 있는 오류를 방지할 수도 있는 것이다.
전) iOS에서 캐릭터가 메뉴에서 보이지 않게 처리가 되어있었으며, 이를 종류가 설정되어 있지 않는 콘텐츠들도 모두 보여지도록 코드 수정 처리
후)
[배경]
iOS m.m.r 버전에서 OO 콘텐츠를 노출시키지 않기 위한 예외처리가 되어있음.
[내용]
이는 전체 콘텐츠에서 특정 메뉴를 강제로 진입시키기 위함이였는데, 종류가 설정되어 있지 않는 콘텐츠들도 모두 보이지 않는 현상이 발생.
[처리사항]
종류가 설정되어 있지 않는 콘텐츠들도 노출되도록 코드 예외처리 진행.
본문을 시각적으로 '잘' 표현하기
뭐 현재 글에서는 다루지 않았지만, Jira에는 여러가지 구성요소들이 있고, 개발 스프린트 하나를 피라미드 형식으로 이슈를 쌓기 위한 '유형'(Story,Epic,Development,Defect)이 있다. 갈래로 퍼져 나온 이슈들 중에서 티켓 하나에 어쩔수 없이 글을 많이 작성하게 되는 경우가 있는데, 이는 '문서화'하고 동일한데, 정말 많이 작성하게 될 경우 Wiki/정리페이지 등에 작성하고 링크를 하자.
WIki 까지 갈 내용이 아니라면, 글 짓기, 책 쓰기가 아니기 때문에 긴 내용을 풀어서 쓰는 것 보다 시각적으로 한눈에 알아볼 수 있도록 ' 표현' 하는 것이 더 중요하다.
- 표
- 데이터 자료, 테스팅 자료들을 표현시 텍스트로 하나하나 표현하기 보다 잘 만들어진 표 하나를 덧붙이는 것이 더 용이하다. 글보다 그림에 더 반응하기가 쉽다.
- 글머리 기호
- 현재 지금 이 마크다운 문서에서도 글머리 기호가 사용되고 있다. 표로 만들어야 하는 내용은 아니지만, 목록화 하여 표현이 필요할 시 글머리 기호를 사용한다.
- 텍스트 포맷
- 잘 보여야 하는 것에는 굵게, 특이한 것에는 컬러처리/기울기 처리를 하는 것.
- 관련 링크는 본문에 링크거는 것이 아닌, 티켓의 관련 링크에 모아서 넣기
마치며
왜요? 왜요? 왜요? 의 꼬리에 꼬리를 무는 업무진행과 개발을 방지 하기 위해서, 꼭 읽기 쉬운 티켓으로 커뮤니케이션에 대한 소모값을 줄일 수 있었으면 좋겠다.
또한 일어날 수 있는 오해를 방지하며, 쓸데없는 논의를 줄일 수 있다. 처음에 작성할땐 5분씩도 걸리겠지만, 디테일적으로 표현하는 것을 줄이고 '나의 의도' 가 잘 표현 되었는지 작성해보자.
1분 글쓰고 10분 설명하는것보다, 5분 글써서 설명 안하는게 더 효율적이다.
요약
- 1Commit - 1Ticket을 생활화 하자
- 티켓 내용은 간결하고 명확하게 작성한다.
a. 절대 짧게만 쓰라는 말이 아니다. - 내용 항목의 예시처럼, "배경, 내용, 처리사항"으로 쓰면 좋겠지만, 그건 우리팀에 대한 나의 희망사항이고 오래 걸릴것이니 3번까지만.. 이라도 지켜주었으면 한다.
- 표, 글머리 기호, 텍스트 표현을 통해서 깔끔하게 표현하자.
