다음을 통해 공유


우선 순위 지정

Mitch Lacey 작성.Agile 및 Scrum 채택과 개선을 전문으로 하는 컨설팅 기업인 Mitch Lacey & Associates, Inc가 소유자입니다.

2012년 1월

이 문서에서 Mitch Lacey는 많은 Agile 팀에 대해 매우 유용한 것으로 입증된 세 가지 방법을 설명했습니다. 즉, 고객 만족에 대한 Kano 모델, Luke Hohmann의 일련의 혁신 게임 그리고 Karl Weigers의 상대적 가중치 모델입니다.이 중 어느 것을 사용하든 백로그의 우선 순위를 대략적으로 지정하는 것에서 위험과 중요성, 고객 만족도를 충분히 고려하여 정확하게 순서를 지정하는 것으로 발전할 수 있습니다.

적용 대상

응용 프로그램 수명 주기 관리; Team Foundation Server

이 문서의 내용:

  • 소개

  • 고객 만족의 Kano 모델

  • 혁신 게임

    • 제품 트리 정리

    • 기능 구입

  • 상대적 가중치 – Karl Weigers

  • 결론

Agile 팀을 계속해서 효과적으로 작동시키기 위해서는 우선 순위에 따라 제품 백로그에서 항목을 주문한 다음 우선 순위 진행에 따라 이러한 우선 순위를 업데이트해야 합니다.모든 제품 백로그는 비즈니스 가치와 위험에 따라 우선 순위를 지정해야 합니다.이와 같은 우선 순위를 인식함으로써 팀이 제품의 성공에 영향을 가장 많이 주는 기능에 더 집중할 수 있습니다.잘 정렬되고 우선 순위가 지정된 백로그는 팀과 고객의 만족뿐만 아니라 실질적인 비즈니스에 도움이 됩니다.백로그에 대한 자세한 내용은 빌드 및 제품 백로그 관리 합니다., 제품 백로그에 추가 또는 만들기백로그 정리 및 예상를 참조하십시오.

제품 백로그를 주문하고 우선 순위를 지정하면 결정을 정당화할 수 있을 뿐 아니라 많은 요소를 고려해야 합니다.원시 제품 백로그를 시작할 때 그 과정은 거의 굉장해 보일 수 있습니다.다행히 백로그에 있는 모든 항목을 당장 주문할 필요는 없습니다.추정에서는 원시 제품 백로그를 빠르게 추정하고 대략적인 우선 순위를 정하기 위해 이해관계자와 함께 작업하는 효과적인 방법인 "The Big Wall"을 설명하고 있습니다.

이 대략적인 우선 순위 지정 방법은 좋은 시작점이며 사용자 환경에 춘분히 적용할 수 있습니다.그러나 이러한 우선 순위를 구체화하거나 더 과학적인 방법으로 우선 순위가 부여된 백로그에 도착하는 경우도 있습니다.다양한 기법을 사용하여 이 작업을 수행할 수 있습니다.다음 문서에서 많은 Agile 팀에 대한 매우 유용한 것으로 입증된 세 가지 방법을 설명했습니다. 즉, 고객 만족에 대한 Kano 모델, Luke Hohmann의 일련의 혁신 게임 그리고 Karl Weigers의 상대적 가중치 모델입니다.이 중 어느 것을 사용하든 백로그의 우선 순위를 대략적으로 지정하는 것에서 위험과 중요성, 고객 만족도를 충분히 고려하여 정확하게 순서를 지정하는 것으로 발전할 수 있습니다.

고객 만족의 Kano 모델

고객 만족의 Kano 모델은 1980년대에 Tokyo Rika 대학의 Noriaki Kano 교수가 개발했습니다.그의 모델은 필수 특성과 차별화 특성 사이를 구분하는 간단한 순위 구성표를 제공합니다.질문 기반 접근 방식의 모델은 제품의 특징을 시각화하고 디자인 팀 내부의 논의를 활성화하는 강력한 방법입니다.

예제 제품 기능 그래프

Kano에서는 작동 및 오작동의 두 가지 형식의 일련의 질문을 합니다.예를 들어 차량용 GPS 네비게이션 시스템에 대해 고객에게 묻고 있다고 합시다.먼저 질문의 기능적 형태에 대해 질문합니다:

  • 이 차량에 GPS 네비게이션 시스템이 있다는 것을 어떻게 느끼셨습니까?

우리는 다음 질문에 대한 응답을 제한합니다.

  • 그런 방식을 좋아합니다.

  • 그런 방식이 될 것으로 기대합니다.

  • 저는 중립

  • 그런 방식을 수용할 수 있습니다.

  • 그런 방식을 좋아하지 않습니다.

이 예제의 경우 가상의 고객이 “그 방법이 마음에 듭니다.”라고 응답했다고 합시다.

그런 다음 질문의 오작동 형태를 질문합니다.

  • 이 차량에 GPS 네비게이션 시스템이 없다는 것을 어떻게 느끼셨습니까?

가상 고객은 나열된 응답에서 선택할 수 있습니다.그러나 답변은 대개 다릅니다.이 예에서 변동 양식 질문에 가상 고객이 "이렇게 될 것을 알았습니다"라고 대답했다고 생각해보십시오.

실제 프로젝트에 대해 이 작업을 수행하면 여러 고객 그룹에 이러한 반대 질문 목록을 요청할 수 있습니다. 즉, 고객 조직의 다른 기능을 나타내는 개인들의 다른 집합을 요청할 수 있습니다.마케팅 그룹, 계정 그룹, 제조 그룹 등이 있을 수 있습니다.그러나 모델을 이해하기 위하여 한 고객 그룹에 하나의 질문만 한다고 상상해 보십시오.우리의 응답 쌍(기능 및 역기능 형식에 대한 응답)을 컴파일한 다음 표 1과 같이 눈금 위에 매핑합니다.

예제 Kano 매핑

표 1 – Kano 매핑

이 예제에서 가상 고객은 기능적 질문에 좋아합니다 그리고 역기능적 질문에 기대합니다라고 답변했습니다.이러한 쌍을 모눈에 매핑할 때 노란색 강조 표시된 사각형이 표시하는 대로 이러한 두 가지 특성의 교집합이 E임을 알 수 있습니다.우선 순위가 지정된 백로그에 대해 어떤 의미인지 검토해 보겠습니다.

  • E = 여자기.이는 고객이 예상하지 않고 제품과 그 경쟁자를 진정으로 차별화하는 기능입니다.이는 흥미로운 기능을 끌어내는 질문을 떠올리기 어렵기 때문에 처음에 식별하기 특히 어렵습니다.이러한 이유 때문에 익사이터가 발생하여 프로젝트 진행에 따른 우선 순위를 상향 조정하고, 고객의 피드백이 시작됩니다.

    • 고객은 이런 기능들로부터 커다란 만족을 얻게 되며 그에 대한 프리미엄 가격을 기꺼이 지불할 것입니다.예를 들어, 애플사의 iPod의 화면 방향에 따라 콘텐츠가 회전하도록 하는 직관적인 기능을 고객들은 좋아합니다.그러나 고객이 이에 대해 예상할 수 없을 수도 있으므로 이러한 기능이 없어도 만족을 줄어들지 않을 수 있습니다.

    • 이 예제에서는 GPS 네비게이션이 흥미로운 기능이 될 것입니다.이 기능 탐색은 고객이 피트백을 받을 때까지 높은 우선 순위를 가집니다.

  • B = 기준이러한 기능이 제품에 있어야 합니다.이들은 반드시 해야 하는, 우선 순위가 높은 기능입니다.

    • 이러한 기본 특성이 실행되는지 여부에 관계 없이 고객은 제품에 중립적으로 남을 것입니다.예를 들어, 워드 프로세서에는 "문서 만들기"와 "문서 저장" 기능이 있어야 합니다.항목의 가격입니다.

    • 우리가 고객들에게 좌석 벨트에 관해 문의한 결과, 대부분의 고객은 새 자동차에 좌석 벨트가 포함되기를 기대하고, 좌석 벨트가 없는 것을 싫어합니다.이러한 두 개의 대답을 고려하면, 좌석 벨트는 기본적으로 갖춰야 할(B) 필수적인 기능입니다.

  • L = 선형.고객 만족과 직접 관련이 있는 성능 요구 사항, 선형 기능으로도 알려져 있습니다.이들은 우선 순위에서 기준 기능에 약간 밑돌았지만 비용 대비 균형을 맞추어야 합니다.

    • 향상된 기능 또는 실행 품질은 고객 만족도를 높여줍니다.기능이 감소되면 만족도도 감소합니다.

    • 제품 가격은 종종 이러한 특성과 관련되어 있습니다.

  • I = 무관심.이러한 기능은 고객에게 가장 덜 중요하므로 제품에도 가장 덜 중요합니다.이들은 수익이 거의 없거나 비즈니스 가치가 없습니다.

표 1에서는 Q와 R을 보여줍니다.

  • Q: 의심스러움 – 질문이 아마도 잘못되었거나 답변이 의심스럽습니다.

  • R: 역 -대답의 조합이 계산되지 않습니다.GPS 탐색 시스템을 적용하십시오. 누군가 그럴 것으로 예상하지만 그렇지 않을 경우에도 좋다면 이는 R 답변입니다.

응답 쌍 Q 또는 R 등급인 경우, 당신은 질문 또는 응답 쌍을 보다 면밀하게 조사해야 합니다.

혁신 게임

혁신 게임은 주요 시장 조사를 개발하는 데 도움이 되는 도구입니다.이러한 도구를 사용하여 고객은 제품이나 서비스에 대한 피드백과 입력을 생성할 목적으로 "게임"을 재생합니다.Luke Hohmann은 라이브러리에 추가된 그의 책 혁신 게임에서 12개 이상의 이러한 게임을 만들어 설명했습니다.백로그에 우선 순위를 지정하는 두 개의 좋아하는 게임은 Luke가 그의 책 일부(권한을 가지고 사용)에서 설명한 제품 트리 정리기능 구입입니다.

Hh765981.collapse_all(ko-kr,VS.110).gif제품 트리 정리

정원사는 성장을 제어하기 위해 나무의 가지를 정리합니다.때때로 정리는 예술적이며 동물이나 흥미로운 추상 셰이프 같은 모양의 관목을 그립니다.대부분 정리는 고품질 결과를 산출하는 균형이 맞춰진 트리를 작성하도록 설계되었습니다."프로세스"는 '잘라내기"가 아니라 "셰이핑"에 대한 것입니다. 고객이 원하는 제품을 만드는 데 도움을 제공하려면 이 은유를 사용합니다.

게임

화이트보드 또는 버처 용지에 대형 트리를 그리거나 트리의 그래픽 이미지를 대용량 형식의 포스터로 인쇄하기 시작하십시오.굵은 발은 시스템 내에서 주요 기능 영역을 나타냅니다.가장 바깥쪽 분기인 트리 가장자리는 현재 릴리스에서 사용할 수 있는 기능을 나타냅니다.나뭇잎 모양의 여러 인덱스 카드에 잠재적 새 기능을 작성합니다.성장의 다음 단계를 정의하면서 고객에게 트리에 원하는 기능을 배치하도록 요청하십시오.균형 있게 성장하는 트리 구조를 갖고 있습니까?한 분기, 아마도 제품의 핵심 기능이 크게 성장합니까?트리의 충분히 사용되지 않는 부분이 더 강력해집니까?트리(지원과 고객 만족 인프라)의 루트는 최소한 캐노피 만큼 확장되어야 합니다.당신은?

제품 트리 정리에 대한 예제 레이아웃

제품 트리 –Hohmann

작동 방식

여러분과 고객 모두 기능의 중요성에 차이가 있다는 것을 알고 있습니다.따라서 가장 중요한 기능인 최고의 가치를 고객에게 제공하는 기능에 노력을 기울이는 경향이 있습니다.그러나 때로는 이는 제품을 완료하는 데 필요한 기능에 너무 적은 노력을 쏟았음을 의미합니다.제품 트리 잘라내기 게임은 전체적으로 제품을 구성하는 기능의 집합을 검색함으로써 고객에게 의사 결정 프로세스에 입력을 제공하는 방법을 제공합니다.

Hh765981.collapse_all(ko-kr,VS.110).gif기능 구입

고객이 제품을 구입하도록 유도하는 기능은 무엇입니까?고객이 업그레이드하도록 하는 기능은 무엇일까요?어떤 기능이 고객을 행복하게 하여 고객이 수정하거나 제거하길 원하는 기능을 무시하거나 허용합니까?

제품 기획자는 여러 가지 질문에 대해 끊임없이 토론합니다.기능의 올바른 집합을 선택하여 단기 오류 및 장기 성공 사이의 차이를 표시하는 릴리스에 추가합니다.불행하게도 너무 많은 제품 기획자들이 제품에 가장 많은 영향을 미치는 사람인 고객을 포함시키지 않고 이런 선택을 합니다.기능 구입 게임을 통해 고객에게 도움을 줄 사항을 질문함으로써 이러한 결정의 품질을 개선합니다.

게임에 대한 예제 레이아웃

기능 구입 –Sterne

게임

잠재적 기능 목록을 만들고 각각의 가격을 제공합니다.실제 제품과 마찬가지로 가격은 개발 비용, 고객 가치 등에 기초할 수 있습니다.가격은 기능에 대해 청구하고자 하는 실제 비용이지만 일반적으로 필수적 요소는 아닙니다.고객은 그들에게 지불하는 비용을 활용하여 차후 출시되는 제품에 대해 그들이 원하는 기능을 구매합니다.일부 기능은 한 고객이 구입할 수 없을만큼 충분히 높은 가격인지 확인하십시오.고객에게 특히 중요하거나 값비싼 기능을 구입하기 위해 돈을 저축하도록 권장합니다features.이는 어떤 기능이 가장 중요한지에 관한 고객 간의 협상에 동기를 부여하는 데 도움이 됩니다.

이 게임은 그룹으로 된 4~7명의 고객에서 가장 잘 작동하기 때문에 고객이 협상을 통해 돈을 끌어올 수 있는 더 많은 기회를 만들 수 있습니다.제품 상자 게임과는 달리 기능 구매 게임은 개발 로드맵에 있을 수도 있는 기능의 목록에 기반합니다.

작동 방식

제품 기획자는 종종 고객이 제품 우선 순위를 명확하게 정의했다는 생각의 함정에 빠지고는 합니다.일부를 수행합니다.대부분 그렇지 않습니다.옵션 집합을 제공하면 많은 고객은 단순히 "저는 그 모두를 원합니다."라고 말하고 요청의 우선 순위를 부여하는 책임을 사용자에게 넘깁니다.그렇지 않으면 제품 관리자들은 고객과 일대일로 작업하여 기능 우선 순위를 얻으며 그 과정에서 의식하지 못한 채 다시 한 번 우선순위를 지정하는 역할을 담당하게 됩니다.고객을 그룹으로 참여시키고 제한된 리소스를 제공함으로써 그룹으로서 욕구에 우선 순위를 정할 수 있는 기회를 제공합니다.하지만 마법이 아닙니다.마법은 고객이 특정 기능에 대해 서로 간에 협상할 수 있도록 대화를 구조하는 데 있습니다.고객이 정말로 원하는 것을 이해하는 것이 이 협상입니다.

상대적 가중치 – Karl Weigers

우선 순위 지정을 위한 또 다른 탁월한 메서드는 Karl Weigers가 1999년에 소개한 상대적 가중치 입니다.이 메서드는 사용자 입력과 피드백을 기반으로 요구 사항에 우선 순위를 지정하는 메커니즘을 제공할 뿐만 아니라 팀의 전문가 판단도 포함합니다.Kano 및 혁신 게임과 마찬가지로 상대적 가중치를 사용하면 제품 소유자는 구현할 기능 및 우선 순위 순서를 더 잘 측정할 수 있습니다.

첫 번째 단계는 기능의 상대적 혜택에 가중치를 할당하는 것입니다.이점은 최종 제품에서 기능을 가진 사용자를 위한 장점입니다.다음은 상대 페널티를 할당하는 것입니다.페널티는 최종 제품에 기능을 갖지 않는 사용자의 결과입니다.(장점과 단점을 평가하면 Kano 기법의 작동 및 오작동 형태 질문과 동일한 작업을 수행할 수 있습니다.) 가중치는 회사가 기능의 이점과 위험에 어떤 가치를 두는지 나타내는 임의의 숫자입니다.이는 교사가 전체 등급을 결정할 때 과제, 출석, 퀴즈 및 테스트의 가중치를 결정하는 방법과 매우 비슷합니다. 이는 교사마다 다릅니다.만약 이익이 손실보다 크다면, 결정한 비율에 따라 손실보다 크게 가중치를 만듭니다.페널티가 혜택보다 큰 경우 그에 따라 가중치를 조정합니다.표 2의 예제에서 상대적 가중치 2의 이점과 상대적 가중치 1의 패널티가 제공되었으며 이는 최종 순위를 결정할 때 계수가 클수록 이점이 된다는 것을 의미합니다.

같은 방식으로 비용 비율 및 위험 비율의 가중치를 결정합니다.다음 예제에서 위험은 프로젝트에 대해서는 문제가 되지 않으므로 비용 백분율에 가중치 1과 위험 백분율 가중치 0.5가 부여되었습니다.(백분율 값을 계산하기 전에 장점과 단점을 측정하여도 비용과 위험은 백분율로 계산된다는 것을 참고하십시오.) 위험이 높은 프로젝트가 있는 경우 비용보다 높은 위험에 가중치를 줄 수 있습니다.

예제 기능 테이블 - 시작

가중치가 설정되었으므로 사용자에게 각 기능의 상대적 이점 및 상대 벌칙을 평가하도록 요청하십시오.각 혜택 및 벌칙은 설정 배율에 비례합니다-Weigers는 1-9를 권장하지만, 일관성을 유지하는 한 다른 배율을 선택할 수도 있습니다.상대 이점은 기능을 제공하는 값입니다. 상대 벌칙은 이 기능을 수행하지 않아 발생하는 잠재적인 부정적인 영향입니다.

예를 들어, 하나의 가능한 기능이 "사베인스-옥슬리 규정을 준수하여 위젯을 만듭니다."라고 가정하면 상대적으로 사용자에게는 이익이 없지만 규정을 준수하지 않은 회사는 영업을 할 수 없게 되므로 회사에게는 상대적으로 큰 손실입니다.따라서 상대 이익은 1점이나 2점이, 상대 불이익은 8점이나 9점이 표시될 것입니다.

다음 예제에서 사용자는 "공급 업체 주문의 쿼리 상태"에 대한 상대 이점을 5로 평가했습니다.상대 페널티를 3으로 평가했습니다.해당 기능의 전체 값을 해당 기능을 파생시키려면 상대적 가중치로 두 수를 곱한 후 함께 더합니다.

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 *2) + (3*1) = 13

이 경우 기능에 대한 총 값은 13점입니다.

예제 기능 테이블 - 진행 중

이러한 기능에 대해 전체 상태 값과 값 백분율을 가져올 때 사용자에서 멀어져 에서 통찰력을 가져옵니다.우리는 같은 배율을 사용하여 각 기능을 구현하기 위해 팀이 관련 비용을 예측하도록 요청합니다.Karl Weigers는 "개발자는 요구 사항의 복잡도 같은 요소에 기반한 비용 등급, 필요한 사용자 인터페이스 작업 범위, 기존 디자인 또는 코드를 재사용할 수 있는 잠재적인 기능 및 필요한 테스트 수준 및 설명서를 추정합니다."라고 설명합니다.

상대 비용을 예측한 후 상대 위험을 예측합니다.다시 한 번, Weigers는 말합니다. "개발자는 1에서 9까지 측정 범위에서 각 기능에 관련된 기술 또는 다른 위험의 상대 수준을 예측합니다."추정치9는 가능성, 필요한 전문 지식을 가진 직원 또는 검증되지 않거나 익숙하지 않은 도구와 기술 사용에 대해 심각한 우려를 나타내며, 1이면 절전 모드에서 프로그래밍할 수 있습니다.스프레드시트는 각 기능에서 오는 종합적인 위험의 백분율을 계산합니다.”

상대적 이점, 페널티, 비용 및 위험의 가치를 확인한 후에 각 열을 요약합니다.이러한 합계는 백분율을 계산하는 데 사용됩니다.

  • 총 값 백분율 값: 상대적 이점 및 벌점의 합계 값을 아래쪽의 총 합계로 나눕니다.다음 예제에서 이것은 13 / 154 = 8%입니다.

  • 상대 비용 비율: 상대 비용 값을 맨 아래의 전체 비용 합계로 나눕니다.다음 예제에서 이것은 2 / 42 = 4.8%입니다.

  • 상대 위험 비율: 상대 위험 값을 맨 아래의 전체 위험 합계로 나눕니다.다음 예제에서 이것은 1 / 33 = 3%입니다.

  • 우선 순위: 백분율 값을 (비용 비율 * 비용 가중치) + (값 비율 * 값 가중치)로 나눕니다.다음의 예제에서 이것은 8.4% / ((4.8% * 1) + (3% * 0.5) 입니다.우선 순위 값(1.345)을 제공합니다.

우선 순위 값을 구한 후 가장 높은 우선 순위가 항목 위에 오도록 내림차순 우선 순위로 열을 정렬합니다.제품 백로그에 항목이 추가되거나 스토리에 대한 자세한 내용이 생기면 우선 순위를 재평가해야 합니다.

결국 시트는 이 테이블처럼 보일 것입니다.

예제 기능 테이블 - 완료

이 방법을 사용하여 팀과 이해 관계자 관련 작업 범위를 보다 잘 이해할 수 있습니다.각 기능의 이점, 패널티, 비용 및 위험 같은 요소를 객관적으로 구분하기 어렵기 때문에 근거 토론을 더 잘 할 수도 있습니다.

Weigers는 실제와 더 근접한 모델을 만드는 방법에 대해 설명합니다.

용도에 따라 요구 사항 완료를 통해 이 모델을 조정하거나 이전 제품에서 기능을 조정합니다.계산된 우선 순위 시퀀스와 테스트 설정에서 요구 사항이 얼마나 중요한지에 대한 사후 평가가 일치할 때까지 가중치 요소를 조정합니다.이 모델은 제한된 새 요구 사항을 평가할 때 절충된 의사 결정을 할 수 있도록 해줍니다.적절한 구현 시퀀스를 선택하기 위하여 기존 요구 사항과 얼마나 일치하는지를 보여줄 수 있도록 이 모델을 사용하여 우선순위를 평가합니다.정치적 영역에서 객관적이고 분석적인 영역으로 요구 사항 우선 순위를 이동시키는 모든 작업은 가장 적합한 순서로 가장 중요한 기능을 제공하도록 프로젝트의 기능을 향상시킬 수 있습니다.

Karl Weigers는 상대적 가중치에 대한 세부 사항을 다루는 다음 두 권의 책을 저술했습니다. 소프트웨어 요구 사항, 두 번째 버전소프트웨어 요구에 대한 자세한 소개: 매우 어려운 문제와 실용적인 조언

이러한 메서드 중 하나 또는 다른 일부 기술을 사용하든지 제품 백로그가 살아있다는 점을 기억하십시오.한 번 우선 순위화한 다음 그만 두는 것이 아닙니다. 우선 순위화는 정상 백로그를 유지 관리의 일환으로 사용됩니다.프로젝트를 계속 진행하려면 스토리, 프로젝트를 기준으로 하는 중요도 및 새 정보가 백로그에 미치는 영향을 지속적으로 재평가해야 합니다.이해 관계자 및 고객이 프로젝트 전반에 걸쳐 참여하도록 해야 합니다.또한 항목의 예측이 우선 순위를 결정 하는 데 필수적이란 사실을 기억해야 합니다.백로그가 부실해져 사라지지 않도록 하십시오.백로그를 육성하고 정리하는 데 시간과 노력을 투자합니다. 최종 제품 뿐만 아니라 맨 아래 줄에 결과가 나타납니다.

참고 항목

개념

팀으로 시작

Agile 계획 및 반복

요청 하 고 팀 웹 액세스를 사용 하 여 프로세스 이해 관계자 의견

작업 추적 및 워크플로 관리

  1. Agile Software Requirements, Dean Leffingwell, Addison Wesley

    “Attractive Quality and Must-be Quality” Noriaki Kano, Quality JSQC, Vol.14, No.2, 1984년 10월.Kano의 원래 기사입니다.

  2. http://www.processimpact.com/articles/prioritizing.html