관련 글들 묶어둡니다.
이슈 관리 도구 비교 (2) : 이슈관리란? 이슈관리 도구란? - http://xelion.tistory.com/1303
이슈 관리 도구 비교 (1) : 이슈와 버그란 무엇인가? - http://xelion.tistory.com/1302Mantis Mobile, 사마귀 모바일로 들어오다. - http://xelion.tistory.com/1251알려드립니다. 오래된 글들은1) 현재 제 생각과 다를 수도 있고,2) 그 당시 제가 잘 못 알고 있었을 수 있으나 수정할 생각은 없으며,3) 예전 글들은 당시의 언어로 쓰여져지금 읽기에는 편하지 않으실 수 있습니다.
이슈 관리 도구 비교 (1)편에서 이슈 관리 도구에 대한 이야기를 하기 앞서, 어떤 것이 좋은 이슈 관리 도구인지를 알기 위해 그 배경이 되는 이슈에 대한 이야기와 이슈 관리가 가야할 방향에 대해 언급하였습니다. 오늘은 이슈 관리 도구에 대한 기본적인 이해를 돕는 글을 포스팅해 볼까합니다.
2편. 이슈관리란? 이슈관리 도구란?
1. 이슈 관리 도구란?
이슈 관리 도구는 영어로 Issue Tracking System이라고 하며, 보통 실무자들 끼리는 ITS라고 통칭하기도 합니다. 앞서 1편에서 소프트웨어 버그를 일컫는 말이 다양하다고 말씀드린 바와 같이 ITS 역시 Trouble Ticket System, Support Ticket System, Incident Ticket System, Task Ticket System, Bug Tracking Tool 등 다양한 이름으로 사용하기도 합니다. 경우에 따라 Bug Tracking Tool과 Issue Tracking System을 별도로 사용하기도 합니다. [Issue Tracking System, Wikipedia]
이슈 관리 도구는 소프트웨어 개발 회사 내에서 발생하는 제품 개발의 주요 문제점들에 대해 기록하고 관리하기 위해 사용되는 것이 일반적입니다. 고객으로부터 접수된 신고들을 기록하거나, 내부 개발팀들이 실무 중 발생하는 현황들에 대한 기록을 합니다.
이슈라는 단어 자체에서 오는 어감이 애매모호 하듯이 이슈 관리 도구도 어떻게 사용하느냐에 따라 다양한 관점으로 접근이 가능하여 한 가지 용도나 사례로 그 훌륭함을 설명하기는 쉽지 않습니다. 그렇기 때문에 우리는 이슈란 무엇인지를 살펴보았고, 이제 이슈 관리란 무엇인지, 이슈 관리 도구란 무엇인지에 대해 알아보아야 합니다.
< 그림 출처 : 이슈관리시스템을 활용한 프로젝트 관리법 >
2. 이슈 관리는 대체 무엇일까요?
1편에서 필자는 「소프트웨어 이슈」를 소프트웨어 상에서 발생하는 문제점, 요구사항, 미래에 대한 전략 등이라고 정의하였습니다. 계획과 전략에 대한 이야기는 너무 긴 이야기이니 이번 포스팅에서는 제외하고, 문제점이나 신규 요구사항이 발생했을 경우 어떤 방식으로 처리될 지에 대한 이야기에 집중해 보려고 합니다.
※ 오늘 이야기하는 이슈는 = 문제점 + 요구사항 (미래에 대한 전략은 제외)
보통 소프트웨어 개발에서 이슈 관리가 필요한 이유는 이슈를 효율적으로 관리함으로써 얻어지는 회사의 이익이 있기 때문입니다.
일단 소프트웨어의 문제점은 일반적으로 버그라고 부르니 일단 버그라고 칭 하시죠. 이전에 소프트웨어 버그를 곧 바로 수정해야 하는 10가지 이유에서 어느 외국 테스터의 사려깊은 이야기로 소개되었다시피, 소프트웨어 버그는 그것을 고치는 시기를 적절히 고려하지 않을 경우, 소프트웨어 내의 의존성(Dependency)이나 데이터의 흐름 등에 의해 고치지 않음만 못할 경우도 있습니다. 잘 못 고려된 수정 시기는 더 많은 문제점들을 야기하거나, 회사의 비용으로 돌아오는 경우가 많습니다. 그래서 대부분의 경우 버그는 발견 즉시 수정 계획을 수립하여 수정하라고 이야기하는 것입니다.
요구사항에 관련된 이슈들은 이해하기 쉽습니다. 고객의 요청이나 시장이 변했을 때, 현재 변화한 수요나 잠재되어 있는 시장 수요를 예측해서 소프트웨어에 기술적으로 녹여들이는 것이죠. 필요한 기술 사항이나 설계, 분석, 구현 작업 등을 각각/하나로 이슈화해서 관리함으로써 회사가 필요할 때 사업 변경을 성공적으로 적용할 수 있도록 도와줍니다.
이런 이슈 관리를 통해 비가시적이고 관리하기 어려운 소프트웨어 개발 중간에 발생하는 이슈들을 해결하는 일련의 활동을 「이슈관리」라고 부릅니다.
3. 이슈를 처리하는 방법
일반적으로 이슈관리 대장이나 이슈관리 도구에 항목이 등록되면, 그 항목을 "이슈"라고 부르거나 "티켓" 이라고 부릅니다. 이슈/티켓에 대한 것은 1편에서 이야기 하였으므로, 1편을 참고해주세요.
(1) 소프트웨어 개발에서 이슈 관리 방법에 개선이 필요한 이유
소프트웨어 개발에서 이슈 처리는 무척 어려운 일입니다.
소프트웨어에서 이슈 처리가 어려운 이유를 두 가지 정도 제시해 보자면,
A. 소프트웨어 내의 의존성 문제와 이로 인해 발생하는 우선순위 문제가 존재하기 때문이며,
B. 소프트웨어의 사용자들은 하나의 요소를 보지만, 사실 개발하는 입장에서 보면 작은 기능하나에도 많은 사람들이 엮여 있기 때문입니다.
B번을 이해하기 쉽도록 예를 들어봅니다. 왼쪽의 그림은 NCSoft의 블레이드앤소울이라는 작품입니다. 일반 사용자들이 게임을 할때는 그냥 클릭하고 스킬 쓴다고 생각하실 수도 있습니다만 이를 뜯어 보면 이렇습니다. (1) 기본 캐릭터 디자인, (2) 애니메이션, (3) 애니메이션을 구현해줄 클라이언트 프로그램, (4) 클라이언트를 돌게 해 주고 서버와 클라이언트를 연결해줄 게임 엔진, (5) 서버 데이터, (6) 서버측 처리 라이브러리, (7) MMO를 가능하게 해 주는 다른 플레이어와의 네트워크 통신, (8) 게임상 사냥을 위한 적 캐릭터와의 상호작용, (9) NPC 및 몬스터의 AI 등등... 그 외 기획요소들이나 스킬, 마을, 세계관 등을 모두 합치면 가히 가공할 만큼의 업무 복잡도를 보입니다. 그리고 이 모든 작업들이 거의 대부분 각기 다른 사람에게서 작업됩니다. 이렇게 되다보니 캐릭터 하나에서 버그가 발생하면 어디가 문제인지, 어떻게 고칠지, 누가 고칠지 등 너무 많은 사안들이 복잡하게 동시 다발적으로 발생합니다.
또한 이를 해결하기 위해서는 고쳐도 되는 것인지까지 보아야 하는데, 여기에서 A번의 의존성과 우선순위 문제까지 얽히면 상당히 처리하기 까다로운 문제로 돌변해 버립니다. 이런 경우는 대부분 눈에 보이는 것들보다 눈에보이지 않는 부분들, 특히 확장성 부분들이 괴롭히는 경우가 많습니다.
(2) 이슈처리 방식, 프로세스
다음은 이슈처리 방식의 사례입니다.
< 참고 : InfoWorld - JAVAWorld : 버그질라의 이슈 관리 >
이슈가 새로 생성(New, Open, Created)되고 완료(Closed)될 때까지를 우리는 이슈의 생명주기(Issue Lifecycle), 혹은 이슈처리 프로세스, 이슈관리 프로세스라고 부릅니다. 이슈관리 프로세스는 각 회사마다 모두 다르게 적용되어야 하며, 최상의 사례는 존재하지 않습니다. 이슈관리 프로세스는 조직의 구성과 그 구성 내에서 최대 효율을 낼 수 있도록 고려되어야 합니다. (만약 어딘가의 컨설턴트가 와서 자기네거만 최고라고 한다면 한대 때려주셔도 됩니다 푸흐흐...)
위의 그림은 JAVA 진영에서 가장 유명한 이슈관리 도구인 버그질라의 기본 프로세스 도식도입니다. 버그질라에서는 기본적으로 이런 프로세스로 사용할 수 있도록 구현되어 있습니다. 이 그림은 버그 관리에 대한 가장 기본적인 프레임워크를 제공합니다. 하지만 회사가 더 다양한 프로젝트 이해관계자로 구성되어 있거나, 책임 소재가 명확하게 구성되어야 한다면 변경해야 합니다. 자세한 사항은 이슈관리 도구 웹사이트를 참고하세요.
[ 일반적인 이슈들의 상태 ]
그 전에, 이슈들이 처리될 때 사용되는 상태 용어에 대해 짚고 넘어가봅니다. 모든 상태가 영어입니다만, 영어로 오랜 동안 사용하다보니 한국말로 쓰는게 더 어색하게 되었습니다. 이걸 한국말로 고쳐서 사용하는 회사도 있긴 하더라구요. 그런데 실무자들끼리는 그냥 영어로 된 상태로 이야기들 많이 합니다. 이 도구를 사용할 사람은 사장님이 아니라 실무자들이므로, 그냥 영어로 쓰도록 두는 것이 효율적이라 사료됩니다.
New - 새로 등록된 이슈임
Open - 새로 등록된 이슈임
Created - 새로 등록된 이슈임
Reviewed - 누군가 등록된 이슈를 처리하지 않고 본 상태임
Assigned - 이슈가 누군가에게 할당된 상태임
Resolved - 이슈가 어떤 결정에 의해 처리된 상태임
Resolve (상태1) Fixed - 이슈가 수정되어 적용됨
Resolve (상태2) Duplicate - 과거 중복된 이슈가 올라와 있음
Resolve (상태3) Won't Fix - 여러 사정으로 인해 고칠 수 없음 / 고칠 필요 없음 / 고치지 않음
Resolve (상태4) Worksforme - 정상 작동 (Works for me = 내 자리에선 잘 됨)
Resolve (상태5) Not a bug - 문제점이 아님
Resolve (상태6) Invalid - 문제점이 아님 / 추가할 수 없는 요구사항임
Verified - Resolve됨을 확인 하였고 Resolve의 상태에 동의함
Reopen - 다시 발견됨 / 재발함 / Resolve 상태에 동의할 수 없음
Unconfirmed - 이슈가 수정처리 되지 않았음 / Resolve 상태에 동의할 수 없음
Closed - 이슈의 처리가 완료됨
4. 이슈 관리도구의 일반적인 장단점
이슈관리 도구에 대해 검색하시면 해당 도구를 이용한 사례들이나 장단점이 잘 나열되어 있습니다. 제가 워낙 남들하는 이야기는 잘 하려들지 않고, 남들이 잘 안하는 속사정, 배경 이야기 하는 것을 좋아하다보니, 이번에도 남들이 다 이야기한 부분은 그냥 넘어갈까 합니다. 대신, 제가 생각하는 장점하나와 단점하나를 남겨봅니다.
(1) 이슈관리 도구 사용 시 장점 : 추적성 확보
소프트웨어를 개발하다보면 본의와는 다르게 모든 사항들을 파악하기는 어렵습니다. 특히 소프트웨어 제품의 덩치가 커지면 커질수록 그런 현상은 심화됩니다. 어떤 소프트웨어 상의 문제점이 과거 작업 내용이나 과거 히스토리와 연관되어 있다면, 해당 문제의 크기와 상관 없이 상당한 커뮤니케이션 비용이 발생하게됩니다. 또 대부분 이런 문제점의 경우 소프트웨어의 복잡도을 증가시키는 경향이 있습니다. 이슈관리 도구는 이를 손쉽게 해결할 수 있도록 도와줍니다. 모든 이슈의 기록들이 데이터베이스에 저장되어 있고, 검색이 가능하기 때문에 과거의 일들 추적하고, 이를 통해 정량적 분석이 가능하게 해 줍니다.
물론 이 장점 자체에도 한계는 존재합니다. 이슈관리 도구를 사용하면 한 번에 프로젝트의 추적성이 확보되고, 정량적 분석이 가능해 지는 것이 아닙니다. 도구와 프로세스, 기술과 사람은 각기 별개의 관점으로 관리되어야 합니다. 이슈관리 도구의 추적성, 정량적 분석 능력을 확보하기 위해서는, 소프트웨어의 설계가 잘 되어 있어야 합니다. 또한 좋은 설계를 만들기 위해서는 훌륭한 제품에 대한 품질 전략이 필요하게 됩니다. 결국 전략의 문제로 귀결되네요.
(2) 이슈관리 도구 사용 시 단점 : 도구와 업무
이 세상 어떤 도구든, 프로세스든, 이를 도입할 때 고민되는 부분은 바로 도구에 조직을 맞추는가, 조직에 맞게 도구를 맞추는가에 대한 고민일 것이라 생각합니다. 이슈관리 도구의 사용에서도 같은 문제가 발생합니다. 이슈관리 도구를 사용하는 것은 대부분 실무자들인데, 의외로 2013년인 현재까지도 이슈관리 도구에 대한 개념이 없거나, 그런거 사용안해도 자신이 모든 것을 통제 가능하다고 믿는 실무자들이 많습니다. 또한 큰 기업의 경우 조직은 이미 사업 방향 대로 설계해 두었는데, 특정 도구를 차용함으로 인해 조직 전체의 구도를 바꾸어야 하는 경우도 발생할 수 있습니다. 이런 과정에서 도구 자체의 쓰임이 거부되거나, 퇴물로 남을 수 있습니다.
물론 이 단점에도 보완 가능한 방법은 존재합니다. 이슈관리도 도구를 도입하면 어찌되었거나 업무 규칙이나 업무 흐름, 그리고 조직 설정이 변경되어야 합니다. 그러므로 처음부터 유료 도구를 쓰시기 보다는, 무료 도구를 내부 서버로 구축하여 1~2년 정도 사용하시면서 조직에 내재화 시킨 뒤, 필요한 경우 컨설턴트나 유료 도구를 이용해서 추가적인 개선을 살피시는 방법을 추천합니다.
[ 인터넷에서 검색하실 분들을 위한 검색어들 ]검색 엔진에서 아래의 키워드들을 입력하시면 더 많은 정보들을 보실 수 있습니다.버그 관리 도구버그 처리 도구이슈 관리이슈 관리 도구이슈 추적Bug tracking toolBug managementIssue managementIssue management toolIssue tracking toolSoftware issue managementSoftware bug management
이슈관리 도구에 대한 이야기를 더 진행하기 전에 필자와 이해를 같이 하기 위해서는 이슈란 무엇인가에 대한 인식과 인슈관리에 대한 추가적인 지식들을 보시고, 이후에 나눌 이야기에 대해 공감대를 형성할 수 있었으면 해서 추가적인 지식들을 공유합니다.
[ 참고 ]
조엘 온 소프트웨어
Painless Bug Tracking - Joel Spolsky
Painless Bug Tracking - Joel on Software.mht[ 참고 ]How to report bugs effectively
[ 참고 ]소프트웨어에 관련된 이야기는 아니지만, 일반적인 이슈관리에 대한 철학적이고 통찰력 있는 글입니다.Issues Management : It's Pas, Present, and Future - Robert L. Heath
Issues Management_its past, present, future.pdf사실 이슈는 고객관리 센터에서 관리되기도 하고, QA담당자가 전담하기도 하며, PM담당자가 결정 권한을 가지기도 하며, 내부 직원들 모두가 이슈를 관리하기도 합니다. 어떤 방법이 옳을 지는 각자의 회사에 맞게 결정하시면 됩니다.
(1) 명확히 하셔야 할 부분 1 : 이슈관리 도구를 이용하여 이슈를 관리하게 되면, 권한에 따라 책임과 역할이 분명하여야 합니다. 그렇지 않을 경우 실무자들이 자신은 권한 없이 책임만 안고 있다는 느낌을 받을 수 있습니다.
(2) 명확히 하셔야 할 부분 2 : 도구가 사람을 대신할 수 없듯이 사람 역시 도구를 대신할 수 없습니다. 사람으로 해결해야 할 일을 도구를 이용하거나, 도구로 해결해야 할 일을 사람을 써서 해결하려고 들어선 안됩니다.
(3) 이슈관리 책임에 대한 오해 타파 : 이슈관리 도구를 관리한다는 것을 이슈/버그에 대한 책임을 지는 것으로 오해하면 안됩니다. 이슈에 대한 모든 책임은 PM담당자, 혹은 사장님/임원분이 지셔야 합니다.
[ 역할 제안 ](1) QA 혹은 Test Officer (Tester가 아님)- 역할 : 이슈/버그에 책임을 지는 것이 아니라, 보고된 이슈/버그의 무결성에 대한 책임을 지는 것(2) QA Manager 혹은 QA Lead- 역할 : 개발 중인 제품의 테스트 coverage가 충분한(애매하네요) 상태에서 이슈가 등록되었는 지에 대한 책임을 지는 것(3) Project Management 담당자- 역할 : 이슈 처리의 우선순위를 정하고, 품질 계획을 수립하고, coverage 등 지표를 확인하여 의사 결정을 내려야 함
[ 참고 ]
이 블로그에서 쓰이는 호칭은 일반적인 호칭과 다를 수 있습니다. 저는 개발자라는 말을 쓰기보다는 Programming 담당자, 혹은 디벨로퍼, 혹은 Dev팀이라고 부릅니다. 프로젝트 관리자도 Project Manager라고 하니까, 자기가 관리자라서 프로젝트에 대한 지휘권을 행사한다고 착각하는 것 같아서 Project Management 담당자, 혹은 PM담당자라고 습니다. 또한 QA도 마찬가지로 QA담당자라고 표현하는 것이 옳다고 생각합니다.
옛날 글에는 아닐 수 있지만, 앞으로는 그렇게 사용할 예정입니다.
7. 최근의 유행에 발 맞추기
최근 소프트웨어 업계에는 글로벌화되거나 원거리에 있는 분산된 팀과의 협업에 대한 이야기들이 이슈입니다. 예전에 외국 회사들이 그들의 사업을 한국에 많이 들고와 진출했던 바와 같이, 최근에는 한국의 업체들도 외국에 사업소를 두고 진출하는 등 한국은 소프트웨어 분야에서 큰 성공을 거두고 있습니다.
(1) CI와 하나로 합쳐 형상관리에 한 발자국 다가가기
1편에서 과거의 형상관리 방법이 소스관리(Source Control)과 문서관리(Documentation)에 집중되어 있었으며, 제대로된 형상관리를 위해서는 전략적인 방법으로 계획하여야 한다고 하였습니다. 같은 선상에서의 주장입니다. 예전에는 소스관리 시 소스 변경 기록을 SVN에 남기도록 하였지만, 최근에는 CI 도구를 이용하여 자동으로 변경된 부분에 대한 기록 및 관리가 가능합니다. 또한 코딩 시 코멘트처리하여 이슈 번호를 남겨두면, CI 도구에서 빌드할 때 이슈 번호를 감지하여 어떤 부분의 소스가 어떤 이슈로 변경되었는 지 기록해줍니다. 이런 방법을 사용하여 이슈관리도구와 CI, 소스관리도구를 하나의 도구로 사용할 수 있게 됩니다.
이 글을 읽으시는 분이 지속적으로 통합하는 과정을 거치는 스크럼을 사용하는 팀이라면 반드시 브랜치와 서브브랜치, 패치 개념이 등장하게 되는데, 어느 시점이 지나면 비효율적으로 쌓여있는 패치들을 메인 브랜치에 통합해야 하는 시기가 오게됩니다. 그 때 업무를 효율적이고, 명확하게, 정확하게 하기 위해서는 이슈관리도구를 효율적으로 이용하는 것이 매우 중요합니다.
아, 물론 그러기 위해서는 웹 기반으로 구성된 도구를 사용하는 것이 유리하겠네요. 웹 기반으로 구성된 도구들은 대부분 OS에 의해 제한 받지 않고, 모바일로도 사용 가능하기 때문입니다. 모바일로도 사용 가능하다는 점에 실무자들은 들고다니면서 일해야 하니 피곤할 수도 있지만, 적어도 어떤 이슈를 언제 어떻게 처리해야 하는지를 빠르게 결정할 여지를 준다는 점에서는 상당히 고무적인 듯 하네요.
(2) 웹 기반 이슈관리 도구들 모바일로 진출하다
웹기반의 이슈관리 도구들은 클라이언트를 따로 띄울 필요 없이 모바일에서도 접근이 가능합니다. 일전에 Mantis의 모바일 서비스를 소개하는 포스팅을 개재하였는데, 웹용 Mantis는 무료이지만 모바일용은 100$(2013년 2월 기준, 약 11만원)에 판매하고 있습니다. 하나의 라이센스로 무제한으로 사용할 수 있으니 굉장히 좋은 상품이라 생각되네요.
< 그림 - 만티스터치, 하나의 라이센스로 무제한 사용자라는 어마어마한 정책 >
JAVA 진영에서 많이 사용하는 버그 질라도 OpenAPI를 이용해서 iPhone용과 안드로이드용으로 출시되어 있습니다. 두 개 정도만 소개해 봅니다. (찾아 보면 아마 더 많이 있을거에요. Bugzilla 같은 경우는 OpenAPI를 이용해서 많이 만들었지 싶습니다.)
※ iPhone용 iBzilla - Bugzilla on iPhone
※ Android용 BugDroid - Bugzilla Client
※ Android용 Bugzi - Bugzilla Client
[ 짜투리 주저리 ]
나중에 정리 하겠지만 언급한 김에 짜투리 한 마디 남겨봅니다. 버그질라가 외국의 JAVA 프로그래머들에게 인기가 많은 이유는 그것이 가진 기능의 유연성도 있겠지만, 자바 개발도구에서 플러그인 형태로 직접 사용할 수 있기 때문입니다.
간단히 하려고 많이 빼냈는데도 2편은 꽤 길어져 버렸네요. 다음 편에는 또 다른 이야기들로 찾아뵙겠습니다.
