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