如何進行優先級排序?具體故事的優先級,和版本規劃的優先級之間有何關係?html
敏捷開發裏邊有不少地方須要屢次進行優先級排序,本文將探討其不一樣的應用場景,及其關係。性能優化
值得注意的一點是,敏捷開發中有無數的「自類似性」,好比估算,每一年、每個月乃至天天人們都在潛移默化地估計本身的任務;又如計劃,也是每一年每個月天天都有成文或不成文的計劃;而發佈,也是每一個故事自成單元,而又與其餘的故事構成每個月的交付,進而造成幾個月的大版本交付……架構
因爲這些自類似的活動顆粒度不一樣,必定不要認爲只要作一次就能夠了,也不要認爲用一種方法作就能夠了。要就具體活動思考這一活動的目標是什麼,以及如何才能更好地達成這一目標。併發
這個是最高級別的優先級排序,排序的預見性大約在3~5年左右;排序者通常是產品總監等高級管理者;其排序的對象通常不是用戶故事,甚至不是功能模塊,而是產品線和產品。ide
排序思路大體是:不一樣的用戶羣須要不一樣的功能 > 所以致使產品應該面向客戶羣開發 > 識別出當前最重要的客戶羣規劃下一個產品 > 即便相同的客戶羣也須要逐步爲其提供服務 > 根據客戶的業務計劃或用戶的消費習慣制定產品的版本方案。工具
若是對此特別感興趣,請參考文末的連接。性能
應該注意的是,每每公司缺乏產品總監的職位,或者雖然有可是極少對中長期的產品規劃進行計劃,因此不少時候中層的產品經理也須要思考這個問題。優化
這個是中等級別的排序,排序的預見性大約在6~10個月左右;排序者通常是產品總監和產品經理;其排序的對象大約是模塊及史詩故事級別。spa
先說說什麼是史詩故事。敏捷開發裏邊定義史詩故事是一些「比較大」的故事,但沒有定義其絕對的尺度。火星人認爲,「業務數據」是一種很好的史詩故事尺度,好比咱們說:一個產品(假設就是敏捷開發管理工具)要管理下面的數據,請問在半年的開發週期中,應該先開發哪些?.net
用戶故事,優先級,用戶故事樹……迭×××發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,包括後來的三期線上沙龍的內容中常常說起。