보통 잘 되어있는 소프트웨어 개발 프로세스를 보면 사용자들로 부터 버그 리포트 등을 받게 되면 이를 관리자가 검토한다음 수정해야할 버그라고 생각되면 담당 개발자에게 할당 (Assign)하게 된다. 그런 다음 이 개발자는 자신에게 적당한 버그면 수정을 하고 그렇지 않다면 이 버그는 다른 새발자에게 넘겨준다 (Tossing)
보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?
그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.
우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.
재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?
우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?
여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?
보통 버그는 몇명에게 Tossing된 다음 Fix 될까?
이 Tossing에 어떤 패턴이 있을까? 늘 Tossing하는 사람들의 그룹이 있을까?
그래서 Mozilla의 버그 리포드 35만개를 가지고 실험을 해보고 이런 그래프를 얻었다. 어떤 버그는 무려 24명의 개발자가 할당되기도 했다.
우선은 데이타 량이 너무 많이 그림이 복잡한데 하나의 노드는 개발자나 메너저를 의미하고 하나의 화살표는 100번의 버그 Tossing을 의미 한다.
재미있는 형태의 그래프가 나오긴 했지만 무엇에 사용할 수 있을까?
우선 1. 개발자들의 그룹을 자동으로 알수 있게 된다.
2. 혹 개발자들간의 그룹이 확연하게 나타나면 버그를 할당할때 해당 그룹 모두에게 할당하여 서로간의 할당 시간을 줄일 수 있지 않을까?
3. 메니저가 버그를 할당할때 이 그래프가 힌트를 줄 수 있을까?
여러분들이 한 소프트웨어 프로젝트의 메니저이고 자신의 팀들의 버그 Tossing관계를 보여 준다면 어디다 사용할수 있을까요?
Prev
Rss Feed