이것도 se66.com의 내가 펏던 글을 재펌한 글.
기억하고 싶은 글이다.



다른회사들은 어땠는지 모르겠지만 어찌되었든 IT기업이 아닌 회사의 전산실에 오랬동안 근무한적이 있는 제가 당시 느꼈던 불만중의 하나가 바로 전산부서는 비용발생부서라는 오명입니다.

다시말해서, 전산부서는 비용만 발생하고 수익을 내지 못하는 부서라는 인식입니다.

이러한 어의없는 인식으로 인하여 전산부서가 최첨단 기술부서니 뭐니 하지만 실제로는 전혀 대우를 받지 못하는 지원부서로 회사에서는 분류가 되어 있으며, 이는 중간관리자를 거쳐 고위층으로 승진하는데 있어서도 상당한 부담이 되는 요소가 된다는 거죠.

그중에서도 시스템관리부서는 가장 비용이 많이 발생하고,  업무는 밤낮 구분없이 하면서도 업무양에 비하여 대우를 받지못하는 부서 였었습니다.

프로젝트를 하고나면 쫑파티를 하는데도 잘 불러주지도 않고, 프로젝트 성과에대한 포상을 하여도 늘 시스템부서는 뒷전이었습니다.

그 뿐입니까.

시스템은 가만~히 놔두면 다운되지 않는 것으로 인식을 하여,  시스템관리를 잘해서 다운되지 않으면 본전이고, 어쩌다가 시스템이 다운되면  업무태만정도로 생각하여 추궁을 당하거나 시말서를 쓰는 것이 보통이었습니다.

이런 문제는 왜 발생할까요.

왜 전산부서는 비용이 발생만 하고, 수익은 없는 부서로 인식되어 있는 것일까요.

이것은 어찌보면 연말결산시 전산관련부서장들의 목소리가 적어 경영진을 설득시키지 못한 이유도 있고, 마켓팅이나 영업부서들이 자기부서들의 실적을 많이 올리려고 비용은 대충 감추고 매출만 나타내려는 욕심이 그 이유중의 하나 입니다.

오히려 자리에 가만이 않아, 관리만 하는 총무인사 또는 재경부서등 관리부서를 보면  비용은 잡비정도이고 수익은 수익부서의 수익을 인원비율로  나누어가져 최소한 적자는 면하는데, 전산부서는 도입되는 모든 시스템들은 전산부서의 비용이고, 매출은 하나도 없는 이상한 계산법이 연말이면 도입됩니다.

웃긴얘기죠.

전산부서는 따지고 보면 엄청난 이윤을 가져다주는 부서입니다.

만일, 전산화가 않되었다는 가정하에서 소요되는 비용을 따져본다면 업무전산화로 인한 회사의 비용절감은 어마어마 한 것이죠. 그것이 사실은 모조리 전산부서의 수익으로 계산될수도 있는 것입니다.

더 정확하게 따지려면 전산부서의 시스템 및 프로그램들의 비용은 현업에서 그러한 시스템 및 프로그램을 사용하여 업무의 효율성을 높이는 부서들이 나누어 부담해야 하며, 잔산부서의 비용은 순수 시스템관리 시스템 또는 관리 소프트웨어 비용이며, 수익은 현업부서의 인력지원 인건비로 계산되어 오히려 지원을 받는 부서에서는 전산부서 인원만큼의 비용이 발생해야 하는 것입니다.

그렇게 되면 전산부서는 최소한 적자는 아니거나, 경우에 따라서는 어마어마한 수익을 올리는 부서로 탈바꿈 하는 것입니다.

그러나 아쉽게도 이러한 인식이 되어있지 않는 경우가 왕왕 있습니다.

이제는 이러한 부분을 분명히 社측에 인식시킬 필요가 있습니다.

전산부서는 비용발생부서가 아니라 수익창출부서이다.

Ref: http://www.ibmmania.com/zb40/zboard.php?id=ibmboard2&no=50181

우리사회에 리엔지니어링이라는 단어가 확산되고, 팀제의 성공사례가 "Corporate Re-engineering"이라는 책에 소개되면서부터 "팀"제 조직이 유행했다. 이 책은 Micheal Hammer라는 시스템공학자에 의해 쓰였지만 한국 출판사가 엉뚱한 사람들에게 번역을 시켜 원 저자의 뜻이 상당히 왜곡됐다. 그래서인지 한동안 우리나라에서 너도나도 팀제를 채택했지만 이는 과장이나 부장에 팀장이라는 이름을 붙여준 것에 불과했다. 내용은 그대로이고 무늬만 팀제였던 것이다.

거의 모든 기업이 팀제가 무엇을 의미하는지 조차 이해하지 못한 채, 남들이 하니까 우리도 하자는 식으로 팀제를 운영했다. 선진국의 1개 팀에는 서로 다른 기능을 가진 사람들이 모여 있는데 반해 우리나라 팀에는 지금도 같은 기능을 가진 사람들만 모여 있다. 10명의 회계 기능인들을 모아놓고 회계팀이라고 부르는 것이다. 여러 기능을 컨베이어벨트 개념에 따라 나열해놓고 기능 조직이 내놓는 결과물을 컨베이어벨트를 흐르는 식으로 조립하자는 게 한국식 조직 운영 방법이고, 여러 종류의 기능인력을 동시에 한 곳에 투입하여 토의를 통해 화학적 에너지를 내자는 게 서구식 팀제다. 선진국의 1개 팀은 하나의 프로젝트를 처음부터 끝까지 팀의 이름을 걸고 책임을 지면서 수행하지만, 한국의 1개 팀은 컨베이어벨트의 일부처럼 부분만을 수행하여 옆 팀으로 넘겨준다.

프로젝트가 코끼리라고 가정해 보자. 선진국 1개 팀은 코끼리 한 마리를 팀의 명예를 걸고 완성하지만, 한국의 1개 팀은 코끼리의 뒷다리를, 1개 팀은 코끼리 목을, 또 다른 팀은 코끼리 머리를 완성하는 식이다. 여러 팀의 산물을 모아야 코끼리가 완성되지만 A팀에서 만든 코끼리의 목과 B팀에서 만든 코끼리 머리가 제대로 결합되지 않는다. 심지어는 A팀은 코끼리 목을 만들고 B팀은 사자의 머리를 만들어 낸다. 코끼리도 아니고 사자도 아닌 현상이 발생하는 것이다.

선진국형 팀제의 장점은 세 가지다. 하나는 팀 파워를 낼 수 있다는 것이고 다른 하나는 유사한 팀을 여러 개 만들어 경쟁을 시킬 수 있다는 것이며 또 다른 하나는 실명제로 단일 책임을 지울 수 있다는 것이다. 두 사람 이상에게 공동으로 책임이 있다는 말은 아무에게도 책임이 없다는 말이다. 책임이 없으면 경영도 없다. 따라서 모든 프로젝트는 팀장이 전적으로 책임을 지도록 하는 단일 책임제로 운영돼야 한다. 

5명 1개조로 자동화장비를 설치해주는 회사가 있었다. 설치해주고 오면 곧바로 A/S가 발생해서 그로 인해 적자가 났다. 사장은 각 조가 설치하는 기계에 동판을 붙이고 거기에 조원들의 한문 이름과 주민번호를 새기게 했다. 그렇게 하자마자 각 조는 이름을 걸고 일을 했고, 그 결과 적자가 흑자로 돌아서게 되었다. 실명제란 이렇게 무서운 것이다. 하지만 대부분의 한국사회에서는 권한을 행사할 때에는 얼굴을 크게 내보이고, 책임질 일이 있을 때에는 얼굴을 감춘다. "컨베이어 벨트에서 한 부분을 맡아 일했을 뿐인데 왜 내가 책임을 지느냐?"

하나의 프로젝트를 놓고 기능과 생각이 서로 다른 사람들끼리 토의를 하는 것은 얼른 보면 비효율적인 것처럼 보일 수 있다. 하지만 이러한 방법은 설계, 생산, 품질, 작업 계획 등 모든 분야에서 아이디어를 높일 수 있고 시행착오를 줄이는 데 결정적인 역할을 수행한다.  가장 중요한 사항이 무엇인지, 가장 먼저 해야 할 일이 무엇인지, 가장 실수하기 쉬운 과정이 무엇인지, 어느 작업들을 동시에 병렬식으로 수행할 것인지, 어느 부분을 외주 줄 것인지 등을 따지다 보면 토의 능력이 향상되고 에러가 걸러지며 관리가 철저해 진다.

기업 내부에는 경쟁이라는 개념이 별로 없다. 기업마다 경쟁을 시키고는 있지만 서로 하는 일이 다른 기능 조직들에 경쟁을 붙여봐야 불만과 비웃음만 자아낼 뿐이다. 프로젝트 단위를 총체적으로 책임지는 사람도 없다. 일이 실패하면 모두가  자기 책임이 아니라는 데 지혜를 동원한다. 경쟁은 자극이다, 자극 없는 조직과 개인은 게으르고 퇴화한다. 팀들이 경쟁을 하게 되면 팀장을 훌륭한 경영인으로 훈련될 수 있다. 팀원에게 큰 소리 치고, 고압적인 팀장은 꼴등을 하게 될 것이고, 팀원을 다독거리고, 아이디어와 창의력을 조직적으로 유도해 내는 노력을 하는 팀장은 지연이 두각을 나타내게 될 것이다. 

팀조직이 궤도에 진입하면 무 하자 제품을 만들 수 있다. 납기를 획기적으로 단축시키고 에러로 인한 엄청난 비용을 제거할 수 있다. 시간이 갈수록 팀조직이 기업의 핵심 경영능력으로 발전하여 제작 방법을 스스로 창안할 수 있는 자생 능력까지도 기를 수 있을 것이다. 이렇게 되면 최초에 구성된 10명이 1-2년 내에 4-5명으로 줄어들 것이다. 

팀제가 과연 좋으냐? 이론과 성공사례를 보면 팀제는 분명 엄청난 파워를 낸다. 한국에서 팀제가 운영되지 못하는 것은 1) 팀제에 대한 정확한 컨설턴트가 없었기 때문이거나 2) 최고 경영자의 의지가 없거나 3) 남이 해보지 않은 것에 도전하려는 의욕들이 없거나 4) 새로운 지식과 이론을 소화할 수 있는 능력들이 없기 때문이다.

2008.4.30.

Ref: http://www.systemclub.co.kr/

출처: http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=28&no=126&page=1

제목이 좀 도발적이죠?

이글의 실제 내용 "Quick-Kill Project Management"와 제목을 연관시키려다 보니 이렇게 되었네요.

얼마전 여기 Devpia에 링크되어있는 "노땅엔지니어의 노트"에서 본 것 같은데, 우리 나라의 낮은 개발자 처우, 너무 과도한 프로젝트와 빡빡한 일정 이런 것 어떻게 바꿔야 하지 않겠는가 하는 글을 읽은 적이 있었습니다.

물론 처우개선할 것은 해야 하지만 현실이 쉽게 바뀌지 않는다면 우리 자신이 이런 상황을 타개해 나가야 하지 않을까요?

"Quick-Kill Project Management"이라는 기사를 인터넷에서 읽고 과중한 프로젝트 압박은 비단 우리 나라에만 있는 것은 아닐성 싶었습니다.

필요는 발명의 어머니라고 하지 않았던가. 이 지구상의 수많은 사람들중 어떤 한 사람이라도 같은 고민을 하고 있을 겁니다. 그리고 운 좋으면 해결책까지 이미 가지고 있고요. 요즘 뭐 개발 하라고 하면 인터넷에 비슷한 소스 있나 먼저 찾아보는 이유도 다 이런 범주에 속하겠죠.

이 글은 말그대로 성공적인 프로젝트 수행을 위한 빠른 프로젝트 관리 기법을 소개한 글입니다. 개발 5년차가 넘어가서 이제 프로젝트 관리까지 담당을 해야하는 개발자 겸 책임자에게 도움이 될 것 같아 이렇게 올립니다.

꼭 기법을 배우지 않더라고 글 중간중간에 닥치는 상황과 고민이 어쩜 나하고 같지 하는 공감을 불러 일으키리라 봅니다.

영문 원문을 바로 읽으시려는 분은 http://www.ddj.com/architect/189401902 로 가시면 됩니다.

이곳에 있는 것을 좀 서투른 영어지만 성심껏 번역했습니다.

번역본 word 파일이 필요하시면 제 블로그에서 가시면 있습니다.

자!! 이 부분부터 번역한 글입니다.

__________________________________________________________________________________________

빠른 처리(Quick-Kill) 프로젝트 관리

 극히 불가능한 일정에 직면했을 때 조차 현명하게 소프트웨어를 개발 하기

 저자:  Andrew Stellman and Jennifer Greene

작성일: 30, 2006년 6월 30

출처: Dr. Dobb's Journal(http://www.ddj.com/dept/architect/189401902)

 앤드류와 제니퍼는 “Applied Software Project Management (O'Reilly & Associates)” 책의 저자이다.

 당신이 다섯 명으로 이루어진 개발 팀 리더라고 하자. 한 프로젝트에 몇 주 동안 매달린 결과, 팀이 막 결과물을 내놓기 시작했다. 팀은 경력상으로 고참 설계자로부터 학교를 갓 졸업한 초보 프로그래머에 이르기까지 다양하게 구성되었다. 그때 당신의 상관이 당신을 불러 부사장이 전화로 자기를 씹어대며 어제까지 그 프로젝트가 끝났기를 바랬다고 말한다. 알려진 바와 같이 이 프로젝트는 확연히 드러나고 오랫동안 약속된 것이다. 고객은 이 소프트웨어로 처리할 일이 있고 이 소프트웨어는 매우 중요하다. 만약 이게 잘 안 돌면 당신은 옷 벗을 생각을 해야 한다.

 일전에 이런 종류의 높은 압박 속의 팀에 있었다면 그 프로젝트는 악몽이었을 것이다. 팀원들이 몇 날을 헤매고 있고 당신은 영웅 역할을 해야 해서 심각한 설계 오류를 고치기 위해 뛰어 들어가 주말 40시간 일을 한다. 고참 관리자와의 끝없는 회의와 결코 없어지지 않는 끈질긴 버그들과 야밤의 너무 많은 커피와 피자가 있다. 그리고 마침내 팀이 어떤걸 내놓자, 고객은 그것을 싫어한다. 그들이 버튼을 누를 때 마다 버그가 있고 그들이 기대했던 어떤 것도 그 소프트웨어 전체 기능 안에는 전혀 구현이 안된 것처럼 보인다.

 

빠른 처리(Quick-Kill)

요즈음 많은 팀들은 이런 상황에 놓여있고 개발 책임자는 심각한 도전에 직면해있다. 그는 직접적으로 그의 팀을 관리할 필요는 없지만 그 소프트웨어가 출시될 수 있게 하는데 책임이 있다. 팀은 그를 존중하고 그가 결정 하면 사람들은 보통 그를 따른다. 그렇지만 개발 책임자의 일은 관리가 아니라 개발에 있다. 그는 솔루션과 소프트웨어 설계와 코드를 작성하는데 대부분의 시간을 보낸다.

 이상적인 프로젝트 관리는 전담 프로젝트 관리자가 있거나 아주 많은 프로젝트 준비 시간을 필요로 한다. 하지만 당신이 팀을 이끌고 있고 올바른 프로젝트 관리를 위한 시간도 예산도 없다면 어떻게 하겠는가? 이런 자리에 있는 사람이 어떻게 시작해야 하는지 조차도 어려운 일이다. 이것이 “빠른 처리(Quick Kill)”의 탄생 배경이다 – 프로젝트에서 가장 큰 문제들만을 처리하기 위한 아주 범위를 좁힌 시스템. 다르게 말하면 프로젝트 책임자들에게 가장 적은 비용으로 큰 이익을 얻게 하는 행동 강령이다.

 빠른 처리(Quick-kill) 프로젝트 관리는 상관이 기대하고 고객이 필요로 하는 제품이 산출될 수 있게 돕는 세가지 기술로 구성된다.

• 비전과 범위 문서(Vision and scope document)

• 작업 세분화(Work breakdown structure)

• 코드 검토(Code review)

위의 각 기술을 실행하는 데는 시간이 얼마 걸리지 않고 팀이 대부분의 일반적이고 큰 비용을 치러야 하는 프로젝트의 큰 위험을 회피할 수 있게 한다. 이것들을 사용하여 책임자는 만족스러운 소프트웨어를 만들 수 있는 확률을 여러모로 높일 수 있다.

 

비전과 범위 문서: 최대 6시간

만약 팀이 어떤 소프트웨어를 만들고 있는지를 실제 이해하지 못하면 프로젝트 전 과정에 걸쳐 잘못된 결정들을 내릴 소지가 더 농후하다. 팀은 이러한 잘못된 결정들을 고치기 위해 귀중한 시간을 허비해야 하거나 만약 고치지 않고 남겨 프로젝트가 고객의 필요를 충족하지 못했을 때 고객에게 사정해야 할 상황에 놓이게 된다. 프로젝트 실제 범위에 대한 올바른 이해 없이 팀은 촉박하다는 것만을 보게 되고 그들이 채워야 하는 요구 사항에 대한 궤도를 잃게 된다. 프로그래머들은 큰 그림을 보지 못하고 그들이 해결 하고자 하는 일의 개별적인 문제만을 볼 수 있다. 그리고 이것은 프로젝트 실패와 지연을 야기시키는 가장 큰 단일 원인이다.

다행히도 팀이 이러한 문제를 회피하게 만드는 간단하고 실행에 옮기기 쉬운 것이 있다. 비전과 범위 문서를 작성하는 데는 하루가 안 걸리고 이는 팀이 몇 주의 재 작업과 잘못된 시작을 하지 않도록 하는데 도움이 된다.

비전과 범위 문서 작성의 첫 번째 단계는 프로젝트 관계자와 이야기 하는 것이다. 불행히도 누가 관계자인지 항상 분명한 것은 아니다. 프로젝트 책임자는 어떤 사람이 그 프로젝트에 의해 가장 영향을 받을 지를, 그것을 그가 사용하는 것을 계획했기 때문인지 또는 개발 되는 것에 대한 다소 책임이 있기 때문인지를 파악해야 한다. 바꾸어 말하면 책임자는 그 소프트웨어가 개발이 안되었다면 누가 가장 어려워질 건지를 찾아야 한다. 개발 책임자가 또는 가능하면 다른 팀 구성원들까지도 관계자들과 꼭 해야 할 일이다. 이러한 요구 사항을 수집하는 것은 관계자 한 사람당 한 시간이 안 걸릴 것이다.

비전과 범위 문서(표1)는 몇 페이지가 넘지 않게 간단해야 한다. 관계자들과 대화를 통해 팀이 수집한 모든 정보는 문제 서술 장(Problem Statement section)에 추가되어야 한다.

1. 문제 기술(Problem Statement) a. 프로젝트 배경(Project Background) b. 프로젝트 관계자(Stakeholders) c. 사용자(Users) 2. 솔루션의 비전(Vision of the Solution) a. 비전 서술(Vision Statement) b. 기능 목록(List of Features) c. 개발에서 제외된 기능(Features That Will Not Be Developed)

표 1: 비전과 범위 문서 윤곽

 프로젝트 배경 장은 그 프로젝트가 해결해야 할 문제를 요약한다. 문제의 간단한 이력과 어떻게 그 조직이 그 문제를 다루기 위한 소프트웨어 개발을 결정했는지에 대한 설명을 제공해야 한다.

 프로젝트 관계자 장에는 관계자들을 기술한다. 개개의 관계자는 이름, 직책 또는 역할(지원 부서 관리자, SCTO, 선임 관리자)에 의해 언급될 수 있다. 각 관계자의 요구 사항은 몇 문장으로서 기술된다. 사용자 장은 사용자들 목록을 포함하여 비슷하게 작성된다. 관계자들에 대해 했던 것 같이 각 사용자도 이름 또는 역할(고객지원 상담자, 통화 품질 감사, 가정에서 사용하는 웹 사용자)에 의해 언급될 수 있지만 만약 많은 사용자가 있다면 각 사용자를 지칭하는 것은 보통 비효율적이다. 각 사용자의 요구사항은 기술된다.

 사용자와 관계자의 요구 사항은 이 문서에서 가장 중요한 부분이다. 팀이 그 프로젝트를 이끄는 요구 사항을 이해하지 못하면 관계자들에게는 사소한 문제를 처리하기 위해 팀의 시간을 소모시키는 원인이 되는 지협적인 초점에 매달릴 수 있다. 잘못된 문제를 해결하는 거대한 소프트웨어를 만들기는 쉽다. 적절한 소프트웨어를 만들기 위한 단 한가지 방법은 일이 시작되기 전 왜 어떻게 소프트웨어가 만들어져야 하는지에 대해 프로젝트 참여자의 모든 사람의 이해와 동의를 구하는 것이다. 이것이 프로젝트 계획의 목적이다.

 비전과 범위 문서의 비전 부분은 소프트웨어의 최종 목적에 대한 설명을 일컫는다. 모든 소프트웨어는 특정 사용자와 관계자의 요구를 충족하기 위해 만들어진다. 팀은 그러한 요구 사항을 식별하고 비전 기술서(어떻게 그런 요구 사항이 충족될 것인지를 설명하는 비전 기술서)를 작성해야 한다. 비전 기술서 장의 최종 목표는 성취하기 위해 무엇이 프로젝트에 기대되는가를 기술하는 것이다. 프로젝트의 목적이 설명되어야 한다. 이 목적은 프로젝트에 소비되는 시간, 돈, 자원에 대한 필수 불가결한 이유와 합당한 타당성이 있어야 한다.

 "기능 목록"과 "개발에서 제외된 기능" 장들은 무엇이 구현되고 구현되지 않을 것인지에 대한 정확한 목록을 담아야 한다. 이 장들을 쓰기 전에 팀은 문서 나머지 부분을 작성해야 하고 충족시키고자 하는 요구사항에 대해 열린 회의를 해야 한다. 팀은 종종 확실해 보여서 어떤 기능을 도출하지만 실제 필요하지 않는 것으로 판명이 되는 것이 있다. 이와 같은 기능들은 "개발에서 제외된 기능"에 기술해야 된다.

 

작업 세분화 구성(Work breakdown structure):  2 시간

 만들 기능들에 대해 작업 들어가기 전에 책임자는 팀과 함께 각 기능을 구현하는데 얼마가 소요될 것인가 하는 추정 목록을 마쳐야 한다. 많은 개발자들은 추정을 크게 어려워한다. 다행히도 추정 단계를 보다 직관적이고 신뢰성 있게 만드는 다소의 지침들이 있다.

 추정 단계는 팀 구성원이 프로젝트의 모든 관점을 생각하게끔 하는 것으로 중요하다. 대부분 프로그래머들은 그들이 예측 했던 작업량보다 나중에 더 일이 많음을 알게 될 때 위축되게 된다. 만약 다른 팀 구성원이 그 일에 의존하고 있다면 전체 프로젝트에 혼선이 일 것이다. 올바르게 추정하는 것은 팀이 모든 현격하고 일반적인 실패를 회피할 수 있도록 한다. 프로젝트 추정은 끝마치기 위해 필요한 절차와 각 절차가 요구하는 처리가 몇 일(주, 달, 시간 등등) 걸릴 것인지를 팀이 미리 도출하게끔 만든다. 이러한 단계와 소요 시간을 구하기 위한 유일한 방법은 하지 않으면 프로젝트 후반에까지 남겨질지 모르는 많은 상세한 사항들을 한 팀으로써 모여 앉아서 생각하는 것이다.

 추정하기 위한 첫 번째 단계는 그 프로젝트를 최종 제품에 포함될 작업 목록으로 쪼개는 것이다. 이 목록을 “작업 세분화 구성(work breakdown structure: WBS)”라고 부른다. 프로젝트를 “작업 세부화 구성”으로 나누는 여러 방법이 있다. 책임 개발자는 팀원들과 이 작업 목록을 토의할 회의를 가져야 한다.

 가장 유용한 법칙은 어떤 프로젝트라도 10에서 20개의 작업으로 쪼갤 수 있다는 것이다. 예를 들어 우주선 프로젝트와 같이 큰 프로젝트의 작업들은 “항해 시스템 시험”과 같이 아주 클 것이고 간단한 계산기 작성 같은 작은 프로젝트는 “덧셈, 곱셈, 두수의 곱셈을 위한 산술 객체의 제작”과 같이 작업들이 작을 것이다. 팀원들과 작업 목록에 대해 회의는 한 시간이 안 걸려야 한다.

 일단 팀 구성원들이 “작업 세분화 구성”에 동의하면 각각에 대해 추정할 수 있도록 각 작업에 대한 토의를 시작할 수 있다. 프로그램 초기 단계에는 팀 구성원들이 추정에 필요한 모든 정보를 갖지 못했지만 어쨌든 수치를 뽑아내야 한다. 부족한 정보를 메우기 위해 할 일에 대한 가정 해야만 한다. 가정 했으므로 팀 구성원은 보다 정확한 추정을 나중에 추가하기 위한 정보에 대해서는 표시를 남길 수 있다.

가정은 추정에 있어 매우 중요한 요소이다. 만약 두 사람이 얼마나 걸릴 것인가에 대해 동의하지 않는다면 그 원인은 일의 세부적인 내역 또는 그것을 도출하기 위한 전략에 대해 서로 다른 가정을 했다고 할 수 있다. 달리 표현하면 이 의견 차이는 보통 그것을 끝내기 위해 들인 노력에 관한 것이 아니라 그 일 자체를 하기 위해 무엇이 필요한 것인가에 관계된다. 예를 들어 컴퓨터 시간을 설정하는 툴에 대한 비전(vision)과 범위(scope) 문서를 주면 두 개발자는 아주 다르게 추정할 수 있다. 한 개발자는 간단한 명령 입력 방식이라고 생각하는 반면 다른 개발자는 운영 체제의 제어판과 완벽하게 통합되는 사용자 인터페이스를 가져야 한다고 가정할 수 있다.

 책임자는 다른 프로그래머들이 이러한 가정들을 의논하게 하고 그들의 다른 견해에 관해 임시적인 결정을 하게 함으로써 그 작업에 대한 하나의 추정에 동의하도록 도울 수 있다. 책임자는 차례로 각 작업을 꺼내고 각 작업에 대해 팀이 얼마나 걸릴 것 인가를 결정하게 해야 한다. 의견 차이가 발생할 때 마다 가정하는데 있어 무언가를 놓치고 있는 것을 의미한다. 책임자는 그 가정들이 무엇인지를 정확히 밝히기 위해 나머지 팀 구성원과 같이 처리해야 한다. 이것들이 밝혀지면 기록해야 한다. 회의가 진행 될수록 더 많은 가정들이 쓰여지면 팀 구성원들은 그 프로젝트에 관해 더 많이 알게 된다. 그리고 어떤 소프트웨어를 만들어야 할지를 토의 할 것이다. 이것은 그 팀이 각 작업에 대한 추정들을 취합하게 돕는다.

 최종 “작업 세분화 구성”은 작업 목록과 각 작업에 대한 추정, 작업에 대한 가정한 목록으로 구성 되야 한다. “작업 세분화 구성”의 10에서 20개의 작업에 대한 가정과 추정을 도출하는데 대략 한 시간이 소요 되야 한다. “작업 세분화 구성”을 만들고 예측을 하는 총 시간은 보통 두 시간 정도이다. 보통의 다섯 사람이 하는 프로젝트의 기본 추정 시간으로서는 충분하다. 그렇지만 큰 프로젝트이면 팀을 나눌 필요가 있고 각 나뉜 팀은 두 시간씩의 추정 시간을 가질 수 있다.

 

코드 검토: 한 검토 건수당 2.5 시간

 코드 검토란 팀이 샘플 코드를 검사하고 거기에 오류가 있으면 고치는 것이다. 오류라고 하는 것은 프로그래머가 의도하는 대로 동작하지 않거나 잘못되지는 않았지만 개선될 수 있는 여지가 있는 것을 일컫는다. 예를 들자면 보다 가독성 있게 만들거나 성능이 향상될 수 있는 것이라 할 수 있다.

 코드 검토의 첫 번째 작업은 검토할 샘플 코드를 선택하는 것이다. 코드 전체 줄을 검토하는 것은 불가능 함으로 프로그래머는 검토할 코드 부분을 선택할 필요가 있다. 검토에 적당한 코드를 선택하면 보다 효율적인 검토작업이 된다. 대부분의 프로젝트에서 밝혀진 바로는 대부분의 오류는 비교적 작은 코드 조각에 집중되는 경향이 있다. 코드가 잘 선택되면 이 검토는 만약 남겨진다면 나중에 그것을 찾아 고치는 비용보다는 훨씬 적게 들게 된다.

 책임 개발자에게 검토를 위한 적당한 코드를 선택하는 일을 어렵지 않다. 좋은 검토 후보 코드는 이상한 알고리즘을 구현하거나 어려운 API 또는 객체 인터페이스를 사용한 것, 유지보수하기 위해 전문 기술이 요구되는 것, 새로운 기술을 수용한 것이 될 수 있다. 오류가 있으면 큰 재앙을 불러일으킬 위험이 큰 부분의 코드를 선택하는 것은 특히 유용하다. 보다 더 많은 오류가 있을 성 싶어서가 아니라 보다 많은 사람들이 전적으로 그것에 의존할 수 있기 때문이다. 소프트웨어 많은 부분에 큰 변경을 요구하는 큰 수정이 있으면 오류를 불러일으킬 위험이 높다. 이런 코드 또한 좋은 후보이다.

 검토를 준비하기 위해 책임자는 줄 번호가 있이 인쇄한 선택한 코드를 각 팀 구성원에게 배포한다. 팀 구성원 각자는 개별적으로 샘플 코드를 한 시간 반에 걸쳐 가능하면 실행도 해보면서 읽는다. 그들은 작성자가 하고자 한 의도대로 코드가 진짜 동작하는지 밝히기 위해 최선을 다해야 한다. 그들은 정확성, 유지보수, 신뢰성, 견고함, 보안, 확장성, 재 사용성, 효율성에 문제가 있는지 찾아야 한다. 이것 중 어떤 것이라도 오류로 간주된다. 각 팀은 최대한 많은 오류를 찍어내어 복사본에 표시한다.

 각자의 준비가 끝나면 팀 책임자는 검토회의를 위해 모두 모은다. 코드 검토는 책임 개발자가 큰소리로 최초의 코드 조각을 읽는 것으로 시작된다.  그는 말 그대로 코드에 쓰여진 명령을 읽는 것이 아니라 코드 조각의 목적에 대해 간단한 설명을 한다. 만약 책임자를 포함해서 누구라도 코드가 뭐 하기 위한 건지 이해하지 못하거나 그 해석에 동의하지 않으면 코드 작성자가 그 코드가 어떤 것을 이루기 위함이었는지 설명한다. 종종 팀 구성원이 동일한 것을 구현하기 위해 보다 좋은 제안을 할 수 있지만. 문제 제기한 사람에게 단순히 코드의 목적을 설명하는 정도이다.

 팀 구성원은 그 다음에 코드 조각에서 발견된 모든 오류에 대해 의논한다. 바로 이 지점에서 책임자가 회의 사회자로 나서야 한다. 만약 누구라도 오류를 발견하면 책임자는 그 시점에서 고칠 건지 여부를 결정한다. 책임자가 구성원들이 고칠 수 있다 판단되면 그렇게 한다. 그렇지 않으면 책임자는 코드 작성자가 나중에 고쳐야 할 문제점으로 기록한다. 어떤 경우든 책임자는 검토이력을 담는 스프레드 시트 한 행을 추가해 기록한다. 스프레드 시트에 한 오류당 한 행을 작성하며 각 행은 오류를 가지고 있는 줄 번호, 누가 발견했는지 어떻게 해결했는지 또는 아직 해결이 안된 문제라는 표시를 담는다.  사회자는 이 이력의 위 부분에 언제 회의가 있었고 어떤 조각의 코드를 검토했는지 적어야 한다.

 이 회의는 두 시간을 초과해서는 안 된다. 만약 이것보다 더 걸리면 다음 코드 검토에서는 더 간단한 샘플 코드를 선택해야 한다. 만약 회의가 끝나면 책임자는 나머지 팀원에게 검토 이력을 이메일로 보내고 해당 코드에 책임이 있는 사람에게 수정을 지시한다. 오류가 수정된 후 그는 수정된 코드를 검토하고 잘 고쳐졌는지 확인해야 한다.