가이드라인: 반복 계획
주제
초기에 가장 높은 위험은 주로 비즈니스 위험이나 기술 위험입니다. 초기의 가장 주요한 비즈니스 위험은 주로
프로젝트 자금을 확보하는 것입니다. 따라서 개념 증명의 프로토타입은 주로 초기 단계의 결과입니다. 개념 증명의 프로토타입에서
주요 기능이나 일부 필수 기술을 시연합니다.
신제품의 초기는 대개 가장 어렵습니다. 소프트웨어를 제작하는 것 외에 초기에
달성해야 할 여러 가지 새로운 국면이 있습니다(예: 프로세스 가동, 팀 구축, 새로운 도메인
파악, 새로운 툴에 익숙해지기 등). 구체화할 수 있는 구조의 양에 대한 기대나
달성할 수 있는 유용한 기능의 정도에 대한 기대에 신중하십시오. 너무 높게 목표를 정하면 첫 번째
반복 완료가 지연되고, 반복의 총 수가 줄어들고, 따라서 반복적인 방법의 장점이 줄어들 수
있습니다. 첫 번째 반복에서는 구조를 올바로 준비하는 데 초점을 맞추어야 합니다. 따라서 초기 반복을
계획하는 과정에 소프트웨어 아키텍트를 포함시켜야 합니다.
구현화의 경우, 반복에서는 안정적인 구조 정의, 시스템의 기본적인 작동을 설계 및 구현, 일련의
구조 프로토타입을 통해 기술적인 구조 문제점을 탐색하는 데 초점을 맞춥니다.
"구조적으로 중요한" 시나리오는 시스템의 구조를 정의한 방법으로 시행하는 하위 플로우입니다.
구현이 완료될 무렵 구축 및 전이 중에 반복 프로세스를 추진하기 위한 변경 요청(소프트웨어 변경 요청 또는
SCO라고도 함)이 시작됩니다. 다음은 SCO의 결과입니다.
- 개선사항 요청
- 범위가 개별 패키지나 클래스를 벗어난 변경 요청
- 반복 범위 및 목적의 변경
- 요구사항 기준선 변경을 제안하는 요구사항이나 승인된 변경사항을 요구사항 기준선에 수용하는
요구사항의 변경사항.
기존 프로젝트 계획, 반복 계획 및 기존 위험 목록에 대해 이 SCO를 확인합니다. SCO로 인해
요구사항 우선순위를 다시 평가하거나 위험의 우선순위가 재지정될 수 있습니다. 그러나 프로젝트
제어가 손실되지 않도록 SCO를 신중하게 관리해야 합니다.
구축 및 전이 중에는 구조를 구체화하고 나머지 모든 요구사항을 구현하는 데 초점을
맞춥니다.
전체 시스템을 한 번에 고려하는 워터폴 모델과는 달리 각 반복에 있는 시스템의 일부
기능만 고려합니다.
각 반복 중에 전체 시스템의 서브세트를 분석, 설계 및 구현합니다. 서브세트의 존재와
탐색 정도를 선택하는 것이 후속 반복의 위험을 줄이는 데 중요합니다. 두 개의 기본적인
전략(WS 및 ND)이 있습니다.
WS(wide and shallow) 전략에서는 전체 문제점 도메인을 분석하지만 표면적인 세부사항만 고려합니다. 모든 유스 케이스가
정의되지만 현재 문제점을 명확하게 파악하기 위해 대부분은 매우 자세하게 구체화됩니다. 구조는 개괄적으로 정의되고
구조 컴포넌트에서 제공하는 주요 메커니즘과 서비스도 정의됩니다. 서브시스템의 인터페이스가 정의되지만
중요한 위험이나 불확실성을 관리해야 할 경우에만 해당하는 내부 세부사항을 설명합니다. 대부분의 반복이
발생하는 구축 시점까지 거의 구현되지 않습니다.
다음과 같은 경우 WS 전략이 적절합니다.
- 팀이 문제점 도메인이나 기술 영역(방법 또는 프로세스 포함)에 경험이 없을 경우.
- 앞으로의 성능에 있어서 안전한 구조가 주요 요구사항이고 구조가 전에 없던 구조일 경우.
그러나 이 전략에는 다음과 같은 잠재적인 일부 함정이 있습니다.
- 팀이 분석 마비상태(설계가 완벽하지 않으면 아무 것도 구현할 수 없다는 비논리적인 생각)에
빠질 수 있습니다.
- 확실성과 신뢰성을 구축하려면 주로 조기 결과가 필요합니다. 프로젝트 팀이 실행 가능한 것을
만들지 못하는 기간이 길 수록 자신의 능력에 대한 신뢰도가 떨어질 것입니다.
- 실제 기술 위험을 파악하기 위한 충분한 기술적인 세부사항과 구조의 위험이 노출되지
않습니다.
ND(narrow and deep) 전략에서는 문제점 도메인의 일부분을 철저하게 분석합니다. 이 좁은 부분에 관련된
유스 케이스가 정의되고 매우 자세하게 구체화되어 현재 문제점을 명확하게 파악합니다. 이 바람직한 작동을 지원하는 데
필요한 구조가 정의되고 시스템이 설계 및 구현됩니다. 후속 반복에서는 다른 수직 부분을 분석, 설계 및 구현하는 데
초점을 맞춥니다.
다음과 같은 경우 ND 전략이 적절합니다.
- 주요한 위험을 극복하고, 지원을 획득하며, 실행 가능성을 증명하기 위해 조기 결과를
시연해야 할 경우.
- 요구사항이 끊임없이 발전하여 상세한 설계 및 구현 작업을 시작하기 전에 모든 요구사항을
완벽하게 정의하는 것이 어려울 경우.
- 개발의 조기 시작이 성공적인 납품의 열쇠이기 때문에 최종 기한이 필수적일 경우.
- 더 높은 수준의 이익이 되는 납품이 가능하도록 높은 수준의 재사용이 가능한 경우.
그러나 결점이 없는 전략은 없습니다.
- 모든 반복에서 수직적으로 통합되지만 수평적으로 호환 불가능한 소프트웨어를
개발하려는 경향이 있습니다. 이를 때로 난로 연통 신드롬이라고 하고 시스템을
통합하기가 어렵게 합니다.
- 완전히 새로운 문제점 도메인의 시스템이나 전례가 없는 구조를 기준으로 시스템을
개발하는 데는 적합하지 않습니다. 균형이 맞는 구조를 달성하려면 시스템 기능의 대부분을
샘플링해야하기 때문입니다.
일반적으로 초기 반복에서는 WD 전략을 선호하지만, 후기 반복(안정된 구조가 개발된 경우)에서는
ND 전략을 따르는 경향이 있습니다.
대개 첫 번째 반복이 가장 어렵습니다. 전체 개발 환경이 필요하고 프로젝트 팀이 제 자리에 있어야 하기
때문입니다. 툴 통합과 팀 구축 문제점이 최초 반복의 복잡도에 추가됩니다. 구조 문제점에 초점을 맞추면
초점을 유지하면서 팀이 세부사항에 너무 빨리 빠져드는 것을 방지할 수 있습니다.
- 초기에서 사용한 ND 전략
프로젝트의 기본적인 실행 가능성에 새로운 기술의 개발이 필수적인 경우. 대부분의 e-business
프로젝트에서는 일반적으로 수행하는 것보다 더 깊이 새로운 기술을 탐색해야 합니다. 개념 증명의 프로토타입은
"낭비"로 간주되고 프로젝트 개념의 실행 가능성만 탐색합니다.
- 초기에 사용한 WS 전략
시스템 범위를 파악하고, 구조에서 원하는 기능을
제공할 수 있도록 시스템 기능의 넓이를 샘플링하기 위해 이 전략을 수행합니다.
- 구현에서 사용된 WS 전략
이 방법을 사용하면 주소 관련 기술 위험에 선택적인
ND 전략에 초점을 맞추고 건전한 구조를 개발할 수 있습니다. 구축시, 견고한 구조를 설정하면
일련의 통합된 증분으로 기능을 개발 및 제공할 수 있는 ND 전략으로 포커스를 되돌릴 수
있습니다.
- 구축시 사용된 ND 전략
구축 반복은 항상 팀이 동시에 필수 기능을 개발 및 제공하는 ND 전략을 사용합니다.
새로운 팀은 대개 처음에는 자신이 완성할 수 있는 것에 대해 몹시 낙관적입니다. 이에 대항하고
실제 결과에 낙관적인 기대치가 부족할 경우 발생하는 잠재적인 사기상의 문제점을 피하기 위해
첫 번째 반복에서 달성할 수 있는 기능의 양에 신중하십시오. 성취 및 프로젝트 추진력에 대한 감각을
만들면서 경험을 구축해보십시오.
개발 환경이나 방법이 팀에게 새로운 것일 경우 첫 번째 반복의 기능을 최소로 줄이십시오. 환경 통합 및 조정과
툴에 익숙해지는 것에 초점을 맞춘 다음 후속 반복에서 기능 내용에 질주하십시오.
어느 정도까지 재작업은 좋습니다. 반복적인 개발의 주요 장점 중 하나가 실수와 실험을 허용하는 것이지만
정정 조치를 취할 수 있을 만큼 조기일 경우입니다. 그러나 특정한 기술 직원들은 하나의 반복과 다음 반복 간의
완성까지 재작업을 하려는 경향이 있습니다.
각 반복이 끝날 때 반복 평가 중에 팀은 현재 릴리스의 어떤 부분을 재작업할 것인지 결정해야
합니다. 전체 시스템과 비교하여 다음 백분율로 단계에 할당된 재작업을 예상해보십시오.
- 초기, 40%-100% - 선전용의 입문적인 프로토타입을 개발할 수 있습니다.
- 구현, 초기 반복의 경우 25%-60%; 후기 반복의 경우 25% 미만, 또는 전개 주기의 경우.
- 구축, 구조 기준선 후, 반복마다 10% 이하 및 총 25%
- 전이, 5% 미만.
재작업은 피할수 없습니다. 재작업의 필요성이 보이지 않더라도 의심해보아야 합니다. 다음과 같은 이유 때문입니다.
- 과도한 압력의 스케줄.
- 실제 테스트 또는 평가의 부족.
- 동기 부여나 포커스의 부족.
- 잘못되거나, 자원 장비이거나, 불완전이나 실패의 인정이라는 재작업에 대한 부정적인 인식.
재작업을 너무 많이 하는 것은 위험합니다. 요구사항 변경이 허용 가능한 수준이 아닐 경우
그럴 수 있습니다. 일부 재작업의 필요성을 평가하기 위해 비즈니스 사례를 수행해야 합니다. 반복 관리에 대한 시간표적인 접근 방법 때문에 이전 반복의 범위를 벗어난 작업은 '재작업' 범주에
포함시키지 않습니다. 프로젝트 관리자는 이렇게 범위를 벗어난 작업을 다음 반복의 내용을 정의하는
기능 풀에 포함시켜야 합니다. 이러한 작업은 보통 높은 우선순위를 갖습니다. 프로젝트 관리자는 계획한
목표를 달성하기 위해 이전 반복의 실패에 대한 이유를 발견하여 신중하게 고려해야 합니다.
예를 들어, 스케줄에 맞추기 위한 노력으로 임의로 직원을 추가할 것을 권고하지 않지만, 각 반복마다
야심만만한 계획을 반복적으로 작성하면서 직원이 부족한 채로 만성적으로 프로젝트를 실행하는 것은
합리적이지 않습니다. 그러면 대개 팀 사기가 떨어지고 고객의 불만을 야기할 것입니다. 올바른 균형을
찾아야 합니다. COCOMO II([BOE00] 참조) 같은 평가 모델이 이를 도와줄 수
있을 것입니다. 각 반복에서 프로젝트는 생산성과 품질의 달성 역사를 구축합니다. 다음 반복을 계획 중인
프로젝트 관리자에 대한 강력한 표지는 이전 반복에서 달성한 내용입니다.
최초 반복 계획이 완료되면 팀 리드는 프로젝트 관리자와 함께 활동 레벨에서 이를 작업 계획으로
재조정할 수 있습니다. 포함된 활동 레벨의 Microsoft® Project
Templates에서 이 방법을 보여줍니다. 이 작업 계획을 반복 계획에서 도출하지만 결과물과는
독자적으로 별도로 작성되지 않습니다. 프로젝트 관리자가 제어할 경우 작업 계획을 프로젝트 관리자의
반복 계획 상태로 전개할 수 있습니다.
|