 |
이 타스크는 프로젝트 정보와 관련된 반복 평가 결과를 평가하고 해당 변경사항을 결정하는 방법을 설명합니다. |
|
목적
이 타스크의 목적은 다음과 같습니다.
-
반복 성공 또는 실패 판별
-
프로젝트를 수정하거나 프로세스를 개선하기 위해 교훈 캡처
|
관계
역할 | 기본:
| 추가:
| 지원:
|
입력 | 필수:
| 선택사항:
| 외부:
|
출력 |
|
기본 설명
폭포식 접근 방식을 통한 반복 접근 방식의 주요 이점 중 하나는 반복이 진행상태 및 바운딩 위험성에 대한 자연스런 이정표를 제공하는 것입니다. 반복 내에서 진행상태 및 위험성을 지속적으로
평가하여(비공식적으로라도) 어려움으로 인해 프로젝트가 좌초되지 않도록 해야 합니다.
|
단계
메트릭 수집
목적
|
상태 및 개선을 위해 프로젝트에 관한 품질 및 진행상태 정보 수집
|
이 단계는 프로젝트의 측정 계획에 따라 다음 작업을 수반합니다.
-
기본 메트릭 수집
-
메트릭 계산, 확인 및 유효성 검증
-
상태 평가 보고서에 메트릭 포함
반복 평가 중에 메트릭을 점검하고 조치를 결정합니다. 여기에는 측정 계획 재확인을 비롯하여 재계획, 재정비, 훈련, 재구성 등이 포함될 수 있습니다. 마찬가지로 주기 끝에 "사후 검토"는 수집된 일부 메트릭을
이용하여 프로세스를 개선하거나 예상 목적으로 사용할 수 있음을 확인할 수 있습니다. 메트릭에 대한 자세한 정보는 중간 산출물 가이드라인: 메트릭을
참조하십시오.
몇 주 또는 심지어 몇 개월간 계속되는 반복의 경우, 메트릭 수집 및 보고는 지속적인 타스크이며 중간 결과를 캡처하는 주기적인 중간
산출물: 상태 평가가 이루어집니다.
|
반복 결과 평가
각 반복이 끝날 즈음 코어 프로젝트 팀은 다음에 초점을 맞추고 반복을 평가하기 위해 만남을 가져야 합니다.
-
반복이 목적 달성에 성공적이었습니까?
-
위험성이 줄어들거나 제거되었습니까?
-
릴리스가 기능 및 품질 목표를 충족시켰습니까? 성능 및 용량 목표는 어떻습니까?
-
프로젝트 변경사항 및 향후 반복 계획이 필요합니까?
-
중간 산출물: 개발 조직 평가에서 캡처된 찾은 결과가 반복 중 변경사항에 의해 무효화되었습니까(프로젝트의 개발 프로세스와 같은 기타 중간 산출물에 대한 변경이 필요하기 때문에)?
-
반복 중 프로젝트의 개발 프로세스에 어려움이 있었습니까?
-
현재 릴리스의 어떤 부분이 기준선이 됩니까? 재작업이 되었습니까?
-
새로운 위험성이 식별되었습니까?
-
외부 변경이 발생했습니까(시장, 사용자 커뮤니티 또는 요구사항의 변경)?
반복 계획에 대해 마련된 평가 기준(기능성, 성능, 용량, 품질 척도)에 따라 반복 결과를 평가하십시오. 테스트 타스크로 인한 메트릭과 메트릭 수집 단계를
평가의 기초로 사용하여(사용 가능한 경우) 평가를 수량화하십시오. 정성적 척도는 도입/인식(Inception) 및 초기 반복에 적합하며 나중에 정제(Elaboration), 구현/구축(Construction) 및
전이(Transition)는 특정 테스트 품질에 의존하여 품질, 성능, 용량 등을 평가해야 합니다. 반복 중 수행된 상태 평가에서 캡처된 해결되지 않은 기타 문제 및 프로젝트 관리자의 문제 목록에 있는 기타 문제를
처리하십시오.
모든 위험성이 허용 가능한 수준으로 줄어든 경우, 모든 기능성이 구현되고 모든 품질 목표가 충족되며 제품이 완성됩니다. 전이(Transition) 단계 끝에 이렇게 되려면 우수한 계획과 실행이 필수입니다.
|
외부 변경 고려
목적
|
프로젝트와 "외부 세계"와의 연결성 확보
|
프로젝트 팀이 너무 내부에만 초점을 맞춘 탓에 프로젝트 팀 외부 세상의 변화를 모르기 쉽습니다. 비즈니스는 변화할 수 있으며, 주요 요구사항이 추가, 변경 또는 제거될 수 있습니다. 또는 경쟁업체가 유사한 제품을
갖고 시장에 진입하여 시장 타이밍 요구사항, 기능 또는 대상 제품 비용이 변경될 수 있습니다.
외부 환경의 현재 상태를 고려할 때 프로젝트 계획(이정표 포함)이 여전히 유효합니까? 위험성이 변경되어 반복 계획을 다시 고려해야 합니까? 올바른 제품이 빌드되고 있으며, 비전이 여전히 유효합니까? 제품 팀이 해당
제품을 제공합니까? 외부 환경의 변화로 인해 프로세스 변경이 필요합니까?
이런 논의의 결과를 사용하여 비전, 위험성 목록, 소프트웨어 개발 계획, 반복 계획 또는
프로젝트의 개발 프로세스에 대한 변경 요청을 생성하십시오.
|
평가 기준 점검
목표를 너무 높게 설정한 탓에 반복이 기대에 못미치는 경우가 있습니다. 목표를 높게 설정하는 것이 중요하지만 적극적인 것과 비현실적인 것을 구별하기 힘든 경우가 있습니다. 프로젝트 팀은 자신의 능력을 펼칠 수 있는
목표로 인해 동기부여가 되지만 계속해서 목표에 도달할 수 없는 경우에는 사기가 저하됩니다. 프로젝트 팀이 압도당하지 않고 도전의식을 갖도록 목표를 정의할 경우 팀이 함께 작업하여 한계를 인식하게 되면서 그 자체로
약간의 반복을 거치게 됩니다.
평가 기준을 점검하여 현실적인지 여부를 판별하십시오. 때때로 반복의 이점은 특정 요구사항이 원래 생각이 그 자체로서 가지고 있던 가치만큼 중요하지는 않음을 밝혀내는 데 있습니다. 최신 기술에 사로잡혀 지나치게
열심인 사용자가 부과하는 복잡하지만 가치가 낮은 요구사항으로 인해 프로젝트가 붕괴되는 경우가 종종 있습니다. 한 번 또는 두 번의 반복으로 기대를 재설정하고 실제 가치를 제공하는 기능성에 초점을 맞출 수 있게
됩니다.
때때로 반복은 특정 기능이 구현하기에 너무 비용이 많이 들거나 유지할 수 없는 아키텍처를 작성한다는 사실을 밝혀냅니다. 이 기능에 대한 비즈니스 사례를 재확인하여 기능이 여전히 범위 내에 있어야 하는지 또는
개정하여 비용 효율적인 방법으로 요구사항을 충족시킬 수 있도록 해야 하는지 여부를 알아야 합니다.
|
변경 요청 작성
|
특성
다중 발생 |  |
이벤트로 구동됨 |  |
진행 중임 |  |
선택사항 |  |
계획됨 |  |
반복 가능함 |  |
자세한 정보
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|