敏捷開發一千零一問系列之二十六：如何進行優先順序排序？
這是敏捷開發一千零一問系列的第二十六篇。（在這裡提問，之一，之二，之三，問題總目錄）
問題
如何進行優先順序排序？具體故事的優先順序，和版本規劃的優先順序之間有何關係？
分析
敏捷開發裡邊有很多地方需要多次進行優先順序排序，本文將探討其不同的應用場景，及其關係。
值得注意的一點是，敏捷開發中有無數的“自相似性”，比如估算，每年、每月乃至每天人們都在潛移默化地估計自己的任務；又如計劃，也是每年每月每天都有成文或不成文的計劃；而釋出，也是每個故事自成單元，而又與其他的故事構成每月的交付，進而形成幾個月的大版本交付……
由於這些自相似的活動顆粒度不同，一定不要認為只要做一次就可以了，也不要認為用一種方法做就可以了。要就具體活動思考這一活動的目標是什麼，以及如何才能更好地達成這一目標。
方案
產品路線圖級別的版本優先順序排序
這個是最高級別的優先順序排序，排序的預見性大約在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任務更重要。但本人比較傾向於每個迭代集中注意力處理一類功能，而不要零星地摻雜日後的所謂重要的功能。這樣可以有效地防止注意力分散導致的生產率下降。
如果你不太喜歡這個結論，其實更應該嘗試一下流開發（日後會有詳細描述）。流開發需要的管理模式對人的要求更高，但用好了可以應對很多這類問題。實際上火星人採用的就是流開發，而非迭代式開發。