- Last Paromix -

추정(Estimate)에 관해 잠깐 얘기해 볼까 합니다.



<소프트웨어 공학의 사실과 오해>을 보면 55가지의 사실 중에 21번째에는 이런 내용이 담겨 있습니다.

문제의 복잡성이 25% 증가하면 소프트웨어 솔루션의 복잡성은 100% 증가한다.

- 소프트웨어 공학의 사실과 오해 中 -

25%와 100%라는 숫자가 정확하게 맞는지는 모르겠지만(실험을 통하여 얻어낸 숫자라고 하니 어느정도 타당하다고 믿어 볼까요.) 문제의 복잡성이 커지는 것에 비해 솔루션의 복잡성이 커지는 비율이 아주 높은 것은 사실이죠. 하지만 대게 초보개발자들이(또는 천성이 낙관적인 개발자들이) 일정을 잡을 때에는 문제의 복잡성을 기준으로하여 추정하게 되곤 합니다. 물론 여전히 초보개발자인 Paromix군도 마찬가지고 말입니다.^^

경영진과 프로그래머 사이에는 단절이 있다. 한 연구 조사에 따르면, 추정에 맞추지 못해 경영진은 실패라고 생각하는 프로젝트에  대해, 거기 참여했던 기술자들은 그들이 작업한 것 중 가장 성공적인 프로젝트라 평가했다고 한다.

- 소프트웨어 공학의 사실과 오해 中 -

Paromix군도 다른 많은 개발자와 비슷하게도 낙관적인 추정을 하곤 하죠. 실제 끝나는 시점이 Paromix군이 예상한 것보다 늦춰지는 경우가 많이 있습니다. 하하. (대신에 다른 사람에게 일정을 얘기할 때는 스스로 생각한 일정보다 조금 길게 잡고 얘기하긴 하죠.^^) Paromix군이 추정에 실패하는 이유를 곰곰히 생각해봤더니 설계와 코딩에 들어가는 시간만 계산하고 있고, 테스트와 디버깅(그리고 기타 집중하지 못하는 시간들)에 들어가는 시간은 계산하지 않는 버릇이 있었다는 걸 깨달았습니다. 게다가 실제 개발하는 시간도 생각한 것보다 오래 걸리는 경우가 많고 말이죠.

끝에서 끝까지(End-To-End)는 생각하는 것보다 더 멀다.

- 익스트림 프로그래밍 中 -

아마 이런 점을 간과하고 있기 때문에 추정이 어려운 것일까요.

스스로 추정에 실패하고 있다는 사실을 깨달은 다음부터는(사실 깨닫는데에도 시간이 오래 걸렸다죠) 테스트와 디버깅이 설계와 코딩에 들어가는 시간과 비슷하다고 보고 감으로 떠오르는 시간에 두배를 곱해서 추정을 하기 시작했습니다. 정확하지는 않았지만 예전에 비해서는 정확도가 꽤 올라갔죠. (그 전까지 Paromix군이 얼마나 엉터리로 추정을 했었는지 알 수 있겠죠?? 하하)
그래도 아직 그리 정확하진 않았습니다. (세상엔 재밌는 일은 많지만 쉬운 일이 없다니까요^^)

Jeffery와 Lawrence는 "추정을 전혀 하지 않은 프로젝트가 생산성 측면에서 가장 성공적이었다."는 사실을 발견했다. 바로 다음은 기술자들이 추정을 수행한 프로젝트가 차지했고, 관리자가 추정을 수행한 프로젝트는 최악이었다.

- 소프트웨어 공학의 사실과 오해 中 -

추정을 하지 않은 프로젝트가 가장 생산성이 높았다고는 하지만, Paromix군이 그리 선호하는 방식은 아니군요. 그래서 조금 더 정확하게 개발시간을 알아내고 싶었습니다. 문득 <조엘 온 소프트웨어>에 나오는 내용이 떠오르더군요. (책 읽는 보람이 있긴 있나봅니다.^^) 할일들을 능력껏 세부적으로 나누고 각각 예상되는 시간을 적어두었습니다. 그리고 실제 일을 하면서 투자한 시간을 적어 두는거죠. 여러 번 반복해서 해보고 나니 실제로 개발하는데 걸리는 시간에 대해 어느정도 감이 새로 오기 시작합니다. 오늘도 한건 했군요. 보람찬 하루죠? 하하.^^



다른 분들은 어떻게 스스로의 일정 시간을 추정하시나요.? :D



"Paromix"