使用MoSCoW法則排定Sprint Backlog的優先級 | IDCF

咱們在敏捷開發中一直強調要將Backlog按優先級排序，迭代的時候也嚴格按照這個優先級來開發，這樣就能夠保證咱們當下是在交付最高價值的用戶故事（User Story，如下簡稱US）了，就像下圖這樣，最高優先級的故事最早被完成：

可是咱們不少團隊實際的迭代過程倒是下圖這樣的，高優先級的故事未被完成甚至並未開始，可是低優先級的故事已經開始甚至已經完成了：

那咱們應該怎樣對Sprint Backlog進行排序，才能讓高優先級的故事最早被完成呢？本文將介紹一個優先級排序工具：MoSCoW法則，來幫助你們對Sprint Backlog作出一份合理的優先級排序。

1、什麼是MoSCoW法則

1.1 MoSCoW中的四個大寫字母

MoSCoW的四個大寫字母，M、S、C、W分別對應如下四個詞彙的首字母：

• Must have：必須有。

若是不包含，則產品不可行。Must have的功能，一般就是最小可行產品（MVP）的功能。

• Should have：應該有。

這些功能很重要，但不是必需的。雖然「應該有」的要求與「必須有」同樣重要，但它們一般能夠用另外一種方式來代替，去知足客戶要求。

• Could have：可能有。

這些要求是客戶指望的，但不是必需的，而且能夠以不多的成本改善用戶體驗，或提升客戶滿意度。若是時間充足，資源容許，一般會包括這些功能。但若是交付時間緊張，一般現階段不會作，會挪到下一階段作。

• Won’t have（this time）：（此次）不會有。

最不重要，最低迴報的項目，或在當下是不適合的要求。不會被計劃到當前交付計劃中。「（此次）不會有」的需求會被刪除，或被放入Product Backlog以便之後的Sprint從新考慮（注意：有些地方會使用Would like to have這個術語，可是這種用法是不正確的，由於最後這個優先級清楚地代表有些需求超出了本次交付的範圍）。

1.2 MoSCoW中的兩個小寫字母

MoSCoW法則中，除了上述四個詞彙的首字母外，還有兩個o，這兩個o是作什麼的？
其實莫斯科法則的全稱是：

Must or Should, Could or Won't.

爲何Must和Should中間有一個or，Could和Won't中間也有一個or，而Should和Could中間卻沒有？是否是老外爲了讀起來有朗朗上口的感受，特意這麼設計的？

其實不是的，真實緣由是由於要區分一個US是Should have仍是Could have是很容易的，可是要區分一個US是Must have仍是Should have，或者是Could have仍是Won't have的時候，不一樣的人會有不一樣的見解，即便是同一我的，不一樣時間、不一樣環境下看同一個US，也可能會得出不同的結論。這段描述是否是看得有點頭暈？不要緊，舉個例子你應該就明白了：

假設一個電商APP有如下2個US：

1.做爲一個電商APP的用戶，我想註冊一個帳號，以即可以買到我心儀的商品。（如下簡稱註冊帳號）

2.做爲一個電商APP的用戶，我想編輯個人我的資料，以即可以個性化個人我的信息。（如下簡稱編輯資料）

若是從Should have仍是Could have的角度來劃分以上2個US，大家會得出怎樣的判斷？

我在公司組織過一個10人的小組投票，結果以下：

投票結果幾乎是一邊倒，註冊帳號是應該作的（Should have），編輯資料是能夠作的（Could have）。

而後我又問了如下兩個問題：

註冊帳號是必須作的（Must have），仍是應該作的（Should have）？

編輯資料是可能作的（Could have），仍是可能不作的（Won't have）？

而後你們就吵起來了。

好比關於註冊帳號的爭論以下：

甲：沒有註冊功能，我怎麼知道是哪一個用戶下的單呢？因此我以爲是Must have。

乙：幹嗎非要有個註冊功能呢？用戶能夠用三方帳號受權登陸啊，好比微信或微博受權登陸不就能夠了嗎？因此我以爲註冊功能不是Must have，應該是Should have。

甲：登陸功能強依賴第三方APP，會被App Store拒絕上架的。

乙：那能夠接入蘋果帳號的受權登陸啊！

甲：那Android和網頁版怎麼辦呢？

乙：那能夠用微信受權登陸啊！

甲：那工做量豈不是比開發一個註冊功能還要大！

……

一樣，編輯資料這個US也是各有各的理解，可是誰也不能說服對方。

各位同窗看到這，應該就明白了MoSCoW法則中的那兩個o的做用了吧，四個字歸納就是：

求同存異

一個US，只要肯定它是Must or Should仍是Could or Won't，而不用細化到Must、Should、Could仍是Won't。

這裏插個題外話，以前一個諮詢公司的副總在給咱們最敏捷導入培訓的時候，談起敏捷宣言的誕生過程，他說了這麼一個小故事（不知道真假，你們看看就好）：

當年那17位敏捷大師在猶他州的滑雪場聚會的時候，他們一開始是想定一個你們都承認的實踐方案的（好比相似Scrum、Kanban、XP等），可是發現分歧實在太大了，每一個人都認爲本身的實踐方案是最優的，後來你們實在談不下去了，因而就退而求其次，你們發現每種實踐方案的指導思想基本都是一致的，因此就抽象出了一份《敏捷宣言》。

MoSCoW法則其實有點相似《敏捷宣言》的誕生過程，既然細節處沒法達成統一，那咱們就再向上抽象一層吧。

2、Sprint Backlog優先級的肯定

2.1 PO使用MoSCoW法則對Sprint Backlog排定優先級

在對Product Backlog的高優先級的故事進行梳理和估算以後，PO須要在Sprint計劃會以前再對這份潛在的Sprint Backlog作一次優先級的排序，排序的原則就是MoSCoW法則。PO在實際使用這個法則的時候，其實不須要刻板的拿Must or Should仍是Could or Won't這個概念往上套，而是問本身這麼一個問題：

這個US若是本次Sprint作不完，我（以及我所表明的利益相關者）能夠接受嗎？

若是能夠接受，那就把這個US放到Could or Won't，不然就放到Must or Should。
假設Sprint Backlog總共有20個US，通過PO的排序後，其中10個被劃分到了Must or Should級別（意味着必須作完），10個被劃分到了Could or Won't級別（意味着能夠作不完），PO排序完的Backlog相似這樣：

表1 PO排序後的用戶故事列表

至此，PO對優先級排序的主要工做就結束了，可是，這樣就算完成了嗎？

2.2 開發團隊對Sprint Backlog排定優先級

此時PO已經使用MoSCoW法則對Sprint Backlog作了優先級的排序，可是這個排序是PO是從「必須作完」和「能夠作不完」的角度給的（準確的說，只能算是個分類），大部分狀況下，研發團隊並不能嚴格按照這個順序來開發，舉個常見的例子：

咱們研發的大部分的功能模塊，可能都會涉及「增刪改查」的功能，作過開發的同窗都知道，這幾個功能的研發順序，通常都是聽從增→查→刪/改的順序來進行的，不作增，是無法查的；不作查，是無法刪/改的（手動操做數據庫除外）。

由於大部分PO不懂技術，因此他/她可能會把增/查放到「能夠作不完」的分類中，而把刪/改放到「必須作完」的分類中；或者把刪/改的優先級放到增/查前面，這就致使若是按照這個優先級的排序來開發，會致使研發的同窗進行不下去的。

這裏再插個題外話：

程序員跟產品經理常常互懟，本質上是由於這兩個羣體的思惟方式徹底不同：在拿到一個需求以後，技術思惟想的是：這個需求好實現麼? 實現起來須要多長時間？這樣操做會不會有性能問題，之前的代碼支持這個功能可能須要重構，那咱們趕忙團結起來，把這個需求懟回去。

而產品思惟是這樣的：這個需求是用戶須要的麼？解決了用戶的什麼痛點？能帶給用戶什麼樣的價值？功能上線後會給咱們帶來多少商業利益？我思考了這麼多問題才設計出來這麼優秀的產品方案，大家一幫程序員趕忙給我作出來，不要跟我嗶嗶什麼技術細節！

總之一句話，技術思惟可能是以自我爲中心的，而產品思惟是以用戶爲中心的。這一點致使在Backlog優先級的劃分上，兩邊也會存在分歧。而Sprint計劃會，正是解決這個分歧的最佳時機，而促成解決這個分歧的人，就是SM。

因此在PO按照MoSCoW法則作好優先級的分類後，SM要引導開發團隊對這個分類再作一次評審，通常咱們是按照如下幾個點來檢查的：

• 實現依賴

好比上面提到的增刪改查的技術依賴，被依賴的功能要排在高優先級。

• 團隊依賴

若是還有其餘團隊對咱們即將要作的US有依賴，通常這種需求要放在最高優先級。

• 技能依賴

這點在成熟的敏捷團隊可能影響會比較小，可是若是團隊裏大部分紅員還達不到一專多能的要求，你們還都是隻會一門技術，好比J2EE、Android、iOS、Web等，那在排定優先級的時候，也要考慮一下技能的依賴，好比一個團隊有2個Web研發，1組APP研發（Android+iOS）（注意，Scrum中的研發團隊是沒有嚴格的職位區分的，我這裏說的是早期的敏捷團隊，他們剛從傳統的職能部門轉成跨職能團隊，不少人早期都只會一門技術），那在排定Backlog優先級的時候，最好是按照2個Web故事→1個APP故事→2個Web故事→1個APP故事……這樣的順序來排定。

• 其餘

有時也須要考慮一下特殊狀況，好比有人會請假、某個故事難度比較大（也就是估點較多）等。

有一點請注意：研發團隊的排序前提，是在PO給定的2個大的分類範圍內進行的，原則上只能將低優先級的故事提到高優先級上（從「能夠作不完」提高到「必須作完」），若是要將一個「必須作完」的故事下降到「能夠作不完」，須要徵得PO的贊成。

通過研發團隊和PO共同排序後，US的順序可能會大變樣，並且「必須作完」和「能夠作不完」的US數量也會有所變化，相似這樣（注意和表1對比）：

表2 PO和研發團隊共同排定的優先級順序

至此，Sprint Backlog的優先級排序工做所有完成。

3、一些特殊狀況的補充說明

每一個敏捷團隊的人員組成都是不同的，技能也是不同的，作的事情也是不同的，因此上面的方法可能也不是適用於每一個團隊，可是有些特殊狀況，仍是有些應對方式的。

3.1 項目要求和研發技能不匹配

這是咱們常常遇到的一個問題，就是咱們要作的事情，可能以咱們團隊目前的人員配置，並非最合適的，好比咱們團隊有2個很厲害的APP研發，可是咱們要作的項目並無APP的任務，那怎麼辦呢？

個人作法是鼓勵你們再學習一門新的知識，在一個氛圍良好、溝通順暢、充滿心理安全感的團隊中，團隊成員是不排斥、也不害怕學習新知識的。（關於如何創建團隊的心理安全感，之後我會單獨寫一篇文章介紹的。）

那一個研發人員，須要學習多長時間才能上手一門新技術呢？

這個問題沒有明確的答案，小程序可能一週就上手，Android轉Java可能也就一、2周，可是這個也要看這個研發同窗以前的經驗如何，若是是個大神，可能上手更快，若是是個菜鳥，那可能時間要翻倍，甚至更多。可是無論怎樣，有一點SM必定要注意：

全部的學習任務，都要當作「學習型」US，放到Sprint Backlog中，而且設置明確的驗收標準（AC），好比：

做爲研發人員，我想看完《XXX從入門到放棄》，以便掌握XXX的基礎知識。

做爲研發人員，我想使用X編程語言模仿Y作一個Y demo，以便促進我更好的掌握X的知識。

學習型US，也同樣貼到Scrum板，每日站會的時候跟蹤進度。以我我的的經驗，即便是學習一項全新的知識，2個迭代（4周）基本也就能上手了。

3.2 每一個迭代開始前，都要從新評估Poduct Backlog中全部US的優先級

我在文章開始的時候舉了個例子：

做爲一個電商APP的用戶，我想編輯個人我的資料，以即可以個性化個人我的信息。（如下簡稱編輯資料）

這個US大部分人都選了Could or Won't的優先級，也就是這條是「能夠作不完」的，可是咱們能夠看下淘寶、京東等主流的電商APP，他們都是有編輯資料這個功能的，並且功能作得還都特別完善。那爲何我當時調研的人大都選擇了「能夠作不完」，而淘寶、京東他們卻不約而同的都作了個這麼盡善盡美的編輯資料功能呢？難道是咱們的判斷標準跟他們不一致？

其實不是判斷標準不同，而是編輯資料這個功能對於一個剛起步的電商軟件和一個成熟的電商軟件的價值不同：

假設電商APP的用戶中有1%的人想要用這個功能，那在項目早期，可能日活（DAU）也就幾10、上百人，即便發展到成千上萬人，可能也不會影響到多少用戶。可是若是咱們項目的DAU達到十萬、數十萬甚至百萬級別了，那影響到的用戶可能就要達到幾千甚至上萬人了，到了這個時候，編輯資料這個US的價值就大大提高了，若是到那時這個需求尚未作，PO就要在合適的時間點，將這個US挪到「必須作完」這個級別了。

關於產品不一樣時期的用戶需求的區別，你們能夠看下《精益創業》中關於種子用戶、主流用戶的描述，以及《跨越鴻溝》裏的創新者、早期使用者、早期大衆、末期大衆和滯後者模型，可能會對PO的決策有所幫助。

3.3 其餘

因爲每一個人的從事的工做不一樣、所在的團隊不一樣、團隊成員的水平也不一樣，因此可能還有一些個性化的狀況沒有談到，你們若是有問題，能夠留言一塊兒討論下。

最後但願你們帶領的每一個團隊都能有一個完美的迭代過程！

來源：小船哥說敏捷

做者：adoudou

聲明：文章得到做者受權在IDCF社區公衆號（devopshub）轉發。優質內容共享給思否平臺的技術同伴，如原做者有其餘考慮請聯繫小編刪除，致謝。

IDCF DevOps黑客馬拉松，首創端到端DevOps體驗，精益創業+敏捷開發+DevOps流水線的完美結合，2021年僅有的3場公開課，數千人蔘與並一致五星推薦的金牌訓練營，追求卓越的你必定不能錯過！關注公衆號回覆「黑馬」便可報名

北京：7月24-25日上海：9月11-12日深圳：11月20-21日