溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
如何進行優先級排序？具體故事的優先級，和版本規劃的優先級之間有何關系？
敏捷開發里邊有很多地方需要多次進行優先級排序，本文將探討其不同的應用場景，及其關系。
值得注意的一點是，敏捷開發中有無數的“自相似性”，比如估算，每年、每月乃至每天人們都在潛移默化地估計自己的任務；又如計劃，也是每年每月每天都有成文或不成文的計劃；而發布，也是每個故事自成單元，而又與其他的故事構成每月的交付，進而形成幾個月的大版本交付……
由于這些自相似的活動顆粒度不同，一定不要認為只要做一次就可以了，也不要認為用一種方法做就可以了。要就具體活動思考這一活動的目標是什么，以及如何才能更好地達成這一目標。
這個是最高級別的優先級排序，排序的預見性大約在3～5年左右；排序者一般是產品總監等高級管理者；其排序的對象一般不是用戶故事，甚至不是功能模塊，而是產品線和產品。
排序思路大致是：不同的用戶群需要不同的功能 > 因此導致產品應該面向客戶群開發 > 識別出當前最重要的客戶群規劃下一個產品 > 即使相同的客戶群也需要逐步為其提供服務 > 根據客戶的業務計劃或用戶的消費習慣制定產品的版本方案。
如果對此特別感興趣，請參考文末的鏈接。
應該注意的是，往往公司缺少產品總監的職位，或者雖然有但是極少對中長期的產品規劃進行計劃，所以很多時候中層的產品經理也需要思考這個問題。
這個是中等級別的排序，排序的預見性大約在6～10個月左右；排序者一般是產品總監和產品經理；其排序的對象大約是模塊及史詩故事級別。
先說說什么是史詩故事。敏捷開發里邊定義史詩故事是一些“比較大”的故事，但沒有定義其絕對的尺度。火星人認為，“業務數據”是一種很好的史詩故事尺度，比如我們說：一個產品（假設就是敏捷開發管理工具）要管理下面的數據，請問在半年的開發周期中，應該先開發哪些？
用戶故事，優先級，用戶故事樹……迭×××發Sprint Backlog，迭代計劃會……人員，角色，權限……部門，團隊，小組……
我們就可以說，這樣規劃吧：
第一個月：用戶故事，優先級，用戶故事樹……
第二個月：迭×××發Sprint Backlog，迭代計劃會，任務分配Assignment……
第三個月：人員，角色，權限……
第四個月：部門，團隊，小組……
……
第N個月：整合并發布一個版本
注意在這個尺度上，我們幾乎不討論具體的操作（比如對“用戶”，應該有增刪改查等操作），而只會討論對哪些業務數據進行操作，這非常符合人們的工作習慣。
這種名詞性質的業務數據，就可以當作合理的史詩故事來看待。
而如果觀察每個月的內容，會發現他們比較相關，比如“人員，角色，權限”這三個功能，如果把它們分散到不同的迭代中，很難單獨開發。
這類強烈相關的業務數據，就可以稱之為“模塊”，劃分的依據仍然是業務。
盡管很難讓每個Sprint與一個模塊一一對應，但應該建立這種意識，即每個迭代應該開發相對集中的一個或多個模塊。
也就是怎么決定哪個模塊或史詩故事優先開發。人們習慣性地會根據依賴關系來開發，但這不是一個好習慣。
比如，有人認為若系統連登錄都不能，談何繼續工作，于是就是把“人員，角色，權限”放到首位，然后很可能會是“部門，團隊，小組”，這樣萬事俱備之后，就能很好地開發用戶故事、任務分配這些功能了。其實這種做法十分不妥。
第一個可能出現的問題是：由于還沒有開發業務，所以其實很難說清楚需要什么樣的人員、角色、權限管理辦法才能支撐業務。
第二個問題更為突出：在第二個月完成的時候，其實我們針對業務什么都還沒做，造成高層領導很難理解我們的進度，在投資、招人這些事情上會猶豫不決，因為我們已經完成的功能很難幫助他下結論。
在新產品研發的過程中第二個問題尤為突出，高層心急如焚急需知道產品的競爭力，而我們正不緊不慢地搭建底層架構。
所以正確的做法是：先從核心業務入手，進行優先級排序。
沒有人員、角色、權限，那就大可讓每個人無需登錄就可以管理用戶故事、優先級、用戶故事樹等；沒有部門、團隊，那就大可先認為只有一個團隊，日后再支撐多團隊。
總之，先把核心業務做出來，判斷產品優劣之后再說。
這個是具體開發級別的優先級排序方法，排序對象是敏捷開發的用戶故事；排序人員是產品經理（PO）；排序依據是“此功能在此版本中完成的必要性”。
值得注意的一點是：此功能很重要，不等于此功能必須在這個迭代中完成，它很可能只要在版本發布前完成開發就可以了（當然，越重要就越要在早一點的迭代中實現）。那么到底依據什么排序呢？
還是““此功能在此版本中完成的必要性””。這句話看起來很抽象，但是舉一個例子就比較清楚了。
假設這個迭代做“用戶，角色，權限”，那么應該先做哪些用戶故事？注意這里要探討具體的用戶故事了，而非這三個史詩故事。
多半有這么幾個用戶故事：
增加用戶，刪除用戶（不小心寫錯了用戶名，而又不能修改），編輯用戶（的郵件），批量增加用戶，凍結用戶（保留記錄但禁止登錄）……
增加角色，分配角色到用戶，編輯角色（編輯角色的名字但不修改其權限），刪除角色……
增加權限，分配權限到角色（透過角色進而分配到用戶），分配權限到用戶，刪除權限……
可以看出有幾個操作幾乎是必需的：增加用戶，批量增加用戶，凍結用戶，分配角色到用戶，分配權限到角色。
而另外幾個可能不太需要，比如：增加角色（可以先寫死幾種常見的角色），編輯角色（先寫死日后再提供修改功能），增加權限……
還有幾個幾乎可以在早期版本中不要，比如：刪除角色，刪除權限（這個是基于火星人產品的實際情況分析的，讀者的產品或許不同），雖然有了更好。
有了大致的概念，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，包括后來的三期線上沙龍的內容中經常提及。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
