작은 규모 팀의, 이슈 관리 프로세스 개선

Redmine
Issue
Guide

Redmine 이슈 관리 가이드 문서를 공유합니다.

문서를 만든 목적

PM으로 일하게 된 SI 프로젝트에서 배포된 시스템에 대한 이슈 관리(버그 및 기능 추가)가 잘 되지 않았습니다. 대표적으로 다음과 같은 문제가 자주 발생했습니다.

  1. 수정된 코드의 문제가 고객에 의해 발견되는 일들이 있었습니다.
  2. 버그의 정확한 원인 분석 없이 주먹구구 식으로 문제를 덮는 일들이 발생했습니다.
  3. 개발자들이 언제까지 이슈를 처리할 것인지에 대한 일정 공유가 잘 되지 않았습니다.

문서의 주요 내용

그래서 문제를 해결하기 위해 다음과 같이 이슈 관리 프로세스를 정의하여 개발팀과 공유하였습니다.

  1. 개발자가 코드를 수정 완료하면 [해결됨] 상태가 되고, 테스터 또는 매니저에 의해 검증이 완료되면 [종료] 단계로 전환되도록 하였습니다. [종료] 단계에 놓인 이슈만 배포하도록 했습니다.

  2. 이슈 명세에 아래와 같이 논리적인 흐름에 따라 문제를 명시하도록 문서 양식을 가이드 하였습니다. 아래와 같이 3 단계로 문제를 기술해보고 논리적 흐름이 빈약하면 반려하도록 했습니다.

    • 문제가 무었인가?
    • 원인이 무었인가?
    • 어떻게 처리했는가?
  3. 레드마인 이슈에 완료예상 일정을 등록하도록 하여 개발팀과 관리자와 고객이 일정을 공유하도록 했습니다.

결과

정략적인 지표로 제시할 수는 없지만 단순하게 코드 수정을 누군가 한 번 더 검증하도록 하고, 문제를 논리적으로 기술하도록 가이드함으로써 이슈 처리의 질이 훨씬 좋아진다는 것을 느낄 수 있었습니다.

댓글