這是敏捷開發使用者故事系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）
優先順序排序聽起來是乙個很簡單的工作，乙個字段無外乎「重要/一般……」，調整一下然後按排序，就出來了。
但其實裡邊有不少名堂：誰應該負責排序工作？誰最終拍板？研發因素要不要考慮？需求依賴關係導致的順序如何處理？持續交付的考慮？商業決策的考慮？
以下知識與經驗，來自於多個**，主要是部分網上資料、實際專案的訪談，並在自己現在正在做的乙個專案中得到驗證。具體應用時，應靈活掌握。
product owner負責。
在產品研發環境中，一般是產品經理；在專案開發環境中，一般是專案經理。
作為產品或專案的掌舵人，這個人必須對產品或專案的概貌非常了解，從業務概貌到業務細節，都應該了解。從業務這一點上說，了解程度要超過研發團隊本身。
有些團隊把排序工作交給客戶，非常不妥。客戶任何時候都只是淺層參與，隨時可能會懶散、不專心，因此不要嘗試把主動權交給他們。即使此事必須通過客戶，也要有內部相應的人加以把控，判斷排序的真實性。
要想既了解概貌，又了解細節，對產品經理（以下略去專案經理的情況）而言要求過高，這時候一般配備產品總監，以在更高的層面把控方向。
產品總監的工作更傾向於長遠化、市場化、人性化。比如很多消費電子類產品的產品經理負責研究新潮的功能，而產品總監則負責研究「使用這些功能的新潮的人」。
儘管一心一意希望按客戶價值排序，但實際情況是往往制約於產品功能的技術實現和依賴關係，不得不做變通。
因此，應該考慮研發團隊的介入。
什麼？客戶，產品經理，產品總監，研發團隊……導致誰說了算？說對了，這時候一般需要「產品負責人團隊」，即po團隊。
第一次聽到這種團隊，是看乙個國外遊戲團隊的開發經驗。他們的產品負責人團隊，他們引入了自己公司的高層、策劃人員（即需求開發和管理人員）、開發人員、發行商、熱心玩家等等，最終工作由主策劃（產品經理）彙總。
其實多數需求依賴都可以被避開，比如沒有「刪除功能」，在開發的初期，一樣可以登入資料庫直接暴力刪除。
但是這個會帶來以後的問題，比如要持續交付，這個讓客戶怎麼用？更深入的問題，下面繼續談。
上次在mpd做培訓的時候，有人問到乙個問題大致如下：「我們是持續交付了，但是剛開始的產品缺胳膊少腿，介面也不美觀，客戶看了直搖頭，對我們印象很差，該怎麼辦？」忙了半天才做到持續交付，居然起到反作用。
這裡邊其實發生的最大的問題是：一定要從客戶的角度理解可執行軟體和持續交付，而不要從開發角度！
從開發角度看，上了持續整合系統，每天有乙個exe或dll生成，就可執行了，可持續交付了，其實大錯特錯。
比如做乙個敏捷開發管理軟體，從第一分鐘，就是可以執行的軟體；但估計要做出可以填寫、展示使用者故事，無論如何也要到第二週；而要最後賣掉，怎麼也得有「使用者和許可權」這些次要功能。把這些所謂「次要功能」做出來之前就給客戶，而又未能向客戶說明，極有可能適得其反。
當然一種做法是：把「登入功能」提前唄，不就從第一天就能真的給客戶了？不。
作為產品而言，永遠應該把最體現差異化價值觀的功能置於萬事之前，也就是三個月內要決定產品是否值得做，六個月內決定產品的主要功能及投入多少人力，九個月到一年的時候，就發布了（這裡邊的時間點僅為舉例，需靈活掌握）。因此千萬不要把登入功能這類大路邊的功能做在前面，會積壓大量資金人力並大大推遲決策點。
比如某家遊戲企業，為了能提前獲知遊戲是否好玩，以平台化的方法做出了很多基本的能登入、能玩、能買賣、有的遊戲，新團隊只需要在上面做出核心玩法，即可提供高層做出是否繼續的判斷。
提前做體現價值觀的功能，或做出平台加速核心功能開發，都是為了更早給出決策。
專案開發的情況，本人遇到的比較少，但是顯然不應該從在開始做那些路邊的功能。
所謂故事群，是在觀察一些團隊及自己親自實踐的結果。
故事群接近史詩故事的概念，即將故事按照每個故事**付後，客戶可完整操作部分功能的方式，將若干個故事歸入一群，並嘗試在每個迭代中實現一群，交付或展示給客戶。
比如如果做乙個敏捷開發軟體，則可能規劃如下的群：
1. 使用者故事相關群
2. 迭代計畫相關群
3. 日常工作相關群
4. ……
這樣的好處包括：
1. 每個**付後，區域性的功能比較齊全，客戶可以較為完整地使用，從而可針對某類功能集中地給以反饋。
2. 由於這些功能整體在說一件事情，客戶和開發人員的精力比較集中，能把一件事情想得比較透徹。
當然，這種方法對產品經理的工作能力還是有要求的，否則乙個乙個群之間很難銜接順暢。
敏捷開發一千零一問系列之四 優先順序排錯怎麼辦？
原文出處 對於不斷更新的需求，導致需求優先順序的判斷出現了錯誤，知道專案週期後期才發現，怎麼辦？1.臨時方案 確保所有排序均是由po完成的 常常出現所謂現場客戶 由客戶出po 由乙個銷售當po的情況，都是應該避免的。po一方面要熟悉具體的需求和原始目的 廣度與細度的要求 另一方面則應該對產品的商業目...
敏捷開發一千零一問系列之四 優先順序排錯怎麼辦？
這是敏捷開發一千零一問系列的第四篇。在這裡提問，之一，之二，之三，問題總目錄 對於不斷更新的需求，導致需求優先順序的判斷出現了錯誤，知道專案週期後期才發現，怎麼辦？1.臨時方案 確保所有排序均是由po完成的 常常出現所謂現場客戶 由客戶出po 由乙個銷售當po的情況，都是應該避免的。po一方面要熟悉...
敏捷開發使用者故事系列之五 使用者故事的分類
這是敏捷開發使用者故事系列的第五篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 在之一 之二 之三中，我們曾經提到了 作為乙個 可以 以便 的使用者故事描述方式，還提到應該如何描述使用者故事，才能更好地反映客戶價值。下面請嘗試一下描述這兩個故事 1.如果把 儲存按鈕 統一放在頁面上端而非下...