목적
  • 반복 성공 또는 반복 실패 판별
  • 프로젝트를 수정하거나 프로세스를 개선할 수 있도록 배운 교훈을 캡처
역할:  프로젝트 관리자 
빈도: 반복당 한 번 
단계
입력물:    결과물:   
툴 강좌:   

워크플로우 세부사항:   

워터폴(waterfall) 접근법을 통한 반복적인 접근법의 주요 장점 중 하나는 이러한 반복을 통해 진행상태를 평가하고 위험성을 제한하는 데 자연스러운 이정표를 제공한다는 것입니다. 즉, 진행상태 및 위험도를 계속 평가하여(비공식 평가인 경우) 장애요소로 인해 프로젝트가 실패하지 않도록 해야 합니다.

반복 N 평가 요약.

 

메트릭 수집 페이지 맨 위

목적 프로젝트 상태에 대한 품질 및 진행 정보와 개선사항 수집 

이 단계에는 프로젝트의 평가 계획에 따라 다음 작업이 포함됩니다.

  • 초기 메트릭 수집
  • 메트릭 계산, 확인 및 유효성 검증
  • 상태 평가 보고서에 메트릭 포함

반복 평가 동안에 메트릭을 조사하고 조치를 결정합니다. 이 조치에는 재계획, 재도구화, 훈련, 재구성하거나 측정 계획 다시 수행 등이 포함됩니다. 마찬가지로 사이클 마지막에 "사후 분석 검토"를 수행하여 수집된 메트릭 중 일부가 프로세스 개선 또는 평가용으로 사용될 수 있도록 합니다.

수 주나 수 개월이 걸리는 반복의 경우 메트릭 수집 및 보고 조치는 중간 결과를 캡처하는 주기적인 활동: 상태 평가가 포함되는 지속적인 활동입니다.

반복 결과 평가 페이지 맨 위

목적 반복의 실제 결과와 예상 결과 비교 

각 반복이 끝날 즈음에 핵심 프로젝트 팀은 다음에 중점을 두면서 반복을 평가해야 합니다.

  • 반복이 목표를 성취하는 데 성공적입니까?
    • 위험이 감소 또는 해소되었습니까?
    • 릴리즈가 기능 및 품질 목표를 충족했습니까? 성능 및 용량 목표를 충족했습니까?
  • 프로젝트 및 향후 반복 계획에 대한 변경이 필요합니까?
  • 반복 중에 개발 프로세스 문제점이 있습니까?
  • 현재 릴리즈에서 기준선이 지정된 부분은 어디입니까? 재작업된 부분은 어디입니까?
  • 새 위험이 식별되었습니까?
  • 외부 변경사항이 발생했습니까(시장, 사용자 커뮤니티, 요구사항의 변경)?

반복 계획 중 확립된 평가 기준(기능성, 성능, 용량, 품질 평가)에 따른 반복의 결과를 평가하십시오. 가능한 경우 평가를 수량화하기 위해 평가에 대한 기초로 테스트 활동 및 메트릭 수집 단계에서 발생하는 메트릭을 사용하십시오. 초기화 단계 및 초기 반복에는 질적인 평가가 적절하며 이후의 구현화, 구성 및 전이에는 품질, 성능, 용량 등을 평가하는 특정 테스트 평가를 사용합니다. 반복 중에 수행한 상태 평가에서 캡처된 기타 해결되지 않은 사안 및 프로젝트 관리자의 사안 목록에 있는 기타 사안을 처리하십시오.

모든 위험이 승인 가능한 레벨로 감소되고 모든 기능성이 구현되며 모든 품질 목적이 충족된 경우 제품이 완성됩니다. 전이 단계 종료 시에 제품이 완성되도록 하려면 적절한 계획과 실행이 필수입니다.

외부 변화 고려 페이지 맨 위

목적 프로젝트가 "외부 세계"와 연계되어 있는지 확인 

프로젝트 팀은 내부에만 너무 집중하여 외부의 변화를 간과하기가 쉽습니다. 비즈니스의 핵심 요구사항은 변경, 추가 또는 제거될 수 있습니다. 또는 경쟁자가 유사한 제품을 가지고 시장에 들어와 시장 타이밍 요구사항, 기능 또는 대상 제품 비용에 변경을 유발할 수도 있습니다.

현재 외부 환경을 고려해 볼 때 프로젝트 계획(이정표 포함)이 여전히 유효합니까? 위험성이 변경되어 반복 계획을 재고해야 합니까? 올바른 제품이 빌드되고 있으며 비전이 여전히 유효합니까? 생산 팀이 해당 제품을 제대로 공급하고 있습니까? 외부 환경이 변화되어 프로세스를 변경해야 합니까?

논의된 결과를 사용하여 비전, 위험 목록, 프로젝트 계획, 반복 계획 또는 개발 케이스에 대한 변경 요청(CR)을 생성하십시오.

평가 기준 조사 페이지 맨 위

목적 평가 기준이 현실적인지 확인 

경우에 따라 목표가 너무 높게 설정되어서 반복이 기대치에 미치지 못하는 경우도 있습니다. 목표를 높게 설정하는 것도 중요하지만 공격적인 것과 비현실적인 것은 엄연히 다릅니다. 능력을 증대시킬 수 있는 목표가 동기를 부여해 주기도 하지만 계속해서 능력을 벗어날 경우에는 사기가 저하될 수 있습니다. 프로젝트 팀에서 지나치게 높지 않으면서 도전할 만한 목표를 정하려면 함께 작업해 보고 팀의 한계를 경험해 보아야 하기 때문에 프로젝트 팀 내에서 몇 번의 반복이 필요할 수 있습니다.

평가 기준을 조사하여 목표가 현실적인지 판별하십시오. 때로 반복의 이점은 특정 요구사항이 원래 생각했던 것 만큼 중요한 것은 아니라는 점을 발견하는 것일 수 있습니다. 흔히 최신 기술에 매혹된 열성적인 사용자가 복잡하면서도 가치가 낮은 요구사항으로 강요하여 프로젝트를 손상시키는 경우가 있습니다. 한 번 또는 두 번 반복하여 기대치를 리베이스하고 실질적인 가치를 제공하는 기능에 집중하도록 할 수 있습니다.

반복을 수행하면 특정 기능은 구현하기에 비용이 너무 많이 들거나 유지보수할 수 없는 구조가 작성됩니다. 이 기능에 대한 비즈니스 케이스를 재방문하여 기능이 범위 내에 있는지 확인해야 하며, 경우에 따라 비용상 효율적인 방법으로 요구사항에 접근할 수 있도록 비즈니스 케이스를 수정해야 합니다.

변경 요청(CR) 작성 페이지 맨 위

목적 프로젝트 계획 결과물 갱신 

평가 결과에 따라 비전, 위험 목록, 프로젝트 계획, 반복 계획, 개발 케이스 및 요구사항에 대한 변경 제안서를 작성하십시오.



Rational Unified Process   2003.06.15