敏捷開發使用者故事系列之四：優先順序排序

這是敏捷開發使用者故事系列的第四篇。（欄目目錄）

優先順序排序聽起來是一個很簡單的工作，一個欄位無外乎“重要/一般……”，調整一下然後按排序，就出來了。

但其實裡邊有不少名堂：誰應該負責排序工作？誰最終拍板？研發因素要不要考慮？需求依賴關係導致的順序如何處理？持續傳遞的考慮？商業決策的考慮？

以下知識與經驗，來自於多個來源，主要是部分網上資料、實際項目的訪談，並在自己現在正在做的一個項目中得到驗證。具體應用時，應靈活掌握。

誰負責排序？

Product Owner負責。

在產品研發環境中，一般是產品經理；在項目開發環境中，一般是專案經理。

作為產品或項目的掌舵人，這個人必須對產品或項目的概貌非常瞭解，從業務概貌到業務細節，都應該瞭解。從業務這一點上說，瞭解程度要超過研發團隊本身。

有些團隊把排序工作交給客戶，非常不妥。客戶任何時候都只是淺層參與，隨時可能會懶散、不專心，因此不要嘗試把主動權交給他們。即使此事必須通過客戶，也要有內部相應的人加以把控，判斷排序的真實性。

誰負責拍板？

要想既瞭解概貌，又瞭解細節，對產品經理（以下略去專案經理的情況）而言要求過高，這時候一般配備產品總監，以在更高的層面把控方向。

產品總監的工作更傾向於長遠化、市場化、人性化。比如很多消費電子類產品的產品經理負責研究新潮的功能，而產品總監則負責研究“使用這些功能的新潮的人”。

研發因素的考慮

儘管一心一意希望按客戶價值排序，但實際情況是往往制約於產品功能的技術實現和依賴關係，不得不做變通。

因此，應該考慮研發團隊的介入。

什嗎？客戶，產品經理，產品總監，研發團隊……導致誰說了算？說對了，這時候一般需要“產品負責人團隊”，即PO團隊。

第一次聽到這種團隊，是看一個國外遊戲團隊的開發經驗。他們的產品負責人團隊，他們引入了自己公司的高層、策劃人員（即需求開發和管理員）、開發人員、發行商、熱心玩家等等，最終工作由主策劃（產品經理）匯總。

需求依賴的考慮

其實多數需求依賴都可以被避開，比如沒有“刪除功能”，在開發的初期，一樣可以登入資料庫直接暴力刪除。

但是這個會帶來以後的問題，比如要持續傳遞，這個讓客戶怎麼用？更深入的問題，下面繼續談。

持續傳遞的考慮

上次在MPD做培訓的時候，有人問到一個問題大致如下：“我們是持續傳遞了，但是剛開始的產品缺胳膊少腿，介面也不美觀，客戶看了直搖頭，對我們印象很差，該怎麼辦？”忙了半天才做到持續傳遞，居然起到反作用。

這裡邊其實發生的最大的問題是：一定要從客戶的角度理解可運行軟體和持續傳遞，而不要從開發角度！

從開發角度看，上了持續整合系統，每天有一個EXE或DLL產生，就可運行了，可持續傳遞了，其實大錯特錯。

比如做一個敏捷開發管理軟體，從第一分鐘，就是可以啟動並執行軟體；但估計要做出可以填寫、展示使用者故事，無論如何也要到第二周；而要最後賣掉，怎麼也得有“使用者和許可權”這些次要功能。把這些所謂“次要功能”做出來之前就給客戶，而又未能向客戶說明，極有可能適得其反。

當然一種做法是：把“登入功能”提前唄，不就從第一天就能真的給客戶了？不。

商業決策的考慮

作為產品而言，永遠應該把最體現差異化價值觀的功能置於萬事之前，也就是三個月內要決定產品是否值得做，六個月內決定產品的主要功能及投入多少人力，九個月到一年的時候，就發布了（這裡邊的時間點僅為舉例，需靈活掌握）。因此千萬不要把登入功能這類大路邊的功能做在前面，會積壓大量資金人力並大大延遲決策點。

比如某家遊戲企業，為了能提前獲知遊戲是否好玩，以平台化的方法做出了很多基本的能登入、能玩、能買賣、有圖片的遊戲，新團隊只需要在上面做出核心玩法，即可提供高層做出是否繼續的判斷。

提前做體現價值觀的功能，或做出平台加速核心功能開發，都是為了更早給出決策。

項目開發的情況，本人遇到的比較少，但是顯然不應該從在開始做那些路邊的功能。

最佳實務：故事群

所謂故事群，是在觀察一些團隊及自己親自實踐的結果。

故事群接近史詩故事的概念，即將故事按照每個故事群交付後，客戶可完整操作部分功能的方式，將若干個故事歸入一群，並嘗試在每個迭代中實現一群，交付或展示給客戶。

比如如果做一個敏捷開發軟體，則可能規劃如下的群：

1. 使用者故事相關群

2. 反覆項目計劃相關群

3. 日常工作相關群

4. ……

這樣的好處包括：

1. 每個群交付後，局部的功能比較齊全，客戶可以較為完整地使用，從而可針對某類功能集中地給以反饋。

2. 由於這些功能整體在說一件事情，客戶和開發人員的精力比較集中，能把一件事情想得比較透徹。

當然，這種方法對產品經理的工作能力還是有要求的，否則一個一個群之間很難銜接順暢。

 

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》