top of page

MoSCoW 的意義

我們來看看源自於 DSDM 的 MoSCow 手法,可以如何應用在自己的案子:


敏捷專案的倒三角特性,在時程與成本是fixed的前提下,習慣瀑布式專案管理的朋友們可以來想想:從 Risk 角度來看的話,時程與成本都不能動那我們的應變回應 Contingency 應該放在哪裡?


Agile to the Rescue!!!

Contingency 從 Time 與 Costs 轉換成了 Features(Scope)。


因為你可以在 Scope 上有所取捨,Features 的名單 Product Backlog 即變成一個你管理應變的一項重要機制。


MoSCoW 的應用法則是這樣的:
  • Must:包括 Minimum Viable Product, Minimum Usable Subset 大約是 60% of the total development effort

  • Should:約 20% of the total development effort

  • Could:約 20% of the total development effort

  • Won't:0%


既然 Won't 不用做,那為何要specify呢?

因為你要在範疇外圍畫下明顯的界線,利害關係人的 Expectation 才能被好好的管理。


ShouldCould 對於決策人來說怎麼分?

把 Features 拿出來看,若是沒有了的痛苦指數是什麼?痛苦指數高的那一半應該就是 Should ,低的可以放在 Could


60% of total development effort

任何時候想要把 Must 裡面要研發的 Features 移到後段時,建議這樣考量:

  1. 沒有這個 Feature 的話,會讓原來 Business Case 的目的消失,專案失去意義。

  2. 沒有這個 Feature 的話,整個專案會不合法。

  3. 沒有這個 Feature 的話,安全性會消失。


在不違反上述任一原則為前提的情況下,再以60%、80%、100%來看,就是團隊奮鬥的目標。


worst case 要完成 must have

average case 就是要 M+S

best case 就是 M+S+C


要知道敏捷裡面沒有 Perfection ,所以任何在60%到100%之間,而且產品是 Fit for Purpose 的(東西客戶用了有他預想的價值產生的),就可以算是一個成功的敏捷專案喔!


文章同步刊登於:台灣敏捷部落臉書社群

Recent Posts

See All
bottom of page