Talk about Software with hani

팀장의 고백  목차

• 게으른 PL이 프로젝트 일정을 지연시킨다.
• 개발명세서? 그 귀찮은 짓을 왜 하지?
• 개발계획은 팀장의 것? 팀원의 것? (오늘의 Post)
• 팀장! 당신은 진정한 Nego를 할 수 있는가?
• 형상 관리, 그까이거 그냥 폴더에 보관하면 되지
• UnitTest! 미완의 시도
• 인수테스트, 북치고 장구치고
• Trac을 통한 품질 관리
• 진정한 프로젝트의 가치는 어디에서 오는 것일까?

프로젝트 일정과 나비효과

프로젝트의 일정을 100% 지키는 가장 좋은 방법은 무엇일까? 답은 간단하다. 프로젝트를 하지 않는 것이다. ^^ 프로젝트를 하지 않는다면 어떤 일이 벌어질까? 개발자나 팀장인 경우 월급을 못 받기 때문에 (모아 놓은 돈이 없다면) 당장 카드 결재에 빨간 불이 들어올 것이다. 특히 가장으로써 가족을 책임지고 있다면 문제가 더 심각하다. 몇 달 프로젝트가 없어 직장에서 짤리는 날이면 가족 해체의 위기까지 몰릴 수 도 있다. 아이들은 가출하고 부인은 새로운 삶을 찾아 떠나고, 좌절한 남편은 Homeless로 전락 하고… 단지 프로젝트 일정을 지키기 위해서 프로젝트를 하지 않았을 뿐인데 인생이 망한다.(조금은 오버다~)

그렇다면 회사 입장에서 프로젝트를 하지 않는다면 어떤 문제가 있을까? 톰 디마르코, 티모시 리스너의 리스크 관리(Waltzing with Bears, 인사이트)에서는 프로젝트의 Risk와 사업의 기회를 다음의 예로 설명하고 있다.

메릴 린치(Merrill Lynch)의 초기 온라인 트레이딩 시장 지연이 그 대표적인 사례다. 메릴 린치의 입장에서 소위 온라인 트레이딩이라는 것은 어렵고 먼 이야기처럼 느껴졌기 때문에 그들은 이를 무시하기로 결정했다. 그들은 증권 중개 풀 서비스(높은 중개 수수료와 중개인들이 고객들을 영속적으로 유지하는 형태)의 시대가 다시 돌아오기를 희망했으며 … 오늘날, 증권 중개 풀 서비스는 과거 주유소의 풀 서비스와 같이 전락했다. 그리고 지금은 메릴 린치도 고객들에게 저렴한 수수료의 온라인 트레이딩 서비스를 제공한다. 그러나 이렇게 되기까지 10년 가까이 낭비했다. 메릴 린치는 가장 늦게 변화를 받아들인 증권회사였다. … 이트레이드를 비롯한 몇몇 회사는 신생 회사였으며, 이러한 환경의 변화를 기회로 여기고 이를 이용하려는 목적으로 설립되었다. 그러므로 설사 온라인 트레이딩이 단지 한때의 유행으로 지나가 버리고, 이트레이드가 도산했다고 해도 이미 리스크를 감안해서 투자된 자본 외에는 더 손해볼 게 없을 것이다. 반면 피델리티나 슈왑의 상황을 달랐다. 그들은 업계에서 이미 자리를 잡은 회사들이었으로, 상대적으로 잃을 것도 많았다. … 그럼에도 피델리티와 슈왑은 기꺼이 리스크를 감수하는 선택을 했다.

프로젝트는 본질적으로 위험한 것이다. 그럼에도 불구하도 프로젝트는 해야 한다. 개발자는 먹고 살기 위해서, 회사는 새로운 비즈니스의 기회를 잡기 위해서… (그러나 프로젝트 자체는 위험한 것이기 때문에 위험관리를 해야한다. 위험 관리는 이 post의 주제가 아니기 때문에 다음 기회에 다루도록 하겠다.) 이런 위험에는 어떤 종류가 있을까? 위험의 종류는 크게 시간의 위험과 비용의 위험으로 나눌 수 있다. 비용의 위험이란 쉽게 말해 프로젝트의 결과가 쓰레기가 될 때 투입한 비용이 공중에 날아갈 위험이다. 이에 반해 시간의 위험은 프로젝트가 제 때에 끝나지 못할 위험이다. 프로젝트가 제 때에 끝나지 못한다는 것은 사업 기회를 선점할 가능성이 낮아지고, 결국에는 프로젝트를 먼저 완료한 다른 기업에게 선수를 뺏길 수 있다는 뜻이다. 비용 위험은 특히 고객이 안고 가는 것이라면, 시간 위험은 프로젝트 수행 주체가 가져가야할  것이다.

정해진 프로젝트 일정, 바꿀 수 없나?

그런데 프로젝트 기간은 종종 사업적인 이유로 D-day가 정해진다.따라서 프로젝트 수행 주체가 기간을 조정할 수 있는 여지가 매우 적다.  이것은 프로젝트 수행 주체로써 매우 우울한 사실이다. 현실적으로 보아도 프로젝트 계약 단계에 프로젝트를 수행할 프로젝트 관리자라던지, 개발자의 의견이 많이 반영되지 못하고 있다. 정확한 프로젝트의 일정을 산정하기 위해서 완결되어야 하는 사전 작업은 설계 작업이다. 설계 작업은 소프트웨어 개발을 위해서 기본적인 자료를 제공해 주기 때문에 하기도 하지만, 설계 작업을 해야지만 개발 작업을 할당할 수 있다. 즉, 설계는 소프트웨어 개발을 할 때 일의 분량을 산출하고 산출된 일을 나누기 위한 사전 작업인 셈이다. 그런데 대부분의 프로젝트는 영업에서 따오거나 기획에서 기획을 끝낸 후 개발팀에게 몇월 몇일까지 프로젝트를 완료해달라고 부탁한다.(물론 이렇지 않은 조직도 있다… 그 수가 얼마나 많은지는 모르지만) 그런데 이것은 좋은 방식이 아니다. 정확한 프로젝트 기간을 산정하기 위해서는 프로젝트 구간을 크게 두구간으로 나누는 것이 바람직하다. 이와 관련된 이야기는 아래의 post를 참고하길 바란다.

아버지는 말하셨지, “공짜 점심은 없단다!”

이제야 본론이다. 오늘 이야기의 출발점은 설계 작업이 어느 정도 끝나고 실제 개발 인력이 투입되서 개발을 진행할 때다. 개발을 진행하기 위해서는 반드시 개발 일정 계획이 필요하다는 사실에는 누구나 동의할 것이다. 그렇다면 합리적인 개발 일정은 어떻게 작성할 수 있을까? 우선 정확한 개발일정을 산출하기 위해서는 합리적인 판단을 도와줄 수 있는 기본 자료가 필요하다. 다음은 정확한  프로젝트 일정 산정을 위해서 필요한 데이터다.

• Software의 상세 설계안
• 유사 프로젝트 투입 공수
• 개발자의 능력

그렇다면 이 세가지가 어떻게 조합 되서 정확한 프로젝트 일정을 산정할 수 있는지 살펴보자.

Software 상세 설계안

우선 개발하고자 하는 software의 상세한 설계가 나와야 한다. 이 상세 설계안이 나오지 않는다면 무엇을 개발할지 모른다. 예를 들어서 상세 설계안이 “사용이 편리한 웹 하드 개발”이라고 해보자. 이것은 상세 설계가 아니다. 개발 명세서 단계도 지나지 않은 단순한 고객 요구 사항이다. 그러나 이런 수준의 설계를 가지고 개발을 하기도 하는게 우리나라 SI의 현실이기도 하다. 도대체 “사용이 편리한 웹 하드 개발”은 무엇을 말하는가? Drag & Drop 기능을 제공해야 하는지? P2P 방식인지 서버/클라이언트 방식인지? 사용이 편리하다는 말 뒤에는 빙산의 일각처럼 너무나 많은 고객 요구 사항이 있기 때문에, 이 설계안을 가지고 개발을 시작하면 칡뿌리 캐듯이 숨은 고객 요구 사항이 발생한다. 그렇기 때문에 이 설계안을 가지고 산정한 개발일정은 아무런 의미가 없다. 정확한 설계안이 나올 수 없다면 XP에서 사용하는 Story card 수준의 고객 요구라도 작성해야 한다. XP에서 설계를 안하는 것처럼 보이지만 사실 Story card는 일종의 고객 요구 분석인 셈이다. 따라서 정확한 개발 일정 산출을 위해서는 반드시 어느 수준 이상의 상세 설계나 고객 요구 분석이 선행되어야 한다.

유사 프로젝트 투입 공수

어느 정도 설계가 끝났다면 각각의 기능을 개발하기 위해서 일정을 산출해야 한다.  결국 프로젝트 전체 일정이라는 것은 각각의 개발 기능의 일정의 합이기 때문에 기능의 일정을 산출하는 것이 중요하다. 그런데 각 기능의 개발 기능을 알 수 있는 가장 좋은 방법은 과거 진행한 유사 프로젝트의 투입 공수를 살펴 보는 것이다. 하지만 우리나라 현실 상 프로젝트 과거 이력을 충실히 갖춘 회사는 드물다고 생각한다. 물론 PSP(Personal Software Process) 수준을 바라는 것은 아니지만, 적어도 해당 프로젝트에 투입되 시간들은 기록해 두어야지만, 다음 프로젝트에서 그 데이터를 활용해서 새로 시작하는 프로젝트가 얼마의 기간에 끝날 수 있을지 알 수 있다. 만일 이 데이터가 없는 경우 프로젝트 리더의 감으로  각 기능의 개발 기능을 산출할 수 밖에 없다.

개발자의 능력

아무리 상세 설계안이 잘 나오고, 기존 프로젝트를 통해서 어느 정도 개발 기간이 투입될지를 예상해도, 개발자의 실력이 받쳐 줄지 못한다면 개발 계획은 아무런 의미가 없다. 따라서 유사 프로젝트를 통해서 가늠한 프로젝트 일정은 표준으로써 역할을 하는 것이고, 최종적인 개발 일정은 개발자의 능력에 따라서 결정된다. 개발자의 레벨을 가장 손쉽게 평가할 수 있는 것은 개발경력이라고 생각한다. 물론 개발 경력을 토대로 개발자의 정확한 능력을 판가름할 수는 없지만 개발 경력은 어느 정도 정량적인 지표를 제공한다. 그래도 이것은 평균에 관한 이야기다. 현실은 다양한 산포가 존재하고 당신 팀에 배치될 개발자의 수준은 천차만별이다. 따라서 나는 개발 계획을 작성할 때, 개발자가 직접 작성하는 것이 바람직하다고 생각한다. XP의 방법론을 따라서 Story card가 나왔건, 일반적인 waterfall 방식의 프로세스를 따라서 HLD(High Level Design)가 나왔건, 반드시 일의 양을 산출할 수 있는 고객 요구나 설계가 나온 후 이것을 토대로 개발자에게 기능을 개발할 때 얼마의 시간이 걸릴지를 직접 작성하게 만드는 것이다.

개발계획은 팀장의 것? 팀원의 것?

물론 프로젝트의 일정은 정해져 있고, D-day를 지키고 싶지 않는 팀장은 없다. 그러나 이것은 바램일 뿐이다. 물론 프로젝트에는 여러가지 역학 관계가 존재하지만, 그래도 개발 품질과 일정에 가장 큰 영향을 미치는 것은 개발자의 역량이다. 따라서 개발자만이 자신이 어느정도의 효율성을 가지고 개발할 수 있을지 안다. 만일 당신 팀에 소속된 개발자가 당신과 여러 번의 프로젝트를 했다면, 어느 정도의 능력을 가지고 있는지 짐작할 수 있다. 그래도  주어진 기능에 대한 일정은 해당 개발자만이 산출할 수 있다. (특히 과거 유사 프로젝트의 데이터가 없는 경우는 개발자의 말에 의지할 수 밖에 없다.) 또 한가지 사실은 개발일정을 개발자에게  산출하게 함으로써 일정에 대한 확신과 더불어 Owernship을 부여할 수 있다. 따라서  팀장이 정한 프로젝트 일정에 끌려 가는 것이 아니라 스스로의 계획 아래 일이 진행된다는 Pride를 심어 줄 수 있기 때문에 프로젝트 일정을 팀원에게 돌려 주는 것이 여러모로 좋다. 현재 몸담고 있는 회사에서는 수 많은 프로젝트가 진행되었지만 과거 프로젝트 데이터를 현업에서 사용할 수 있도록 정리된 것이 거의 없다. 아쉽지만 상세 설계안과 이를 토대로 개발자가 일정을 작성하여 프로젝트 개발 일정을 산출하였다. 이 때 사용한 포맷은 다음과 같다.(프로젝트 내용 부분은 기업 비밀이기 때문에 삭제하고 공유하는 것을 이해하길 바란다.)

프로젝트 개발 일정표

그림에서 보는것과 같이 Excel을 이용하여 프로젝트 개발 일정을 작성하였다. 예전 프로젝트에서 MS Project로 일정을 산출하고 관리를 하기도 했으나, MS Project를 사용하면서 몇가지 불편한 점이 있어서 Excel로 프로젝트 일정 관리를 변경하였다. Excel을 사용한 이유는 조엘 온 소프트웨어(Joel On Software, 에이콘)에서 언급한 내용으로 대처한다.

마이크로소프트 프로젝트는 과업 사이에 존재하는 의존성을 밝히느라 뛰어다니는 과정에서 많은 시간을 소비해야 할 경우에만 우용합니다. 의존성은 과업 2개를 동시에 수행할 때, 특정 과업을 시작하기 전에 다른 과업이 반드시 끝나야 함을 의미합니다. 소프트웨어 부문에서는 과업 사이의 관계가 너무나 명백함으로, 이런 의존성을 공식적으로 추적하는 과정에 노력을 들일 필요가 없다고 생각합니다. … 사람들이 버튼 하나로 일정을 ‘다시 조율’할 수 있는 기능을 오용하는 것입니다. 필연적으로 이런 기능은 과업을 재배열하고 서로 다른 사람에게 각각의 임무를 다시 할당하게 만듭니다. 하지만 소프트웨어 개발자는  기본적으로 업무를 상호교환이 불가능하기 때문에, 소프트웨어에서 이런 작업은 의미가 없습니다. … 윈속 문제를 해결하는 데 GUI 프로그래머를 투입한다면, GUI 프로그래머는 작업을 멈추고 윈속 프로그래밍에 익숙해질 때까지 시간을 허비하게 됩니다.

개발 일정 작성 방법

이번 프로젝트는 총 3개의 모듈을 개발했으며 그 중 한 모듈에서 작성한 프로젝트 중간 단계의 개발 일정표다. 이 모듈의 개발 계획은 다음과 같이 작성하였다. 인터뷰를 통하여 고객의 개략적인 요구 분석을 작성했으며, 이를 토대로 GUI 설계를 마쳤다. GUI 설계를 마친 후 이를 두고 고객, 프로젝트 리더(나) 그리고 개발자 3명이 모듈의 세부 기능을 추출했다. 상세 개발 기능이 어느 정도 확정된 다음 개발 일정을 산출하였다. 개발자도 약 한 달동안 고객과 협의를 하면서 모듈의 상세적인 기능을 파악한 상태였기 때문에, 개발자에게 일정을 작성하도록 하였다. 단 개발 계획 작성 시 약간의 Guide line과 템플릿을(위의 엑셀 파일) 제공해 주었다. 우선 템플릿은 작업 id, 작업에 관한 간략한 설명, 시작일, 예상시간, 수정 예상 시간, 실제 투입 시간, 완료일, 완료 여부로 구성되어 있다. 하루는 8시간으로 계산해야 하나 고객 Site의 특성 상 하루를 9.5시간으로 계산하였다. 일정 계획 시 중요한 것은 반드시 하루 작업 시간을 9.5가 넘지 않도록 하는 것이다. 수정 예상 시간은 예상 시간 내 작업이 끝나지 않는 경우 변경된 시간을 적도록 하였다. 실제 투입 시간은 하나의 작업이 완료된 후 실제 투입한 시간을 적도록 하였으며, 이 때 완료일도 같이 입력하였다.

하나의 작업은 최소 1일에서 최대 3일이 넘지 않는 범위에서 일정을 산출하도록 했다. 이 부분이 일정 산정 시 매우 중요한 부분이다. 작업 시간을 시간 단위로 산출하게 되면 작업이 너무 산만해진다. 이에 반해 작업 기간을 3일 이상으로 잡으면 그 작업 내는 숨은 고객 요구 사항이나 예상치 못한 문제점이 도사리고 있기 때문에 일정이 지연된다. 따라서 몇 시간 단위로 작업이 산출되었다면 작은 작업을 모아서 하루치 분량으로 만든다. 이에 반해 4일 이상의 작업이라면 잘게 쪼개서 1~3일 분량의 일로 만들어야 한다. 이렇게 작성된 프로젝트 일정은 팀장과 개발자의 협의를 통해 프로젝트 일정에 문제점이 없는 최종 확인한 후 결정한다. 그런데 프로젝트 일정을 점검할 때 팀장의 역할이 중요하다. 일정을 산출할 때 여러가지 목적이 있지만 앞서 지적하였듯이, 개발자가 개발의 주체가 되도록 해야 한다. 즉, 개발자를 밑에서 일을 하는 사람이 아니라 동료로써 생각하고 있다는 신뢰를 주어야 한다. 따라서 애써 작성한 개발 일정이 프로젝트 일정에 치명적이라 하더라도 개인의 판단에 의해 작성한 것이기 때문에, 일정이 늦어지는 이유를 합리적으로 해결해야 한다. 즉, 일정이 합리적인 이유로 길어진 것이라면 여분의 Resource를 지원하거나, 만일 투입이 불가능한 경우 고객과의 협의를 통해서 고객 요구 사항을 조절해야 한다. 고객 요구 사항을 Nego하는 것은 팀장의 주요 역할이다. 이것은 다음 post에서 다루도록 하겠다.

예상 시간을 수정한 경우 작업 소요시간이 3일을 넘지 않는 경우에는 큰 문제가 없으나,  만일 수정 시간이 3일을 넘는 경우 대부분 새롭게 수정한 예상 시간도 어기게 된다. 즉, 3일 이상 작업이 지연된 경우 작업 내용이 명확히 정의되지 않았다는 뜻이다. 따라서 이 경우에는 단순히 시간만 수정해서는 안되고, 해당 작업을 다시 정의해서 작업을 나누어야 한다. 일정 산출 시 가장 조심할 점은 월화수목금금금의 황우석 시간표는 피해야 한다. 황우석 시간표를 만들게 되면 이미 그 프로젝트는 D-day를 맞출 수 없다고 선언하는 것과 동일하다. 사람은 기계가 아니다, 아무리 D-day를 준수해야 한다고 하루 12시간 씩 코딩하고 일주일의 하루도 쉬지 않고 일하면 결국 생산성이 떨어지지 때문에 예초에 하루씩 쉬고 8시간만 일했을 때와 결과는 마찬가지일 때가 많다. 또한 일정 계획은 아무리 완벽하게 세운다고 해도 여러가지 돌발 변수로 인해 지연될 수 밖에 없다. 따라서 만일의 사태에 대비하기 위해서 주말 시간은 반드시 Buffer로 비워 두어야 한다.

끝내면서…

물론 계획을 잘 세운다고 해도 성공적으로 일정을 준수하기란 쉽지 않다. 그렇다고 현실을 무시한 채 일정만 맞추라고 개발자에게 강요할 수도 없다. 개발 계획 수립을 개발자에게 돌려 준다는 것은 개발자를 부하 직원이 아니라 동료로써 인정한다는 선언이다. 따라서 팀장 어깨에만 놓여진 프로젝트의 책임감을 개발자와 공유할 수 있는 방안이기도 하다. 이것으로 오늘 post를 마치고 다음에는 팀장의 nego 능력에 대해서 살펴 보도록 하겠다.

This entry was posted on Monday, April 24th, 2006 at 12:41 am and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.