진정 하고 싶은말

수십 년간, 수많은 학자들이 소프트웨어 공학을 연구하였으며, "소프트웨어 위기"라는 말이 나온 지도 40여 년이 흐른 지금의 우리에게도, 40여 년 전 세대의 소프트웨어 종사자들이 겪었던 문제가 그대로 답습되고 있다.

한 세대를 풍미했던 수 많은 방법론, 그 방법론이 나왔을 땐 마치 모든 문제를 해결할 것만 같았던 - 구조화 프로그래밍, 객체지향 프로그래밍, CBD, 최근의 SOA까지 - 정말 그럴 듯 했던 그 많은 방법론을 적용하여 왔지만 왜 아직도 이 모양일까? 아직 시도해 보지 못한 방법론이 남아서일까? 그렇지 않다면 이 문제들은 이 산업계에 영원히 풀 수 없는 숙제일까?

소프트웨어 위기에서 통상적으로 얘기되는 예산 초과, 개발 지연, 낮은 품질 등의 문제는 거꾸로 생각하면, 예산을 프로젝트 규모에 비해 적게 잡은 것이며, 개발일정을 규모에 비해 짧게 잡은 것이다. 적은 예산과 짧은 일정, 이 속에서 개발된 프로그램이 높은 품질이 될 수 없음은 이미 예견된 사실일 것이다.

끊임없이 반복되는 이 문제들의 근본적 원인은 프로젝트가 우리의 예측 범위 안에 있지 못함에 있으며, 이 적중률을 떨어뜨리는 데에는 소프트웨어 개발 프로젝트를 바라보는 우리의 시각이 한 몫을 차지하고 있다.

그렇다면 프로젝트를 바라보는 우리의 시각은 어떠한가?

첫째, 소프트웨어 개발 프로젝트는 개발을 하는 것이지 생산을 하는 프로젝트가 아니다.

흔히 간과되는 점 중의 하나가, 마치 공장의 생산라인을 생각하듯 개발자를 바라보는 점이다. 생산라인을 24시간 운영하면 생산량이 늘 듯, 개발자 또한 오래, 오래 컴퓨터 앞에 앉아 있을수록 생산성이 높아진다고 생각한다. 소프트웨어는 기계에 의한 생산이나 반복적 노동의 산물이 결코 아니다.

둘째, 우리의 기억력은 물고기 같아서 3초 이상을 기억치 못한다.

지난 번에 수행했던 프로젝트가 예산 부족과 짧은 일정으로 힘들었지만, 새로운 프로젝트를 시작할 무렵이면 이 모든 것을 아주 까맣게 잊어 버리고 잘 되겠지 하는 마음으로 낙관적으로 프로젝트를 계획한다. 이 낙관적인 계획에도 여유를 다소 가져가지만 그마저도 영업팀, 사업팀과의 협의 과정에서, 거품처럼 사라지고, 최초 생각했던 예산마저 깎이면서 계획단계부터 무임의 초과 근무를 고려한 체 시작된다. 이 경우 빠지지 않는 것이, 프로젝트팀의 영웅심 유발인데, 마치 구국의 일념으로 프로젝트에 투입되는 듯한 분위기를 조성한다. "하면 된다"의 해병대 정신, 이 또한 빠지지 않는다.

셋째, 우리에겐 거울이 없다.

거울을 통해 나의 모습을 바라볼 수 있어야 하는 데, 거울이 없으니 손으로 얼굴을 더듬어 대충 추정하는 수 밖에 없으며 이마저도 극히 부정확하다. 프로젝트팀이 서로의 얼굴을 처음 확인하는 자리가 프로젝트 첫날이다. 그마저도 같은 회사도 아니고, '을', '병', '정', '무' 소속된 회사도 제 각각이다. 이러한 프로젝트팀이 생산성이 얼마나 되는 지, 프로젝트팀의 성격은 어떠한 지를 제대로 이해할 때쯤이면 프로젝트의 개발이 한참 지났을 때이다. 팀워크, 팀원간의 의사소통을 가장 프로젝트 성공의 가장 중요한 요인 중 하나로 꼽지만, 수많은 사람들이 서로를 이해하기엔 너무나도 짧은 시간이 주어지는 것이다.

고객에게, 우리 소프트웨어의 최종 사용자에게 정말 제대로 된 소프트웨어를 전하고 싶다. 그러나 이는 앞에서 전술한 몇 가지 이유 외에도 많은 원인이 복합되어 우리의 바램을 이루기 어렵게 한다.

이들 문제의 해법으로 생산성을 들곤 하는 데, 개발 생산성이 2배로 증가로 증가된다고 해서 우리가 바램이 이뤄질 것으로 생각되진 않는다. 아마 처음 한, 두 프로젝트에서는 목표가 이뤄질 지 모른다. 그러나 그 후부터는 2배로 증가된 생산성을 기준으로 프로젝트 계획이 이뤄질 것이며, 이에 따른 일정의 지연, 예산 초과, 품질 저하 등이 반복 될 것이다.

소프트웨어 위기의 문제는, 프로젝트를 제대로 예측할 수 없게 하는 많은 요인들에 의한 이 산업계 전반의 구조적인 문제이지, 결코 개발 도구, 방법론 등으로 해결될 수 있는 것이 아니다. 개발 도구, 방법론 등에는 프로젝트를 성공으로 이끄는 가장 중요한 요소, "사람"이 빠져있다. 성공적인 프로젝트에는 이 프로젝트를 헌신적으로 수행했던 사람이 있다. 사람들을 도외시하고선 성공적인 프로젝트의 완수란 있을 수 없는 것이다.

성공적인 프로젝트, 좀 제대로 된 소프트웨어를 만들기 위해선 프로젝트가 우리의 예측 범위 안에 있어야 하며, 이를 위해 다음 몇 가지를 제시할 수 있을 것이다.

첫째, 훈련된 우리팀이 있어야 한다.

우리팀, 우리 프로젝트라는 생각을 가질 수 있는, 공동의 목표를 위해 함께 일할 수 있는 프로젝트팀이 구성되어야 하며, 이 팀은 적절히 훈련되어 있어야 한다.

비용을 이유로 프로젝트 개발의 많은 부분을 아웃소싱하게 된다. 특정모듈을 아웃소싱하는 경우도 있고, 프로젝트팀 자체를 다국적군 형태로 구성해서 개발을 진행하거나, 개발조직 자체를 아웃소싱하고 단순히 관리조직만 참여하는 경우도 있다.

이러한 아웃소싱이 단기적으로는 회사에 이득일 수 있으나 이러한 것이 반복되다 보면 회사 내에 개발인력은 없고, 관리인력만 있게 되는 순간이 온다. 회사는 프로젝트를 수행할 능력을 잃어버리고 허울뿐인 소프트웨어 개발회사로 자리매김하게 되는 것이다. 전문화, 분업화의 이름 하에 프로젝트 전체를 한 회사가 수행하기는 어렵다. 그러나 프로젝트에 참여하는 사람이 많을수록 의사소통을 위한 경로의 수가 많아지듯, 참여하는 회사가 많을수록 회사간의 책임소재와 이해관계 조정을 위해 허비해야 하는 시간이 증대되며, 이는 프로젝트팀의 갈등을 유발하고, 프로젝트팀내의 반목으로 인해 험악한 분위기가 연출되기도 한다.

군인에게 있어 사기가 중요하듯, 프로젝트 팀의 사기와 동기 그리고 팀원간의 팀워크는 어느 무엇보다 중요하다. 프로젝트의 팀워크는 오랜 시간 같이 일한 팀에서 우러나온다. 설령, 여러 가지 이유로 인해, 다국적군 형태로 프로젝트팀이 구성된다 할지라도, 지난번에 함께 일했던 사람들을 중심으로 프로젝트팀을 꾸려야 한다. 그리고 고객에게 전하고자 하는 핵심 가치는 직접 수행해야 한다. 핵심 가치마저도 아웃소싱하게 되면 고객이 물어올 것이다. "무슨 역할을 하는 회사예요?" 만약 추가로 진행되는 프로젝트가 있다면, 특별한 정치적인 이유가 없는 한, 고객은 추가사업에서 배제하려고 할 것이다.

구성된 프로젝트팀은 훈련되어 있어야 한다. 프로젝트의 방법론을 제대로 이해하고 따르기란 정말 어렵다. 이에 대한 충분한 교육이 있지 않으면, 아무리 좋은 방법론일지라도 제대로 수행되기 어렵다. 그간 많은 회사들이 조직의 프로세스를 개선하기 위해, TQM, QFD, CMMi, 6시그마, ISO9001등 수 많은 시도를 하였다. 그러나 이러한 기법은 조직 전체가 그 내용에 집중하여 적용할 때만 가치를 가지는 것이지, 담당자 몇 명의 작업에 의해, 매 년마다, 유행이 바뀔 때 마다 획득된 인증서는, 대외적 홍보물 이상의 의미가 없다. 과연 이렇게 획득된 인증서가 그 조직의 품질을 담보하는가? CMMi 5 레벨의 회사는 CMMi 3 레벨의 회사보다 좋은 품질의 소프트웨어를 훨씬 저렴한 가격에 제공할 수 있다고 장담할 수 있나? 시장에서 연출되는 가장 코믹한 상황중의 하나는, ISO9001등의 인증서를 획득한 업체가 제안한 프로젝트를 인증과는 아무 관계가 없는 업체가 수행하는 것이다.

프로젝트팀이 사용해야 하는 방법론, 개발도구 등이 있다면 충분히 교육되어야 한다. 회사의 프로세스 개선을 위해 도입한 기법이 있다면 지속적으로 훈련되어야 하며, 이러한 기법이 조직 내에 스며들어 효과를 발휘할 수 있을 때까지 꾸준히 추진되어야 한다.

프로젝트는 사람이 한다. 아무리 좋은 도구와 방법론, 이를 지원하는 훌륭한Back-Office가 있다고 해도, 프로젝트팀이 훈련되지 않고, 팀워크를 갖추지 못한다면 프로젝트는 

해 저문 벌판에서 돌아갈 길을 잃고 헤메이는 어린 양1 

이 되고 만다.

둘째, 재활용, 자동화 그리고 단순화해야 한다

지난 프로젝트의 산출물, 즉 검증된 라이브러리, 모듈 등은 최대한 재활용해야 한다. 아주 사소한 버그로 인해 하룻밤을 꼬박 세운 날이 하루 이틀이 아니다. 이러한 실수는 누구나 할 수 있으며, 이러한 실수를 줄이려면 되도록 이미 검증된 산출물을 사용하는 것이 최선의 방법이다. 재활용은 단지 프로그램 라이브러리 등에 국한되는 것이 아니다. 사용자 요구사항부터 테스트 케이스 등에 이르기까지 프로젝트를 수행하면서 만든 모든 것을 재활용하고자 노력해야 한다.

재활용도를 높이기 위해선, 프로젝트가 완료된 후, 재활용이 가능하게끔 정리하고 다듬는 작업이 필요하다. 경우에 따라서는 신규로 매뉴얼을 작성하는 등의 투자 또한 필요하다. 오픈 소스를 선정할 때, 주요 선정기준의 하나가 제대로 된 매뉴얼이다. 매뉴얼 없는 프로그램 소스를 보고서 분석하는 데 드는 시간이 신규로 개발하는 시간보다 긴 경우가 많다. 정리 안된 수십 기가의 자료를 복사해 주며 프로젝트 기간에 재활용을 해 보라는 건 HDD의 낭비일 뿐이다.

반복되는 작업은 자동화하려고 노력해야 한다. 반복되는 빌드, 반복되는 테스트, 반복되는 배포, 반복되는 자료의 입력, 주위를 둘러보면 수많은 작업들이 반복되지만 목수 집에 비 새는 격으로 프로그램 개발을 업으로 하는 우리지만 우리의 환경을 자동화하는 것에 많이 소홀하다. 농부가 호미를 갈지 않으면 수고로움이 더한 법이다.

복잡한 프로세스, 복잡한 문서, 그리고 양식만 바꿔서 계속 만들어야 하는 것들은 단순화 해야 한다. 프로세스를 계획하는 사람의 입장에선 복잡다단한 것을 만드는 것이 뭔가 일을 한 것처럼 보이겠지만, 프로세스를 복잡하게 만드는 순간 이미 프로세스를 따르지 말라고 공표하는 것과 같다. 마치 따라 해 볼 테면 따라해 봐라고 말하는 것이나 같다. 프로세스는 프로젝트팀원이 누구나 쉽게 이해하고 따를 수 있는 수준에서 정해져야 하며 이들 프로세스는 시스템을 통해서 자동으로 이뤄지게 해야 한다.

A4용지 수십 장을 한꺼번에 봐야 되는 복잡한 다이어그램을 주위에서 쉽게 본다. 과연 이 다이어그램을 누가 볼 것이며, 본다고 한들 제대로 이해나 할 수 있을까? 오히려 핵심이 될 부분만 간략히 기술된 것이 훨씬 이해하기가 수월하다. 복잡한 다이어그램을 그리느라 시간만 소모되고, 쓸모 없는 복잡한 문서를 만들기 보단 사람이 이해하기 편한 간략한 문서를 만들도록 해야 한다. 내용보다 산출물의 두께로 승부하지 않았으면 한다.

그림 21 복잡한 다이어그램은 사람들의 이해도를 떨어뜨린다. (Martin, UML for Java Programmer, 2002, p.14)

셋째, 프로젝트 수행을 위한 지침이 필요하다.

프로젝트 수행지침은 리스크 대응지침, 프로젝트 체크 리스트 등 프로젝트 관리를 위한 지침 또는 Apache 설정 Guide 라인, 웹 보안 가이드 라인 등 프로젝트 수행을 위한 기술지침을 말한다. 이러한 지침은 프로젝트에서 우리가 몸으로 때워가며 배워야 했던 소중한 교훈을 채워나감으로써 그 가치를 높여 나가야 한다.

프로젝트를 마쳤다는 안도감에 프로젝트에서 얻은 지식과 자료에 대한 정리가 소홀하기 마련이다. 이로 인해 정말 우리가 몸으로 때워 가며 배워야 했던 교훈이 소실되고 만다. 회사 내의 지침이 5년 전이나 10년 전이나 별 다른 차이가 없다면, 아마도 이 지침은 지침을 만든 사람이 인터넷 또는 외부 자료를 통해 발췌한 자료를 통해서 만든 것일 것이다. 이 지침마저도 항시 교육되고 공유되지 않는다면 아무 소용이 없다. 프로젝트 수행 지침은 프로젝트가 수행될 때 마다 새로이 갱신되어야 하며, 조직원들에게 공유되고 정기적으로 교육되어야 한다.

어떤 회사가 수년 전에 특정 프로젝트를 수행했으나, 그 프로젝트를 수행한 사람들이 모두 퇴사했다면, 과연 그 회사가 그 분야에 경험이 있는 회사라고 얘기할 수 있을까? 프로젝트를 통해 얻은 교훈에 의한 지침은 회사가 진정 그러한 프로젝트를 수행했음을 증명할 것이다.

넷째, 프로젝트팀의 특성과 생산성에 대한 측정이 필요하다.

프로젝트팀의 특성과 생산성에 대한 측정을 통해서 프로젝트 예측의 정확도를 높이도록 해야 한다. 프로젝트팀 개개인에 대한 측정이 아니다. 프로그램 개발엔 뒤처지더라도 고객과의 커뮤니케이션 능력이 출중하거나 팀원들에게 다양한 아이디어를 제공함으로써 프로젝트 성공의 밑거름을 제공하는 사람을 많이 보아왔다. 이 모든 사람들의 아우러져 하나의 팀을 형성하고 시너지를 발휘하게 된다. 바로 이 "팀"에 대한 평가가 필요하다. 프로젝트에 필요한 예산과 자원은 아래의 공식으로 단순화 할 수 있다. 

고객의 요구사항이 가변적일 수 밖에 없다면 프로젝트팀의 생산성 자료만이라도 보다 정확한 값을 제시할 수 있을 때, 우리가 보다 현실적인 계획을 마련할 수 있을 것이다.

<출처:http://blog.chosun.com/blog.log.view.screen?userId=xqon&logId=2960908>

장판교에서 장비가 조조의 100 대군을 막던 시대, 출중한 장군 몇 명이 전쟁의 승패를 좌지우지하던 시대는 아주 오래 전에 지났다. 소프트웨어 업계에서도 천재적인 개발자 몇 명이 창고에서 프로그램을 개발하여 히트시키던 얘기도 과거 10여 년 전까지의 일이다. 지금은 조직의 힘으로써 프로젝트를 수행해야 하는 시기이며, 조직적인 힘을 발휘하기 위해선 지속적인 노력과 함께 투자가 병행되어야 한다.

소프트웨어 개발자를 구합니다. – Homeless 우대, 회사를 집으로 생각하고, 주변에 친구나 가족이 없고, 컴퓨터 프로그램 개발 외에는 별다른 취미도 없는 분. 하루 18시간 이상 꼼짝 않고 일할 수 있는 체력의 소유자 우대.

제발 이런 상황이 계속 되지 않았으면 한다. 

인용 자료

Boehm, B., Horowitz, E., Westland, C., Madachy, R., Selby, R., & Clark, B. (1995). Cost Models for Future Software Life Cycle Processes: COCOMO 2.0. In J. Arthur, & S. Henry (Eds.), Annals of Software Engineering Special Volume on Software Process and Product Measurement. Amsterdam: J.C. Baltzer AG, Science Publishers.

Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.

DeMarco, T. (1982). Controlling Software Projects. New York: Yourdon Press.

DeMarco, T. (1997). The Deadline : A Novel About Project Management. 김덕규, 류미경 역(2005). 『죽음의 행진』. 서울: 인사이트.

DeMarco, T., & Lister, T. (1999). Peopleware. 박승범 역(2003). 『피플웨어』. 서울: 매일경제신문사.

DeMarco, T., & Lister, T. (2003). Waltzing With Bears: Managing Risk on Software Projects. 김준식 역(2004). 『소프트웨어 프로젝트에서의 리스크 관리』. 서울: 인사이트.

Jones, C. (1995). Software Productivity Research Programming Language Table (7th ed.). Burlington, Mass: Software Productivity Research.

Jones, C. (1998). Estimating Software Costs. New York: McGraw-Hill.

Martin, R. C. (2002). UML for Java Programmer. Prentice-Hall, Inc.

McConnel, S. (1996). Rapid Development: Taming Wild Software Schedules. 박재호, 이혜역 역(2003). 『RAPID DEVELOPMENT: 프로젝트 쾌속 개발 전략』. 서울: 한빛미디어.

McConnel, S. (2003). Software Project Survival Guide. 김덕규, 류미경, 이종철 역(2003). 『소프트웨어 프로젝트 생존전략』. 서울: 인사이트.

McConnel, S. (2004). Code Complete (2nd ed.). 서우석 역(2005). 서울: 정보문화사.

Symons, C. (1991). Software Sizing and Estimating: Mk II Fpa (Function Point Analysis). Wiley-Interscience.

Yourdon, E. (2004). Deatch March (2nd ed.). 김병호, 백승엽 역(2004). 『죽음의 행진』. 서울: 소동.

[원문주소] :  http://swarchi.tistory.com/6

프로젝트 생산성

생산성과 근무시간

소프트웨어 개발에 참여했던 사람들이 모여서 하는 얘기 중 하나가, 자기가 참여했던 프로젝트가 얼마나 힘들었었는지, 휴일 없이 얼마나 오랜 시간 쉼 없이 일했는지를 자랑스럽게 얘기하곤 하는 것이다.

그러나 이것은 그들이 참여했던 프로젝트가, 대부분의 불운한 프로젝트와 마찬가지로 프로젝트 크기에 대한 일정과 비용 추정이 잘못되었던지, 그들 고객의 마음이 갈대와 같았던지 혹은 그들의 역량이 보통 이하의 수준이었음을 증명할 뿐 그 이상 그 무엇도 아니다.

우리 모두가 알 듯 하루 18시간 이상 일하며 1년 혹은 2년 이상을 줄곧 같은 패턴으로 일할 수는 없다. 장시간의 긴 노동은 사람의 몸과 마음을 지치게 하며, 이는 집중력 저하와 잦은 실수로 이어져 프로젝트를 엉망으로 만들고 만다.

젊고 프로젝트에 대한 열정이 넘치는 프로젝트팀에게 2~3개월 동안의 소규모 프로젝트라면 잔업이 큰 문제가 되지 않을 수 있다. 그러나 잔업이 장기화 되고, 개발 초반의 열정이 식게 될 무렵엔, 잔업은 프로젝트에 오히려 독이 될 수 있다.

그림 17 생산성과 근무시간 (Yourdon, Death March, 2004, p. 179), 생산성과 근무시간에 대한 예시일 뿐 결코 연구결과에 의한 일반화된 그래프가 아니다.

그림 17에서 처럼 잔업에 의한 생산성은 60~80시간까지는 증가할 지 모르지만 그 이상은 한계상황에 도달하며 더 이상의 작업은 아무것도 안하니만 못한 상황이 될 수 있다.

사막지역에서 현대식 집을 지을 때는 40~60Kg짜리 벽돌을 쓰는 데, 모래 위에 집을 짓는 것이라 무거운 벽돌을 이용해 집을 짓는다. 벽돌이 너무 무거운지라 그것을 쌓는 데도 상당한 시간이 걸렸다. 
하루는 건축기간을 단축시키고자 하루에 벽돌을 쌓는 수만큼 인센티브를 주기로 하였다. 인센티브 소식에 하루에 체 2단을 쌓기도 어렵던 일이 4단, 5단씩 쌓였다.
다음 날 아침, 건설현장엔 허리 부상을 이유로 아무도 출근치 못 했다. 부상이 모두 회복되기까지 2주간의 시간이 필요했다. 
                                                                                                                         - 건축과 수업 중에서

잔업이 일시적으로 생산성을 향상 시키는 요인이 될 수는 있으나, 이러한 잔업이 장기화되면 프로젝트팀의 사기를 극도로 낮추는 요인이 될 수 있다.

전쟁은 군인의 사기로 하는 것이지, 무기의 양으로 하는 게 아니다. 만약 무기의 양으로 전쟁을 한다면, 전쟁초기에 국경에 모여 전차 개수와 핵 폭탄의 개수 등을 헤아려 인명 피해 없이 승부를 가늠할 수 있을 것이다.

마찬가지로 소프트웨어 개발 프로젝트 또한 상당부분을 프로젝트팀의 사기에 의존하게 되는 데, Yourdon은 프로젝트팀의 사기에 가장 큰 영향을 끼치는 요인으로 프로젝트 관리자의 통제하에 있는 잔업과 보상을 꼽았다. (Yourdon, 죽음의 행진, 2004)

프로젝트의 수행을 위해서 잔업이 필수불가결 하다면, 잔업에 따른 보상 또한 필수불가결한 요소이다.

"프로젝트 분석, 설계 때부터 하루 12~13시간씩 일해왔어요. 6개월 동안의 분석, 설계가 끝나고막상 개발을 시작했을 땐 몸과 마음이 많이 지쳤어요. 그리고 또다시 8개월이 흘렀어요. 지난 수개월 동안은 토요일, 일요일도 없었구요. 이젠 이 프로젝트를 어서 빨리 끝내야겠단 마음보단어떻게 하면 이 프로젝트를 빠져 나갈까를 궁리해요.
"이 프로젝트가 1주일, 1개월이 빨리 끝난다고 해서 제게 무슨 이득이 있나요?" 
                                                            - 프로젝트 오픈이 2개월 지연된 날 새벽, 개발팀원과의 대화 중에서 

개인별 업무 능력

개인별 생산성을 조사했던 Tom DeMarco에 따르면, 개인의 능력차가 10배에 다 달았으며, 중간 이상의 업무능력을 가진 사람과의 차이도 2.5배의 차이를 보였다. (그림 18)

특이할 만한 사실중의 하나는 프로그래밍 언어, 경력등과 생산성이 관련성이 없다는 사실이었으며, 더욱 놀라운 사실 중의 하나는, 같은 회사 사람들이 갖는 편차가 21%밖에 되지 않는다는 사실이었다.

이는 업무 능력이 뛰어난 사람들이 모여 있는 회사가 있고, 그렇지 않는 회사가 있을 수 있음을 나타내며 이들 회사간의 능력차도 10배에 이를 수 있음을 보여준다.

회사의 업무환경과 기업문화의 영향으로 인해 뛰어난 사람들을 유치하거나 혹은 뛰어난 사람들을 이직하게 함으로써 회사간의 생산성의 차이를 유발한다.

그림 18 개인별 생산성 편차 (DeMarco & Lister, Peopleware, 1999, p. 79)

프로그래밍 언어와 경력이 생산성과 무관했던 사실은 이 조사가 수행되었던 시기가 80년대 중반이었음에 기인했던 것으로 추정된다. 당시는 3GL / 4GL 언어 등의 구분이 없었던 시기였으며 프로그램 언어의 성숙도 또한 현재보단 낮았다.

4GL 언어는 3GL 언어보다 구현노력을 75%까지 줄일 수 있다는 연구결과가 있으며 (Jones, Software Productivity Research Programming Language Table, 1995) 이는 3GL 언어에서 프로그래머가 직접 구현해야 했던 많은 부분을 4GL 언어 자체가 제공하고, 보다 직관적인 비쥬얼 프로그래밍이 가능함으로써 가능하게 되었다. DeMarco에 의해 개인별 생산성 편차에 대한 연구가 이뤄졌던 당시에도 어셈블리어로 개발하는 경우는 포트란이나, 코볼 등의 언어보다 생산성이 낮았다.

4GL언어가 3GL 언어보다 많은 부분을 제공하였지만, 이를 제대로 사용하기 위해서는 과거보다 더 많은 학습이 필요해 졌으며, 고객의 눈높이 또한 높아져 이 눈높이를 맞추기 위해서는 더욱 많은 노력이 필요하게 되었다. 과거 프로그램 언어를 배우는 과정이 문법만을 배우면 되던 시기였다면, 현재는 그와 관련된 수많은 라이브러리와 프로젝트의 프레임워크를 익혀야 되는 시기가 되었으며, 프로그램의 복잡도 또한 몇 배나 증가되어, 과거보다 높은 숙련도를 요구하는 시기가 되었다.

단적인 예로 예전엔 개발 툴을 1.2MB 짜리 디스켓 몇 장으로 설치하던 시기였으나 현재에는 4GB 짜리 DVD로 설치해야 하는 시기가 된 것이다.

프로젝트 도구와 생산성

새로운 도구를 적용하게 되면 마치 모든 것이 다 해결될 것인 양 벤더에서 광고를 하지만 이제 우리는 그런 광고에 너무도 익숙해져서 그러한 얘기에 현혹된 정도로 순진하진 않다.

물론 새로운 도구가 프로젝트의 생산성에 도움을 준다. 하지만 그림 18에서 처럼 새로운 도구를 프로젝트에 도입하게 되면 학습곡선으로 인해 일시적으로 프로젝트의 생산성은 낮춰지며, 만약 그 프로젝트가 이러한 손실을 만회할 정도로 크지 않다면 새로운 도구의 도입은 프로젝트 전체를 지연의 늪으로 빠뜨릴 우려가 있다.

그림 19 학습 곡선이 생산성에 미치는 영향 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 356)

따라서 프로젝트의 수행 시 새로운 도구의 도입은 신중해야 하며 되도록 검증된 것으로 그리고 프로젝트 팀원이 익숙한 도구로써 시작하는 것이 바람직하다.

개발자의 동기와 일정압력

프로젝트가 지연되면 고객이나 관리자가 제일 먼저 보이는 반응은 프로젝트 팀에 일정에 대한 압력을 가하고 초과근무를 종용하는 것이다.

프로젝트 팀에 가해진 일정 압력이 평균을 상회하는 경우, 프로젝트 팀의 사기를 극도로 저하시키는 데 이는 생산성에 지대한 영향을 줌으로써 전체 진척율을 떨어뜨리는 효과를 낳는다. 또한 타의에 의해 종용된 초과 근무는 초과 근무에서 오는 생산성의 증가보다 동기저하로 이뤄지는 생산성의 저하가 크다(그림 20)

그림 20 일정압력/근무시간, 전체결과, 개발자 동기 사이의 관계 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 608)

주당 60시간 이상의 근무가 장시간 지속되는 경우, 사람들은 동호회 일을 보거나 개인 블로그를 관리하는 등 개인적인 일을 근무시간에 하게 된다. 이로 인해 사무실에 남아있는 시간은 길지만 실제로 일하는 시간은 이보다 훨씬 적게 되며, 생산성은 저하되고 육체적 피로만 가중되는 상황이 벌어진다.

결국 개발자의 동기에 의한 자발적 초과근무만이 생산성 향상을 이끌어 낼 수 있다.

관리팀의 辯 

사람들이 초과 근무를 하는 이유는 과제를 주어진 시간 안에 끝마치기 위해서라기보다는, 일을정해진 기간까지 끝마치지 못했을 때 비난 받게 될 것을 우려해 자신을 보호하기 위함이다 – 제리 와인버그 

알고 있었다.
프로젝트가 망가진 이 마당에 개발자를 추가로 투입한다는 것이 그다지 소용이 없으며, 개발자들이 밤늦게까지 앉아 있는다고 해서 그다지 진척이 없다는 것을. 
프로젝트가 망가졌음이 공공연한 사실로써 받아들여졌을 무렵부터 개발자들이 일에 전념을 하지 않고, 인터넷을 뒤지거나, 전엔 잘 가지도 않던 은행을 자주 가고 있었다. 
시력을 잃으면 다른 감각이 발달한다고, 개발 쪽 일을 하다가 관리라는 것을 하게 되면 평소엔관심도 없었던 주변 사람들의 전화 소리가 더 잘 들려오게 되고, 개발자 모니터에 떠있는 화면들 또한 더 눈에 잘 들어온다. 
현재에서 최선의 방법은 일단 모두가 1주일 정도 쉬고, 개발량에 맞춰서 개발일정을 한참 뒤로늦추거나, 개발일정에 맞춰서 개발량을 줄이는 방법밖에 없음 또한 알고 있었다. 
프로젝트가 망가진 뒤부터, 평소엔 관심도 없던 회사 분들이 이걸 조사해서 보내달라, 프로젝트복구 방안을 만들어서 달라, 온갖 리포트를 만들어 줄 것을 요청해 왔다. 그리고 대책 회의는 왜그리도 많이 잡히는 지. 정신이 없었다.
회의 내용은 한결 같았다. 도와줄 테니 방안을 제시해라. 방안? 이 방안이란 것에도 항상 수식어구가 따랐다. 비용 안 들이고, 프로젝트의 일정과 품질을 준수하는 방안. 그런 게 있었다면 우리가 벌써 했을 것이다. 회의에 참석한 이 많은 사람들이 도와주려고 온 건지, 일을 방해하려고 온건지 구분조차 안 되는 장시간의 마라톤 회의. 답은 뻔한 데도 누구 하나 제대로 말을 못하는 그런 회의가 계속 되었다. 
프로젝트가 망가질 수 있음은 이미 분석, 설계를 끝마치고 예견했던 사실이었다. 그러나 이 사실을 회사 관리팀에 보고했을 때, 돌아오는 답변이라곤 프로젝트 기간이 아직 남았지 않느냐? 그 동안 생산성을 향상할 수 있는 방안을 마련해서 적용하면 되지 않겠냐는 답변뿐이었다. 
생산성 향상? 마치 전쟁터에 나가 적들과 싸우면서, 총의 성능을 개량해 보란 얘기랑 똑같았다. 
결국 개발에 대한 중간보고 시점이 되었을 때, 프로젝트 복구방안이라고 낼 수 있는 것이라는게, 고작 초과근무와 추가 인력투입이었다. 
어렵사리 승인을 받아 추가된 인력이 왔을 때, 개발자들이 난감해 함을 알고 있었다. 일은 잘라줘야 하는 데 어디서 어떻게 잘라야 할지? 또 업무를 어떻게 가르쳐야 할 지? 대략 난감. 그러나우린 "우리가 이 어려운 프로젝트를 제 날짜에 끝내기 위해 이렇게 투자하고 있습니다." 라고 고객에게 말할 것이 필요했다. 
고객과의 정기 회의가 다가올 때면 가슴이 두근거리고, 오늘은 또 어떤 얘기를 하려나? 걱정이되었다. 이건 되었느니, 저게 안 되었느니. 정말 그 사람 눈에 우리 시스템은 왜 그리도 맘에 안드는지. 일정은 어떻게 되냐고 다그치고. 그러다가 웃으며 툭 던지는 말. 
"추가 사업 더 안 하실 거예요?"
 개발자들에게 프로젝트에 대한 동기를 부여하고 싶었다. 그러나, 갑을 제외한 을, 병, 정, 무까지 있는 프로젝트 팀원에게 동기를 부여할 방안이란 게 마땅치 않았다. 휴가? 오픈 일자가 한참지난 이 시점에? 하루에 물고 있는 지체 보상금이 계속 누적되어 가고 있는 이 시점에 휴가를 간다고? 얘기를 꺼냈다간 사장이 당장 목을 칠 눈빛인데? 결국 개발자들에게 그간의 인간적인 정으로 호소하는 것 외에는 딱히 해 볼 도리가 없었다.

이미 사기는 바닥을 쳤고 프로젝트는 망가질 대로 망가지고, 하루하루가 살 얼음 판을 걷고 있었던 그 때. 
우리는 과연 무엇을 할 수 있었을까?
개발자들에게 술을 좀 더 먹였어야 했나? ^^;

[원문주소] : http://swarchi.tistory.com/5

프로세스에 대한 오해 

소프트웨어 프로세스는 소프트웨어 개발을 위한 생산적인 절차이다.

이 소프트웨어 프로세스에는 요구사항의 문서화, 요구사항에 대한 변경추적, 버전관리 툴을 통한 소스코드 관리, 결함 추적 등이 있을 수 있다.

흔히 프로세스에 대한 오해, 즉 프로세스가 실제 개발을 위한 생산적인 업무를 저해한다는 생각을 갖기 쉬우나, 프로젝트가 진행될수록 프로세스의 중요성을 사건이 터질 때 마다 한번씩은 느끼게 된다.

예컨대, 소스코드의 정기적인 백업, 버전관리 툴을 통한 소스코드 관리 등의 프로세스 부재로 인해, 열심히 작업했던 소스코드를 누군가 엎어 쓰면서 재작업을 해야만 했던 가슴 아픈 추억은 누구에게나 있을 것이다.

그림 15에서 처럼 프로젝트 초기, 프로세스를 제대로 계획하지 못하면 프로젝트가 끝날 무렵이면 갖가지 문제로 인해 허비하는 시간은 늘어나고, 이를 방지하기 위한 프로세스도 늘게 된다.

그림 15 프로세스에 무신경한 프로젝트의 실 사례 (McConnel, Software Project Survival Guide , 2003, p. 51)

따라서 프로젝트 초기, 프로세스에 대한 계획과 이에 대한 프로젝트 팀원들의 충분한 교육 및 공감대를 형성하도록 노력해야 한다.

그림 16 프로세스에 관심을 기울인 프로젝트의 실 사례 (McConnel, Software Project Survival Guide , 2003, p. 53)

앞서 소프트웨어 프로세스를 "생산적인" 절차라고 했음에 유념해야 한다. 결코 불필요한 산출물을 많이 만들거나, 복잡한 절차를 따르는 것이 생산적인 것은 아니다. 산출물은 프로젝트팀과 고객과의 의사소통 수단을 목적으로 하여야 하지 프로젝트팀의 최종 목적물이 되어선 안 된다. 프로세스는 프로젝트 팀이 쉽게 이해하고 실천할 수 있는 수준에서 정립이 되어야 한다. 복잡하게 여러 단계를 거쳐야 하는 프로세스는 프로젝트 팀의 큰 부담이 되며 신속한 진행을 가로막는 요인이 되기 쉽다.

고객과 산출물에 대해서 얘기를 하는 중에 특정 산출물이 꼭 필요하다고 얘기를 했다. 이러저러한 이유를 들어 문서를 만드는 것이 이번 프로젝트에는 맞지 않는다고 얘기를 하니,
“전문가가 와서 보면 시스템에 대해서 쉽게 이해할 수 있는 좋은 문서라 하던데요.”
다 뻥이다.
아마 무슨 교육에선가 이 문서의 중요성에 대해서 들었나 보다. 프로젝트팀에서 이해치 못하고 운영자가 이해치 못하는 문서는 쓸 때가 아무 곳에도 없다. 프로젝트팀이 그 시스템의 최고 전문가다. 보여주기 위한 문서가 아니라 정말 필요하고 사용하기 위한 문서를 만들어야 한다.

Agile Software 개발을 주창했던 Martin Fowler, Kent Beck, Ron Jeffries1 등이 그들의 저서와 애자일 소프트웨어 개발 선언2을 통해 고객의 책장을 장식하는 두꺼운 문서보다 제대로 돌아가는 프로그램의 중요성에 대해서 역설했다.

이러한 그들의 주장이 정작 필수적인 문서마저도 쓰기 싫어하는 프로젝트팀의 이론적 기반이 되기도 하는 데, 그러나 소프트웨어 개발에 있어, 요구사항의 문서화 등은 반드시 이뤄져야 하며, 이에 대해Ron Jeffries가 Extreme Programming Uninstalled3 라는 글에서 다음과 같이 밝혔다.

사람들이 글쓰기에 어려움을 느낀다는 것은 사실이며, 쓰여진 말은 오해를 일으키기도 한다. 그러나 적어도 이것은 변화하지는 않으며, 사람들에게 이해를 위한 많은 시간을 준다. 우리가 이해할 수 있는 문서를 가지고 있지 않으면, 우리는 동작하는 Software를 새로 만들 수 없을 지 모른다

프로젝트의 문서작업은 필수불가결한 것이며, 프로젝트팀과 고객과의 의사소통을 위한 수단으로써 합리적인 방법으로 작성되어야 한다.

특히 요구사항을 꼼꼼히 문서화 하도록 하자. 이 문서가 프로젝트의 양을 줄여주지는 못 할지라도, 우리 고객의 얼마나 변덕스러웠으며, 그로 인해 프로젝트 팀이 얼마나 힘들어 하고 있는지를 증명할 것이다.

[원문주소] : http://swarchi.tistory.com/4#footnote_link_4_1 

프로젝트의 크기가 미치는 영향

프로젝트가 커질수록 필요한 비용 – Man-Month 등 – 에 대해 영향이 있을 뿐 아니라 오류, 생산성, 개발활동 등에도 영향을 미치게 된다.

오류에 미치는 영향

프로젝트의 크기가 증가할수록 개발이 아닌 요구사항과 설계상의 오류가 증가하게 된다.

그림 10 프로젝트의 크기와 오류가 발생하는 단계 (McConnel, Code Complete, 2004, p. 895)

프로젝트의 크기는 오류가 발생하는 위치에 영향을 줄 뿐 아니라 단위 코드당 발생하는 오류의 개수에도 영향을 준다. 즉, 프로그램의 사이즈가 2배가 되면 프로그램의 오류 개수는 2배 이상이 된다.

그림 11 프로젝트의 크기와 단위 코드당 오류의 개수 (McConnel, Code Complete, 2004, p. 896)

생산성에 미치는 영향

작은 프로젝트(2,000줄 이하)에서는 개발자의 능력이 생산성에 가장 큰 영향을 미치지만 프로젝트의 크기가 증가할수록 팀의 크기와 조직이 생산성에 더 많은 영향을 미친다. (Jones, Estimating Software Costs, 1998)

생산성은 프로젝트의 성격, 개발자의 능력 등 수많은 요인에 영향을 받기 때문에 통계적 수치를 일반화 할 수 없다. 그러나 그림 12이 보여주는 경향, 즉 작은 프로젝트가 큰 프로젝트에 비해서 생산성이 높을 수 있으며, 작은 프로젝트에서의 생산성을 기준으로, 큰 프로젝트를 단순히 산정-예컨대, 프로젝트의 크기가 2배가 되면 프로그래머도 2배로 한다 – 할 수 없음을 이해해야 한다.

그림 12 프로젝트의 크기와 생산성 (McConnel, Code Complete, 2004, p. 897)

개발활동에 미치는 영향

프로젝트의 크기가 변화함에 따라 프로젝트 내에서의 각 단계별 활동 비율도 변화하게 된다.

소규모 프로젝트에서는 가장 크던 개발과 디버깅, 단위 테스트, 상세 설계의 비중이 규모가 커질수록 작아지고 아키텍처와 통합, 시스템 테스트의 비중이 확대되어 간다.

그림 13 프로젝트 크기와 개발활동 비율 (McConnel, Code Complete, 2004, p. 898)

그 외 미치는 영향

프로젝트의 크기가 증가함에 따라 선형적으로 증가하리라고 예상했던 많은 작업들이 우리의 생각과는 다르게 그림 14와 같이 기하급수적으로 증가하게 된다. 다음은 기하급수적으로 증가하는 작업의 목록의 예시이다.

의사소통 / 계획 수립 / 관리 / 요구사항 개발 / 시스템 기능 설계 / 인터페이스 설계와 명세 / 아키텍처 / 통합 / 결함 제거 / 시스템 테스트 / 문서 제작 (McConnel, Code Complete, 2004, p. 899)

그림 14 프로젝트 크기와 노력 (McConnel, Code Complete, 2004, p. 899)

[원문주소] : http://swarchi.tistory.com/3

Mythical Man-Month

프로젝트와 개발자 관계에 관해서 흔히 하기 쉬운 착각 중에 하나가 개발자를 공장의 생산 기계로 생각한다는 것이다. 따라서 생산량이 부족하면 증산을 위해서 생산 기계를 하나 더 들여놓으면 되는 것으로 단순하게 생각한다.

그러나 프로그램의 개발은 공장에서 제품을 생산하는 단계가 아닌 제품을 개발하는 단계와 같으며, 앞서 프로젝트 비용과 일정에서 설명한 바와 같이, 결코 그림6과 같은 등식은 성립될 수 없음을 유념해야 한다.

그림 6 프로젝트 일정과 투입인력 관계 (DeMarco, The Deadline : A Novel About Project Management, 1997, p. 127)

프로젝트팀의 인원이 커질수록 의사소통을 위한 경로가 기하급수적으로 커질 수 밖에 없는 데 의사 소통 경로가 증가할수록 의사 소통에 따른 문제가 증가하고 이를 효율적으로 관리하기 위한 인원과 프로세스가 추가적으로 필요하다.

그림 7 의사소통 경로의 수는 팀원의 수에 제곱에 비례한다 (McConnel, Code Complete, 2004, p. 893)

그림 6의 경우 의사소통 경로가 20명이 투입된 경우 190(20*(20-1)/2)가지이며 10명의 경우 45(10*(10-1)/2)가지 이다.

결국 프로젝트의 생산성은 인원에 비례하지 않는 결과를 낳는다.

그림 8 프로젝트 생산성과 팀원 수와의 관계 (DeMarco, The Deadline : A Novel About Project Management, 1997, p. 130)

프로젝트가 망가졌을 때 이를 복구하기 위해 인력을 추가하는 것은 불에 기름을 붓는 것과 같다 (Brooks, 1975). 실제로 프로젝트에 새 인력이 추가되면 추가된 인력이 팀의 생산성에 도움을 주기까지는 일정시간이 필요하며 그 시간까지는 프로젝트에 대한 교육 등의 이유로 팀 생산성을 낮추는 요인으로 작용한다.

그림 9 프로젝트 생산성과 신규 인력의 추가 (DeMarco, The Deadline : A Novel About Project Management, 1997, p. 130)

프로젝트 개발기간의 반이 흘렀을 무렵, 개발자 2명이 추가 투입되었다. 이미 많은 시간이 흘러서 개발자에게 업무를 주자니 업무분석 단계의 history를 이해하질 못했고, 개발을 위해서 처음에 만들었던 Library에 대한 이해가 부족해서 업무를 나눠서 주질 못했다. 결국 단순한 업무 – 화면을 고친다던 지, SQL을 만든다던 지 – 밖에 줄 수 없었고 개발자들에게 작업을 주는 것 조차부담스러울 때가 있었다.

[원문주소]  : http://swarchi.tistory.com/2

들어가며

숲 속에서 숲을 바라보기가 어려운 것처럼, 우리가 항시 수행하고 있는 소프트웨어 개발 프로젝트이지만 프로젝트의 실체에 대한 바라보기란 쉽지 않다. 그러나 우리는 프로젝트에 대한 아무런 정보 없이도, 그 프로젝트가 제 날짜에 끝나지 못한다고 자신 있게 예상할 수 있다. 프로젝트가 제 날짜에 끝나지 않고, 프로젝트팀이 지속되는 야근에, 피곤에 젖어 사는 것은 너무나도 흔해서 굳이 천지신명의 도움을 받지 않아도 쉽사리 맞출 수 있는 것이다.

소프트웨어 개발 프로젝트가 이렇듯 힘든 작업이 된 데에는, 기존 제조업의 생산개념으로 소프트웨어 개발을 바라보는 시각 – 소프트웨어는 개발이지 생산이 아니다 -, 건축공사와 같이 프로젝트의 진척사항을 즉각적으로 바라볼 수 없는 비가시성 그리고 소프트웨어 산업의 짧은 역사로 인해 소프트웨어 개발 프로젝트의 실체를 제대로 바라보지 못하는 고객과 프로젝트팀의 인식 부족 – 메디컬 드라마나 소설을 통해 의사의 애환과 어려움에 대해서 우리는 더 많이 알지도 모른다 -등 많은 요인이 복합적으로 작용한다.

소프트웨어 개발 프로젝트의 실체에 대한 보다 정확한, 아니 보다 현실에 가까운 이해는 소프트웨어 개발 프로젝트의 성공을 위한 초석이 될 수 있다.

이 글은 몇몇 통계 자료를 통해 소프트웨어 개발 프로젝트에 대해 미처 생각지 못했던 또 다른 관점을 제공하고자 한다. 

프로젝트 예측

개발 프로젝트의 진행과정 중 가장 난이하고 어려운 일은 프로젝트 규모 즉 비용에 대한 예측이다. 아무리 분석, 설계를 잘하고 개발을 잘한다 하더라도, 프로젝트 초기에 프로젝트의 대한 예측이 잘못되어 있다면 프로젝트가 정상적으로 수행될 수 없다.

프로젝트 비용 예측

그림 1은 우리가 주먹구구식으로 수행하고 있는 프로젝트 규모 산정이 얼마나 위험한 것인지를 보여주고 있다. 프로젝트의 제품설계가 끝난 시점에서도 오차가 무려 -20% ~ +25% 이다.

흔히 프로젝트 규모 예측은 전문가집단의 감에 따라 이루어지는 데, 프로젝트 고객의 성향, 요구사항의 끊임없는 변경, 프로젝트 개발팀의 능력, 개발 환경 등 너무나 많은 것이 프로젝트에 영향을 주기 때문에, 프로젝트의 규모를 정확히 산정하는 것은 천지신명의 도움을 받아야만 가능한 예술의 경지가 되어 있다.

그림 1 예측 값 수렴곡선 (Boehm, et al. Cost Models for Future Software Life Cycle Processes: COCOMO 2.0., 1995, p. 7)

이러한 오차를 조금이라도 줄이고자 한다면, 소프트웨어를 보다 구체화하고, 개발팀의 수행능력에 대한 통계적 데이터를 마련하는 등 오차를 줄이기 위한 지속적인 노력이 필요하다.

칠흑 같은 밤, 완전군장을 하고서 야간 행군을 나서게 되었다. 무반동 총이며, 포판이며, 중대원들이 그 무거운 것을 하나씩 들고서 계곡을 지나 산 정상에 도달했을 무렵이 새벽4시. 늦가을이라 싸늘한 새벽공기에도 땀을 뻘뻘 흘리며 겨우 산 정상에 도달했음에 안도하고 있을 무렵, 저 앞에서 들리는 중대장의 목소리에 우리 모두는 앞으로 쓰러져야했다. 
"이 산이 아니갑다~"

프로젝트 개발에서 이런 일은 너무도 흔해서 놀랍거나 신기하지도 않다. 

정말 아주 특이하게도, 다 지어진 건물의 창문 위치를 변경하는 것에 추가적인 비용이 드는 것은 누구나 이해하지만, 다 만들어진 프로그램을 변경하는 것에 비용이든다는 것을 이해하는 사람은 극히 소수다.

프로젝트 일정 예측

프로젝트의 규모를 제대로 예측하기 어려운 만큼 프로젝트의 수행 일정 또한 제대로 맞추기가 어렵다. 따라서 일정 또한 확률론에 입각한 추정밖에 있을 수 없는 데 결국

"몇일쯤이면 프로젝트가 끝날 확률이 50%정도입니다."

라는 식만이 현실적으로 가능한 것이다.

그림 2 손익분기 일정수립 (DeMarco, Controlling Software Projects, 1982)1

그림 2는 Tom DeMarco가 제안했던 일정수립에 관한 그래프이다. 그래프의 면적이 프로젝트를 끝낼 확률을 나타내는 데, 불확실성 구간의 크기는 N지점(극소확률일자: 프로젝트를 완료할 확률이 0이 아닌 첫 번째 날짜)에 비해 통산 150~200%이다. 따라서 N이 25개월인 프로젝트의 경우 불확실성 구간의 끝은 75개월에 이른다.

Tom DeMarco의 경우 그림 2에서와 같이 일찍 마칠 확률과 늦게 마칠 확률을 50/50으로 잡을 것을 제안했다.

관리자라면 당연히 그림 3과 같이 이 불화실성 구간을 줄이고자 할 것이다. 그러나 이것은 개발 과정에 얼마나 많은 Noise2가 포함되는가에 따라 결정된다.

그림 3 불확실성 구간이 작은 예 (DeMarco & Lister, Waltzing With Bears: Managing Risk on Software Projects, 2003, p. 92)

일정을 어떻게 잡을까에 대한 연구가 진행되었는데 간략하게는 아래의 공식을 사용할 수 있다.

일정(개월) =  3.0 * (Man-Month)^(1/3)

프로젝트에 65 Man-Month가 든다고 예측하였다면 12개월(3*65^(1/3))이라는 최적 일정을 얻을 수 있다. (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 189)

프로젝트 규모에 대한 이상적인 자원 투입

프로젝트 규모의 산정이 어렵고 프로젝트의 진행에 따라 변경될 수 있다는 것을 인정한다면 당연히 프로젝트에 투입되는 자원 또한 프로젝트의 규모가 변경되는 것에 맞춰서 변경되어야 한다. 그것이 합리적이지 않나? 그러나 Turnkey방식이라는 미명하에 개발사가 모든 것을 책임지는 분위기에서는 초기 할당되는 인력과 자원은 고정시켜 두고서 요구사항만 한 없이 늘어나는 게 현실이다.

그림 4 소프트웨어 진행에 따른 자원변화 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 177)

프로젝트 비용과 일정

그림 5 비용과 일정과의 관계 (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 198)

프로젝트 수행에 있어서 더 이상 단축하지 못하는 최단일정이란 것이 존재한다.

예컨대, 한 명이 일주일 동안 개발해야 하는 프로그램 1,000줄을 5명이 하루에 개발할 수 있을까? 40명이 1시간 내로 개발할 수 있을까? 산모 10명을 데려다 놓는다고 해서 1달 안에 아기가 태어날 수는 없다

또한, 일정을 통상적인 일정보다 짧게 잡으면 비용은 급속하게 증가한다. 일정을 줄이고자 하면 단순히 개발자 수나 초과 근무량을 늘여서 일정을 줄일 수 있다. 그러나 그림 5에서 보듯이 개발기간의 단축에는 엄청난 부하가 든다. 의사소통 부하와 관리 부하가 커져서 상대적으로 비효율적인 인력충원 패턴을 써야 하기 때문이다. (McConnel, Rapid Development: Taming Wild Software Schedules, 1996, p. 197)

일정압축에 따른 비용에 대해서는 일반적으로 찰스 사이몬의 연구결과 (Symons, 1991)을 사용할 수 있다.

일정 압축률 = 원하는 일정 / 초기 일정

압축한 일정 노력 = 초기 노력 / 일정 압축률

프로젝트 초기 일정을 12개월로 예측했고 10개월 안에 완료하고 싶다면 압축률은 0.83(10/12)가 된다. 초기 노력 예측값이 70 Man-Month였다면 70/0.83을 하여 94Man-Month가 나오게 된다. 17%의 일정을 줄이고자 한다면 34%의 인력을 충원해야 한다. 물론, 이것은 개발환경이 동일하다는 가정하에서의 일이다.

대부분의 연구 결과에 따르면 아무리 인력을 투입한다고 해도 25%이상의 압축률은 불가능한 것으로 결론짓고 있다

[원문주소] : http://swarchi.tistory.com/1