소프트웨어 프로젝트 생존전략 3장 :: 생존의 개념

2장은 체크리스트로 이루어져있어서 스킵~!
이번 장을 통해 소프트웨어 개발을 성공시키는 데 결정적인 요소들이 무엇인지 알아보자!

'프로세스'의 힘

필자가 생각하는 '소프트웨어 프로세스'의 의미는 아래와 같다.

- 모든 요구사항에 대하여 문서화를 보장하는 것
- 요구사항에 대한 추가와 변경을 통제하기 위하여 체계적(systematic)인 절차(process)를 적요하는 것
- 모든 요구사항, 설계, 소스코드를 체계적으로 테크니컬 리뷰(technical review)하는 것
- 테스트 계획, 리뷰 계획, 결함 추적 계획 등을 포함하는 체계적인 품질 보증 계획(QAP)을 수립하는 것
- 소프트웨어의 컴포넌트(functional component)를 개발하고 통합하는 순서가 명시된 구현 계획을 수립하는 것
- 자동화된 도구로 소스코드를 관리하는 것
- 마일스톤이 달성될 때마다 비용과 일정 추정을 재검토하는 것

프로세스에 대한 부정적 시각

소프트웨어를 개발하는 사람들 가운데 일부는 '프로세스'라는 단어를 아주 싫어한다. 이들은 '소프트웨어 프로세스'를 융통성이 없고 제한적이며 비효율적이라고 본다. 이런 사람들은 어느 정도의 시행착오(thrashing)나 비생산적인 일이 발생해도 이상하게 여기지 않는다. 또 개발자들의 실수도 있을 수 있는 일이라고 생각한다. 프로세스를 추가하는 것이 순전히 부담만 줄뿐이고 생산적인 일을 할 시간을 잡아먹을 것이라 생각한다. 

프로젝트에 적용할 프로세스에 대해 무심한 경우 프로젝트 후반으로 갈수록 소프트웨어 기능 확장은 엄두도 못 낸다. 온종일 회의하고 에러를 수정하느라 시간을 다 써버리기 때문이다. 이쯤되면 개발자들은 프로젝트가 실패하고 있음을 알아차리고, 데드라인을 지키지 못하게 되면 생존 욕구가 발동한다. 이제 '나만의 개발 방식(solo development mode)'로 돌입하여 각각 개인의 데드라인에만 집중하게 된다. 

프로세스 살리기

프로젝트 시작 처음에는 프로세스를 중시한 팀(process-oriented team)이 프로세스를 중시하지 않은 팀에 비해 생산성이 떨어지는 것처럼 보인다. 하지만, 프로세스 중반에 들어서면 일찌감치 프로세스에 집중했던 팀은 프로젝트 초기보다 시행착오가 많이 감소되고, 프로세스도 많이 간소화시켰을 것이다. 프로젝트 종료 단계가 되면 프로세스 중시 팀은 작은 시행착오가 있긴 하지만 활기차게 운영될 것이다. 프로젝트가 종료된 후 결과를 보면 프로세스를 중시한 팀이 프로젝트 전반에 걸쳐 훨씬 적은 노력을 들였음을 알 수 있다. 

 

프로젝트 초기에 프로세스에 투자하면
후반에 많은 혜택을 가져온다.

 

개발 프로세스를 향상시키는 데에 중점을 둔 조직들은 수년동안 제품 출시 시기(time-to-market)를 1/2로 줄였다. 비용은 3배, 결함은 10배로 감소시켰다. 

프로세스 대 창의성과 사기(morale)

체계적인 프로세스를 수립하고자 할 대 가장 흔한 반대 이유는 프로그래머의 창의성을 제한할 것이라는 우려다. 프로그래머들에 있어 창의적이라는 것은 매우 중요하나, 그에 반해 관리자와 프로젝트 스폰서에게 있어서 프로젝트는 예측 가능해야 한다. 하지만, 프로세스를 중시하는 회사들은 효율적인 프로세스가 창의성과 사기에 도움이 된다는 사실을 알게 되었다. 

프로그래머는 자신들이 가장 생산적일 때 최고의 기분을 느낀다. 훌륭한 프로젝트 리더는 명확한 비전을 확립해야 한다. 그런 후에 잘 짜인 프로세스를 집행하여 프로그래머들이 굉장히 생산적이라고 느낄 수 있도록 해야 한다. 프로그래머들은 조직적이지 못한 리더를 싫어한다. 조직적이지 못하면 프로그래머들이 서로 엇갈리는 목적을 향해 작업을 하게 된다. 프로그래머들은 예측성, 가시성, 통제 등을 강조하는 식견 있는 리더를 높이 평가한다. 

체계적인 프로세스로의 전환

정교하지 못한 프로세스는 일반적으로 다음과 같은 형태를 띤다.
1. 개발할 소프트웨어에 대해 협의한다.
2. 코딩을 한다.
3. 결함을 찾기 위한 테스트를 실시한다.
4. 결함의 근본 원인을 찾아 디버그한다.
5. 결함을 해결한다. 
6. 프로세스가 아직 끝나지 않았다면 1번부터 반복 수행한다. 

이제 이 책을 통해 더욱 세련되고 효율적인 소프트웨어 프로세스를 다뤄보자!

상류와 하류 효과

소프트웨어 개발자로부터 소프트웨어 프로젝트의 '상류(upstream)'와 '하류(downstream)' 에 대해 자주 듣게 될 것이다.
'상류'라는 단어는 요구사항 분석, 아키텍처 같은 프로젝트 전반 부분을 가리키고, '하류'는 구축과 시스템 테스트 같은 프로젝트 후반 부분을 가리키는 것이다. 전문가들이 조사한 바에 의하면, 프로젝트 상류에서 저지른 오류를 프로젝트 하류에서 정정할 경우 많은 비용이 소모된다고 한다. 예를 들어 요구사항이나 아키텍처의 오류 등은 발생 당시 정정한 경우에 비해 약 50~200배 이상의 비용이 소요된다는 것이다.

한 문장으로 된 요구사항을 요구사항 단계에서 정정할 수 있는 기회가 생긴다면, 결함이 생긴 바로 그 단계에서 결함을 발견하고 수정하는 것을 의미한다.

훌륭한 프로젝트 팀은 요구사항과 아키텍처를
주의 깊게 검토하여 상류 쪽 문제를
정정할 수 있는 기회를 스스로 만들어 낸다. 

 

불확실성 고깔(Cone of Uncertainty)

소프트웨어 개발은 지속적인 정제(refinemet) 과정이라고 말할 수 있다. 크게 쪼갠 후에 다시 그것을 작게 쪼갠다. 거시적 차원에서 결정을 내리고 다시 세세한 결정을 내린다. 한 단계(stage)에서 내린 결정이 다음 결정에 영향을 주기 마련이다. 프로젝트 팀은 대부분 거시적 단계(large-grain level)에서 가능한 한 최선의 결정을 내리지만, 가끔은 세밀한 단계(fine-grain level)에서 미처 예상하지 못했던 문제가 일어나 광범위하게 영향을 미치기도 한다. 그렇게 되면 하고 있던 작업을 취소하고 결국 프로젝트 팀이 루틴, 모듈, 서브시스템 등을 재설계해야 한다는 것을 의미한다. 

따라서, 프로젝트 팀은 다음 단계에서 어떤 일이 필요한지 집작해보고 숙지하기도 전에, 이전 단계에서 모든 것을 생각하고 결정내려야 한다는 것이다.

프로젝트 추정이 의미하는 것

불확실성의 고깔이 소프트웨어 프로젝트 추정에 대하여 시사하는 바는 크다. 즉, 초기 단계에서는 프로젝트를 정확히 추정하는게 어려울 뿐 아니라, 이론적으로도 불가능하다는 것이다. 이를 위해서 프로젝트 일정이나 예산 목표에 맞추기 위해 의사결정 방식을 통제해야 한다. 여러분은 목표한 기능을 매정하게 잘라버릴 준비가 되어 있는가? 그렇다면 여러분은 프로젝트 초반에 확실한 일정과 예산 계획을 세울 수 있따. 이렇게 되기 위해서는 초기에 프로젝트 목표를 아주 명확하고 혼란스럽지 않게 수립해야 한다. 또한 제품에 대한 개념을 매우 유연하게 유지해야 한다. 그리고 프로젝트 전반에 걸쳐 개발 작업을 적극적으로 추적하여 관리하고 통제해야 한다. 

프로젝트 초반에는 '비용 및 일정 목표가 확실' 하던가
아니면 '요구사항이 확실'하던가 둘 중의 하나다. 
이 두 가지 모두 확실한 경우는 없다.