敏捷開發中的MoSCoW優先順序排序方法

作者：陳勇

出處：blog.csdn.net/cheny_com

 

    有沒有遇到某個重要的條目每次都被漏下完不成的情況？

    有沒有遇到衝刺結束的時候發現一大堆條目都已經開工了但都沒有完成的情況？

    有沒有遇到Product Owner想用一個重要的變更來替代原來Sprint Backlog中的某些條目卻發現這些條目都已經“開發中”了？

   有沒有遇到團隊爭議每次都應該完成所有條目（這真的很難）還是只需要完成最重要的一些？

   有沒有遇到團隊爭議是否將Sprint延期一天來完成最後一個差點就完成的任務？

 

    這些都和MoSCoW優先順序排序方法有關。

 

一般在反覆項目計劃會上使用MoSCoW方法進行這種排序，將要Sprint Backlog中的條目分為四級（其實只有前3級）：

Must：必須做的；

Shoud：應該做的；

Could：可以做的；

Would not：不要做的。

要按照這些順序來做，保證Product Owner所需要的Must、Should完成，并力爭Could能完成；在發生重要變更的時候，犧牲Could乃至Should保證變更。

 

如果使用故事牆Story Wall進行管理，最好也按M、S、C（W其實不會出現）三個層級排放待開發的故事，優先拿M，最後動C。如果願意，可以用三種顏色的便簽紙來表示，防止M、S完成前就有人動C。

MoSCoW只是對Sprint Backlog的排序方法，更多關于敏捷中的“優先順序排序”問題，請閱讀：從優先順序排序看敏捷開發的自相似性。

 

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