알라딘MGG와이드바


측정하지 못하면 관리하지 못한다. 정말? 개발 이야기

소프트웨어 크리에이티비티 2.0 을 읽다가
작년부터 계속 고민해왔던 생각을 떠올라 써 봅니다.

작년 KGC 에서 내가 발표한 내용 중, UnitTest 도입 효과에 대해 설명한 것이 있다.
대략 다음과 같은 그림이었는데...


이 자료는 다음과 같은 방식으로 수집했다.
1. 버그 추적 도구에서 데이터를 XML 로 export 한 후
2. C# 의 XML 파서를 사용해서 디버깅 생산성 측정 프로그램을 만든 후 데이터를 분석

통계는 다음 규칙을 만들었다.
1. 버그가 처음 보고된 시간으로부터 버그를 수정한 시간까지의 평균
1-1. 우선순위가 높은 것부터 확인. 너무 우선순위가 낮은 버그는 통계에서 무시
1-2. 사례보고 같이 몇 년동안 해결되지 못한 버그도 무시
2. 버그가 발생한 횟수를 개발 분기별로 분류

'500% 생산성 증가'란 말에는 약간 과장이 있지만, (특히 레거시 코드에서는) 200% ~ 300% 이상 생산성이 증가한다고 생각한다. 이런 자료 덕분에 막연히 UnitTest 를 도입하면 생산성이 향상되고, 버그가 줄어든다더라가 아니라, 실제로 해 보니 이렇게 생산성이 향상되고 버그가 줄었다고 얘기할 수 있는 근거를 얻게 되었다.

문제는 이제부터인데,
막상 이런 식으로 디버깅 생산성 측정 규칙을 정했더니, 그 규칙에 내가 끌려다니게 되었다.
예를 들자면, 버그 추적에 아직 올라와 있지 않은 긴급한 서버 Crash 가 날 경우, 당연히 Crash 를 다른 무엇보다도 먼저 수정해야 한다. 하지만 Crash 는 버그 추적 도구 대신 개발팀에 직접 이메일로 전달되는 '시급한' 문제다보니, 이걸 고친다고 하루, 이틀 고생해 봐야, 위에서 정한 디버깅 생산성 통계만 놓고 보면 내가 아무 것도 안 한 것이 된다.
마찬가지로, 다른 사람이 버그로 고생하고 있을 때에도, '내꺼부터 빨리 수정해야지, 다른 사람 도와줘봐야 측정도 안 되고...'라는 어이없는 생각에서 벗어날 수가 없게 되었다.
(디버깅 생산성 측정 프로그램은 순전히 UnitTest 를 적용했을 때의 효과를 확인하기 위해서만 썼지, 팀원들의 생산성을 측정하는 용도 등으로는 쓰지 않았는데도 불구하고 말이다)
Crash 수정 횟수라던가 다른 사람을 도와준 횟수도 같이 기록하면 되지 않겠냐고 할 수 있겠지만, 이것 역시 누가 얼마나 공헌했는지를 알기도 어렵고, 이렇게 모든 걸 다 기록하기 시작하면, 어느새 작업량보다 측정을 위한 일이 더 많아지게 된다.

그래서...? 당장 디버깅 생산성 측정 프로그램을 폐기해 버렸다. ㅎㅎ
이렇게 하고 나니, 마음이 편안해지고, 다시 팀에서 가장 중요한 일을 먼저 할 수 있는 마음가짐을 가질 수 있게 되었다.

시간당 LOC(line of code) 를 기록하는 회사도 있다고 하는데, 누가 하루 종일 고민해서 대박 버그를 찾아내 고쳤는데, LOC 만 놓고 보면 시간당 1 라인을 작업했다고 나와서, 관리자가 왜 이리 일을 안 하냐고 다그쳤다는 얘기도 있다.

개발자의 생산성은 어떻게 측정하더라도, 거기에 맞춰 사람들이 최적화되기 때문에, 가능하면 하지 않는게 좋다. 생산성을 측정하겠다면, 그 목적이 사람들을 평가하기 위해서가 아니라, 팀 개발 프로세스 중 어디에서 생산성을 더 높힐 수 있는지를 확인하고, 변경한 프로세스가 이전보다 생산성을 얼마나 높혀주었는지를 확인하는 목적에만 써야 한다. 그렇지 않고, 어떻게든 사람을 평가하기 위해 측정 방법을 도입한다면, 개발자들은 그에 맞춰 배신게임을 할 것이다.

핑백

  • sosa0sa.com » 개발자들의 적응력 2009-07-01 09:24:32 #

    ... 얼마나 높혀주었는지를 확인하는 목적에만 써야 한다. 그렇지 않고, 어떻게든 사람을 평가하기 위해 측정 방법을 도입한다면, 개발자들은 그에 맞춰 배신게임을 할 것이다. 측정하지 못하면 관리하지 못한다. 정말? Categories: note Tags: Comments (0) Trackbacks (0) Leave a comment Trackback No comments ... more

  • 박피디의 게임 아키텍트 블로그 : UnitTest++ 1.4 Window Project 에 추가하기 2010-04-23 23:09:47 #

    ... 었습니다. 참고 : KGC2007 - 'UnitTest, TDD in Games' 발표 자료 낡은 코드(Legacy Code)로 효율적으로 일하기 측정하지 못하면 관리하지 못한다. 정말? 테스트 주도 개발. 무엇을 어떻게 왜? 실전! 지속적인 통합 7편: 단위 테스트 2편 - UnitTest++ 도입하기 - 최재훈 Visua ... more

  • 박피디의 게임 개발 이야기 : 애자일/스크럼 프로젝트는 왜 실패하는가? Part 2 2011-09-30 13:01:01 #

    ... 석하면서 개발자들의 일정만 관리시켰는데 아니나다를까 몇 달 후 그 회사에서는 더 이상 스크럼을 하지 않았다. 속도를 측정해 이를 근거로 야근을 강요했다.측정하지 못하면 관리하지 못한다. 정말? 에서 언급한 내용과 비슷한 경우다. 이슈트래커로 Backlog 를 기록하고, Burndown Chart 를 통해서 현재 개발팀의 작업속도를 측정 ... more

덧글

  • 써니 2009/06/03 11:39 # 답글

    마지막 하나의 문장에 핵심이 잘 담겨진 듯 합니다.
    좋은 글과 책 출간 정보 감사드립니다.
  • 박PD 2009/06/03 17:46 #

    감사합니다.
  • 커널0 2009/06/03 12:25 # 삭제 답글

    올쏘올쏘~~~ 감동의 포스팅입니다.
  • 박PD 2009/06/03 17:49 #

    그래도 우리 팀은 이런 일이 없어서 회사 다닐만 하구만.
    앞으로는 또 어떻게 될지 모르지만 ㅎㅎ
  • anemos 2009/06/03 13:24 # 삭제 답글

    생산성 꿈의 0 % 를 몸소 실천 중.. 쿨럭;;
  • 박PD 2009/06/03 17:49 #

    버그 발생 0% 이기도 하겠지. 팀의 기둥이 왜 이런 댓글을 :)
  • kks 2009/06/05 09:56 # 삭제 답글

    박PD~ 우리회사 와서 얘기 좀 해다우. OTL
  • 박PD 2009/06/07 12:09 #

    강연료 비싸게 불러주시면 생각해 볼께요 :)
  • dalmuri 2009/06/05 12:19 # 삭제 답글

    재밌게 잘 읽었습니다~ 시간 되시면 버그 데이터 분석하는 방법 좀 자세히 알려주세요^^
  • 박PD 2009/06/07 12:09 #

    버그 데이터 분석에 관심 있으신 분들이 좀 있으시네요.
    다음에 한 번 정리해 보겠습니다.
  • TTF 2009/06/07 02:51 # 삭제 답글

    와우~ 생각지도 못했던 의외의 결과를 알려주셔서 감사드립니다.

    유닛테스트의 기능적인 장점만을 생각했었는데, 생산성 측정의 기준으로 정말 적합하지 않네요.
    요즘 재미있게 읽고 있는 프로그래밍 심리학에서도 프로그래머 혹은 프로그램을 측정하는 기준 선정의 어려움이 나와 있는데요.
    이번 블로깅을 읽지 않았다면, 관리자에게 유닛테스트의 훌륭함을 어필하고 유닛테스트 결과가 평가 기준으로 선정되도록 노력하려는 생각도 했었습니다.
    (관리자는 항상 손쉬운 평가 방법을 선택하고 싶은 유혹에서 벗어나기 힘들죠.)

    유닛테스트 결과를 평가 기준으로 삼을 경우에는 최악의 경우엔 유닛테스트 결과를 만족하기 위한 행동을 하게 되겠네요.
    결국 일보다는 평가를 받기 위해 열심히 프로그래밍을 하는 상황으로 변질될 우려가 있었네요. -_-;
  • 박PD 2009/06/07 12:10 #

    네.. 제 스스로가 그런 유혹에 시달렸으니 관리자들은 더 할 것도 없겠죠.
    평가는 쉽지 않다는 걸 알게 된 소중한 경험이었습니다. :)
    프로그래밍 심리학 보고 있으면 같이 스티디 하면 좋았곘네요. 다음에 뵙겠습니다.
  • yagur 2009/08/18 20:44 # 삭제 답글

    상당히 고무적인 글이군요... =)
댓글 입력 영역


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2