가이드라인: Wide-Band 델파이 기술을 사용한 노력 평가
Software Development Magazine의 허가를 받아 Karl Wiegers가 RUP에
기고한 내용(www.processimpact.com)입니다. Rational Software Corporation에서 추가 편집했습니다.
주제
소개
이 가이드라인에서는 소프트웨어 개발 노력을 평가하는 데 사용할 수 있는 기술을 설명합니다. 광대역 델파이
평가 방법은 다음과 같이 요약할 수 있습니다.
- 전문가 팀을 선정하고 각자에게 평가할 문제점을 설명합니다.
- 타스크 목록에 문제점을 세분화하는 것을 포함하여 노력의 평가(흔히 익명)와 각 타스크에
대한 노력의 평가를 제공하도록 각 전문가에게 요청합니다.
- 그러면 전문가들은 합의점에 이를 때까지 자신들의 평가 내용을 반복적으로 수정하면서 공동 작업을 수행합니다.
광대역 델파이 방법을 사용하면 하나의 개별 평가 내용을 확보하는 것 이상으로 여러 가지 장점이
제공됩니다. 첫 번째, 각 참여자가 타스크에 대해 생각하기 때문에 완전한 타스크 목록을 작성하거나
주요 활동에 대해 작업 분해 구조를 작성하는 데 도움을 줍니다. 합의 접근법은 자칭 전문가, 경험이 없는 평가자
또는 회의 안건 또는 다양한 목적을 숨겨온 영향력이 있는 개인이 작성한 평가 내용에서 편견을 제거하는 데
도움을 줍니다. 사람들은 일반적으로 다른 사람이 작성한 평가 내용보다 자신이
작성한 평가 내용에 집착하게 됩니다. 평가 활동에서 어떤 참여자도 "정답"을 알지 못하며
여러 평가 내용을 작성하다 보면 이러한 불확실성을 인정할 수 밖에 없습니다. 결국 델파이 접근법의 사용자는
복잡한 활동에서 반복의 가치를 인정하게 됩니다.
광대역 델파이 적용
광대역 델파이는 무엇이든 가상적으로 평가하는 데 사용할 수 있는데, 즉, 특정 서브 시스템 구현에
필요한 근무 개월 수, 전체 제품에서 코드 행 또는 클래스의 수, 빌 게이츠의 집을 다시 장식하는 데
필요한 페인트의 갤론 수 또는 Capapility Maturity Model의 레벨 2를 수행할 특정 조직의 선택 노력 등이
있습니다.
델파이 방법은 상세한 작업 분해 구조를 개발하는 데 도움을 주며, 이 구조는 또한 상향식 노력과 스케줄
또는 크기 평가를 위한 기초를 제공합니다. 델파이 세션의 출발점은 비전 문서, 평가 중인 문제점 또는 초기
상위 레벨 구조 설명에 대한 세부 요구사항 스펙 또는 프로젝트 스케줄이 될 수 있습니다. 결과물은 자세한
프로젝트 활동 목록, 연관된 품질, 프로세스 관련 및 오버헤드 활동 목록, 평가 가정, 그리고 일련의 활동 및 전체
프로젝트 평가서입니다. 참여자마다 하나씩 작성합니다.
그림 1은 광대역 델파이 세션에 대한 프로세스 플로우를 설명합니다. 계획 중에 평가할 문제점을 정의하고
참여자를 선정합니다. 착수 회의에서는
모든 평가자들이 문제점에 집중합니다. 그러면 각 참여자는 자신의
초기 활동 목록 및 평가서를 개별적으로 작성합니다. 참여자는 이 항목을 평가 회의에 상정하여 회의 중에
여러 번의 평가 주기를 거쳐 포괄적인 활동 목록과 수정된 일련의 평가서를 작성합니다. 중재자 또는
프로젝트 관리자는 구분된 평가 정보를 오프라인에서 취합하고 팀에서 평가 결과를 검토합니다. 사전 결정된
몇 가지 퇴출 기준이 충족되면 세션이 완료됩니다. 결과로 나타나는 평가 범위는 어떠한 단일 평가서보다
향후에 대한 현실적인 예측 자료가 될 수 있습니다. 이제 다음 프로세스의 각 단계를 살펴보겠습니다.
광대역 델파이 세션을 계획할 때 문제점을 정의하고 참여자를 선정합니다. 착수 회의에서는
모든 평가자들이 문제점에 집중합니다. 그러면 각 참여자는 초기 활동 목록 및 평가서를 개별적으로 작성합니다. 평가
회의 중에 여러 번의 주기를 거쳐 포괄적인 활동 목록과 수정된 일련의 평가서를 작성합니다. 오프라인으로 정보를
취합하고 팀에서 평가 결과를 검토합니다. 사전 결정된 퇴출 기준이 충족되면 세션이 완료됩니다.
계획 
광대역 델파이 세션은 문제점인 비전, 유스 케이스 모델, 기존 시스템 및 예비 구조를 정의하고
범위를 지정하는 것에서 시작합니다. 큰 문제점은 여러 팀에서 정확하게 평가할 수 있도록 관리 가능한
부분으로 세분화하는 것입니다. 평가 활동을 시작한 사람은 신뢰할 수 있고 정보에 근거한 평가서를 작성할 만큼
충분한 정보를 참여자에게 제공하도록 문제점 스펙을 취합합니다.
평가 참여자에는 활동을 계획하고 조정하는 중재자, 프로젝트 관리자 및 두 명에서 네 명의
기타 평가자가 포함됩니다. 중재자는 평가자로 참여할 만큼 충분한 정보를 가지고 있어야 하지만
자신의 편견이나 식견으로 인해 결과를 왜곡하지 않는 공정한 진행자로서의 역할을 수행해야
합니다. 참여자는 문제점 또는 프로젝트 및 관련 평가 문제를 이해하기 때문에 선정된 것입니다.
착수 
최대 한 시간 가량 진행되는 초기 착수 회의에서 모든 참여자는 평가 문제점을 신속하게 처리합니다. 중재자는
광대역 델파이에 익숙하지 않은 팀 구성원에게 해당 내용을 설명하고 다른 평가자에게는 문제점 스펙 및 가정
또는 프로젝트 제한조건을 제공합니다. 중재자는 평가자 자신의 평가에 부당하게 영향을 주지 않고 작업을 문제 없이
수행할 수 있도록 충분한 정보를 평가자에게 제공합니다.
팀에서는 평가 목적을 검토하고 문제점과 평가 문제를 논의합니다. 참여자는 주, 근무 시간, 달러 또는 코드 행과
같은 사용할 평가 단위에 대해 합의합니다. 중재자가 모든 팀 구성원들이 평가 활동에 기여할 정도로 충분히 지식을
갖추었다고 결론을 내리면 그룹이 활동할 준비를 시작합니다. 그렇지 않으면 참여자는 자신이 평가하는 문제점에
대해 완벽하게 브리핑을 받아야 하거나 정확한 평가서를 작성할 수 있는 다른 사람에게 자리를 내줘야 하는
경우도 발생합니다.
광대역 델파이 세션을 진행할 준비가 되어 있는지 여부를 판별하려면 입력 기준(후속
프로세스 단계를 진행할 수 있도록 충족되어야 하는 전제 조건)을 확인하십시오. 실제 평가를 진행하기
전에 다음 조건이 충족되는지 확인하십시오.
- 적합한 팀 구성원들이 선정되었는지 확인합니다.
- 착수 회의가 개최되었는지 확인합니다.
- 참여자가 평가 목표 및 단위에 합의했는지 확인합니다.
- 프로젝트 관리자가 세션에 참여할 수 있는지 확인합니다.
- 평가자가 효과적으로 참여하는 데 필요한 정보를 보유하는지 확인합니다.
개별 준비
특정 프로젝트를 완료하는 데 필요한 작업량의 총계(일반적으로 근무 시간으로 표현됨)을 평가하려 한다고
가정해 보겠습니다. 평가 프로세스는 모든 참여자가 그림 2에 표시된 것과 같은 양식을 사용하여 확인된
프로젝트 목표를 달성하기 위해 완료해야 할 초기 타스크 목록을 각각 개발하는 것부터 시작합니다. 그러면
각 참여자는 각 타스크에 소요될 노력을 평가합니다. 정확하게 평가할 수 있는 정도의 작은 활동으로 각 타스크를
세분화하십시오. 일부 사람들은 모든 참여자 활동 목록을 하나의 합성 목록으로 병합해야 하므로 활동을
명백하게 기술하십시오. 초기 전체 평가 내용을 생성하기 위해 각 프로젝트 타스크에
대한 평가 내용을 협의한 단위로 종합하십시오.
평가 프로세스는 모든 참여자가 각각 이 양식을 사용하여 확인된 프로젝트 목표를
달성하기 위해 완료해야 할 초기 타스크 목록을 개발하는 것부터 시작합니다.
해당 평가 내용은 프로젝트 관리자 또는 기타 스테이크홀더가 듣고자 하는 응답과
아무런 관계가 없어야 합니다. 허용 가능한 프로젝트의 스케줄 범위, 노력 또는 비용 범위를 넘어 평가가 이루어지는
좋은 기회가 있으며 이를 통해 협상을 요구하고 범위 축소, 스케줄 연장 또는 자원 조정을 유도할 수 있는
상황이 존재하게 됩니다. 그러나 프로젝트가 진행되는 방법에 가장 적합한 계획이 외부 압력에도 변동이
없어야 합니다.
프로젝트 타스크를 식별하는 것 외에 관련 또는 지원 활동에 대한 타스크를 별도로
기록하십시오. 첫 번째 주기에서 관리, 형상 관리 및 프로세스 관련 활동을 다루는 타스크가 나열된
목록을 반드시 작성해야 합니다. 테스트 또는 검사 활동에 이어지는 재작업 활동도 반드시
포함시키십시오. 결함을 정정하는 재작업은 실제로 발생할 수 있는 파트이므로 재작업에 대한 계획도
반드시 수립해야 합니다. 스케줄을 평가할 경우, 계획에 반영해야할 프로젝트에 특정하지 않은 오버헤드
활동을 생각해 보십시오. 여기에는 회의, 휴가, 교육훈련, 기타 프로젝트 할당과 하루 정도 소요될 수 있는
수많은 잡무가 포함됩니다.
근본적으로 다른 가정으로 인해 다양한 평가서가 작성될 수 있기 때문에 평가서를 작성하는 동안 가정한
내용은 모두 기록하십시오. 예를 들어, 특정 컴포넌트 라이브러리를 구매한다고 가정하거나 이전 프로젝트의
컴포넌트 라이브러리를 재사용한다고 가정했다면 이러한 내용도 기록하십시오. 다른 평가자는 프로젝트에서
이 라이브러리를 개발한다고 가정할 수 있는데, 이는 두 가지 전체 평가 내용 사이에 불일치를 유발하게 됩니다.
다음 평가 가이드라인을 염두해 두십시오.
- 한 사람(사용자)이 모든 타스크를 수행하는 것으로 가정하십시오.
- 모든 타스크가 순차적으로 수행될 것이라 가정하십시오. 이 때 후속 및 선행 타스크는 염려하지 마십시오.
- 각 타스크에 부단한 노력을 기울일 수 있다고 가정하십시오. (이는 매우 낙관적일 수 있지만 평가
프로세스를 단순화시켜 줍니다.)
- 달력 시간 단위로 타스크 사이에 발생할 것으로 예상하는 알려진 대기 시간을 목록으로
작성하십시오. 이렇게 하면 추후에 노력 평가서를 스케줄 평가서로 전환하는 데 도움이 됩니다.
평가 회의
중재자는 참여자의 개별 평가서를 수집하여 그림 3과 같은 도표를 작성함으로써 평가 회의를 시작합니다.
각 참여자의 전체 프로젝트 평가서는 "Round 1" 행에 X로 표시됩니다. 각 평가자는 자신의
초기 값이 스펙트럼을 따라 적합한 위치에 놓이는 것을 볼 수 있습니다. 초기 평가서는 매우 큰 범위를 다루게 됩니다. 수집한 다양한 결론으로 인해 참여자 중 한 사람에게 이 사람이 작성한 평가서에 대해
질문하고 해당 평가서가 프로젝트를 계획하는 데 사용된다고 상상해 보십시오.
중재자는 참여자의 개별 평가서를 수집하여 도표화하는 것으로 평가 회의를 시작합니다. 각 참여자의
전체 프로젝트 평가서는 "Round 1" 행에 X로 표시됩니다. 초기 평가서는 매우 큰 범위를 다루게 됩니다.
일부 조직에서 중재자는 각 평가서의 작성자를 식별하지 않습니다. 이러한 익명성이 델파이 기술에서
중요한 특성이기 때문입니다. 익명성은 솔직하게 의견을 밝히는 동료 참여자로 인해 기타 참여자가 자신의
의견을 제대로 밝히지 못하는 상황을 방지해 줍니다. 팀 구성원은 자신의 분석 내용과 다른 결론이 도출될 때
가장 지명도가 높은 참여자의 판단에 맡기는 경향이 거의 없다는 의미이기도 합니다. 그러나 이것이 필수적인
사항은 아닙니다.
각 평가자는 수립한 가정을 식별하고 평가서의 작성자가 자신이라고 밝히지 않은 상태로 질문 또는 문제를
제기하면서 관련되는 초기 타스크 목록을 읽습니다. 각 참여자는 수행해야 할 다양한 타스크를 나열한 목록을
작성합니다. 이 개별 타스크 목록들을 결합하면 다른 단일 평가자가 작성한 것보다는 완벽한 목록이
됩니다. 이러한 접근법은 수 십개의 개별 타스크에도 해당됩니다. 이보다 타스크가 더 많으면
상세하게 작성될 수 있습니다. 문제점을 여러 가지 하위 문제점으로 세분화하여 개별적으로 평가할 수 있습니다.
이런 초기 토론 중에 팀 구성원은 문제점에 관하여 자신들의 가정, 평가 문제 및 질문에 관하여 대화를
나누기도 합니다. 따라서 이 팀은 공유된 일련의 가정과 공통 타스크 목록을 다루는 것부터
시작합니다. 다음에 유사한 프로젝트를 평가해야할 경우 출발점으로 사용할 이 최종 타스크 목록을 보유하십시오.
이 초기 논의 후 모든 참여자들은 회의실에서 자신의 평가 내용을 동시에(그리고 조용하게) 수정합니다. 논의 중에
공유된 정보에 따라 자신의 타스크 목록을 수정할 수 있고 타스크 범위 또는 변경된 가정에 대해 새롭게 파악한 내용에 따라
개별 타스크 평가를 조정하게 됩니다. 모든 평가자는 해당 양식에 새 타스크를 추가하고 초기 타스크 평가서의 변경 예정
내용을 메모할 수 있습니다. 모든 타스크에 대한 실제 변경사항은 해당 참여자의 전체 프로젝트 평가서의
변경사항과 일치합니다.
중재자는
수정된 전체 평가서를 수집하여 동일 도표의 "Round 2" 행에 플롯합니다. 쉽게 볼 수
있도록 화이트보드에 차트를 만들었습니다. 그림 4에서 설명하는 바와 같이 두 번째 라운드에서는 Round 1 값의 평균보다
더 큰 평균을 가지므로 이 평균을 중심으로 평가의 분포가 좁아지게 됩니다. 라운드를 추가할 수록
분포는 좁아집니다. 타스크 목록 수정 주기, 문제 및 가정 논의, 그리고 새로운 평가서 작성은
다음의 경우까지 지속됩니다.
- 네 개 라운드를 완료할 때까지
- 평가가 수용 가능한 좁은 범위(사전 정의된)로 수렴될 때까지
- 할당된 평가 회의 시간(일반적으로 두 시간)이 종료될 때까지, 또는
- 모든 참여자가 마지막으로 자신의 평가서를 변경할 때까지
초기 평가서를 논의한 후 모든 참여자는 해당 평가서를 수정합니다. 중재자는
수정된 전체 평가서를 수집하여 동일 도표의 "Round 2" 행에 플롯합니다. 이후 라운드에서는 Round 1 값의 평균보다
더 큰 평균을 가지므로 이 평균을 중심으로 평가의 분포가 좁아지게 됩니다.
중재자는 그룹을 계속 트랙하며 끊임 없이 공전되는 상황을 방지하도록 15 또는 20분 토론을 실시합니다. 중재자는
정시에 시작해서 끝내는 것과 같이 효율적으로 회의를 진행하고 모든 참여자가 회의 전념하도록 격려하고 공평하고
비판단적인 환경을 유지해야 합니다. 개별 평가서의 익명성을 유지하는 것이 처음 두 번 라운드에서는 중요한 반면
팀 구성원은 테이블에 모든 카드를 올려 놓고 공개 토론을 통해 결론에 도달할 수 있도록 몇 가지 사항에서 동의할
수 있습니다. 여기에서 자신의 평가서에 의해 실질적으로 변화될 수 있는 타스크를 논의해 볼 수 있습니다. 그렇지
않으면 중재자는 세션이 완료될 때까지 최종 평가서를 작성한 개인을 식별하지 않아야 합니다.
타스크 취합

평가 회의에서 결론이 내려진다 해도 작업이 완료된 것은 아닙니다. 중재자나 프로젝트 관리자 중에서 한사람이
프로젝트 타스크 및 개별 평가서를 하나의 마스터 타스크 목록으로 취합합니다. 이 사람은 또한 가정, 품질 및
프로세스 관련 활동, 오버헤드 타스크 및 대기 시간에 대한 개별 목록을 병합하기도 합니다.
병합 프로세스에서 중복 타스크를 제거하고 개별 타스크에 대해 몇 가지 합리적인 다양한 평가의 해결책에
도달해야 합니다. "합리적"이란 팀의 평가서를 프로젝트 관리자가 선호하는 가치로 대체한다는
의미는 아닙니다. 외형적으로 유사한 타스크에서 나타나는 상당한 평가 내용의 차이는 평가자가 해당 활동을
다양한 방법으로 해석했음을 나타내는 것입니다. 예를 들어, 두 사람이 모두 "클래스 구현"이라는
활동을 할 수 있습니다. 그러나 한 평가자가 타스크에 단위 테스트 및 코드 검토를 포함시킬 수 있는 반면
다른 평가자는 코딩 노력만 생각하고 있습니다. 모든 평가자는 이 병합 단계 중에 혼란을 최소화 하도록
해당 활동을 분명하게 정의해야 합니다. 병합 단계에서 각 타스크에 대한 평가 범위를 보유해야 하지만
한 평가자의 타스크 평가서가 다른 평가자의 타스크 평가서와 상당히 다른 경우 이를 파악한 후 폐기하거나
수정하십시오.
검토 결과

최종 단계에서 평가 팀은 요약된 결과를 검토하고 최종 결과물에 대한 합의점에 도달합니다. 프로젝트 관리자는
기타 평가자에게 전체 타스크 목록, 개별 평가서, 누적된 평가서, 가정 목록 및 기타 정보를 제공합니다. 팀의 평가
활동을 마감하기 위해 30 - 60분의 검토 회의를 진행하십시오. 이 회의는 또한 팀이 광대역 델파이 프로세스의
실행을 심사숙고하고 추후 적용을 위해 개선될 수 있는 방법을 제안하는 기회를 제공합니다.
참여자는 최종 타스크 목록이 가능한 완벽하게 작성되었는지 확인해야 합니다. 평가 회의 이후 추가 타스크를
생각해 볼 수 있습니다. 이제 이 파트도 타스크 목록에 추가할 수 있습니다. 상당히 다양하게 개별적으로 평가된
타스크가 적합한 방법으로 병합되었는지 확인하십시오. 최종 목표는 프로젝트 관리자 및 기타 핵심 스테이크홀더가
수용 가능한 신뢰 레벨에서 프로젝트 계획 및 실행을 진행할 수 있는 평가 범위를 만들어내는 것입니다.
평가 완료

완료를 선언하고 일상적인 작업을 계속 진행할 수 있는 시점에서 지정된 종료 기준이 충족될 때
평가 프로세스가 완료됩니다. 일반적인 광대역 델파이 종료 기준은 다음과 같습니다.
전체 타스크 목록이 취합되어 있습니다.
가정을 평가하는 요약 목록이 있습니다.
평가자는 개별 평가서가 수용 가능한 범위의 단일 세트로 병합되는 방법에 대해 합의점에 도달했습니다.
이제 데이터를 가지고 수행할 작업을 결정해야 합니다. 여러 개의 최종 평가서를 평균하여 단일 평가서로
만들 수 있는데, 이는 평가서를 요청한 사람이 원하는 것이기도 합니다. 그러나 단순한 평균이 너무 낮을
가능성이 있으므로 평가서 범위를 보유하는 데 이점이 있습니다. 평가서는 향후에 대한 예측이며 해당 범위는
수정 구슬을 응시하는 것과 같은 고유의 불확실성을 반영합니다. 세 가지 수치인 계획된 경우로서 평가의
평균, 최상의 경우로서 최소 값 및 최악의 경우로서 최대 값을 제시할 수 있습니다. 또는 정상적인
예상 결과로서 평균 값, +(최대 값 - 평균 값) 및 -(평균 값 - 최소 값)을 제시할 수 있습니다.
각 평가 내용에는 실현 가능성이 있는 확률이 있으므로 일련의 평가가 확률 분포를 형성합니다. Discipline for Software Engeineering(Addison-Wesley, 1995)의 6장에서 Watts Humphrey는 상한 및 하한 예측 간격이 있는 전체 평가를 생성하기
위해 복수 평가와 해당 불확실성을 결합하는 정밀한 수학적 방법을 설명합니다. 다른 정교한 접근법은 최종 평가 값에
따라 가능한 평가 결과의 확률 분포를 생성하는 Monte Carlo 시뮬레이션을 수행하는 것입니다.
델파이 세션의 결과가 유력자가 필요로 하는 것이 아니지만 이 유력자는 10 퍼센트 신뢰 레벨에서 프로젝트를 계획할지
아니면 90 퍼센트 신뢰 레벨 또는 10 - 90 퍼센트 사이의 어느 한 레벨에서 계획할지 판별할 수 있습니다. 실질적인
프로젝트 결과를 해당 평가와 비교하여 향후 평가의 정확성을 개선하십시오.
다시 수행(반복)
이 방법에서 한 가지 훌륭한 특성은 초기 평가 후와 예를 들어 시작하는 중에 대략적인 평가를 수행한 후
각 단계(또는 각각의 반복 시점)에서 평가 내용을 개선할 수 있다는 것입니다. 평가자가 동일하고 이전 평가
주기 중에 위치하던 곳에서 시작하는 경우 프로세스가 더 빨라질 수 있습니다. 문제점에 대한 자세한 정보를
사용할 수 있고 일부 가정은 수정되었으며 노력을 세분화하는 데 도움을 주는 데 적합한 구조가 정립됩니다.
새 평가서의 범위가 좁아질 수 있지만 이전 평가서의 범위 내에 반드시 있을 필요는 없습니다. 더 높아질 수도 있고
더 작아질 수도 있습니다. 더 높아질 경우 프로젝트 관리자에게 전달되는 분명한 위험 신호가 있는데,
이는 한 번에 처리해야 하는 위험입니다.
평가된 광대역 델파이

완벽한 평가 방법은 존재할 수 없습니다. 완벽하다고 해도 평가가 아닌 예측에 불과합니다. 그러나 광대역 델파이 기술은
충실한 평가 원칙을 포함하고 있습니다. 팀 접근법에서 여러 전문가의 Perspective를 결합하는 가치를 인식할 수 있습니다. 작성된
평가서의 범위는 평가 프로세스에 고유한 변화성을 반영합니다.
평가에 시간이 소요되고 경험이 풍부한 평가단이 필요할지라도 광대역 델파이는 평가에서 정책적인 파트를 일부 제거하고
극단적인 초기 가치를 필터합니다.
|