2008. 11. 3. 22:27

버그 넘기기 (Tossing Bugs)

보통 잘 되어있는 소프트웨어 개발 프로세스를 보면 사용자들로 부터 버그 리포트 등을 받게 되면 이를 관리자가 검토한다음 수정해야할 버그라고 생각되면 담당 개발자에게 할당 (Assign)하게 된다. 그런 다음 이 개발자는 자신에게 적당한 버그면 수정을 하고 그렇지 않다면 이 버그는 다른 새발자에게 넘겨준다 (Tossing)

보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?

그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.



우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.

재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?

우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?

여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?


Trackback 0 Comment 3
  1. 화사 2008.12.10 12:33 address edit & del reply

    저라면 유사 버그 발생시에 이번 버그와 가장 유사한 기존 발생 버그를 찾아내서, 그 버그를 해결한 사람에게 의견을 구하겠어요. 3번 처럼 매니저가 버그 할당시 그래프가 도움이 되겠네요.

  2. Gurutect 2011.08.09 22:48 address edit & del reply

    35만개의 버그리포트를 가지고 나온 그래프라서 그런지...매니저라면 안 볼것 같습니다..^^;;
    대신 토싱하는 사람들에 대한 정보가 있으니... 코드리뷰를 할때 자동으로 reviewer로 추천하면 좋을것 같네요. 그리고 기존에 유사한 버그를 해결한 사람에게 의견을 구할수도 있지만, 어떻게 해결을 했는지 연결을 시켜서, 리뷰시나 defect을 fix할때 참고할 수 있도록 해놓으면 좋을듯합니다.

  3. sangheestyle 2012.05.13 17:02 address edit & del reply

    다음 팀 빌딩때 tossing이 자주 발생하는 그룹을 한 팀으로 엮는 시도를 해볼수 있을것 같습니다. Tossing이 자주 발생하는 문제의 경우 한 사람의 역량보다 여러명의 역량과 뷰가 필요한 경우가 있는데, 팀이 다른 경우 이해관계등에 의해서 협업이 깨져 비용이 더 드는 경우를 많이 봐왔습니다. 따라서 다음 팀 빌딩(예. 조직 변경)시에 이를 이용해서 tossing이 덜 일어나도록, 일어나더라도 그 횟수가 줄도록 하는게 좋을거라 생각합니다. 더불어 Gurutect 님의 말씀처럼 reviewer 로 추천하는것도 좋은것 같기는 한데, 그렇게 하면 너무 많은 메일을 받을 수 있다는 단점도 있기는 합니다. (실제 그런 사례를 보니 관련자들이 고통스러워했습니다.) :0