敏捷開發一千零一問系列之二十六：如何進行優先級排序？

問題

如何進行優先級排序？具體故事的優先級，和版本規劃的優先級之間有何關係？

分析

敏捷開發裏邊有不少地方須要屢次進行優先級排序，本文將探討其不一樣的應用場景，及其關係。

值得注意的一點是，敏捷開發中有無數的「自類似性」，好比估算，每一年、每個月乃至天天人們都在潛移默化地估計本身的任務；又如計劃，也是每一年每個月天天都有成文或不成文的計劃；而發佈，也是每一個故事自成單元，而又與其餘的故事構成每個月的交付，進而造成幾個月的大版本交付……

因爲這些自類似的活動顆粒度不一樣，必定不要認爲只要作一次就能夠了，也不要認爲用一種方法作就能夠了。要就具體活動思考這一活動的目標是什麼，以及如何才能更好地達成這一目標。

方案

產品路線圖級別的版本優先級排序

這個是最高級別的優先級排序，排序的預見性大約在3～5年左右；排序者通常是產品總監等高級管理者；其排序的對象通常不是用戶故事，甚至不是功能模塊，而是產品線和產品。

排序思路大體是：不一樣的用戶羣須要不一樣的功能 > 所以致使產品應該面向客戶羣開發 > 識別出當前最重要的客戶羣規劃下一個產品 > 即便相同的客戶羣也須要逐步爲其提供服務 > 根據客戶的業務計劃或用戶的消費習慣制定產品的版本方案。

若是對此特別感興趣，請參考文末的連接。

應該注意的是，每每公司缺乏產品總監的職位，或者雖然有可是極少對中長期的產品規劃進行計劃，因此不少時候中層的產品經理也須要思考這個問題。

 

版本內部的迭代優先級排序

這個是中等級別的排序，排序的預見性大約在6～10個月左右；排序者通常是產品總監和產品經理；其排序的對象大約是模塊及史詩故事級別。

 

史詩故事

先說說什麼是史詩故事。敏捷開發裏邊定義史詩故事是一些「比較大」的故事，但沒有定義其絕對的尺度。火星人認爲，「業務數據」是一種很好的史詩故事尺度，好比咱們說：一個產品（假設就是敏捷開發管理工具）要管理下面的數據，請問在半年的開發週期中，應該先開發哪些？

用戶故事，優先級，用戶故事樹……迭×××發Sprint Backlog，迭代計劃會……人員，角色，權限……部門，團隊，小組……

咱們就能夠說，這樣規劃吧：

第一個月：用戶故事，優先級，用戶故事樹……

第二個月：迭×××發Sprint Backlog，迭代計劃會，任務分配Assignment……

第三個月：人員，角色，權限……

第四個月：部門，團隊，小組……

……

第N個月：整合併發佈一個版本

注意在這個尺度上，咱們幾乎不討論具體的操做（好比對「用戶」，應該有增刪改查等操做），而只會討論對哪些業務數據進行操做，這很是符合人們的工做習慣。

這種名詞性質的業務數據，就能夠看成合理的史詩故事來看待。

模塊

而若是觀察每月的內容，會發現他們比較相關，好比「人員，角色，權限」這三個功能，若是把它們分散到不一樣的迭代中，很難單獨開發。

這類強烈相關的業務數據，就能夠稱之爲「模塊」，劃分的依據仍然是業務。

儘管很難讓每一個Sprint與一個模塊一一對應，但應該創建這種意識，即每一個迭代應該開發相對集中的一個或多個模塊。

迭代排序依據

也就是怎麼決定哪一個模塊或史詩故事優先開發。人們習慣性地會根據依賴關係來開發，但這不是一個好習慣。

好比，有人認爲若系統連登陸都不能，談何繼續工做，因而就是把「人員，角色，權限」放到首位，而後極可能會是「部門，團隊，小組」，這樣萬事俱備以後，就能很好地開發用戶故事、任務分配這些功能了。其實這種作法十分不妥。

第一個可能出現的問題是：因爲尚未開發業務，因此其實很難說清楚須要什麼樣的人員、角色、權限管理辦法才能支撐業務。

第二個問題更爲突出：在第二個月完成的時候，其實咱們針對業務什麼都還沒作，形成高層領導很難理解咱們的進度，在投資、招人這些事情上會猶豫不決，由於咱們已經完成的功能很難幫助他下結論。

在新產品研發的過程當中第二個問題尤其突出，高層心急如焚急需知道產品的競爭力，而咱們正不緊不慢地搭建底層架構。

因此正確的作法是：先從核心業務入手，進行優先級排序。

沒有人員、角色、權限，那就大可以讓每一個人無需登陸就能夠管理用戶故事、優先級、用戶故事樹等；沒有部門、團隊，那就大可先認爲只有一個團隊，往後再支撐多團隊。

總之，先把核心業務作出來，判斷產品優劣以後再說。

迭代內的用戶故事排序

這個是具體開發級別的優先級排序方法，排序對象是敏捷開發的用戶故事；排序人員是產品經理（PO）；排序依據是「此功能在此版本中完成的必要性」。

排序依據

值得注意的一點是：此功能很重要，不等於此功能必須在這個迭代中完成，它極可能只要在版本發佈前完成開發就能夠了（固然，越重要就越要在早一點的迭代中實現）。那麼到底依據什麼排序呢？

仍是「「此功能在此版本中完成的必要性」」。這句話看起來很抽象，可是舉一個例子就比較清楚了。

假設這個迭代作「用戶，角色，權限」，那麼應該先作哪些用戶故事？注意這裏要探討具體的用戶故事了，而非這三個史詩故事。

多半有這麼幾個用戶故事：

增長用戶，刪除用戶（不當心寫錯了用戶名，而又不能修改），編輯用戶（的郵件），批量增長用戶，凍結用戶（保留記錄但禁止登陸）……

增長角色，分配角色到用戶，編輯角色（編輯角色的名字但不修改其權限），刪除角色……

增長權限，分配權限到角色（透過角色進而分配到用戶），分配權限到用戶，刪除權限……

能夠看出有幾個操做幾乎是必需的：增長用戶，批量增長用戶，凍結用戶，分配角色到用戶，分配權限到角色。

而另外幾個可能不太須要，好比：增長角色（能夠先寫死幾種常見的角色），編輯角色（先寫死往後再提供修改功能），增長權限……

還有幾個幾乎能夠在早期版本中不要，好比：刪除角色，刪除權限（這個是基於火星人產品的實際狀況分析的，讀者的產品或許不一樣），雖然有了更好。

MoSCoW

有了大體的概念，MoSCoW是一種具體的操做方法來幫助咱們實現。它是這幾個詞的縮寫：

Must：這個迭代必定要作的。好比前面提到的「必需」的功能。

Should：應該作，但若沒時間就算了。好比前面提到的「不太須要的」功能。

Could：不太須要的，但有了更好。好比前面提到的「幾乎早期版本中不要」的功能。

這樣，全部人就知道這個迭代中應該先作什麼了。不過，這和你們真的會這樣作還有點距離，常常須要一些技術手段，好比在故事板上，把TODO的任務按MoSCoW寫在不一樣底色的故事卡片上，在真正完成M和S以前，不許開工W的任務。

值得注意的一點是，MoSCoW能夠認爲是一種思惟方式，能夠處理全部自類似的優先級排序問題，未必只是迭代內的（儘管它的設計初衷是）。

處理灰色地帶

「若是我真的有時間，應該作那些Could的任務，仍是乾脆作下一個迭代的Must的任務？」這真是一個問題。

理論上說，下一個迭代Must的任務比這個迭代的Could任務更重要。但本人比較傾向於每一個迭代集中注意力處理一類功能，而不要零星地摻雜往後的所謂重要的功能。這樣能夠有效地防止注意力分散致使的生產率降低。

若是你不太喜歡這個結論，其實更應該嘗試一下流開發（往後會有詳細描述）。流開發須要的管理模式對人的要求更高，但用好了能夠應對不少這類問題。實際上火星人採用的就是流開發，而非迭代式開發。

不一樣優先級之間的繼承關係及處理優先級變動

是否由於「用戶」比「部門」優先級更高，而致使「增長用戶」比「增長部門」更高，以及「刪除用戶」比「增長部門」也更高？（注意不是「刪除部門」）

咱們本身嘗試的結果是：不必定。

儘管繼承關係大體存在，但用戶故事很難乾淨地從史詩故事繼承優先級；而迭代也很難從版本直接繼承。

因此要把精力放在實際業務上，而不要嘗試找到萬能方法。

另外，咱們常常在幾個月後發現原來一個原本認爲不過重要的功能，仍是必要的。爲了處理這種不斷的問題，咱們會按期安排一個迭代，稱之爲「優化……」或「重構……」迭代，其中包含了處理遺漏的功能，還包括性能優化等其餘事務。

有了這個迭代，就不是太擔憂偶然出現的優先級錯誤。另外也沒必要太擔憂這個迭代中處理的事情太雜亂而無從下手：是的，前面說過儘可能只作幾個有限的史詩故事來保證注意力集中，那是由於剛開始作版本的時候，你們不可能對全部故事都熟悉，同開始太多的事情會讓你們更加混亂；但在版本的末期，全部事情都相對熟悉了，這種內容發散的迭代影響不大，反而能幫助你們從新整合和總體思考一下不一樣的功能。

 

關於產品路線圖級別的排序在本文中有詳細描述：http://cheny.blog.51cto.com/3988930/1101465

關於MoSCoW：http://cheny.blog.51cto.com/3988930/1100076

關於史詩故事及用戶故事：這裏邊不少http://blog.csdn.net/column/details/agile.html，包括後來的三期線上沙龍的內容中常常說起。