Scrum 是什麼？我們一定要用它嗎

    看到我前面的文章很多次提到 Scrum 那麼，Scrum 究竟是什麼？他其實是 Agile（敏捷開發）的其中一支
，對 Scrum 執行內容有興趣的讀者可以參考 Scrum Guide 的網站說明。在說明 Scrum 的核心概念前，要先來聊聊他與我們慣用的方式差在哪裡。

    我們習慣的瀑布式 (Waterfall)  通常就是先用 WBS 分拆工作擬定需求，再來詳細的分配工作，並把所需要的格式與文件都打得盡善盡美，之後，就是讓底下的成員把每個規劃好的行程與任務完成，如果前面的規劃流程與分拆是完整的，那之後的製作與產出也會輕鬆容易。

    但是，現在的產業不一樣了。Scrum 是因為網路業的興起，許多的測試進程都縮短許多，因此如果照之前的流程，會有許多的時間是浪費的，因此也才跑出了新的專案管理流程。在現在這個需求更改越來越快的時代，消費者越來越不知道我們要什麼，那麼如果依照舊的模式，我們每發現一次需求更改，我們就要在改動一次。

下列是 Scrum 的四大宣言：

• 個體與互動 重於 過程和工具
• 可用的軟體 重於 完備的文件
• 客户協作   重於 合同談判
• 響應變化   重於 遵循計畫

    Scrum 的核心定義是：沒辦法可以很即時知道消費者需要的是什麼，所以我們需要做出來，才去看我們的產品符不符合客戶需求。就像，我們還沒開始製作遊戲，怎麼會知道楓之谷（我們這一輩都知道的）的打怪遊戲是吸引人的，不像是如果在開發的時候遇到了更吸引人的線上遊戲模式，當然不可能等到做完，才發現自己差人家一階。在製作的時候就是需要一直測試並作出 Protottype（原型），並端到消費者面前，藉由回饋慢慢更正，最後才能製作出一個完整且符合消費者需求的產品。

    那麼是不是 Waterfall 真的就一無是處？不，只是使用的地方不一樣，所以這篇文章不是打臉 Waterfall ，Waterfall 的本意就是為了降低未來可能的成本，像是一次測試就要花你 100 萬，你要不要好好考慮？這篇的目的是要澄清，現在的活動或任務，不一定適合我們習慣的方式。

那究竟要不要用 Scrum ？我們可以用幾點要點來判斷：

1. 你要做的產品（活動）是不是需求很不清楚？

      我們如果單純要辦一場吉他成果發表會，使用 Scrum 的結果是，大家會一直受到流程修正的打斷，況且歌曲就是選定的那幾首，難道我們還要每個禮拜練一首，試試哪一首比較好聽？情況轉到ㄇ業界，如果我們要蓋一棟房子，我們一定要有完善的規劃流程，並再三確認前置作業是足夠的，才能把地基房子建上去，有看過建商在試蓋的嗎？

      所以，我們如果想要演出一場好的戲，但是這齣戲的主題並不明確，那我們就可以採行這個方式，透過快速的修正以及不停的討論，讓整齣戲趨向我們要的模樣。同理，軟體業也是一樣，因應這個時代快速的需求變動，採取 Scrum 可以更快速的因應消費者的需求。

2. 團隊可以承受劇烈的組織更動。

      這點，我相信是這幾點裡面最重要的，因為要有巨大的改變，就必須承受巨大的風險。筆者之前剛學 Scrum 的時候，因為在專案開始時，就直接導入 Scrum 的工作模式。雖然在一開始，所有的樣貌都很美好，然而，當團隊的推進遇到問題時，有些人就會開始傾向改回原本的模式，甚至開始批評本身的方法無效，導致組織的內部衝突。如果一開始沒有決心，那還不如不要導入。

3. 團隊的每個人需要有足夠獨立運作的能力。

      因為 Scrum 強調每個人「自主認領」自己想要的任務（Task），所以他給予了更多的「自由度」，也因此，它要求團隊裡面的人幾乎都要有即戰力，這也代表，如果團隊的人不夠有自己的做事邏輯，或是自己無法獨立完成一些任務，採用這個方式只會導致事倍功半。

    通常在現實是——沒有那麼多時間可以讓你去導入這套工作流程（唉），你有看過在帶活動的幹部群，有先讓他們學習管理模式，並有系統的訓練他們的基本能力？通常都是先問有沒有人要參加，之後就在一陣混亂中，大家開始自己要做的事情，最後的慣性就會讓大家趨向之前的工作方式。讓整個活動以最讓人所知的方式進行。

    看到這裡，大家可能會有一個誤會：Scrum 可以少掉前面的規劃，或是，因為我們跑 Scrum 所以我們隨機應變。大家從前面看起來，會以為 Scrum 就可以少掉前面的規劃步驟，讓整體的流程更快速。但其實完全相反。

      Scrum 的重點就在於：利用快速的反饋以及修正，配合「團隊的大量溝通」提升透明度，以產出符合客戶的需求。所以 Scrum 其實更需要更多的計畫以及規範，因為在每一輪的衝刺（sprint, 是每次測試計畫的一次週期，通常都是 2~4 個禮拜），都要重新訂定每一次的目標以及調整需求清單（在 Scrum 裡稱 Product Backlog），每一次的推進都要滿足最優先項的要求，所需要的時間以及嚴謹度，並不會比 Waterfall 的方式更少。而且， Scrum 本身就是建立在大量的變動與更改需求的情境下，自然需要更多的規劃以及解決問題。

    再來，所花的規劃時間也不會比 Waterfall 的總人時（每個人時間的加總）還要少：因為時間其實都在每一天的每日立會、衝刺前的階段計畫會議，衝刺後的回顧會議中分散掉了。一個人每次花 15 分鐘，十個人就是 150 分鐘了，每天開的情況下，累積起來的總人時其實反而會比一班的瀑布式流程還多。

    所以，有沒有決心以及需不需要導入 Scrum ，就看團隊的需求以及團隊的素質了。

你可能會想要看：

活動總是改來改去？—淺談現代的專案管理如何改善流程

一個好的活動怎麼完成？從小活動一個一個完成—從辦活動淺談 WBS 的專案作法