出處：blog.csdn.net/cheny_com
自相似性是指乙個事物的區域性與其更大的區域性乃至整體具有相似性。
從大的方面看，敏捷開發具有重視客戶價值，提倡持續交付等思想。但一般而言，
product owner
常常具備相當好的客戶價值意識，而一線開發人員則比較關注技術本身，所以一旦僅僅停留在思想層面，在實際工作的時候就會發現有所背離。因此應該從自相似性的眼光看待敏捷開發的整體思想與區域性實踐，從而做到年年月月日日事事均符合敏捷開發的思想。
本文只從「優先順序排序」這乙個敏捷開發思想來分析敏捷開發的自相似性。
「優先順序排序？是不是就是
product owner
在開計畫會前要做的事情？」是，也不是。
對
product backlog
的排序這次排序的目的，是弄清楚哪些需求最重要因此可能在最近的一兩次迭代中進行開發。參與排序的條目一般足夠接近半年的開發工作量，但多數只有乙個簡短的名稱，只有最高優先順序的需求才會被真正細化，也就是近一兩次迭代要開發的需求列表。這個需求列表其實有乙個專門的名稱：
willing list
，「意向表」。
為什麼要用意向表做緩衝，而不是直接形成下個衝刺的
sprint backlog
？因為在計畫會之前估算都很粗略，其實沒辦法準確列出下個衝刺工作量的條目；而且
product owner
應該細化或至少是深入了解超過乙個衝刺的開發項，才能使這個衝刺的開發具備一定的前瞻性。
對
willing list
的排序這個過程是在計畫會上進行的，也可以說是按「優先順序」從中挑選出本次衝刺要開發的條目的過程，也就是常說的
sprint backlog
。要完成這個選擇其實不太容易，因為如果只是盯著「重要程度」這個排序依據，極有可能從很多功能模組中各自挑出最重要的需求，而這些需求湊在一起，只能形成乙個四不像的版本。因此常常可以挑選最重要的功能模組中的多個條目，形成整體完整的乙個「故事群」，這樣無論開發、測試和演示環節，都有乙個相對內聚的目標。
為了防止大家中途跑偏，常常給每個衝刺要都起乙個簡短的名稱，比如：「本次迭代將發布乙個具有電子節目單的版本。」
對
sprint backlog
的排序sprint backlog
也要排序？是的。有沒有遇到某個重要的條目每次都被漏下完不成的情況？有沒有遇到衝刺結束的時候發現一大堆條目都已經開工了但都沒有完成的情況？有沒有遇到
product owner
想用乙個重要的變更來替代原來
sprint backlog
中的某些條目卻發現這些條目都已經「開發中」了？有沒有遇到團隊爭議每次都應該完成所有條目（這真的很難）還是只需要完成最重要的一些？這都是因為沒有對
sprint backlog
排序的結果。
一般在迭代計畫會上使用
moscow
方法進行這種排序，
must
：必須做的；
shoud
：應該做的；
could
：可以做的；
would not
：不要做的。要按照這些順序來做，保證
product owner
所需要的
must
、should
完成，並力爭
could
能完成；在發生重要變更的時候，犧牲
could
乃至should
保證變更。
對
story wall
的排序任務都上故事牆了還要排序？是的。故事牆一般按照待開發、開發中、待測試、測試中、完成幾列，但很容易出現越來越多故事進入了開發中、測試中，卻很少進入完成。這是因為
moscow
方法做虛了，沒有真正執行好。故事板的乙個重要功能就是監控「開發中的故事的數量」（這個筆者也是在一年前左右才剛聽到），因此一般「開發中」這一列是最窄的，只能放下為數不多的條目，目的就是為了防止上一段開頭提出的各種問題。
而且「待開發」這一列中的故事，一般也按m、
s、c（
w其實不會出現）三個級別排放，優先拿
m，最後動
c。如果願意，可以用三種顏色的便簽紙來表示。
對
version
的排序還有？是的，其實最開始漏掉了最大乙個級別的排序：如果產品開發生命週期很長，每個版本應該順序包含哪些內容呢？最好的答案是：按照商業步調計畫版本內容，也就是每個版本出來後，都要滿足某些需求、獲取某些客戶、打敗某些對手、取代某些產品……
如果產品能迅速獲取良好的市場反饋回籠資金，高層領導一般都會馬上向專案投錢投人；反正他們會在推進和放棄專案之間糾結。很多專案經理熱切期盼領導重視和投入自己的專案，卻不知道其實命運其實就掌握在自己手中！
本文所提內容的相關細節，可在博主部落格分類「敏捷開發」下找到。
敏捷開發中的MoSCoW優先順序排序方法
出處 blog.csdn.net cheny com 有沒有遇到某個重要的條目每次都被漏下完不成的情況？有沒有遇到衝刺結束的時候發現一大堆條目都已經開工了但都沒有完成的情況？有沒有遇到product owner 想用乙個重要的變更來替代原來 sprint backlog 中的某些條目卻發現這些條目都...
敏捷開發使用者故事系列之四 優先順序排序
這是敏捷開發使用者故事系列的第四篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 優先順序排序聽起來是乙個很簡單的工作，乙個字段無外乎 重要 一般 調整一下然後按排序，就出來了。但其實裡邊有不少名堂 誰應該負責排序工作？誰最終拍板？研發因素要不要考慮？需求依賴關係導致的順序如何處理？持續交付...
敏捷開發一千零一問系列之四 優先順序排錯怎麼辦？
原文出處 對於不斷更新的需求，導致需求優先順序的判斷出現了錯誤，知道專案週期後期才發現，怎麼辦？1.臨時方案 確保所有排序均是由po完成的 常常出現所謂現場客戶 由客戶出po 由乙個銷售當po的情況，都是應該避免的。po一方面要熟悉具體的需求和原始目的 廣度與細度的要求 另一方面則應該對產品的商業目...