이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다.

복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다.

기초적인 것이 해결이 안된 상태에서 너무 어려운 것을 적용할 수 없다.

기초적인 것들이 여러가지가 있지만 회사의 이슈들을 한군데로 모으는 것만도 정말 어렵다.

이슈(버그)관리시스템을 사용하는 회사는 많지만 이슈관리시스템에 회사의 모든 이슈를 다 모아서 개발자는 오로지 이슈관리시스템만 보고 개발을 할 수 있는 회사는 드물다.

이슈관리시스템을 통하지 않고 전화, Email, 메신저를 통해서 여전히 개발 요청을 하는 경우가 많다.

어려운 시도를 하기보다는 먼저 이슈관리시스템에 모든 이슈를 모으는 일을 먼저 해보기를 권한다. 이것만 해도 회사에 제대로 정착되는데 1년이 넘게 걸리곤 한다. 그것도 잘 되었을 경우이다.

 버그, 개발요청, 업무요청, 협업관련정보 등 개발 이슈는 무조건 다 모아야 하고, 그외에 업무 이슈들도 모으면 좋다.

개발자는 하나의 시스템에서 모든 개발 요청을 다 볼 수 있고 관리할 수 있어야 한다.

전화, Email을 통한 요청을 일부라도 허용하는 예외를 둬서는 안된다. 예외는 전체 문화를 망가뜨릴 것이다.

시스템은 많아질수록 개발자가 귀찮아지고 비효율적으로 변한다.

경영자가 관리가 잘 안된다고 생각하고 자꾸 관리하는 시스템을 늘리면 관리가 잘되는 것이 아니고 빠져나갈 구멍만 늘어간다. 중심이 되는 이슈관리시스템 하나라도 제대로 사용하는 것이 중요하다. 

개발에 투입할 절대 시간은 정해져 있으니 최대한 개발에 집중할 수 있도록 시스템은 간소화 하고 집중화 해야 한다. 시스템이 많아지면 시스템 때문에 개발 시간을 빼앗기게 된다. 

하지만 이슈관리시스템으로 모을 수 없는 것들이 있다. 원래 전문 시스템이 있는 고객요요청, 재고관리, 인사, 재무, QA관련, 프로젝트 관리, 비용처리등은 ServiceDesk, ERP, HR, MIS, QMS, PMS 등의 시스템을 사용해야 한다. 일부는 이슈관리시스템과 연동할 수 있지만 대체는 안된다. 

작은 회사에서 전문 시스템이 없을 경우 이슈관리시스템으로 대충 관리를 할 수 있지만 이는 임시이다. 나중에 회사가 커지면 전문 시스템을 도입해야 한다.

이슈관리시스템 하나만 보더라도 회사의 역량이 얼마나 되는지 대충 알 수 있다. 어디 끝내주는 방법이 없을까 고민하지 말고 이슈관리시스템 하나라도 제대로 쓸 수 있도록 하자.

이슈관리시스템을 쓰면서 일이 더 많아졌다.

이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다.

이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서  일이 더 많아졌다고 하곤 한다.

이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다.

일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적으로 처리가 된다. 물론 많은 이슈는 처리하지 않고 해결하는 것으로 종료된다.

이슈가 빠짐없이 처리되는 것은 물론 이슈를 처리하는 과정은 완전히 투명하게 공개가 된다.
억지주장을 해도 모두 알게 되고 요청을 무시하거나 늦장을 부려도 누구나 알 수 있다. 완전히 투명하게 업무가 진행된다. 투명한 업무처리를 싫어하는 사람들은 이를 꺼려할 수는 있지만 전사적으로는 대단히 큰 강점이 된다. 

따라서 이슈관리시스템에는 버그 뿐만 아니라 업무요청, 자료요청, 새로운 아이디어 등 온갖 이슈는 모두 등록하는 것이 좋다. 또한 이슈관리시스템을 사용하면서 전화로 구두로 요청하는 것은 거의 없애야 하면 이슈를 공유하고 논의하는 회의의 대부분은 사라져야 한다. 회의에 불려가는 시간도 줄어야 하며 전화나 구두로 요청하는 인터럽트도 많이 줄어야 한다. 이렇게 세이브된 시간은 쉬거나 좀더 창의적인 일을 하는데 쏟는 것이 좋겠다.

이슈관리시스템은 전사적으로 제대로 쓰는 것만으로도 회사의 개발문화에 많은 변화를 가져온다.

버그관리시스템 사용 현황 조사 결과

그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다.

소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다.

물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다.

질문은 다음과 같습니다.

버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요.

복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다.

그럼 그 투표결과를 분석해보도록 하겠습니다.

버그관리시스템 사용 vs. 미사용 비율

버그관리시스템을 사용하는 것만으로도 소프트웨어 개발 생산성 및 효율성은 상당히 향상됩니다. 그리고 소프트웨어의 규모나 복잡성이 증가할 수록 시스템 없이 파일 등으로 관리하는 것은 점점 불가능해집니다. 물론 소프트웨어가 아무리 작아도 엑셀파일로 관리하는 것보다는 버그관리시스템이 훨씬 낫죠.

전체 투표 결과

전체 투표결과는 위와 같습니다. 엑셀로 버그관리를 하는 비율(18%)와 자체 제작한 버그관리시스템 사용 비율이 매우 높다는 것에 놀리자 않을 수 없었습니다. 특히 자체 제작한 버그관리시스템은 실패하는 것이 일반적입니다. 버그관리를 간단하고 쉽게 생각하고 자신의 회사에 딱 맞는 버그관리시스템을 만들 수 있다고 착각하지만, 실제 만들어서 사용하다보면 문제점이 많습니다.

우선 자신의 회사에 딱 맞는 시스템이라는 것이 기존의 회사에서 개발하는 방식에 문제가 있는 경우가 대부분이기 때문에 이에 딱 맞추면 회사의 개발 프로세스는 나아지는 것이 없습니다. 오히려 제대로 된 툴에 회사의 프로세스를 변화시켜서 맞춰나가는 것이 성공할 가능성이 더 높습니다. 또 버그관리시스템에 대한 전문적인 지식 없이 표면적인 기능만 구현을 하게 되면 계속되는 기능 추가 및 유지보수 이슈로 본업인 제품개발에 지장을 초래할 수도 있습니다. 이러다가 결국 포기하고 제대로된 툴을 사용하다보면 그동안 나쁜 버릇들이 몸에 베어서 정상적인 경우면 1,2개월이면 적응할 것을 적응 기간이 몇배 더 들고 또 실패할 수도 있습니다. 운동도 처음에 나쁜 자세가 몸에 익어버리면 제대로 배우는데 처음부터 배우는 것보다 몇배 더 오래 걸리는 것과 같은 원리입니다.

따라서 버그관리시스템은 처음부터 기존에 나와았는 상용이나 무료 툴들을 사용하는 것이 올바른 방법입니다. 서투른 다른 시도는 안하니만 훨씬 못합니다.

버그를 관리하지 않는 비율이 7%나 되는데, 음.. 버그가 하나도 없다는 얘기일까요? 신기하군요. 회사가 작다면 작은 PC에다가 Mantis등의 무료 버그관리시스템을 설치해서 써보는 것도 좋은 방법입니다. 제대로 쓰기만 하면 개발 패러다임이 바뀔 것 입니니다.

버그관리시스템의 사용 비율

버그관리시스템을 사용하고 있는 집단에서의 시스템 사용비율을 따로 뽑아봤습니다.

그 결과 Mantis가 32%를 기록했습니다. 즉 버그관리시스템을 사용하고 있다면 3명중 1명은 Matis를 사용하고 있다는 것입니다.

그리고 Trac, JIRA, Bugzilla등의 순서인데, IBM CQ나 Teamwork를 쓰고 있는 회사도 소수 있었습니다.

Mantis는 설치가 쉽고 사용이 쉽고 직관적이라서 많은 개발자들이 선호하는 것으로 보입니다. 또 무료라는 것도 무시할 수 없는 매력이겠지요.

결론

버그관리시스템의 사용비율은 예상외로 낮았습니다. - 68%

또, 자체적으로 만들어서 사용한다는 비율도 꽤 높았습니다. - 10%

이를 미루어 볼 때 버그관리에 대한 의식이 매우 낮고, 버그관리를 만만하게 보는 경향을 엿볼 수 있었습니다.

소스코드관리시스템을 만들어서 사용한다는 개발자들은 별로 보기가 힘듭니다. 일단 어려워보이거든요.

하지만 버그관리시스템을 팔기위해서가 아니고 자신들이 사용하기 위해서 만든다고 하는 개발자들을 쉽게 볼 수 있는 이유는 버그관리시스템이 만들기 쉽다고 생각하는 것 같습니다. 

DB 좀 핸들링 할 줄 알고 Web 프로그래밍을 할 수 있으면  버그관리시스템을 만들 수 있다고 생각합니다. 버그관리시스템은 그렇게 간단한 것이 아닙니다. 크고 작은 소프트웨어 회사의 전체 개발프로세스를 완전히 이해하지 않으면 이를 개발할 수는 없습니다. 현재 유명한 Mantis 등의 버그관리시스템들도 모두 수십년에 걸쳐서 축적된 버그관리 철학이 녹아 있는 것입니다.

따라서, 이러한 버그관리시스템에 잘 적응해여 사용하는 것만으로도 수십년간 축적된 개발 프로세스와 문화를 흡수할 수 있는 좋은 기회입니다.

버그관리가 별거 아니라고 생각하는 서투른 착각으로 이런 좋은 기회를 차버리는 과오를 범하면 안되겠습니다.

버그관리시스템을 도입하거나 사용하시면서 의논할 사항이 있으면 언제든지 연락을 주세요. 도움을 드리도록 하겠습니다. 감사합니다.

효과적인 버그 처리 방법

HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다.

의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다.

개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다.

주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다.

여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠.

개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기술을 잘 아는 관리자가 있기도 하고 기술을 잘 모르는 관리자가 있기도 합니다. 하루에 버그가 하나도 보고되지 않을 수도 있고, 하루에 수백개의 버그가 보고되는 경우도 있습니다.

이러한 모든 경우에도 버그는 가장 적절한 개발자에게 신속히 할당이 되어서 신속히 해결을 해야 합니다. 해결이라함은 꼭 버그를 Fix하는 것을 의미하는 것이 아니고 연기할 수도 있고, 수정하지 않기로 할 수도 있고, 버그가 아닌 경우도 있죠. 어쨌든 이런 요구를 항상 만족시키기란 쉽지 않죠.

그래서 사람들이 찾아낸 방법이 "자율"입니다. 완전한 자율은 아니고 "Process"와 적당히 혼합된 "자율"입니다. 소프트웨어 개발에 있어서 "자율"은 매우 자주 등장하니 그리 놀랄 일도 아닙니다.

버그할당의 의무와 역할을 관리자에게만 두는 것이 아니고, 개발자도 그 역할을 조금씩 나눠 갖는 겁니다.

버그가 보고되면 관리자나 관련 개발자나 누구나 먼저 인지를 한 사람이 버그를 할당하는 겁니다. 여기서 버그를 할당했다고 해서 당장 버그를 고친다는 의미는 아닙니다.(이는 버그 관리 정책에 따라서 다릅니다.)

모든 개발자가 모든 버그를 다 감시할 수는 없겠죠. 버그의 카테고리는 기능별, 모듈별로 모두 등록을 해 놓아서 카테고리와 담당개발자의 연관성을 높이고 개발자들은 자신과 주로 관련된 카테고리들만 감시를 해도 충분합니다. RSS Feed를 지원하는 Bug Tracking System이 있으면 이렇게 감시를 하기 편리합니다. 그리고 나면 버그 해결 스케쥴은 시스템을 이용하여 정할 수도 있고, 회의를 하기도 합니다.

버그할당의 최종 책임은 관리자에게 있으므로 이렇게도 할당이 안된 버그는 관리자가 처리를 해야죠.

이러한 방법은 대부분의 경우에 상당히 효율적입니다만, 자율에 의한다는 것은 각 구성원의 성숙도에 많은 영향을 받으므로 이를 감안해서 시행해야 할 것입니다. 

버그의 처리에는 시간이 걸릴 수 있어도 버그의 인지는 신속해야 하고, 버그의 할당도 빠르게 이루어져야 합니다. 버그인지 자체가 일주일 이상 걸리는 상황이라면 그 기간 동안 버그는 완전히 방치가 되고 있는 상황이라고 할 수 있습니다. 그래서 회사에 따라서는 버그 인치와 처리 시간을 줄이기 위해서 KPI에 이 수치를 포함해서 평가의 지표로 삼곤 하는데, 별로 바람직한 시도는 아닙니다. 어차피 자율에 의한 방법이기 때문에 좀더 성숙한 개발 문화와 이를 북돋울 약간의 당근만이 필요할 뿐입니다.