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


問題

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

分析

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

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

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

方案

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

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

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

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

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

 

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

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

 

史詩故事

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

用戶故事,優先級,用戶故事樹……迭×××發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,包括後來的三期線上沙龍的內容中常常說起。

相關文章
相關標籤/搜索