2006년 4월 24일 월요일

소프트웨어 프로젝트 생존 전략 (Software Project Survival Guide)

소프트웨어 프로젝트 생존 전략 (Software Project Survival Guide)
스티브 맥코넬 지음, 김덕규 외 옮김, 인사이트

근래 읽었던 책 가운데 가장 재미없었던 책이다. 그런데도 반복해서 4번을 통독했다.
지금 나에게 직접적인 도움을 주지 않는, 코드 한 줄 없는 책이지만, 왠지, 어쩐지, 꼭 체화해야할 내용인 것 같아서 지루해도 참 고 읽었다.

실제로 이 책은 소프트웨어 프로젝트 매니저를 위해 쓰여졌다. 중간 규모의 프로젝트가 중단되지 않고 끝까지 생존 할 수 있도 록, 그리고 성공적으로 제품을 출시할 수 있도록 구체적인 가이드를 제시한다.

이 책의 근간을 이루는 중심 단어는 체계적인 프로세스, 추정, 통제, 단계별 릴리즈이다. 체계적인 프로세스, 추정, 통제는 저자 의 다른 책에서도 핵심적으로 다루는 주제이다. 프로젝트를 매 단계별로 상세히 계획하고, 철저히 프로세스에 의하여 관리하며 모든 활동을 정해진 양식에 기록하여 생존을 위해 위험을 통제해야 한다는 것이다.

소스 코드 통합 절차를 예로 들면, 개발자가 코드를 개발한 다음 단위 테스트를 실시하여 모든 예외나 오류를 포함혀 꼼꼼히 코 드라인을 살핀 후, 개인적으로 복사해 둔 메인 빌드에 통합하여 테크니컬 리뷰를 실시한다. 그리고 이 코드를 테스터에게 넘겨 주어 테스트를 수행하도록 하고, 테스트 수행 중 일어난 문제를 수정하고 수정된 내용을 리뷰한다. 그리고 최종 코드를 메인 빌 드에 통합한 후, 프로젝트 활동 목록의 해당 항목에 '완료'로 체크한다.

보통의 소프트웨어 프로젝트는 요구사항 분석 후 바로 설계와 코딩으로 들어가지만 이런 프로젝트가 기일에 맞춰 제대로 동작 하는 소프트웨어를 제작할 확률은 매우 낮다. 내 경험에서도 거의 항상 납기 기일에서 얼마 정도는 버퍼로 두고 완료일을 당겨 놓고 밤샘 작업을 해도 납기일을 맞춘 적이 거의 없다. 이제는 소프트웨어 제품의 고객들도 어떤 제품의 출시 예정일을 신뢰하 지 않는 것이 당연한 것처럼 여겨지기도 한다.

저자는 성공적인 프로젝트를 위해서는 프로젝트 상류에 해당하는 작업, 예를 들면, 프로젝트 계획, 요구사항 개발, 아키텍쳐 및 상세 설계 등에 많은 시간과 자원을 투자해야 한다고 주장한다.

몇몇 전문가들은 "프로젝트의 성공 여부는 수행 초반기 10퍼센트에서 결정난다"고 보고하였다. 프로젝트 초기에 프로젝트 탐 색 단계를 종료한 후 PCR(Planning Checkpoint Review)을 실시하게 되는 데 이 때 필요한 자료만 해도,
- 프로젝트 주요 의사결정자 명단
- 프로젝트 비전 선언문
- 업무정의서
- 개략 공수(effort)와 일정 목표
- 개략 공수와 일정 추정
- 10대 리스크 목록
- 사용자 인터페이스 스타일 가이드
- 상세한 사용자 인터페이스 프로토타입 결과
- 사용자 매뉴얼 및 요구 명세서
- 소프트웨어 품질 보증 계획(Quality Assurance Plan)
- 상세한 소프트웨어 개발 계획(SDP : Software Development Plan)
와 같다. 저자는 위와 같은 자료가 없이 PCR을 한다면 아무런 의미가 없다고 말한다. 이 외에도 수많은 상세 단계와 각 단계별 산출물(주로 문서)들이 존재하여 자칫 너무 관료적이라는 느낌마저 준다.

이런 절차가 개발자에게 무거운 짐을 지우고 창의성을 해치지는 않을까 걱정이 되지만 저자는 통계와 여러가지 경험적 사실을 바탕으로 오히려 반대로 제대로된 저차가 개발자의 사기를 북돋아 주고 더 좋은 결과를 가져올 수 있다고 주장한다. 저자가 실 력있는 개발자였기 때문에 그 주장을 신뢰하지 않을 수 없다.

나 또한 주먹구구식 시스템에서 많은 시행착오를 경험하고 있기 때문에, 작성해야 할 너무도 많은 문서와 따라야할 너무도 많 은 절차가 있음에도 불구하고 스티브 맥커넬의 주장에 동의하지 않을 수 없다.

댓글 없음:

댓글 쓰기