가이드라인: 광대역 델파이 기법을 사용하여 노력 예상
이 가이드라인은 소프트웨어 개발 노력을 예상하는 데 광대역 델파이 기법을 사용하는 방법을 설명합니다.
관계
기본 설명

Software Development Magazine의 허가를 받아 Karl Wiegers가 RUP에 기여했습니다(www.processimpact.com). Rational Software Corporation에서 추가로 편집했습니다.

소개

이 가이드라인은 소프트웨어 개발 노력을 예상하는 데 사용할 수 있는 기법을 설명합니다. 광대역 델파이 예상 메소드는 다음과 같이 요약할 수 있습니다.

  • 전문가팀을 선택하여 모두에게 예상할 문제점에 대한 설명을 제공합니다.
  • 각 전문가에게 타스크 목록으로 분류된 문제점 분석을 포함한 노력 예상(종종 익명으로 수행함) 및 각 타스크에서 노력 예상을 제공하도록 요청합니다.
  • 그 다음 전문가는 협업하여 합의에 도달할 때까지 예상을 반복적으로 개정합니다.

광대역 델파이 메소드를 사용하면 개별의 예상을 확보하는 데 여러 가지 장점이 있습니다. 첫 번째로 각 참가자가 타스크를 검토하므로 주요 타스크의 작업분류체계(WBS) 또는 전체 타스크 목록을 빌드하는 데 도움을 줍니다. 합의를 통한 접근 방식은 자칭 전문가, 서투른 평가자 또는 의사 일정을 숨기거나 다양한 목표를 가지고 있는 영향력 있는 인사가 만든 예상에서 선입관을 배제하는 도움이 됩니다. 일반적으로 사람들은 다른 사람이 만든 예상보다 자신이 만드는 데 도움을 준 예상에 더 관심이 많습니다. 예상 타스크의 어떤 참가자도 "정답"을 알지 못합니다. 여러 가지 예상을 작성하면 이러한 불확실성을 확인하게 됩니다. 마지막으로 델파이 접근 방식의 사용자는 복잡한 타스크에서 반복의 중요성을 깨달게 됩니다.

광대역 델파이 적용

광대역 델파이를 사용하여 가상으로 어떤 사항이라도 예상할 수 있습니다. 특정 서브시스템을 구현하는 데 필요한 노동 일 수(월), 전체 제품에서 코드 수나 클래스 수, Bill Gates의 집에 다시 페인트 칠을 하는 데 필요한 페인트 양 또는 특정 조직에서 능력 성숙도 모델(CMM)의 레벨 2를 달성하는 데 드는 노력을 예상합니다.

델파이 메소드는 자세한 작업분류체계(WBS)를 개발하는 데 도움을 줍니다. 여기에서는 상향식 노력 및 스케줄 또는 크기 예상에 대한 기초를 제공합니다. 델파이 세션의 시작점으로는 비전 문서, 예상되는 문제점의 보다 자세한 요구사항 스펙이나 상위 레벨의 아키텍처 설명 또는 프로젝트 스케줄이 가능합니다. 산출물로 보다 자세한 프로젝트 타스크 목록, 연관된 품질, 프로세스 관련 및 오버헤드 타스크의 목록, 예상 가정 및 전반적인 프로젝트 예상 및 타스크 세트를 참가자마다 하나씩 제공합니다.

그림 1은 광대역 델파이 세션의 프로세스 플로우를 보여줍니다. 예상할 문제점을 정의하고 계획 중 참가자를 선택합니다. 착수 회의로 모든 평가자의 관심을 문제점에 모읍니다. 각 참가자는 개별적으로 초기 타스크 목록 및 예상을 준비합니다. 이 항목을 예상 회의에 가져옵니다. 이 회의에서는 여러 예상 주기를 통해 보다 포괄적인 타스크 목록 및 개정된 예상 세트를 작성할 수 있습니다. 그러면 중개자 또는 프로젝트 관리자가 분류한 예상 정보를 오프라인에서 통합하고 팀에서 예상 결과를 검토합니다. 일부 사전에 결정된 종료 기준을 충족시키면 세션이 완료됩니다. 결과로 나타나는 예상 범위는 단일 예상보다 미래에 대해 보다 현실적인 예측을 제공합니다. 이제 차례대로 각 프로세스 단계를 검토하겠습니다.

광대역 델파이 프로세스 플로우를 표시하는 다이어그램입니다.
광대역 델파이 세션을 계획하면 문제점을 정의하고 참가자를 선택합니다. 착수 회의로 모든 평가자의 관심을 문제점에 모읍니다. 각 참가자는 개별적으로 초기 타스크 목록 및 예상을 준비합니다. 이 예상 회의에서는 여러 예상 주기를 통해 보다 포괄적인 타스크 목록 및 개정된 예상 세트를 작성할 수 있습니다. 그 다음 정보를 오프라인에서 통합하고 팀에서 예상 결과를 검토합니다. 종료 기준을 충족시키면 세션이 완료됩니다.

계획

광대역 델파이 세션은 문제점(비전, 유스 케이스 모델, 기존 시스템, 예비 아키텍처)을 정의하고 해당 범위를 지정하면서 시작합니다. 큰 문제점을 관리 가능한 부분으로 분류하면 서로 다른 팀에서 좀더 정확히 문제점을 예상할 수 있습니다. 예상 타스크를 시작한 사람은 문제점 스펙을 정리합니다. 그러면 참가자가 신뢰할 수 있고 포괄적인 예상을 생성할 수 있도록 충분한 정보를 제공합니다.

예상 참가자로는 중개자(타스크를 계획 및 조정함), 프로젝트 관리자 및 2 - 4명의 다른 평가자가 있습니다. 중개자는 평가자로 참여할 수 있도록 충분한 정보를 알고 있어야 합니다. 그러나 자신의 편견이나 생각에 치우치지 않는 공정한 진행자(facilitator)의 역할을 수행해야 합니다. 참가자는 문제점 또는 프로젝트 및 이와 연관된 예상 문제를 이해하기 때문에 선택됩니다.

착수

첫 번째 착수 회의는 최대 1시간 정도 소요되며, 모든 참가자가 신속하게 문제점 예상에 참여합니다. 중개자는 광대역 델파이에 익숙하지 않은 팀 구성원에게 광대역 델파이를 설명하고 다른 평가자에게 문제점 스펙 및 가정 또는 프로젝트 제한조건을 제공합니다. 중개자는 평가자의 예상 작업에 지나치게 간섭하지 않으면서 평가자에게 충분한 정보를 제공하여 올바른 작업을 수행하도록 노력합니다.

팀에서는 예상 목표를 검토하고 문제점 및 예상 문제를 논의합니다. 참가자는 자신이 사용하는 예상 단위(예: 주, 근로 시간, 달러 또는 코드 라인)에 대해 합의합니다. 중개자가 모든 팀 구성원이 충분한 지식을 갖춰 예상 타스크를 도움이 된다고 판단을 내리면 그룹에서 작업을 시작할 준비가 된 것입니다. 그렇지 않으면 참가자는 예상할 문제점에 대해 더 철저히 브리핑하거나 보다 정확한 예상을 생성할 수 있는 다른 사람으로 대체해야 할 수도 있습니다.

광대역 델파이 세션을 진행할 준비가 되었는지 판별하려면 항목 기준, 즉, 후속 프로세스 단계를 진행하기 위해 만족해야 하는 전제조건을 확인하십시오. 예상 연습을 시작하기 전에 먼저 다음 조건을 만족시키십시오.

  • 팀 구성원이 올바르게 선택되었습니다.
  • 착수 회의를 가졌습니다.
  • 참가자가 예상 목적 및 단위에 합의했습니다.
  • 프로젝트 관리자가 세션에 참가할 수 있습니다.
  • 평가자가 효과적으로 참가하는 데 필요한 정보를 가지고 있습니다.

개별 준비

특정 프로젝트를 완료하는 데 필요한 작업 노력(보통 근로 시간으로 표현됨)의 총 크기를 예상하는 경우를 가정해 보십시오. 예상 프로세스는 각 참가자가 독립적으로 초기 타스크 목록을 개발하는 작업부터 시작됩니다. 이때 타스크는 그림 2에 표시된 것과 유사한 양식을 사용하여 명시된 프로젝트 목적에 도달하기 위해 완료해야 하는 타스크입니다. 그 다음 각 참가자는 각 타스크에 소모되는 노력을 예상합니다. 각 타스크를 정확히 예상할 수 있을 정도로 작은 크기의 타스크로 분류하십시오. 타스크를 명확히 명시하십시오. 나중에 누군가 모든 참가자의 타스크 목록을 단일 컴포지트 목록으로 병합해야 하기 때문입니다. 각 프로젝트 타스크에서 작성한 예상(합의한 단위 사용)의 총계를 계산하여 첫 번째 전반적인 예상을 생성하십시오.

차트에서는 델파이 예상 양식 샘플을 표시합니다.
예상 프로세스는 각 참가자가 독립적으로 초기 타스크 목록을 개발하는 작업부터 시작됩니다. 이때 타스크를 명시된 프로젝트 목적에 도달하기 위해 완료해야 하는 타스크입니다.

예상은 프로젝트 관리자 또는 다른 이해 관계자가 듣길 원하는 대답과는 관련이 없습니다. 예상이 허용 가능한 프로젝트 경계(스케줄, 노력 또는 비용의 측면)를 벗어나게 되는 경우가 있습니다. 이 상황에서는 협상이 요구되며 범위 축소, 스케줄 확장 또는 자원 조정으로 이어질 수도 있습니다. 그러나 외부의 압력으로 프로젝트를 운영하는 방법에 대한 최고의 계획을 변경하지는 마십시오.

프로젝트 타스크를 식별하는 것 이외에도, 별도로 관련 또는 지원 타스크에 해당하는 타스크를 기록하십시오. 첫 번째 주기에서 관리, 형상 관리 및 프로세스 관련 타스크를 처리하는 타스크를 반드시 나열하십시오. 테스트 또는 검수 타스크 이후에 재작업 타스크를 포함해야 합니다. 결함을 정정하는 재작업은 기본적인 사항이므로 재작업에 대한 계획을 세워야 합니다. 스케줄을 예상하는 경우에도 계획 시 빌드해야 할 수도 있는 프로젝트에 특정하지 않은 오버헤드 타스크를 검토하십시오. 여기에는 회의, 휴가, 훈련, 기타 프로젝트 업무 및 작업 시간에 하는 기타 수많은 업무가 포함됩니다.

근본적으로 서로 다른 가정 때문에 예상 편차가 넓어지므로 예상을 준비하는 동안 사용한 가정을 모두 기록하십시오. 예를 들면 특정 컴포넌트 라이브러리를 구매하거나 이전 프로젝트의 라이브러리를 재사용하려고 가정한 경우 이 내용을 기록하십시오. 다른 평가자는 프로젝트에서 해당 라이브러리를 개발한다고 가정할 수도 있습니다. 그러면 두 개의 전반적인 예상이 서로 불일치하게 됩니다.

다음 예상 가이드라인을 명심하십시오.

  • 한 사람이 모든 타스크를 수행한다고 가정해 보십시오.
  • 모든 타스크가 순차적으로 수행된다고 가정해 보십시오. 이때 순서 및 선행 타스크에 대해서는 염려하지 마십시오.
  • 각 타스크에서 간섭을 받지 않고 노력에 전념할 수 있다고 가정해 보십시오(너무 낙관적으로 보이지만 예상 프로세스를 단순화할 수 있음).
  • 달력 시간을 단위로 하여, 타스크 사이에 생길 수 있는 확인된 대기 시간을 나열하십시오. 그러면 나중에 노력 예상을 스케줄 예상으로 변환하는 데 도움이 됩니다.

예상 회의

중개자는 참가자의 개별 예상을 수집하고 그림 3과 같이 차트로 작성하여 예상 회의를 시작합니다. 각 참가자의 총 프로젝트 예상은 "1라운드" 행의 X로 표시됩니다. 각 평가자는 자신의 초기값이 해당 범위에 적합한 경우를 확인할 수 있습니다. 초기 예상 범위는 매우 클 수 있습니다. 참가자 중 한 명에게 자신의 예상만을 물어보고 이 예상을 사용하여 프로젝트를 계획하는 경우 수집할 수 있는 다양한 결론을 떠올리십시오.

차트에서는 광대역 델파이 세션에서 확보한 초기 예상을 표시합니다.
중개자는 참가자의 개별 예상을 수집 및 차트로 작성하여 예상 회의를 시작합니다. 각 참가자의 총 프로젝트 예상은 "1라운드" 행의 X로 표시됩니다. 초기 예상 범위는 매우 클 수 있습니다.  

일부 조직에서 중개자가 각 예상을 작성한 사람을 분간하지 못합니다. 중개자는 이러한 익명성이 델파이 기법의 중요한 측면이라고 생각합니다. 익명성은 거리낌없는 동료가 다른 참가자에게 자신의 의견을 강요하는 것을 방지합니다. 또한 팀 구성원의 고유한 분석이 서로 다른 결론으로 나아가는 경우 팀 구성원이 가장 존경 받는 참가자의 판단에 따르는 상황이 거의 나타나지 않습니다. 그러나 반드시 그런 것은 아닙니다.

각 평가자는 자신의 초기 타스크 목록을 읽으면서 자신의 예상임을 밝히지 않고 이때의 가정을 식별하고 문제나 질문을 제기합니다. 각 참가자는 수행해야 하는 다양한 타스크를 나열합니다. 이 개별 타스크 목록을 결합하면 단일 평가자가 생성하는 것보다 더 완전한 목록을 작성할 수 있습니다. 이 접근 방식은 수십 개의 개별 타스크까지도 적용됩니다. 이보다 타스크가 더 많은 경우 지나치게 상세해 질수도 있습니다. 문제점을 여러 하위 문제점으로 분류하고 이 문제점을 개별적으로 예상할 수 있습니다.

이 초기 논의 동안, 팀 구성원은 자신의 가정, 예상 문제 및 문제점에 대해 제기할 수 있는 질문도 이야기합니다. 결과적으로 팀은 공통 타스크 목록 및 가정을 공유하여 하나로 수렴시킬 수 있습니다. 이 최종 타스크 목록을 보유하여 다음에 유사한 프로젝트를 예상하는 경우 시작점으로 사용하십시오.

이 초기 논의를 마치면 모든 참가자는 회의실에서 자신의 예상을 동시에, 그리고 조용히 수정합니다. 논의 중 공유한 정보에 따라 자신의 타스크 목록을 개정할 수도 있습니다. 가정이 변경되거나 타스크 범위를 새로 파악한 경우 이에 따라 개별 타스크 예상을 조정합니다. 모든 평가자는 자신의 양식에 새 타스크를 추가하여 초기 타스크 예상에서 변경하고자 하는 사항을 기록할 수 있습니다. 모든 타스크에서의 근본적인 변경은 참가자의 전체 프로젝트 예상에서의 변경과 동일합니다.

중개자는 개정된 전반적인 예상을 수집하고 "2라운드" 행에 있는 동일한 차트에 이 예상을 적습니다. 여기에서는 쉽게 확인할 수 있도록 화이트보드에서 작업을 했습니다. 그림 4에 표시된 대로, 2라운드에서는 예상이 1라운드의 평균 값보다 더 높은 평균 주위에, 더 좁게 분배되게 됩니다. 추가 라운드에서는 이 분배가 더 좁아져야 합니다. 타스크 목록의 개정, 문제와 가정 논의 및 새 예상 준비로 구성된 주기는 다음 조건을 만족할 때까지 계속 진행됩니다.

  • 4라운드까지 완료했습니다.
  • 예상이 허용 가능한 좁은 범위로 모아졌습니다(앞에서 정의함).
  • 배정된 회의 시간을 마쳤습니다(보통 2시간).
  • 모든 참가자가 비자발적으로 최종 예상을 고쳤습니다.
예상 차트에서는 광대역 델파이 세션의 3라운드를 표시합니다.
초기 예상 논의를 마치면 모든 참가자가 자신의 예상을 수정합니다. 중개자는 개정된 전반적인 예상을 수집하고 "2라운드" 행에 있는 동일한 차트에 이 예상을 적습니다. 후반 라운드에서는 예상이 1라운드의 평균보다 더 높은 평균 주위에, 더 좁게 분배되게 됩니다.  

중개자는 15 - 20분간 진행되는 시간 제한(timeboxing) 논의가 장황하게 길어지지 않도록 그룹을 계속 관리합니다. 중개자는 효과적인 회의 진행 사례를 따라야 합니다. 예를 들면 정시에 시작하고 마치며, 모든 참가자의 참여를 장려하고 공정하고 선입견이 배제된 환경을 유지해 나가야 합니다. 초반에는 개별 예상의 익명성 유지가 매우 중요하지만, 일정 시간 후 팀 구성원은 모든 의견을 드러내는 공개 논의를 통해 마칠 수 있습니다. 그러면 타스크를 논의할 기회를 얻게 되어 이를 통해 자신의 예상에 상당한 변화를 주게 됩니다. 그렇지 않으면 중개자가 세션을 완료할 때까지 각 최종 예상을 생성한 개인을 분간할 수 없습니다.

타스크 정리

예상 회의에서 결론이 날 때까지 작업이 끝난 것은 아닙니다. 중개자 또는 프로젝트 관리자가 프로젝트 타스크 및 개별 예상을 단일 마스터 타스크 목록으로 정리합니다. 이 작업을 수행하는 사람이 가정, 품질 및 프로세스 관련 타스크, 오버헤드 타스크 및 대기 시간에 대한 개별 목록을 병합합니다.

병합 프로세스는 중복된 타스크를 제거하고 개별 타스크에서 서로 다른 예상에 대한 합리적인 분석에 도달하는 과정과 관련이 있습니다. "합리적"이란 단어는 팀의 예상을 프로젝트 관리자가 선호하는 가치로 바꾸는 것을 의미하지 않습니다. 확실히 유사한 타스크에서 예상 차이가 크게 나타나는 경우는 평가자가 해당 타스크를 다른 방식으로 해석했다는 의미입니다. 예를 들면 두 사람이 "클래스 구현"이라는 타스크를 맡을 수 있습니다. 그러나 한 평가자는 타스크에 코드 검토 및 유닛 테스트를 포함시킨 반면, 다른 평가자는 코드 노력만 포함했습니다. 모든 평가자는 이 병합 단계에서 혼란을 최소화하기 위해 자신의 타스크를 명확히 정의해야 합니다. 병합 단계에서는 각 타스크의 예상 범위를 보유해야 합니다. 그러나 한 평가자의 타스크 예상이 다른 평가자의 예상과 너무 많이 차이가 나는 경우 예상을 이해하고 버리거나 수정합니다.

결과 검토

최종 단계에서 예상팀은 요약한 결과를 검토하고 최종 결과에 대해 합의합니다. 프로젝트 관리자는 다른 평가자에서 전반적인 타스크 목록, 개별 예상, 누적식 예상, 가정 목록 및 기타 정보를 제공합니다. 팀에서 다시 30 - 60분간 검토 회의를 하여 예상 타스크를 마무리합니다. 이 회의에서도 팀에게 광대역 델파이 프로세스 실행을 심사 숙고하여 나중에 사용 시 개선할 수 있는 방법을 제안할 기회를 제공합니다.

참가자는 최종 타스크 목록이 가능한 완전해야 한다는 점을 확인해야 합니다. 예상 회의 이후에 참가자가 추가 타스크를 생각해낼 수도 있습니다. 그러면 지금 그 타스크를 타스크 목록에 추가할 수 있습니다. 개별 예상과 차이가 많이 나는 타스크를 합리적인 방식으로 병합했는지 확인하십시오. 최종 목표는 프로젝트 관리자 및 기타 중요 이해 관계자가 허용 가능한 신뢰 수준으로 프로젝트 계획 및 실행을 진행할 수 있는 예상 범위를 작성하는 것입니다.

예상 완료

예상 프로세스는 지정된 종료 기준을 충족시키는 경우 완료됩니다(성공했다고 선언할 수 있는 시점). 일반적인 광대역 델파이 종료 기준은 다음과 같습니다.

전반적인 타스크 목록을 정리했습니다.

예상 가정을 목록으로 요약했습니다.

평가자가 허용 가능한 범위에서 개별 예상을 단일 세트로 통합하는 과정에 대해 합의했습니다.

이제 데이터를 사용하여 수행할 작업을 결정해야 합니다. 단순히 최종 예상의 평균을 계산하여 단일 예상 지점을 알아낼 수도 있습니다. 이 사항이 예상을 요청한 사람이 원하는 내용일 수도 있습니다. 그러나 단순한 평균이 너무 낮을 수 있으므로 예상 범위를 보유하는 것이 더 좋습니다. 예상은 미래에 대한 예측입니다. 예상 범위는 견고하고 명백한 수치로 좁혀지는 본질적 불확실성을 반영합니다. 계획된 경우로 예상의 평균, 최상의 경우인 최소값, 최악의 경우인 최대값과 같이 세 가지 숫자를 제시할 수 있습니다. 또는 평균값을 명목 예상 결과(즉, (+ 최대값 - 평균값) 및 (- 평균값 - 최소값))로 표시할 수 있습니다.

각 예상에는 실현될 수 있는 특정 가능성이 있습니다. 따라서 예상 세트는 가능성의 분배로 구성됩니다. A Discipline for Software Engineering(Addison-Wesley, 1995)의 6장에서 Watts Humphrey는 상한 및 하한의 예상 간격으로 전반적인 예상을 생성하기 위해 여러 예상 및 불확실성을 결합하는 수학적으로 정확한 방식을 설명합니다. 다른 정교한 접근 방식으로 Monte Carlo 시뮬레이션이 있습니다. 이 방법에서는 최종 예상 값에 따라 가능한 예상 결과의 가능성 분배를 생성합니다.

델파이 세션의 결과가 유력 인사나 거물의 원하는 결과가 아니었어도, 10%의 신뢰 구간, 90%의 신뢰 구간 또는 그 사이의 값에서 해당 프로젝트를 계획할 수 있습니다. 향후 예상의 정확도를 높이려면 실제 프로젝트 결과를 예상과 비교해야 합니다.

다시 수행(반복)

이 메소드의 장점은 초반 이후 다소 개략적인 예상을 수행하면(예: 도입/인식(Inception) 동안) 예상이 단계마다(또는 반복할 때마다) 정제될 수 있다는 점입니다. 동일한 평가자를 사용하는 경우 이전 예상 주기에서 중단되었던 지점부터 시작하면 프로세스 속도가 빨라질 수 있습니다. 문제점에 대한 추가 정보가 사용 가능하고 일부 가정을 수정하며 노력을 분류하는 데 도움이 되도록 아키텍처를 배치합니다.

새 예상 범위는 더 좁을 수 있습니다. 그러나 반드시 이전 범위에 포함되는 것은 아닙니다. 더 높을 수도 있고 더 작을 수도 있습니다. 더 높은 경우 프로젝트 관리자에게는 위험성을 알리는 신호가 됩니다. 이때 위험성은 즉시 해결되어야 합니다.

광대역 델파이 예상

어떤 예상 메소드도 완벽하지 않습니다. 완벽하다면 예상(estimation)이 아니라 예측(prediction)이라고 해야 합니다. 그러나 광대역 델파이 기법은 일부 확실한 예상 원리를 통합했습니다. 팀의 접근 방식을 통해 여러 전문가의 시각을 결합한 가치를 확인할 수 있습니다. 생성된 예상 범위는 본래 예상 프로세스의 변동을 반영합니다.

다소 시간이 들고 숙련된 평가자 패널이 필요하지만 광대역 델파이는 예상 시 정치적인 충돌을 배제하고 극단적인 초기값을 걸러낼 수 있습니다.