개발을 하다보면 발생되는 이슈 관리와 (아울러 커스터머 관리)가 항상 문제입니다.
이슈를 제기하는 쪽은 주로 커스터머 쪽입니다. 설령 회사 내에 동료라고 하여도, 엄밀하게 따지만, 개발자 측면 보다는 커스터머에 좀더 가까운 사람이 이슈를 제기하곤 합니다. 그래서 보통 회사에서는 이런 저런 이유로 대개 이슈 관리를 위한 이슈 트래커 시스템을 도입합니다.
특히 우리 회사처럼 칩개발하고 판매하게 되면 협업해야할 커스터머가 자꾸 늘어나게 되고,
그에 비례하여서 관리 해야할 이슈가 자꾸 발생하게 됩니다. 이런 경우 가끔 가다가 업무가 빠지거나 잊어먹는 소위 말하는 빵구 라는 경험을 자꾸 하게 되면 대개는 체계적으로 이슈를 관리할 필요가 있다고 생각되기 시작합니다.
문제는 이슈 관리하기 위해서 이슈 관리 소프트웨어들을 도입하게 되는데 이런 소프트웨어는 대개 본말이 전도되어서 관리를 위한 관리가 되어 버리기 쉽상입니다. 특히 휘황찬란한 입력 하면은 정말 입력을 포기하게 만들어버리는 일종의 이슈 게이트 키퍼로서의 역활을 하게 됩니다.
각설하고 요새 슬금슬금 고민되는 부분은 이슈가 늘어나기 전에 이슈 관리 시스템을 도입해야 하는 가에 대한 고민입니다.
만약 도입한다면, 회사의 개발자들과 관리자들과 영업/마케팅 사람들과
커스터머의 개발자 + 관리자 + 영업/마케팅 사람들과 함께 관리 시스템을 구축하여야 하는 것이 목표가 되어야 합니다. 하지만 결정적인 문제는 너무 쉬운 시스템은 윗분들이 쉽게 개입할 수 있고 너무 어려운 시스템은 그 자체로 죽어버린 시스템이 될 수 있다는 점입니다.
요새 유행하는 에자일에서는 반대로 이슈를 이런 시스템류에 묶어서 관리하지 말고,
커스터머랑 붙어서 일하라고 주장하고 있습니다. 즉 서로 교감해가면서 일하라는 의미입니다.
작은것 하나라도, 좀더 정밀하게 일하기 위해서는 좋은 접근법이라고 생각합니다.
물론 우리나라처럼 일방적인 갑과 일방적인 을이 존재하는 시스템에서는 교감이란 없습니다.
그런 의미에서 이슈 관리를 위한 방법을 나름대로 고민을 하였습니다.
일단 제일 쉬운 예로 이슈 트래킹 툴을 검토해볼만 합니다.
상용으로 유명한 것은 JIRA이고
GNU에서 유명한것은 MANTIS입니다.
저도 예전에 MANTIS를 도입해서 사용한 적이 있었습니다.
커스터머에 의한 이슈가 많아서라기 보다는 어떤 의미에서는 커스터머와 개발자 사이에 격리가 필요한 사항이었기 때문에 도입했었고 나름대로 효과를 보았다고 생각하였습니다. ( 매니저 측면에서 보았을때 개발자와 커스터머의 격리가 필요한 사항이라는게 좀 이상하겠지만, 그런 경우는 왕왕 발생합니다.)
이런류의 시스템의 문제점은 일단 사용법이 무지하게 귀찮다는 겁니다. 나름대로 잘 정리한 툴도 있고 단순하게 올리면 끝나는 툴도 있지만, 대개의 경우 첫 화면부터 사용자들을 질리게 한다는 점이죠.
이슈를 올리기 위해서 툴을 공부해야 한다면 그것도 문제인 것입니다.
특히 JIRA는 완벽한 이슈 관리를 위한 완벽한 화면을 제공하지만 제공된 화면에 채워야할 칸의 수를 보면서 질려서 포기하게 됩니다. 특히 저같은 게으른 사람에게는 포기하고 싶은 완벽한 이유를 제공합니다.
더구나 실제 개발자가 아닌 윗분들이 그런 복잡한(?) 시스템에 들어와서 관리 현황을 체크하기란 어린아이가 JAVA 코드를 수정하는 것 만큼이나 어려운 문제입니다. 이문제가 JIRA의 구입을 어렵게 하는 요소입니다.
또한, 이런 류의 시스템은 무엇보다도 팀원의 절대적인 지지가 필요합니다. 팀원들이 사용하지 않고 차츰 무시하게 된다면 결과적으로 마지막에 가서는 팀원 전체가 무시하는 시스템이면 곤란하게 됩니다. 아무도 사용하지 않고 커스터머만 메아리없는 이슈를 올리게 되면 큰 문제가 됩니다.
그리고 그 다음 방법이 사실 가장 고전적인 방법인데
메일을 끊임없이 Reply하는 것으로 이슈를 관리하는 것입니다.
대개 창구를 정해놓고 그사람을 통해서 엄청나게 긴 메일을 관리하게 됩니다.
이렇게 되면 누구나 그런 이슈에 참가하게 되지만, 이슈를 관리한다기 보다는 나중에 문제가 터져을 때에
누구 책임인지를 공개적으로 마녀사냥할 수 있다는 점에서 (혹은 면피할 수 있다는 점에서)
애용되는 시스템입니다.
대개 사람들에게 이슈 트래킹 시스템을 갖추자고 한다면,
메일로 되는데 왜 또 다른 시스템을 구비해야 하냐고 답이오는데 이런 경우가 바로 메일로 Never Ending Reply를 하는 시스템을 사용하는 것입니다.
장점은 누구나 쉽게 이용한다는 점이고, 단점은 잘못되면 말장난으로 끝날 수 있다는 점입니다.
그래서 이번에 사용하는 방법은 Excel File에서 양식을 만들어서 Issue와 Action Item, Action Leader를 지정하고 관리할 수 있도록 하는 것입니다.
이 방법의 장점은
엑셀 파일이므로, 관리자들도 쉽게 들어와서 현황 파악을 할 수 있다는 점입니다.
그리고 누구나 테이블 관리가 되므로, 협업에서 커스터머도 참가할 수 있다는 점입니다.
물론 단점이 있는데
이슈가 많아질 경우에 동시 다발 적일 경우에 관리가 혼란스러울 수 있다는 점과
이슈 DB가 만들어지지 않으므로, 종국에 가서는 손해 일 수 있다는 점입니다.
이슈 DB 문제는 약간 수고스럽지만,
Application Note라던가 다른 방법으로 문서를 공유하도록 하면 해결 될 수 있습니다.
동시 다발 적인 발생과 관리에서는 어쩔 수 없는 부분도 있습니다. 뭐 얻는것이 있다면 잃는 것도
있어야죠. 등가 교환의 법칙인 셈입니다.
당장은 아쉬운대로 엑셀 파일로 충분하지만,
회사 규모가 커지고 프로젝트 참가자가 커진다면
지금처럼 엑셀로만 하는것에는 한계가 부딪칠 것입니다.
그때에는 맘에드는 이슈트래커를 찾아야 하겠지요.
다른 회사에서는 어찌하나
그리고 어떻게 하면 팀원들의 참가를 유도할수 있는지 궁굼해집니다.
------------------------------
이에 관련한 좋은 글은 아래 글을 읽어 보시기 바랍니다.
2회(2007년 12월): 이슈 트래커를 슬기롭게 활용하자
------------------------------
관련 자료중에서 ISSUE & WIKI 기반의 통합 관리에 대한 강의자료가 이곳에 있습니다.
발표 자료는 아래에 연결해 두었습니다.
------------------------------
'Embedded' 카테고리의 다른 글
| Altera NIOS-II (1) (0) | 2013.03.15 |
|---|---|
| uC/GUI 데모 그림입니다. (0) | 2010.07.18 |
| 1초만에 부팅되는 Embedded Linux (0) | 2010.07.02 |
| GCC4.5.0이 발표되었습니다. (0) | 2010.04.22 |
| XCode에서 SCM 15505 ERROR가 발생하면.. (0) | 2010.01.13 |
