優先處理順序
Mitch Lacey 原著。擁有者是 Mitch Lacey & Associates, Inc 顧問公司，專精於採用及增強敏捷與 scrum。
2012 年 1 月
在本文中，Mitch Lacey 討論三個經證實非常有利於許多 Agile 小組的方法：Kano 客戶滿意度模型、Luke Hohmann 的一系列 Innovation Games，以及 Karl Weigers 的相對加權模型。這其中任何一項都可以協助您從粗略的待處理項目優先權排定轉移至精確的順序安排，充分權衡風險、重要性和使用者滿意度。
套用至
Application Lifecycle Management; Team Foundation Server
本文內容：
簡介
Kano 客戶滿意度模型
Innovation Games
修剪產品樹
外購功能
相對加權 – Karl Weigers
總結
要保持敏捷小組的工作效率，您必須按照優先順序排列產品待處理項目中的項目，然後隨著專案進度更新優先順序。所有產品待處理項目的優先權都必須根據商務價值和風險來排定。透過辨識這個優先權順序，您的小組就可以更加專注於最可能納入產品成功因素的功能。秩序井然且已排定優先權的待處理項目不僅在小組和使用者的滿意度上表現卓著，同時也在營業的損益中獲得報償。如需待處理項目的詳細資訊，請參閱建立與管理產品待處理事項、建立或新增產品待處理項目 和 整備與評估待處理項目。
當排序和排列產品待處理項目的優先順序時，您必須考量許多因素。也必須確認您的決定。當您開始處理原始產品待處理項目時，處理序可能看起來非常多。幸運的是，您完全不需要立即在您的待處理項目中排列每個項目。在估計中，我會說明稱為「大圍牆」(The Big Wall) 的技術，這是與專案關係人一起快速評估原始產品待處理項目和工作的有效方法，可達成概略的優先順序排定。
這個概略的優先順序是很好的起點，可能適用於您的情況。在某些情況下，however, you might want to refine these priorities or arrive at a prioritized backlog in a more scientific way.在某些情況下，您可能會想要精簡這些優先權，或是以更科學的方式排定待處理項目的優先權。您可以使用很多技巧來完成這項工作。在下列文章中，我討論三個經證實非常有利於許多 Agile 小組的方法：Kano 客戶滿意度模型、Luke Hohmann 的一系列 Innovation Games，以及 Karl Weigers 的相對加權模型。這其中任何一項都可以協助您從粗略的待處理項目優先權排定轉移至精確的順序安排，充分權衡風險、重要性和使用者滿意度。
Kano 客戶滿意度模型
客戶滿意 的 Kano 模型是由東京 Rika 大學 Noriaki Kano 教授於 1980 年代開發的。他的模型提供區分基本和辨別屬性的簡單順位配置。問卷調查方法，這個模型是以視覺化方式檢視產品特性並在設計小組內激發辯論的強大方法。
.png "產品功能圖形範例")
在 Kano 模型中，我們會詢問一系列兩種不同形式的問題：功能性和非功能性。例如，假設我們詢問客戶有關 GPS 汽車導航系統。我們先提出功能形式的問題:
- 如果這輛汽車有 GPS 導航系統，您覺得如何？
我們只回覆下列回答：
我喜歡它這個樣子
我希望它是那個樣子
我不好也不壞
我可以接受這樣的情況。
我不喜歡它這個樣子
這個範例中，假設我們假想的客戶回應「我喜歡它那個樣子」。
接下來我們會提出非功能性形式的的問題：
- 如果這輛汽車沒有 GPS 導航系統，您覺得如何？
我們假想的客戶可以選擇列出的任何問題。不過，答案可能經常不同 (通常是這樣)。這個範例中，假設我們假想的客戶對非功能性形式問題的回應是「我希望它是那個樣子」。
我們在實際專案這麼做時，可以對多個客戶群組提出這份反對清單上的問題，這裡的客戶群組指的是代表客戶組織中不同部門之不同個人所組成的團體。您可能有一個行銷小組、一個會計小組、一個製造小組，諸如此類。不過，為了方便了解這個模型，我們假設我們只向一個客戶群組詢問一個問題。將解答組 (功能性和非功能性問卷的答案) 彙編之後，我們會將它對應到方格中，如表 1 所示。
.png "Kano 對應範例")
表 1 - Kano 對應
請注意，在範例中，我們假想的客戶對功能性問題回答喜歡，而對非功能性問題回答預期。當我們將這個與方格配對時，可以看到兩個屬性的交集是 E (黃色反白顯示的正方形)。讓我們來檢查這對我們已排定優先權的待處理項目有何意義。
E = 刺激者。這些都是客戶未預期的功能，也是讓這項產品與競爭對手與眾不同的功能。它們不容易識別，特別是在一開始時，因為很難提出能引發令人興奮的功能的問題。因此，隨著專案進展，客戶開始有意見時，刺激者通常會出現並且其優先權會上升。
客戶會從這些功能獲得極大滿足，因此願意多付一點錢來擁有它們。例如，Apple 的 iPod 因為具有配合螢幕方向轉動內容的直覺式功能而博得客戶歡心。因為客戶不知道是否要有期望，但缺少該功能不會降底滿意度。
在範例中，有 GPS 導航會是具有吸引力的功能。探索這項功能 (至少到達會收到客戶意見的地步) 應該會相當高的優先順序。
B = Baseline (基準)。這些功能都必須包含在產品中。這些是必要的高優先順序功能。
無論這些基本屬性的執行狀況多麼良好，客戶對產品都保持不好也不壞的看法。例如，文字處理器必須具有「建立文件」和「儲存文件」的功能。它們是入場的代價。
如果我們向客戶群組詢問安全帶，大部分的人會回答他們期望新車隨附提供安全帶，如果沒有提供就會不喜歡。如果我們對應方格中的那兩個答案，就會發現安全帶是基準 (B) 必備的功能。
L = 線性。線性功能 (也稱為效能需求) 會直接與使用者滿意度產生相互關聯。它們的優先順序剛好降至基準功能之下，但必須與其成本平衡。
提升的執行功能或品質會增進客戶滿意度。減少功能會降低滿意度。
產品價格經常與這些屬性相關。
I = 不多不少.這些功能對於客戶最不重要，因此，對於產品也最不重要。它們可能回收的商業價值不高。
表 1 也顯示 Q 和 R。
Q：令人置疑：問題可能不正確或答案不可信。
R：撤回：回應的組合無法計算。以 GPS 導航系統為例，如果有人回答他們期望它的存在，但若是它不存在，他也喜歡這樣的狀況，那麼這是一個 R 答案。
如果解答組已評等為 Q 或 R，您應該深入調查您的問題和解答組。
Innovation Games
Innovation Games 是協助您發展主要市場研究的工具。使用這些工具時，客戶會為了徵求與產品或服務有關的意見和想法而玩「遊戲」。Luke Hohmann 在其所著《Innovation Games》中建立並說明了這 12 種以上的遊戲，這本書籍值得任何圖書館來收藏。我最喜歡玩的兩個排定待處理項目優先權的遊戲是修剪產品樹和外購功能，Luke 在該書的這段摘錄中說到 (經許可使用)：
.gif "Hh765981.collapse_all(zh-tw,VS.110).gif")
修剪產品樹
園丁會修剪樹木來控制其生長。有時候是清除圖片屬性的，因此，我們最終衍生灌木模式化像動物或有趣的抽象圖案。修剪通常是設計來建置產生高品質結果的平衡樹狀結構。此處理序不是關於「剪下」，而是關於「成型」。使用這個比喻來協助建立客戶希望的產品。
遊戲
可以從在白板或是牛皮紙上繪製一個大的樹狀圖開始，或是像大型海報那樣印出樹的圖形。粗的分支代表系統中的主要功能區。樹狀邊緣 - 最外層分支- 表示目前版本中可用的功能。在數張索引卡上寫下可能的新功能，最好以分葉方式寫出。要求您的客戶在樹狀目錄周圍放置所需的功能，定義其下一個階段的擴增。他們是否建構以平衡方式擴增的樹狀結構？一個分支 (或者產品的核心功能) 是否取得大部分的成長？樹狀結構未充分使用的方面是否變得更強？我們知道樹狀結構的根 (您的支援和客戶服務基礎結構) 擴充規模至少要和您的天空一樣大。您的是這樣嗎？
.png "修剪產品樹狀結構的配置範例")
產品樹 –Hohmann
為何有用
您和客戶都知道功能的重要性有所不同。因此，我們傾向於想要將我們的努力放到最重要的功能之後，那些可以提供給客戶最大價值的功能。可惜的是，有時候這表示我們太注重完成產品所需的功能。修剪產品樹狀 (Prune the Product Tree) 遊戲提供一種將輸入放入決策程序的方式給客戶，其方式是藉由整體性地查看組成產品的功能。
外購功能
哪個功能會引誘惑客戶購買產品?哪些功能會讓客戶升級?哪個功能可讓客戶很樂意忽略或容忍他們希望你修正或移除的功能？
產品計劃者不斷爭論這些及其他類型的問題。選擇正確的一組要加入至發行版本的功能通常劃分出短期失敗或長期成功之間的差異。可惜的是，太多產品規劃人員選擇時沒有考慮到多數受影響的人，那就是客戶。購買功能遊戲藉由要求您的客戶幫忙來協助改善這項決定的品質。
.jpg "遊戲版面配置範例")
外購功能 – Sterne
遊戲
建立潛在功能的清單，並提供各項功能的價格。就像在實際的產品一樣，價格可以根據開發成本、客戶價值或其他項目來訂定。雖然這個價格可以是這項功能要收取的實際成本，通常這不是必要的。客戶會使用您提供的虛擬貨幣購買他們希望在您下一版產品中推出的功能。確定某些功能的價格要訂得夠高，使得沒有任何客戶會購買。鼓勵客戶集資購買特別重要和 (或) 昂貴的功能。這有助於鼓勵客戶之間針對最重要的功能進行協調。
這個遊戲最適合四到七個客戶組成的群組，這樣您可以為客戶創造更多機會，透過協商彙集他們的資金。不同於產品包裝盒遊戲，購買精選遊戲是以可能歸入開發藍圖的特殊功能清單為基礎。
為何有用
產品計劃人員經常一昧地認為客戶已清楚定義產品優先權。有些會。最不該做的事。出現一組選項時，許多客戶只會說「我全部都想要」，並且將排列要求優先順序的責任丟給您。或者，產品管理員經常會因為與客戶一對一合作而蒐集 (甚至可能不知不覺在過程中蒐集) 功能優先權的資訊，又再一次擔負排定功能優先權的責任。將客戶當做群組成員來共同參與並提供其限量的資源，讓客戶有機會以群組成員的身分排定其需求項目的優先順序。但這並不是巧妙之所在。魔術就在建構交談中，讓您的客戶置於其中，針對特定功能進行交涉。正是這次交涉，讓您進一步對客戶真正需要的是什麼有所了解。
相對加權 – Karl Weigers
排定優先順序的另一個好方法是「相對加權」，這是 Karl Weigers 在 1999 年引入的。這個方法不僅提供根據使用者輸入及意見排定需求優先順序的機制，也包含小組的專業判斷。就像 Kano 模型和 Innovation Games 一樣，相對加權可讓產品擁有者更精確估量要實作哪些功能以及依照何種優先權順序。
第一步是將加權指定給功能的相對效益。效益是掌握最終產品所具功能之使用者的優勢。接著是指定相對損失。這種效能損失是使用者沒有在最終產品加入該功能所導致的結果。(評定效益和損失可以達成與 Kano 方法之功能性和非功能性問卷相同的目的)。權重是任意數字，代表您的公司如何評估功能的優點和風險。這很像是老師如何判斷指定給決定整體成績之功課、到課率、小考和測驗的權數。權數因老師不同而有差別。如果您決定效益遠超過損失，請視需要增加效益的權重超過損失權重適當的比例。如果您決定損失蓋過效益，請相應調整權重。在表 2 的範例中，我們指定效益的相對權重為 2，而損失的相對權重為 1，表示效益在決定最終優先順序時是較大的因素。
同樣的，我們會決定成本百分比和風險百分比的權重。在下列範例中，風險不是專案的主要顧慮，因此得到的成本百分比權重為 1，而風險百分比權重為 0.5。(請注意，雖然效益和損失是在計算價值百分比之前進行加權，成本和風險還是以百分比進行加權)。如果您有高風險的專案，您可能將風險加權高過成本。
.png "範例功能表 - 開始")
現在權數已設定，我們要求每個使用者對每個功能的相對效益和相對損失評分。每項效益和損失是按照一組尺度 (Weigers 建議使用 1-9) 來評分，但您可以選擇不同的尺度，只要一致就好。相對優點是此功能將傳遞的值；相對缺點則是不執行此功能可能會造成的負面影響。
例如，假設有一個可能的功能是「使新產品符合 Sarbanes-Oxley 法規」。這實際上對使用者沒有相關的效益，但對公司就會造成很大的相對損失。不做的話，甚至會讓公司停業。因此，我們可能會看到相對效益的分數為 1 或 2，而相對損失的分數為 8 或 9。
在下列範例中，使用者將「查詢供應商訂單狀態」功能的效益評等為 5 分。他們將其相對損失評估為 3。為衍生出該功能的總價值，我們將兩個數字乘以其相對權重，然後相加：
(Benefit * Weight) + (Penalty * Weight) = Total Value
(5 *2) + (3*1) = 13
在這種情況下，這項功能的總計值是 13 點。
.png "範例功能表 - 進行中")
當我們取得功能的總相對值和值百分比時，會先擱置使用者而了解小組的見解。我們要求小組估計相對成本，以使用相同的度量實作每一個功能。Karl Weigers 說明「開發人員會根據各種因素估計成本評比，例如需求的複雜度、必要的使用者介面工作範圍、重複使用現有設計或程式碼的能力以及需要的測試和文件層級」。
在評估相對成本之後，我們會評估相對風險。Weigers 又說：「開發人員會評估與每項功能相關聯之技術或其他風險在 1 到 9 級尺度上的相對程度。預估為 1 表示您睡覺也能擬定安排，而 9 則表示需要嚴肅考量可行性、具備專業知識之人員的可用性，或未經驗證或不熟悉之工具和技術的使用。試算表會計算每個功能的總風險百分比」。
記下相對效益、損失、成本和風險的值後，我們會總計每一欄。將使用這些總數計算百分比。
總值百分比：將相對優點和缺點的總值除以下方的總值。在下列範例中，13 / 154 等於 8%。
相對成本百分比：將相對成本值除以位於底部的總計相對成本總和。在下列範例中，2 / 42 等於 4.8%。
相對風險百分比：將相對風險值除以位於底部的總計相對風險總和。在下列範例中，1 / 33 等於 3%。
優先權：將值百分比除以 (成本百分比 * 成本權數) + (值百分比 * 值權數)。在下列範例中，這將會是 8.4% / ((4.8% * 1) + (3% * 0.5)。：這會提供優先順序值 (1.345)。
取得優先順序值之後，我們會以遞減順序排序優先權欄位，讓最高優先權的項目出現在最上方。當項目加入至產品待處理項目，或是出現更多劇本的相關資訊時，我們需要重新評估優先順序。
最後，工作表看起來就像這個表格：
.png "範例功能表 - 完成")
透過這種方式，您可以深入了解小組或的專案關係人的適用範圍。這也有助於提供較好的討論依據，因為客觀分析產品因素 (如效益、損失、成本和風險等項目) 可能有困難。
Weigers 說明如何讓模型更符合現實：
「根據舊版產品中的一組已完成需求或功能，校準這個模型以供您自己使用。調整加權因數，直到計算的優先權序列與您對需求在測試集中之重要性的追尋事實 (after-the-fact) 評估一致。當您評估建議的新需求時，這個模型也可以協助您進行交易決策。使用這個模型評估其優先權，告訴您這些需求與現有需求的吻合程度，讓您可以選擇適當的實作順序。您可以採取任何行動將需求的優先順序從政治舞台移至客觀分析的領域，這都會讓專案更能夠以最適當的順序交付最重要的功能」。
Karl Weigers 已撰寫兩本書，更詳細說明相對加權：《，第二版》(英文) 和《再說軟體需求：棘手問題與實用建議》(英文)。
無論您使用這些方法的其中一個或其他技巧，別忘了產品待處理項目是會變的。您不能只排定一次優先順序之後就加以忽略。要保持良好的待處理項目，就必須重新排列優先順序。要保持專案進度，您必須不斷重新評估劇本、劇本對專案的重要性，以及新資訊對待處理項目所自成的影響。您必須盡力讓專案關係人和客戶在整個專案中一起配合。此外，您必須記住，項目的估計對判斷其優先順序來說不可缺的。不要讓您的待處理項目變成過時和無效。投入時間和精力在維護和整備您的待處理項目，您不僅會在最終產品上，也會在您的營運收益上看到成果。
請參閱
概念
《敏捷式軟體需求》Dean Leffingwell 原著，Addison Wesley 發行
＜魅力品質與必要品質＞(英文) Noriaki Kano 原著，Quality JSQC 第 14 卷第 2 期 (1984 年 10 月)。Kano 的原始文件。