소프트웨어 프로젝트 생존전략 - [3부]

1부 생존을 위한 사고방식

1장 살아남기 위한 방법
2장 소프트웨어 프로젝트 생존테스트
3장 생존의 개념
4장 생존의 기술

5장 성공적인 프로젝트란?

2부 생존 준비

6장 움직이는 표적 맞추기 – 변경통제(change control)에 대해
7장 사전 계획
8장 요구사항 개발
9장 품질 보증
10장 아키텍처
11장 최종준비

3부 단계에 의한 성공

12장 단계 계획 수립의 시작

단계별 계획을 시작할 때는 해당 단계에서 수행될 작업의 상세한 과정에 대한 단계 시작 시의 계획을 수립한다. 프로젝트 팀은 해당 단계의 상세설계, 코딩, 테크니컬 리뷰, 테스트, 통합 및 기타 작업을 수행하는 방법에 관한 개별 단계 계획을 수립한다. 이때 가장 많은 노력이 필요한 작업은 해당 단계의 프로젝트 진척도를 추적하기 위한 상세 마일스톤 목록을 작성하는 것이다. 이러한 마일스톤을 생성하려면 많은 수고를 해야 하지만, 이를 통해 프로젝트 상태를 쉽게 파악할 수 있고 리스크를 줄일 수 있으므로 그만한 가치가 있다.

단계별 납품 방식은 개발 팀이 프로젝트를 진행하면서 여러 번 소프트웨어를 릴리즈 가능한 상태로 만들게 한다. 이렇게 하는 것이 품질 저하 위협을 줄이고, 상대에 대한 가시성을 높이며, 일정 지연을 예방할 수 있는 방법이다. 따라서 각 단계를 시작할때 계획을 세우면서 열정을 다해야 하는 것 처럼, 이 단계에도 많은 동기 부여가 필요하다.

• 요구사항 업데이트
• 상세설계
• 구축
• 테스트 사례 작성
• 사용자 문서 업데이트
• 테크니컬 리뷰
• 결함 수정
• 기술적 조정 작업
• 리스크 관리
• 프로젝트 추적
• 통합 및 릴리즈
• 단계정리 

   ㅇ Binary Milestone

A BinaryMilestone is a single Yes/No question or True/False statement. The MileStone has been reached when the answer is "Yes" or the statement is true. 

With regard to people who say that they are "almost done" - ask them "Would you rather be almost alive, or almost dead?" In project management "almost" should be a synonym for not.

마일스톤(Milestones)은 프로젝트에서 주요한 이벤트를 표시하는 기준점이며, 프로젝트의 진척을 관찰하기 위해 사용합니다. 프로젝트의 최종 목표점이나 완성을 의미하는 것은 아니며, 프로젝트가 진행되는 동안 달성되어야 하는 특정한 목표라고 이해하면 될 것 같습니다. 마일스톤은 프로젝트의 기간에 영향을 주지는 않습니다. 그러나 대신, 마일스톤은 꼭 달성해야만 하는 주요한 목표가 성공에 도달하도록 촛점을 맞춥니다.  마일스톤은 고대 로마 시대에 기원이 있습니다. 아우구스투스 황제 시설 로마의 길목에 1마일마다 돌을 세워 표시했다고 합니다. 아일 스톤을 세운 이유는 몇가지기 있습니다. 예를 들어, 여행자들로 하여금 그들이 로마의 길에 있다는 것을 인지하게 하고, 두 지점간 평균적인 거리 감각을 갖게 하기 위해서였다고 합니다.

ㅇ상세 마일스톤의 정의 범위

상세 마일스톤을 정의할때 프로젝트 팀은 다음 작업에 대한 과정을 계획한다. 그 계획은 오직 현재 상황에서 알 수 있는 범위 내에서만 상세하다.프로젝트 팀은 각 단계에서 상세 마일스톤을 두 차례 생성한다.

• 상세설계를 통해 달성해야 하는 마일스톤 목록을 정의해야 한다.
• 상세설계가 완료되면, 해당 단계를 종료할 때 소프트웨어 릴리스를 통해 달성해야 하는 둘째 마일스톤을 정의해야 한다. 

ㅇ단계 계획과 관리 방식

소극적 방식: 소극적 방식이라 프로젝트에 대한 사람들의 작업이나 프로젝트 자체에 간섭하지 않은 것을 의미한다. 

• 프로젝트 자체에 대해 간섭하지 않는 것은 프로젝트를 실패로 이끄는 방법이다. 소극적 관리 방식을 사용하면 50~200배나 많은 비용이 프로젝트에 잠재하는 것을 허용하게 된다. 
• 중대한 리스크가 효율적으로 수정하기에는 너무 늦게 발결될 수 있다.
• 적극적 관리를 체계적으로 실천하면 소프트웨어 프로젝트를 효과적으로 관리할 수 있다. 이런 적극적 관리 방법에 해당하는 것이 바로 상세 마일스톤 방식을 포함하는 신중한 단계별 계획이다.

 

13장 상세설계

각 단계에서 상세설계는 아키텍처 설계를 확장하는 것으로, 아키텍처 설계와 동일한 주제를 다루지만 이들을 보다 상세하게 처리하는 것이다. 얼마나 상세하게 설계할지는 해당 프로젝트 규모와 개발자의 기술수준(expertise)에 따라 다르다. 상세설계를 리뷰하면 프로젝트의 품질과 비용 측면에서 상당한 교과를 얻을 수 있다. 프로젝트 제1단계에 대한 상세설계는 아키텍처의 품질을 검증하는 것과 같은 특수한 작업이 필요할 때도 있다.

14장 구축

15장 시스템 테스트

16장 소프트웨어 릴리스

각 단계를 종료할 때마다 소프트웨어를 릴리스 가능한 상태로 만들어 두는 것이 통합 실패나 품질 저하 리스크를 관리하는 필수적인 방법이다. 소프트웨어가 릴리스할 만한 상태인지를 직관적으로 결정하기는 어렵다. 그러나 다행이도 몇 가지 간단한 통계적 기법을 사용하면 이런 결정에 도움을 받을 수 있다. 릴리스 단계는 상당히 분주한 시간이며, 릴리스 체크리스트를 활용하면 여러 문제를 피할 수 있다.

17장 단계 마감

우리는 각 단계의 마감을, 진행 과정을 수정하고 해당 단계로부터 경험적 지식을 얻기 위한 기회로 삼을 수 있다. 프로젝트가 진행될수록 보다 정확한 추정 작업을 할 수 있으며, 이 추정은 다음 단계 시작을 위한 계획 수립 시 탄탄한 기초를 제공한다. 프로젝트를 진행하면서 얻은 현재까지의 모든 경험은 이후 프로젝트에서 활용할 수 있도록 소프트웨어 프로젝트 로그에 기록해야 한다.

4부 임무 완료

18장 프로젝트 이력(history)
19장 서바이벌 안내서