流程與流程框架

Oct. 14 09:30~10:41

 

學過Scrum的鄉民應該都知道Scrum是一種「流程框架（process framework）」而非流程（process），這兩者有何不同？為什麼要加以區分？

簡單講，流程就是一種描述什麼角色，在什麼時間，做什麼事，怎麼做，產出什麼東西的一種規範。依據規範事項多寡、詳細或簡略，流程又可以區分為「重量級流程」與「輕量級流程」。例如，Rational Unified Process（RUP）一般來講被歸類在重量級流程，而敏捷開發則屬於輕量級流程。

除了做事情的步驟，流程通常也會規範或建議做事情的方法。例如，RUP建議將需求寫成Use Case，XP建議將需求寫成story、採用TDD方式開發等。

***

流程框架和流程的關係，就好像「應用程式框架（application framework）」和「應用程式（application）」的關係—你可以用應用程式框架寫出各種不同的應用程式，例如用MFC或.NET framework寫出文書處理軟體、影像處理軟體、遊戲軟體等—你也可以用流程框架來產生適合自己團隊或組織運作的流程。

拉回到Scrum身上，身為流程框架，它只規範了角色（PO、SM、Team），活動（sprint planning、product backlog refinement workshop、daily scrum、sprint review、retrospective），產出物（product backlog、sprint backlog、potentially shippable product incremental ），至於這些活動實際上要如何進行，產出物要用何種形式表達，並沒有特別規定。

所以在Scrum裡面鄉民們看不到關於開發實務作法的規範，例如要不要pair programming、CI、TDD、refactoring，沒講。你覺得需要，就做。需求要怎麼產生，沒講。你覺得傳統軟體需求管理的方法有用，就用；覺得用design thinking、腦力激盪、Agile UX、story mapping等方式有用，就自行服用。就好像使用.Net框架寫程式一樣，要產生什麼軟體，還是要靠自己動手寫程式碼。

***

這樣的好處是，Scrum框架本身是「空」的，它的目的是用來暴露問題。至於如何「打怪」，各憑本事。不管是黑貓白貓，只要能抓老鼠的都是好貓。這樣的彈性使得Scrum可以適應不同公司、團隊、專案、文化，讓採用者自己產生自己的流程，並且持續改進它。

Scrum的優點同時也是它的缺點，對於剛開始採用Scrum的團隊，可能會覺得沒有一個「標準答案」或是「參考答案」可以先拿來照抄，又或者是把某種「參考答案」當成神聖不可修改的「標準答案」一輩子照做。其次，因為你想塞入什麼東西到框架裡面都可以，也不會有警察來開你罰單，所以可能會發生「超展開」的情況—好像各種領域的知識都可以拿來放在Scrum這頂帽子底下。多參考與吸納其他領域的做法當然是好的，但如果無法聚焦，可能會變成不斷地在收集工具、方法、新名詞，而遺忘了原本要解決的問題是什麼。

***

在框架底下，流程並非一成不變，而是要持續改善。所以說，如果你採用Scrum但你的做事方法卻沒有持續改變，那就不是在做Scrum了。

***

友藏內心獨白：幹脆自己發明一個框架好了。