소프트웨어 프로젝트 생존전략 4장 :: 생존 기술

계획

소프트웨어 개발에서 성공이란, 세심한 계획에 따른 작은 실수를 통해 계획되지 않은 큰 실수를 얼마나 피할 수 있는 지에 의해 결정된다. 
예를 들어, 네 개의 설계 대안을 준비한 후에 최선의 선택을 했다면 추후에 세 번이나 재코딩 하는 것을 피한 것이다. 

잘 세워진 계획이란

잘 세웠다고 하는 프로젝트 계획은 다음과 같은 특징을 지닌다. 

1. 소프트웨어 개발 계획(Software Development Plan)
: 프로젝트의 추진 방향을 설정. 계획을 문서화 시킴으로써 관계자들이 프로젝트 수행 기간 동안 언제든지 문서 참조
2. 프로젝트 추정(project estimates)
: 예측을 꼼꼼히 하여 프로젝트의 범위를 적절히 선정. 부실한 예측은 프로젝트의 예산, 인력, 일정 등 모든 면을 무리(undercut)하게 만듦
3. 추정치의 개정(revised estimates)
: 추정치를 업데이트하여 프로젝트의 추진 과정을 바로잡음
4. 품질 보증 계획(Quality Assurance Plan) 
: 테크니컬 리뷰와 테스트를 포함한 QAP를 수립하여 악순환 방지
5. 단계별 납품 계획(Staged Delivery Plan)
: 소프트웨어 구축 순서를 포함. 고객의 가치를 극대화 및 프로젝트 리스크 최소화하는 방향으로 수립

계획 체크포인트 리뷰(Planniing Checkpoint Review : PCR)

프로젝트의 성공 여부는 수행 초반기 10퍼센트에서 결정난다.

단계별 예산집행 방식

PM은 프로젝트에 대한 분석 작업을 끝내기도 전에 프로젝트 예산부터 먼저 확보해야 한다. 소프트웨어 업계에 알려진 바에 따르면, 초기 추정치는 약 4배까지 예상이 빗나간다고 한다. 
이럴 때에는 PM이 예산을 요청할 때 2단계로 나눠서 요청하는 방식이 효과적이다. 

1. 프로젝트 탐색 단계: 전체 프로젝트의 10~20퍼센트 정도를 진행 한다. 

2. PCR(Planning Checkpoint Review) 후: 10~20퍼센트를 진행하고, 프로젝트의 진행 여부(go/no go)를 결정한다. 이 때, 프로젝트를 진행시키기로 결정했다면 그때 나머지 부분에 대한 예산을 요청한다. 

PCR 준비

PCR 실시에 필요한 자료들

프로젝트의 주요 의사결정자 명단, 프로젝트 비전 선언문, 업무정의서, 개략 공수(effor)와 일정 목표, 개략 공수와 일정 추정, 10대 리스크 목록, 사용자 인터페이스 스타일 가이드, 상세한 사용자 인터페이스 프로토타입 결과, 사용자 매뉴얼 및 요구 명세서, 소프트웨어 품질 보증 계획(QAP), 상세한 소프트웨어 개발 계획(SDP: software development plan)

위의 자료 없이 PCR을 한다면 프로젝트에 대한 판단할 만한 정보가 없기 때문에 PCR이 의미가 없다. PCR을 위한 자료를 만들어내지 못하고 있다면, 그 프로젝트는 제대로 진행되지 않고 있으며 실패할 가능성이 높다고 생각해도 좋다.

PCR 회의 의제

다음과 같은 사항에 초점을 맞춰 PCR을 실시한다.

• 원래 제품 개념(concept)이 변질되고 있지 않은가?
• 프로젝트 비전에 맞는 제품 개발이 가능한가?
• 최신의 업무 요구가 반영되었으며 그에 따른 비용과 일정 추정도 감안하였는가?
• 프로젝트의 주요 리스크 요인들은 해결 가능한가?
• 상세한 사용자 인터페이스 프로토타입에 대하여 사용자와 개발자 간 합의가 이루어졌는가?
• 사용자 매뉴얼 및 요구 명세서가 향후 개발 작업에 지장이 없도록 완전하고 변동은 없는가?
• SDP는 향후 개발 작업에 지장이 없도록 완전하고 변동은 없는가?
• 프로젝트 예상 비용은 얼마인가?
• 프로젝트 예상 일정은 어떤가?

PCR의 장점

1. 긍정적인 관점에서 프로젝트를 취소할 수 있다.

2. 아무것도 해놓지 않은 상태에서 예산 투자를 요구하는 것보다 10~20퍼센트 진행될 때까지 많은 예산 투자를 보류하는 것이 더 신뢰가 간다. 

3. 예산 투자 전에 10~20퍼센트 정도를 수행하면, 프로젝트의 성공에 결정적인 상류 활동에 더 집중하는 효과가 있다.

리스크 관리

"모든 일이 잘 될 것이라고 생각되더라도 최악의 상태에 대비하라."라는 말을 명심하라.

프로젝트 통제

소프트웨어 프로젝트 통제(control)이 가능해야 한다.
'통제'한다는 것이 몰인정하게 들릴 수도 있다. 이는 팀원을 통제하거나 PM이 전권을 마구 휘두루는 상황을 연상하기 떄문이다.

 

프로젝트의 '통제'를 반대하는 것은
통제되지 않는 프로젝트를 진행하려는 것과 같다.

통제라는 것은 다음의 의미를 뜻한다.

• 소프트웨어 라이프 사이클 모델을 선택하는 것이(ex. 단계별 납품(staged delivery) 모델)
• 꼭 필요한 것은 변경될 수 있도록 요구사항에 대한 변경을 관리하는 것
• 설계와 코드가 서로 일치할 수 있도록 설계 및 코딩 표준을 정하는 것
• 각 개발자가 목표 달성에 기여하도록, 다른 개발자의 과업과 충돌하지 않도록 상세한 계획을 수립하는 것

프로젝트의 가시성(visibility)

소프트웨어 프로젝트에서의 가시성이란 프로젝트의 현황을 정확하게 판단할 수 있는 정도를 말한다. 

가시성을 높이기 위한 방안은 아래와 같다.

• 프로젝트의 비전이나 목표를 설정한다.
• 프로젝트 10퍼센트 수행 후 PCR을 실시하라.
• 계획 대비 실적을 정기적으로 비교하여 계획대로 잘 진행되고 있는지 파악하라.
• 상세한 마일스톤(binary milestones)을 설정하라.
• 정기적으로 릴리스(release)시켜라.
• 프로젝트 각 단계가 완료되면 주요 추정치를 수정하라.

가시성을 좋게 하려면 처음부터 가시성을 높이도록 계획을 수립해야 한다. 

피플웨어(Peopleware)

피플웨어란 '소프트웨어 개발에서 사람의 역할이 중요함을 인정하는 관리 방식'으로 알려져 있다. 이 방식에는 아래의 내용을 포함한다.

• 개발자가 원하는 일을 시켜라 - 업무와 관심사를 일치시켰을 때 개발자는 높은 수준의 동기 부여를 얻는다.
• 개발자들을 진심으로 인정하라 - 일반 사람들도 마찬가지지만 개발자들도 인정받는 걸 좋아한다. 
• 사색할 수 있는 분위기를 만들어라 - 소프트웨어 개발은 끊임없는 발견과 발명이 필요한 작업이다. 
• 나만의 공간을 제공하라 - 개발자 업무는 한 가지 일에 몇시간씩 집중이 필요하다.

사용자 참여

사용자 참여는 요구사항 변경 원인 중 큰 것 하나를 제거할 수 있기 때문에 시간을 절약할 수 있다. 초기에 정확한 소프트웨어를 정의하지 못해서 생겨나는 기능 추가 문제(feature creep)를 해결할 수 있다.

따라서, 추후에 큰 요구 사항 변경을 막기 위해 차용자 참여는 프로젝트 초기에 도입하는 것이 훨씬 효율적이다. 그리고 이것보다 더 중요한 것은 지속적으로 참여해야 한다는 것이다. 단 한번 만에 소프트웨어를 훌륭하게 만들기란 쉽지 않다. 사용자 중심으로 체크 포인트를 설정하면 중간 중간 조금씩 적은 비용으로 시정할 수 있다. 

사용자를 프로젝트에 끝까지 참여시키는 것이
소프트웨어 프로젝트의 핵심 생존 기술이다.

제품의 단순화(minimalism)

소프트웨어 개발은 정신노동이다. 필요없이 복잡하게가 아니라, 최대한 단순하게(as simple as possible) 만들도록 적극 노력해야 한다. 기능 명세서, 설계, 구현 등에 대하여 단순성을 강조해야 한다. 개발자들 대부분이 복잡한 것을 좋아한다. 하지만 프로젝트 성공의 열쇠는 프로젝트를 한층 단순화하는데 있다.

프로젝트의 목표를 달성하기 위한 지름길은 복잡성을 제거하는 것이다. 이렇게 하면 수많은 오류들도 동시에 제거된다.

출시 지향

'Ship-it' 상금 - 소프트웨어는 개발해서 수익을 내는 것이 아니라 출시(shipping)하믕로써 돈을 번다는 사실을 개발자들에게 강조한다. 

이 책에서 강조하고 싶은 하나의 메세지는 소프트웨어 개발이란 원래가 어떤 실질적 목표에 도움을 주는 기능적 활동이라는 것이다. 유능한 개발자들이라면 소프트웨어 프로젝트가 그저 하이테크 장난감을 제공하기 위함이 아니라는 것을 안다. 손익(bottom line)을 생각하지 않는 개발자는 프로젝트에서 도태될 것이고, 이들은 결국 조직에 아무 도움이 되지 않는다.