Software Issue Life Cycle - Status 개선 사례

 

Software Issue Life Cycle - Status 개선 전

 수 년전, 당시 팀원들과 함께 개발 Task 및 Issue Task의 상태(Stauts)에 대해 위와 같이 정의하고 관리를 해오고 있었다. 아래와 같이 정의한 시점에는 Task의 양이 많지 않았고, 제품의 수나 제품 버전 또한 그리 많지 않은 상황이었다. 그 당시에는 아래와 같이 구분해도 충분히 커뮤니케이션 및 History 관리에 무리가 없었던 수준이었다. 

 하지만 수 년이 지난 현재에는 개발/검증 담당자들 또한 많은 변화가 있었고, Task가 워낙 다양하고 많아지게 되었고, 그러다 보니 Task의 History 관리 측면에서 일부 혼선이 발생하고 있었다. 그 중 가장 구별에 혼선이 발생했던 Status는 "Invalid" 로 정의했던 Status 였다. 해당 Task가 잘못 리포트 되었던 Task인 경우에도, 그리고 실제 이슈가 발생하였으나 해당 이슈에 대한 긴급도나 발생 빈도 등에 따라 수정 진행을 하지 않게 된 Task인 경우에도 Invalid로 구분하고 있었다. 하지만 Invalid 상태의 Task가 너무 많이 쌓이게 되다 보니 Task 내용 및 Task에 달린 Comment를 다 읽어야만 어떤 이유에서 Invalid 처리를 하게 된 것인지 파악할 수 있게 되는 지경에 이르렀다.

 신규로 입사하는 팀원들이 하나 둘 늘어가다보니 Invalid 상태에 대한 문의가 좀 많아졌고, 그에 따라 팀원들과 수 차례 좀 더 효과적인 구분 방법에 대한 논의를 통해 아래와 같이 구분하여 관리를 하기로 결정되었다.

 

Software Issue Life Cycle - Status 개선 후

( Reviewing 상태도 추가되었으나, 이 Status에 대해서는 이 포스트에서 생략하도록 한다. )

주 개선 내용은 Invalid 상태를 "Won't fix" 와 "Not a bug"로 구별하여 정의를 하게 된 부분이다.

모호한 Invalid 라는 표현 대신, 좀 더 명확한 의미의 아래 2가지 Status로 분리하여 정의하였다. 

 

<Won't fix> 

개선 예정이 없는 Task.

이슈가 확인되어 리포트 하였으나, 의도된 시나리오거나 유관 부서와의 논의를 통해 수정이 필요없다고 판단되는 경우.

 

<Not a bug> 

이슈로 Report 되었으나 이슈가 아닌 Task.

발생된 적이 있으나, 연관 시나리오 수정으로 더이상 발생 가능성이 없어진 이슈.

 

 

인원 수가 적고, 관리 목록이 적은 시점에는 적당한 수준에서의 분류로도 커뮤니케이션이나 History 관리에 무리가 없었으나, 인원이 늘어가고 Task나 제품 수도 늘다보니 이렇게 작은 부분까지도 소통이 클리어하지 않게 되는 경우를 종종 마주치게 된다. 그래서 요즘은 수 년 전 고민을 통해 만들어 두었던 가이드 들을 조금씩 개선하여 협업을 해나가고 있다. 언젠가 나중에 뒤돌아 보면 이러한 과정은 잊혀지고 최종 결과물만 남아있을 것 같아, 중간 과정이 될지도 모를 개선 History도 기록을 해놓고 싶어 포스트를 쓰게 되었다. 나 혼자 보는 기록이 될지도 모르겠지만.. ^^;