[IT/리뷰] 소프트웨어 프로젝트 생존전략

[알라딘]소프트웨어 프로젝트 생존 전략 (aladin.co.kr)

[알라딘]소프트웨어 프로젝트 생존 전략

애자일 책인줄 알았는데 애자일 선언(2001년) 보다 훨씬 더 이른 시기에 출간된 책(원서 기준 1997년)이었다.  애자일 조직은 이렇게 일합니다(원서 기준 2019년)』라는 책을 쓴 스티브 맥코넬이 저자였기 때문에 출간시기를 모르고 봤을 때의 내용은 혼란스러웠다.

 

책에서 소개하는 개발 방법론은 애자일의 방법론과는 거리가 멀다. 그렇다고 폭포수의 전형적인 모습은 절대 아니다. 폭포수 방법론보다는 개선된 나선형 또는 프로토타이핑 정도의 방법론과 같은 방법이다. 그런데 희한하게 애자일의 모습과도 꽤나 비슷한 모습이다. 애자일 선언에 참가한 17인에 포함되어있지 않았음에도 1997년에 이런 인사이트가 있다는 게 대단하다 느껴졌다.

 

옛날에 쓰인 책이어도 끝까지 읽은 가장 큰 이유는 회사에서 애자일을 사용하지 않기 때문이다. 그래서 도움이 될만한 내용들이 있을 것이라는 기대로 책을 읽었다. 그리고 다른 분들의 책과 같이 애자일 전에 제시한 이 방법이 현재까지도 도움이 적용될 것이라 믿었기 때문이다.

 

앞서 말했듯이 애자일 선언 전에 출간된 책임에도 애자일의 모습과 비슷했다. 하지만 애자일의 모든 핵심 가치를 포함하지는 않는다. 애자일 전에도 중요시 되던 프로세스가 있기 때문에 그 틀은 유지된다. 틀 안에서 부분마다 애자일이 적용되어 있는 형태와 비슷하다. 예를 들어 스팩과 이력을 남기는 문서를 중요하게 여기지만 과도한 문서화가 모든 것을 해결해주지는 않는다는 것을 말한다.

 

다른 내용들은 아래에 정리했다. 애자일 전에 출간된 책임을 감안했을 때 엄청난 인상을 주었지만, 내용을 정리할 때는 오래된 프로세스에서 제시하고 있는 내용 중 적용할 부분들을 간단하게 정리했다. 아래 정리된 내용들도 출간 연도를 감안하고 이해해야하는 부분도 있을 것이다.

---

대부분 요구된 기능을 좋은 품질로 만족시켰다면 성공이라 생각한다. 하지만 비용이 초과했거나 일정을 지연했다면 성공한 프로젝트라 볼 수 없다. Standish 그룹에서 조사한 바에 따르면 프로젝트의 성공률은 25% 정도이다.

소프트웨어 프로젝트에서 성공하기 위한 첫 걸음은 성공과 실패의 문제가 아닌 생존의 필요성을 인식하는 데 있다. 예를 들어, 계획된 일정과 예산의 10% 오차 내에서 프로젝트를 달성할 수 있을 것인지에 대한 걱정은 둘째 문제다. 해당 프로젝트를 끝낼 수 있는가를 우선 고려해야 한다.

 

이 책에서 소프트웨어 프로세스는 다양한 뜻으로 풀이될 수 있다. 필자가 생각하는 소프트웨어 프로세스의 의미다.

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

 

초반에 프로세스를 수립하지 않고 차후에 시도하게되면 시간만 지연되고 효과적이지 못한 프로세스가 나오게 된다. 초기에 프로세스를 수립하는 것이 중요한 이유다.

• 변경 통제(change control)
  • 프로젝트 도중 매니저나 고객이 직접 다양한 변경 요청을 하는 경우가 있다. 팀원들은 비공식적으로 이행에 동의하지만 이러한 변경 통제가 없을 경우 프로젝트 후반에 업무 범위가 20~25% 늘어날 것이다. 예산과 일정도 마찬가지로 늘어날 것이다.
• 품질 보증(quality assurance)
  • 초반에 결함 제거 프로세스가 없다면 끝없는 테스트-디버깅-재작업-재시험에 빠진다. 후반에 많은 결함은 변경통제위원회(CCB)와 같은 곳에서 결함 정정 우선순위를 정하느라 바쁠 것이고 결함을 안은 채 소프트웨어가 릴리즈 될 가능성이 크다.
• 무분별한 개정(uncontrolled revisions)
  • 후반에 발견된 중대한 결함은 소프트웨어를 재설계하고 다시 코딩하게 할 수도 있다.
• 결함 추적(defect tracking)
  • 후반까지 결함 추적을 수행하지 않게된다. 알고 있는 결함도 잊을 수도 있다.
• 시스템 통함(syhstem integration)
  • 통합을 후반까지 수행하지 않는다면 컴포넌트 간의 인터페이스에 문제가 있어 이에 대한 노력과 시간도 많이 필요할 것이다.
• 자동화된 소스코드 통제(automated source code control)
  • 개정 통제(revision control)도 후반까지는 잘 이뤄지지 않는다. 소스코드가 제대로 관리가 안 될 가능성이 있다.
• 일정 관리(scheduling)
  • 일정이 지연되면 개발자들은 할 일이 많아지게 된다. 개발자들은 일주일에 한 번 이상 가능하면 자주 작업이 얼마나 걸릴지 재추정(reestimate) 해야 한다.

게다가 프로젝트 후반에 갈수록 개발자들이 스스로 데드라인을 지키지 못하면 생존 욕구가 발동한다. '나만의 개발 방식(solo development moe)'으로 돌입해 각 개인 데드라인에만 집중하게 된다. 협조가 무너지기 시작하는 것이다.

 

체계적인 프로세스를 사용하지 않은 경우 손쉬운 전환 방법을 알아보자. 현재 소프트웨어 개발 프로세스를 상세히 정리해보고 실행되지 않는 부분을 찾아서 수정해보자. 프로세스가 없는 것 같아 보이더라도 어떤 종류든 프로세스가 있다. 형편없는 프로세스라서 프로세스가 없다고 느끼는 것이다.

 

불확실성의 고깔(Cone of Uncertainty)이 소프트웨어 프로젝트 추정에서 시사하는 바는 크다. 초기 단계에서 프로젝트를 정확히 추정하는 것은 이론적으로 불가능하다는 것이다. 실행도 해보기 전에 내려진 수많은 결정 사항들이 어떻게 영향을 끼칠지 예측할 수 없다.

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

 

예산을 초과하지 않고 제때 소프트웨어를 납품하기 위해 잘 세워진 계획은 다음과 같은 특징을 갖는다.

• 소프트웨어 개발 계획(Software Development Plan)
  • 프로젝트 추진 방향을 설정해 준다. 계획을 문서화시킴으로써 이해 관계자들이 프로젝트 수행기간 동안 언제든지 문서를 참조할 수 있게 한다.
• 프로젝트 추정(project estimates)
  • 계획의 근거를 제공한다. 꼼꼼한 예측은 프로젝트의 범위와 예산, 인력, 일정 등의 계획도 적절하게 수립할 수 있게 돕는다.
• 추정치의 개정(revised estimates)
  • 주요 단계 마무리에는 프로젝트 추정치 업데이트가 필요하다. 추정 과정을 바로 잡음으로써 안정된 기반에서 프로젝트를 추진할 수 있다.
• 품질 보증 계획(Quality Assurance Plan)
  • 테크니컬 리뷰와 테스트를 포함한다.
• 단계별 납품 계획(Staged Delivery Plan)
  
  • 소프트웨어 구축 순서를 포함해야 한다. 단계별 소프트웨어 솔루션은 고객의 가치를 극대화시켜야 한다.
• 요구사항 개발(requirements development)
  • 프로젝트 팀이 해결해야 할 문제를 상세히 정의하는 것이다. '올바른 문제를 풀기 위한' 계획이다.
• 아키텍처(architecture)
  • 문제를 어떻게 풀 것인가에 대한 첫번째 해답이다. '문제에 대한 올바른 해법을 만들기 위한' 계획이다.
• 상세설계(detailed design)
  • 프로젝트가 만들어 낼 것에 대한 종합 설계다. '올바른 방법으로 올바른 해법을 제시하기 위한' 계획이다.

 

소프트웨어 프로젝트의 예산을 확보할 때 추정치와 실제 예산의 차이를 줄일 수 있는 좋은 접근 방법이 있다. 2단계로 나눠서 요청하는 방식이다. 탐색 단계에 대한 예산을 요청한다. 탐색 단계는 전체 프로젝트의 약 10~20% 정도로, 탐색 단계를 마친 뒤 PCR(Planning Checkpoint Review)을 진행한다. PCR 결과에 따라 프로젝트 진행 여부를 결정하게 된다. 프로젝트를 마저 진행하기로 결정했다면 나머지 부분에 대한 예산을 요청한다.

 

소프트웨어 프로젝트에서 사용자의 참여는 매우 중요하다. 첫째, 성공적 구축은 사용자가 사용하기 좋은 제품을 만들어야 가능하다. 둘째, 사용자들이 좋아하는 소프트웨어를 개발하는 비법은 사용자에게 물어보는 것이기 때문이다. 요구사항부터 프로토타입과 제품에 대한 의견까지 사용자의 의견은 필요하다.

 

성공적인 프로젝트를 달성하기 위한 첫 번째 단계는 지식활동 단계다. 발견, 발명, 구현 세 분야로 나눠서 바라볼 때 프로젝트 초반은 발견에 초점이 맞춰진다. 특히 사용자의 요구사항을 발견하는 과정에 집중한다. 중반부에는 발명에 초점을 맞추게 되고, 아키텍처 설계부터 기능이나 클래스까지 발명한다. 이 단계까지도 불확실한 것을 확실한 것으로 바꾸는 단계다. 프로젝트 후반에는 구현에 집중하게 된다. 불확실성은 현저히 줄어들고 발견과 발명 단계에서 계획한 것을 실현시키는 데 집중한다. 단, 발견, 발명, 구현 세 분야는 맺고 끊기는 것이 아니라 프로젝트 전반에 걸쳐 어느정도씩은 발생하게 된다.

 

앞서 얘기를 해왔듯이 이 책에서의 프로젝트 계획은 단계별 납품 방식을 택한다. 단계별 납품 방식은 계획과 리스크의 최소화를 강조한다. 요구사항 수립과 아키텍처 설계 이후의 구현 단계에서는 상세설계-코딩-디버깅-테스트를 반복한다. 단계별로 릴리즈가 가능한 제품을 만들게 되는데, 이 구현 단계의 반복 횟수는 프로젝트 크기에 따라 다르다.

단계별 납품 방식에도 단점은 있다. 주목할 만한 비용 요소가 있다. 여러 차례 릴리즈에 대한 시간과 비용이 증가한다. 각 단계에서 테스트한 기능을 다시 테스트하기 때문에 회귀 테스트에 대한 시간과 비용도 중복된다. 버전 관리 작업도 만만치 않다. 또한 '단계별 납품 계획 수립' 자체가 부담이다. 물론 일부는 프로젝트 후반에 드러나는 숨은 비용이기 때문에 단계별 납품에 의한 추가 비용이라 할 수 없다.

하지만 단계별 납품 방식의 추가 비용은 프로젝트 상태와 품질에 대한 가시성을 높이고 추정치의 정확도를 향상시켜 리스크를 감소시키는 대가로 결코 비싸지 않다.

 

프로젝트에서 마일스톤마다 산출물 목록을 작성해야 한다. 마일스톤은 프로젝트 진척 상황을 최상위 수준에서 추적한다. 일반적으로 프로젝트 기간이 오래 걸리는 이유는 수많은 산출물 목록만 봐도 알 수 있다. 산출물 각각에도 상당한 작업시간이 필요하다. 하지만 이것도 프로젝트를 효율적으로 수행하기 위한 작업이다. 많은 시간을 쏟는 만큼 비효율적으로 수행하거나 별 볼일 없는 결과를 내놓으면 안 될 것이다.

간단히 살펴만 봐도 기본으로 수행해야 하는 산출물의 양은 어마어마하다.

• 프로젝트 시작 : 의사 결정자 리스트 / 프로젝트 비전 / 비즈니스 계획 / 예상 공수와 일정 / 팀원 / 변경 통제 계획 / 10대 리스크 목록 / 프로젝트 로그
• 프로젝트 착수 및 타당성 분석 : QA 담당자 / 공식 문서(계약서 등) / 고객 측 키맨 / 간단한 UI 프로토타입 / UI 스타일 가이드 / 최종 프로젝트 추정치 / 사전 개발 계획 / 10대 리스크 목록 / 프로젝트 로그
• 개략 요구사항 개발 완료 : 상세 UI 프로토타입 / 사용자 매뉴얼 및 요구 명세서 / QAP / 상세 개발 계획 / 프로젝트 추정치 / 10대 리스크 목록 / 프로젝트 로그
• 상세 요구사항 개발 완료 및 PCR : 개발팀 / QA팀 / 문서 작성자 / 아키텍처 / 통합절차 / 단계별 납품 계획 / 테스트 사례 / 사용자 매뉴얼 및 요구 명세서 / 프로젝트 추정치 / 10대 리스크 목록 / 개발 계획 / 프로젝트 로그
• 아키텍처 완성 및 1단계 코딩 완료 : 개발팀 / QA부서 / 단계 착수 계획 / 상세 설계 문서 / 상세 구축 계획 / 테스트 사례 / 빌드 명령어 / 코딩 / 설치 프로그램 / 사용자 매뉴얼 및 요구 명세서 / 납품 / 프로젝트 추정치 / 10대 리스크 목록 / 프로젝트 로그
• 2단계 코딩 완료 : 상세 설계 문서 / 모든 테스트 사례 / 모든 소스코드 / 모든 빌드 명령 / 설치 프로그램 / 배치 문서, 사용자 교육, 소프트웨어 설치 팀 / 통합 제품 납품 / 프로젝트 추정치 / 10대 리스크 목록 / 프로젝트 로그
• 최종 코딩 완료 : 릴리즈 체크 리스트 / 릴리즈 승인 양식 / 최종 납품 / 설치 프로그램 납품 / 최종 테스트 사례 / 납품 소프트웨어 복사본 / 프로젝트 기록 장치 / 프로젝트 로그 / 프로젝트 이력 문서

 

변경통제는 프로젝트 수행기간 동안 발생하는 주요 변경 사항을 평가, 통제, 승인하고 변경사항이 이해 당사자에게 어떤 영향을 주는 것을 주지시키는 것을 말한다.

최초 개발 작업 동안에는 변경통제가 없다. 최초 개발 작업 완료 이후 변경위원회에서 산출물을 관리한다. 보통 주요 이해 당사자 대표(PM, 마케팅 대표, 개발자 대표, QA 대표, 문서관리 대표, 사용자 대표)로 구성된다. 1~3명으로 구성될 수도 있고 30명이 넘을 수도 있다. 변경위원회의 목표는 모든 주요 사안을 고려하였음을 보장하는 중앙 결제원(clearinghouse) 역할을 하는 것이다.

산출물에 대한 변경은 체계적으로 이루어지게 된다. 변경은 변경제안서(change proposal)을 통해 제안된다. 제안자 입장에서는 문제 제기(question), 변경 내용, 변경에 따른 영향(비용 및 효과)을 제시해야 한다. 변경위원회는 변경의 영향을 받는 당사자를 식별해 검토할 수 있도록 변경제안서를 배포한다. 변경위원회는 각 당사자들의 의견을 종합해 변경 우선순위(수용, 거부, 보류)를 정하게 된다.

 

변경통제의 이점으로는 일을 의도한대로 할 수 있게 된다는 것이 크다. 변경 제안을 체계적으로 하게 되기 때문에 불필요한 변경이 없어진다. 또한, 변경 통제에 당사자를 의사 결정에 참여시킴으로써 의사결정의 질을 높일 수 있다. 변경 결과를 통보함에 따라 프로젝트 진척 상황에 대한 가시성도 높여준다.

즉, 변경통제는 엉성한 마일스톤 관리와의 싸움이다. 변경통제는 책임감을 높여준다. 제안자는 타당성을 입증해야 하며 반대하는 사람들도 반대의 이유를 제시해야 한다. 모든 제시된 의견은 영구기록으로 관리되기 때문에 책임감을 줄 수 있다. 그에 따라 PM은 책임있게 변경통제를 수행할 수 있는 시간을 받을 수 있고, PM은 변경위원회의 결정을 무조건 수용해야 한다.

 

리스크 관리란 소프트웨어 프로젝트의 성공 요소(예산, 일정 등)를 방해하는 것들을 줄이려는 노력을 말한다. 프로젝트 전체 노력 중 5%만 리스크 관리에 투자해 보라. 5% 정도면 프로젝트가 정해진 일정과 예산 내에서 끝낼 확률이 50~75% 정도가 된다. 우수한 조직은 적은 비용으로 큰 리스크를 줄일 방안을 찾아야 한다. 리스크를 줄이는데 투자를 너무 많이해도 투자 대비 효과가 미미하다. 예를 들어 미 국방성 프로젝트는 전통적으로 문서 작업이 너무 많다. 이 경우 효과가 미미하며 예산 대부분을 납기 맞추는 데 사용한다.

이 책의 대부분의 내용은 리스크 관리를 다룬다. 직접적인 리스크 관리부터 리스크 관리를 도울 수 있는 것들도 포함한다. 리스크 관리에 필요한 주요사항은 다음과 같다.

• 소프트웨어 개발 계획에 리스크 관리 계획을 포함한다.
• 리스크 관리 책임자를 임명한다. 이때 PM은 리스크 관리 책임자가 되면 안된다. 독립적인 입장의 테스트 담당자의 역할과 비슷하다.
• 10대 리스크 목록을 지속적으로 관리한다.
• 각 리스크별 세부 관리 계획을 수립한다.
• 리스크 보고에는 익명성을 보장한다.

리스크의 예에는 다음과 같은 것들이 있을 수 있다.

• 조용히 늘어나는(creeping) 요구사항
• 요구사항에 담기거나 개발자들이 만드는 겉치레성 기능
• 비현실적 일정
• 릴리즈 소프트웨어의 낮은 품질
• 불안정한 툴 (신규 툴 사용 등)
• 납기 준수 압박
• 고객과의 마찰
• 비생산적 사무 공간

10대 리스크는 또다시 세부적으로 관리 계획을 수립해야 한다. 1~2 페이지 정도로 육하원칙을 준수해 관리 필요성과 관리 방안에 대해 작성하면 된다.

 

인력 관리에서 중요한 것은 '인간을 중심으로 관리하고 책임지라(people-ware management accountability)'는 것이다. 프로젝트 이후 팀원들의 실력이 향상되든 저하되든 관리자가 책임져야 한다는 것이다. 프로젝트 후반에 개발자 5명이 퇴사한다면 당연히 관리자가 책임을 져야할 것이다. 반대로 팀원들 기술이 향상되고 사기가 진작된다는 경우에는 당연히 관리자가 인정을 받아야 한다.

 

일반적인 요구사항 개발 프로세스에 대해 알아보자. 대화형(interactive) 소프트웨어 개발에 초점을 맞춘 것이며 내장형(embedded) 시스템이라면 적용할 것이 많지는 않을 것이다.

1. 구축하는 소프트웨어를 정의할 수 있는 주요 사용자들(end-user)을 확인한다.
2. 사전(preliminary) 요구사항을 정리해 사용자와 인터뷰를 실시한다.
3. 단순한 UI 프로토타입을 만든다.
4. 주요 사용자들로부터 프로토타입의 피드백을 받는다. 프로토타입의 간결성을 유지한 채 개정해가면서 사용자가 긍정적일 때까지 반복한다.
5. 프로토타입의 시각적(look and feel) 요구사항을 명문화시키는 스타일 가이드를 개발한다.
6. 프로토타입을 확장해 소프트웨어 기능을 보여준다. 시스템을 전체적으로 수평적으로 다루되 수직적으로 깊게 들어가지는 않는다. 아직까지 프로토타입으로써 기능적인 것을 보여주기 위한 것이지 구현한 것을 보여주는 것이 아니다.
7. 확장 완료된 프로토타입을 명세서의 베이스라인으로 취급하고, 소프트웨어를 프로토타입에 맞춰 개발한다. 이때 프로토타입을 실제 소프트웨어의 기초로 사용해서는 안되며 프로토타입은 폐기되어야 한다.
8. 프로토타입에 맞춰 상세 사용자 문서를 작성한다. 이는 상세 소프트웨어 명세서가 될 것이다.
9. UI에 관련되지 않은 요구사항 문서를 만든다. 알고리즘, 타 소프트웨어와 상호작용 등에 대한 내용이 포함된다.

프로토타입이 베이스라인이 되었을 때 개발팀은 프로토타입이 실제 기술적으로 타당(feasible)한지 알 수 없을 수도 있다. 이는 자연스러운 현상으로, 리스크 있는 기능 목록은 별도 문서화를 통해 최종 사용자에게 설명해야 한다. 이렇게 리스크 있는 기능이 하나도 없는 프로젝트는 흔하지 않기 때문에 대부분 추후결정(TBD: To Be Determined) 목록을 유지해야 한다.

프로토타입에 근거한 상세 사용자 문서를 작성하게 되면, 별도의(stand-alone) 기술 명세서를 만들 필요가 사라진다. 게다가 일반적인 기술 명세서보다 최종 사용자가 이해하기 더 쉽다. 덕분에 소프트웨어에 대한 최종 사용자의 피드백 품질도 향상될 수 있다. 즉, 최종 사용자들을 프로젝트에 일찍 참여시키며 기술 문서 작성자(technical writers)가 최종 사용자가 할 수 있는 것보다 사용자들의 관점을 더 세련되게 대변할 수 있다.

 

아키텍처는 시스템 전반적인 내용을 기수랳야 한다. 시스템 개요가 없다면 그려내기 어렵다. 고려한 모든 주요 설계 대안의 상위 레벨의 설명은 물론, 채택 안이 선정된 이유와 채택되지 않은 안의 이유도 포함해야 한다.

아키텍처의 목표는 명확히 기술되어야 한다. 동일한 기능을 갖더라도 수정이 용이한 시스템을 목표로 한 설계와 완벽한 성능이 목표인 시스템 설계는 다르다.

좋은 아키텍처는 어떤 문제에도 대응할 수 있어야 한다. 며칠 몇 주 씨름 후에 나온 아키텍처가 '명쾌하고 이해하기 쉬워야' 한다. Harlan Mills는 이런 아키텍처 품질을 심오한 간결성(deep simplicity)이라 표현한다. 복잡한 아키텍처는 훨씬 못한 아키텍처다.

 

아키텍처는 프로그램의 주요 서브시스템을 정의해야 한다. 서브시스템은 출력 형식, 데이터 저장, 분석, 사용자 입력 등과 같은 기능을 모아놓은 집합체를 말한다. 보통 5~9개의 서브시스템을 갖는데, 서브시스템의 수가 많아질수록 아키텍처에서 시스템을 이해하기 어렵다. 아키텍처는 단순히 다이어그램뿐 아니라 각 서브시스템의 책임과 모듈이나 클래스의 개략적(preliminary) 목록이 제공되어야 한다. 또한 서로 다른 서브시스템 간 의사소통 방법을 기술해야 한다. 서브시스템 간 의사소통을 규정하지 않는다면 하위 시스템은 가능한 모든 방법으로 상호작용하게 되며 복잡성을 높인다.

 

요구사항 베이스라인을 마련한 뒤에야 프로젝트에 필요한 공수, 비용, 일정에 대해 추정이 가능하다. 추정 시 다음과 같은 핵심 원칙을 명심하자.

• 프로젝트를 정확히 추정할 수 있다.
• 정확한 추정에는 시간이 걸린다.
• 정확한 추정은 정량적 방식이 필요한데 주로 소프트웨어 평가 도구를 사용한다.
• 정확한 추정에 필요한 데이터는 조직의 과거 완료했던 프로젝트다.
• 추정은 프로젝트가 진행되어 감에 따라 재조정이 필요하다.

프로젝트 추정시 명백히 대상이 되는 활동은 놓치지 않겠지만, 놓치기 쉬운 활동들을 간과하는 경우가 있다. 명백히 대상이 되는 활동은 아키텍처, 상세 설계, 코딩, 테스트, 문서 작성과 같은 것들이 포함된다. 놓치기 쉬운 활동에는 휴가, 사용자와의 접촉, 시연 일정, 리뷰 일정, 문제 해결 일정, 기술 교육, 변경 제안 및 영향 평가 등이 있다.

 

달성하지 못한 상세 마일스톤이 있다는 것은 프로젝트 전체가 위험하다는 경고이다. 그렇다고 마일스톤을 달성하지 못하는 일이 자주 발생하는 것으로 개발팀에 압력을 하는 것은 해결이 아니라 프로젝트를 악화시키는 방법이다.

마일스톤을 지키기 위해 개발자가 초과근무를 하는 것도 문제다. 개발자의 일정에 여력이 없는 것으로, 다른 사람의 작업보다 과소평가된 작업을 수행하는 것일 수 있다. 개발자의 일정을 재조정해줘야 하는 것이 필요한 것으로 재조정하지 않을 시 전체 프로젝트를 지연시키는 부주의한 결정을 내릴 가능성도 있다.

 

테크니컬 리뷰는 특정 컴포넌트를 설계한 개발자가 설계 이후 리뷰하는 과정이다. 설계자 외에 두세 명 정도의 구성원이 가장 효율적이다.

잠재되어 있는 결함 대부분은 회의 이전 사전 검토 작업에서 발견된다. 그러나 리뷰 없이 사전 검토 작업만 수행하거나 사전 검토 작업 없이 리뷰만 해야 한다면 회의를 취소하고 발견한 내용들을 설계자에게 개별 전달하는 게 더 적절하다.

리뷰의 양은 처음에는 클래스 하나, 몇 개의 루틴, 100라인 정도의 의사 코드가 적절할 것이다. 더 적은 양은 검토자들의 시간을 너무 많이 쪼개는 것이며, 훨씬 많은 양은 검토자에게 부담이 되어 작업의 질이 떨어질 것이다.

 

리뷰 회의에서는 상세설계 컴포넌트 대상으로 세 가지 특성을 검토해야 한다.

1. 정확성(Correctness) : 설계가 의도대로 동작할 것인가
2. 완전성(Completeness) : 설계가 의도한 모든 목적에 부합하는가
3. 이해성(Understandability) : 다른 사람도 설계를 쉽게 이해하는가

설계가 복잡할수록 오류도 늘어난다. 개발 초기 단계에서 오류를 피할 수 있도록 가능한 간단하게 설계해야 한다. 그래야 이해성도 높일 수 있고 이후 작업까지 도움을 줄 수 있다. 보통 유지보수 프로그래머는 프로그램 수정 시간보다 이해에 더 많은 시간을 뺏긴다.

요구사항 추적성에 대해서도 설계를 평가해야 한다. 모든 요구사항을 반영했는지, 요구사항과 무관한 요소가 필요 이상으로 포함되어있지는 않은지 검토해야 한다. 빠진 요구사항이 있는 경우 프로젝트 후반에 시스템 자체를 다시 정비해야 하는 경우도 있다. 요구되지 않은 기능은 프로젝트의 비용과 일정을 늘릴 뿐이다.

 

프로젝트에서 상세설계를 처음 수행하는 단계에서는 특별히 고려할 사항이 있다. 초기 단계에서는 시스템 아키텍처에 대한 유효성이나 리스크를 분석해야 한다.

기술적 위험이 따르는 프로젝트를 진행한다면 1단계에서는 시스템의 수직적 구조에 초점을 맞춰야 한다. 이를 통해 개발팀은 기술을 습득할 수 있고 아키텍처대로 개발 가능한지 검증할 수 있다. 기술적 위험이 크지 않은 프로젝트라면 1단계에서 중요한 모든 인터페이스와 서브시스템들 간의 상호작용을 분석하는 데 초점을 맞춰야 한다. 일반적으로는 1단계 구현에서 80%를 수평적 구조에, 20%를 수직적 구조에 힘쓴다.

개발자는 어려운 부분에 집중해야 한다. 바로 완료할 필요는 없지만 심각한 리스크를 파악하고 리스크에 대처하기 위한 상세 계획을 세울 정도는 되어야 한다.

 

소프트웨어가 거의 완료되기 전에는 시스템 테스트의 계획을 세울 수 없기 때문에 시스템 테스트는 소프트웨어 프로젝트의 핵심 공정(critical-path)이다. 이때 적절한 준비가 없으면 충분히 테스트가 불가능하다.

critical path는 동시 처리 작업 중 가장 오래 걸리는 작업을 뜻하는 것으로, 전체 일정에 직접적으로 영향을 미치는 요소를 말한다.

테스트는 소프트웨어 개발 상태에 맞춰서 진행되어야 한다. 테스트 케이스는 소프트웨어 구현의 직전 시점 또는 구현 시점에 작성되어야 한다. 따라서, 실제 개발 전에는 어떤 소프트웨어가 나올지 모르는 프로젝트는 이런 방법이 불가능하다.

그러나 이 책에서 제시하는 방법을 사용하면 테스트 케이스가 코드 검토 후 바로 준비가 가능하다. 완전한 UI 프로토타입과 상세 사용자 매뉴얼 및 요구 명세서를 테스트 케이스 작성 전에 확보할 수 있기 때문이다. 또, 개발과 함께 테스트를 진행하는 방식이기 때문에 프로젝트가 끝날 때까지 품질 관리를 미루는 프로젝트에 비해 QA 활동이 핵심 공정이 될 가능성이 적다. 이미 UI 프로토타입, 매뉴얼, 요구 명세서, 아키텍처, 상세설계, 코드 등 리뷰를 거쳤고, 개발자 단계에서 단위 테스트와 통합 테스트, 일별 스모크 테스트도 통과된 상황일 것이기 때문이다.

 

개발자는 결함을 즉시 수정해 테스트 팀에서 안정적 빌드를 기다리느라 시간을 낭비하지 않도록 해야 한다. 주별 프로젝트 추적에 미해결 결함의 개수를 포함시켜서 관리해야 한다. 개발자는 이따금 발견된 결함을 바로 수정하기보다는 지금 진행 중인 작업에 방해받지 않으려 할 것이다. 이런 주장을 받아들이지 마라. 개발자의 수정 지연은 자신의 코드 버그 때문에 테스트 담당자나 다른 개발자들의 작업이 비효율적으로 된다는 것을 의미하는 것이다.

 

단계별 납품은 유연한 납품 방식이다. 일반적으로 두 가지 방법으로 단계별 납품 계획을 세운다.

1. 각 단계에 대한 계획을 결정론적으로 세우는 것으로, 가장 중요한 기능은 더 일찍 납품하기 위한 방법
2. 각 단계가 끝날 때 해당 단계의 내용을 다시 정의하는 방식으로, 가장 주요한 기능을 더 일찍 납품도 하면서 단계별 마감 때 진행 과정 수정이 가능한 방법

어떤 방식이든 한 번만 납품하는 프로젝트보다 더 빨리 프로젝트 팀의 경험과 전문성을 높일 수 있다.

 

각 단계별 마감 시점은 계획했던 일정 상의 실적과 프로젝트 실제 실적을 비교해 추정을 재조정하기 좋은 시간이다. 처음 추정에 포함되었던 다양한 요소는 다음과 같은 사항들을 고려해 재검토해야 한다.

• 구현해야 할 기능들이 변경되었는가
• 성능, 견고성, 완성도 등에 대한 요구 수준이 변경되었는가
• 개발팀의 생산성이 예상했던 대로인가
• 이전 추정에서 빠졌던 필수 작업이 있는가

추정 단계에서는 생산성도 확인해야 한다. 총 6개월의 기간 동안 진행되며 첫 납품 기한인 8주인 프로젝트가 있다고 해보자. 첫 납품에서 실제로 10주가 걸렸다면 나머지 프로젝트에 대해 추정을 어떻게 재조정할까? 일반적으로 몇 가지 방법이 있는데 그중 세 가지를 보자.

1. 지연된 2주를 나머지 일정에서 만회할 수 있다고 보고 전체 6개월을 고수
2. 전체 일정에 2주를 더해 6.5개월로 전체 일정 조정
3. 전체 일정에 지연율을 곱해서 조정 (이 경우 25% 지연이기 때문에 7.5개월로 전체 일정 조정)

일반적으로 첫 번째 방법이 사용된다. 사람들은 일반적으로 프로젝트 첫 단계에서 배울 것들이 생각보다 많아서 지연이 발생된거라 생각한다. 이후에는 배웠기 때문에 감당이 가능하다 생각한다.

이건 착각이다. 프로젝트 300개 대상으로 수행된 1991년 연구 보고서에서는 초과된 시간을 만회한 프로젝트는 거의 없었다.

가끔 예외가 있지만 가장 정확한 방법은 셋째 방식이다. 실제 프로젝트의 경험, 실적이 추정에 반영된 것이기 때문이다.

 

NASA에서의 프로젝트 성공을 위해 해야할 일과 성공을 위해 하지 말아야 할 일을 나눠서 적어두고 있다. 하지 마라야 할 일은 다음과 같다.

• 팀 구성원이 체계적이지 않은 방법으로 일하게 놔두지 말라
• 터무니없는 목표를 설정하지 말라
• 미치게 될 영향을 평가해보지 않거나 변경위원회의 승인 없이 수정을 가하지 말라
• 겉치레 작업을 하지 말라
• 특히 프로젝트 초기에 인원을 과다하게 배정하지 말라
• 현 단계에서 지연된 일정을 나주에 복구할 수 있다고 가정하지 말라
• 비용 절감이나 일정 단축을 위한 기준을 느슨하게 하지 말라
• 많은 양의 문서가 성공을 보장한다고 믿지 말라