[Code Complete] CH3: Measure Twice, Cut Once: Upstream Prerequisites(1)

 이 챕터에서는 본격적인 construction에 들어가기 전의 Prerequisites, 즉 groundwork을 설명한다. 건축으로 치면 기초 공사에 해당하는 것이다. 저자는 단계별로 설명하고 있고, 포스팅도 책의 순서대로 이루어질 것이지만, 빨리 construction 파트부터 보고 싶다면 CH5로 이동할 것을 추천한다.(독자의 이탈을 막기 위해 저자는 Importance부터 설명하고 있다..) 그래도 기초 공사는 정말 중요하므로, 귀찮겠지만 공부를 시작해보자.

 

1. Importance of Prerequisites

 높은 퀄리티의 SW를 만드는 프로그래머들의 공통분모는, (high quality sw를 만들기 위해) 많은 훈련을 거쳤다는 것이다. 이러한 연습들은 프로젝트의 모든 부분(처음, 중간, 끝)에서 중요하게 이용된다.

 

 우선 프로젝트의 끝 부분에서는 system testing을 잘 해야 high quality를 보장할 수 있다. 그러나, Testing은 오류를 detect하는 것일 뿐, 근본적으로 product의 quality를 올려주지는 못한다. 즉 결점들은 construction 전에 찾아야, 더 훌륭한 결과물들을 만들 수 있다.

 프로젝트의 중간 부분에서는, 당연하게도 construction이 이루어지고, 이 책에서 중요하게 다룰 것이다.

 프로젝트의 시작 부분에서는, construction 전 프로젝트에 대한 plan이 들어간다. planning에서는 문제를 정의하거나, solution을 명시하는 과정이 이루어진다.

 

 물론 모든 부분에서 high quality를 내기 위해 practice를 해야 하지만, 프로젝트의 대부분을 차지하는 construction 이전에 proper preparation을 하는 것이 무엇보다 중요하고, 이것들이 우리가 배우려고 하는 prerequisites에 해당한다. 구체적으로는 architecture, design, project planning 등이 해당한다.

 

 그럼 이러한 prerequisites가 modern SW projects에도 적용될 수 있을까? 중요하지 않다라고 생각하는 사람도 많지만, 1970년대부터 현재에 이르기까지 appropriate preparation이 잘 적용되었을때 프로젝트가 최선의 결과를 낼 수 있음을 확인했다.

 

 preparation의 주요한 목표는, risk reduction이다. 훌륭한 프로젝트 기획자는 큰 프로젝트에 있어서 주요 리스크를 제거하고 프로젝트가 순항할 수 있도록 노력을 기울이고, 여기에 있어 과거부터 지금까지 preparation 과정이 핵심적인 역할을 했다. 

 

 poor preparation이 일어나는 주요 원인은, planner들이 프로젝트를 준비할 때 필요한 전문 지식(expertise)가 부족할 경우이다. 필요한 전문 지식들은 다음과 같다.

• planning a project
• creating a compelling business case
• developing comprehensive and accurate requirements
• creating high-quality architectures

 그러나 어떻게 upstream work를 해야 할 지 모른다면, 할 수 있는게 없고, 이 경우에는 아무리 일을 해도 좋은 결과물은 나오지 않는다.

 

 또 다른 원인으로, 프로그래머들이 전문 지식은 가지고 있지만, 프로젝트를 "빨리" 진행시키고자 하는 욕구를 참지 못하고 기초적인 preparation을 하지 않을 때 발생한다.

 

 마지막 원인으로, 매니저나 기획팀이 개발팀에게 악의적인 압박을 가할 때이다. 이들은 빨리빨리 진행하는 것을 선호하기 때문에 개발팀에서 원활한 프로젝트 설계에 필요한 시간을 부족하게 한다. 무엇보다 개발자들이 코드를 작성하고 있지 않으면 "논다"고 생각한다. 미국에서도 이를 표현하는 단어가 있는데, WISCA(Why Isn't Sam Coding Anything?) 과 WIMP(Why Isn't Mary Programming?) 이 있다. 개발팀 쪼는 것은 만국 공통인 것 같다. 아마 한국에서는 가장 흔한 원인일것이다..

 

 저자는 이 매니저들에게 대항하는 방법을 알려주는데, 첫 번째는 명령을 거부하는 것이고(사실상 불가능), 두 번째는 "코딩하는 척" 을 하는것이다.(...) 세 번째는 보스를 설득하는 것이다. 마지막 대안은 다른 직업을 찾는것(...)이다.  그냥 유머글이

 

 저자는 이 중 세 번째 방법 "설득"하는 방법에 대해서 소개한다. 프로그래머가 비개발 직군 매니저들에게 어떤 방식으로 상황을 설명하고 원활히 프로젝트를 준비할 수 있도록 호소할 수 있는지 서술한다. 도움이 안될 것 같아서 적진 않겠지만, 자세한건 책 pdf를 참고하자.

 

• 논리로 설득
• 비유법으로 설득
• 데이터로 설득

2. Determine the Kind of Software You're Working On

 Software Productivity 연구의 총책임자인 Capers Jones 박사는 20년동안 동료들과 연구를 진행하면서, 40가지의 requirements 탐색 방법, 50가지의 SW 설계 방법, 30가지의 SW 테스팅 방법을 700가지의 서로 다른 프로그래밍 언어에서 발견했다.

 프로젝트마다 preparation이나, construction에 적용하는 방법들은 차이가 있겠지만, 아래 표에서 "일반적으로" 진행되는 방법들에 대해 소개한다.

 

Sequential Approach vs. Iterative Approach

 프로젝트 진행방법은 크게 Iterative approach, Sequential approach로 나뉘지만, 완전히 분리되지는 않고 둘 다 영향을 받는다. 어떤 프로젝트 진행이 Sequential 하다는 것은 Requirements 파악 -> Architecture 설계 -> detailed design -> construction -> Test 가 순차적으로 이루어진다는 것을 의미한다. 따라서 프로젝트를 진행할때 Requirements를 진행하고 -> 이후 보완하고 -> 그다음 아키텍처 설계하고 -> 아키텍처 부분 피드백하고 -> ... 이런 식으로 이루어지는 것이다.

Sequential Approach

 반면 Iterative Approach란, 모든 단계를 동시에 진행하면서, 활성화된 피드백이 전 단계에 걸쳐 발생한다는 것을 의미한다. 다음 그림과 같다.

Iterative Approach

 

 그럼 프로젝트마다 어떠한 방식을 '주'로 할지 선택해야할까? 저자는 이를 판단하기 위한 기준들을 제시한다. 먼저 Sequential Approach를 주로 적용해야하는 일은 다음과 같다.

• The requirements are fairly stable.
• The design is straightforward and fairly well understood.
• The development team is familiar with the applications area.
• The project contains little risk.
• Long-term predictability is important.
• The cost of changing requirements, design, and code downstream is likely to be high.

이와 반대로 Iterative Approach를 도입해야 하는 상황은 다음과 같다.

• The requirements are not well understood or you expect them to be unstable for other reasons.
• The design is complex, challenging, or both.
• The development team is unfamiliar with the applications area.
• The project contains a lot of risk.
• Long-term predictability is not important.
• The cost of changing requirements, desing, and code downstream is likely to be low.

 이렇듯 전체 프로젝트에서 Approach를 정하고, 해당하는 Prerequisites를 구비한다면 project를 진행하면서 defect를 해결하기가 쉬워진다. 만약 Prerequisites를 Skip하게 된다면 발생하는 부작용은, Defect가 발견되었을 때 code를 다시 rework하는 비용이 발생한다는 점이다. 만약 Sequential 적용한 후에 Rework하면 그냥 처음부터 다시만들어야한다.

Effect of Skipping Prerequisites on Sequential and Iterative Projects

 반면 Prerequisites를 잘 구비한다면 average defect correction costs가 감소하고, iterative 기법을 적용할 경우 프로젝트의 끝에 defect를 파악하기보다는 중간중간에 파악하고 그때 고칠 수 있으므로 효율이 좋아진다.

Effect of Focusing on Prerequisites on Sequential and Iterative Projects