Microspeak: Bug jail - The Old New Thing - Site Home - MSDN Blogs.

굳이 우리 말로 번역하자면, 버그 감옥이 되겠다. 이름에서 오는 뉘앙스와는 달리, 버그들이 가는 감옥이 아니고, 버그를 너무 많이 가지고 있는 개발자들이 가는 감옥이다. 쳇.

Bug push 를 위한 기법 중 하나로, 실천 방법은 상황에 따라 팀에 따라 조금씩 다를 수 있다. 예를 들어본다면 이런 식이다. 'P0 버그를 6개 이상 가지고 있는 사람은 그 수가 3이하기 되기 전까지, feature 코딩을 해선 안된다.'

이렇게 묵혀 놓고 있던 버그들을 푸쉬 함으로써 프로젝트 관리상에서 생기는 이점들이 있다. 가능하면 일찍 중요한 버그들을 우선 작업하도록 할 수 있고, 그로인해 막혀있던 커뮤니케이션을 밀어붙일 동력을 얻을 수 있다.

중요한 것은 개발자를 혼내는 데 목적이 있는 것이 아니라, 처리가 원활하게 안되는 것들을 부각시켜서 일을 진행시키는 데 있다는 것이다.

이전 회사에서 딱 한번 Bug jail 을 시도한 적이 있었다. 그 때 세워진 trigger 는 "버그가 n 개 이상인 사람은 집에 갈 수 없다." 였었다. 나는 애당초 버그의 개수가 그리 많지 않았기 때문에 쉽게 출감했으나, 몇 분은 그리하지 못했다. 그렇다고 해서 먼저 출감한 사람들이 그 분들을 도와주는 것도 그다지 장려되지 않았다. 나는 이 방법이 뭔가 잘못됐다고 생각했었고, 그 얘기를 워크샵 술자리에서 하다가 그만 야단 법석이 한번 벌어지고 말았다.

어떤 practice 를 도입하기 전에는 최대한 신중히 하는 것이 좋고, 그것의 목적이 무엇인지 분명히 알아야 한다. 굳이 jail 을 글자 그대로 받아들여 물리적 제약을 가하는 것은 개발자들의 사기진작이나 팀웍 에 그다지 도움이 되지 않는다.