最近很多人開始在炒作Agile相關的管理方式。 提到很多好處，甚至講得好似能取代一切其餘的專案管理手法。 在這氛圍下，不免就有些朋友會開始詢問我這議題，尤其常有人提到他們公司內部有人提出想導入的聲音。 因為很多人誤以為「跑Agile表示不用做計劃，或是能更自由的隨機應變」。

但這恐怕是對Agile這方法的誤解。

所以就興起了想寫一些相關的文章。 那這篇想來談談Agile的一個分支，也就是被稱為Scrum的方法。 這篇將解釋一下這手法的目的以及期待解決的問題是甚麼。 當然，若大家對這議題有興趣，往後我將繼續談談這手法的一些詳細細節。

首先，第一個問題。 Scrum的目的到底是甚麼？

這方法的目的，其實是為了要去對應需求難以在前期明確界定的專案類型。 但因為大部分專案都還是有嚴格的時間限制。 所以Scrum將把管理重心放在需求澄清、以及需求控制上，並以時間限制的方式來做為管理的核心限制。

那在詳細解釋前，先來談談這跟傳統手法的差異在哪。

傳統專案管理的方法，是明確的分階段往後推展。 比方說先提出概念、再做設計、然後施工、萬一有問題再來修改。 這在需要投入實體資源的專案中，有其不得不為的苦衷，也有它的好處。 因為材料投入往往成本耗費甚巨，所以最好能在前期透過紙上作業的方法確定彼此的認知。 不然一旦投入材料又要修改，那可是巨額的開支。 而且也可以盡量透過小成本的逐步投入，讓變動風險盡量壓低。 (換言之，等候期大量成本投入時，需求已經很清楚了。)

可是這在面臨軟體開發專案，尤其是遊戲相關案子的開發時，這方法將會碰到兩個問題。

一個問題在於，軟體開發的成本大多都是人力。 人力配置在哪一階段，成本其實大都是類似的。 可是軟體的問題在於很多東西其實使用者並不完全清楚自己的需求為何，也往往不具備開發所需的專業知識。 往往得等實體出現後，認知才會更清楚。 對於一般使用者而言，他無法閱讀ER Diagram；但東西做出來後，他才會突然跟你說，那個同樣公司的客戶，有辦法透過選單來選，而不要每次都由使用者手動輸入嗎？

遊戲開發時這狀況更明顯。 舉例而言，馬力歐的跳躍感是無法靠規格書來描述的。 必須等整個馬力歐世界都構築出來，包含主角、包含磚塊、包含敵人的移動方式，真正的呈現在螢幕上，並跟角色互動了，我們才能知道這樣的跳躍模式到底是否有充分的遊戲性以及挑戰性。 所以很難讓大家分頭工作，最後整合起來就自動1+1=2的變成一個好玩的遊戲。 反而是得有一個摸索期，做出簡單的可動版本來找出遊戲的關鍵好玩之處。 等關鍵確定後，再考量剩餘時間，加入其餘的配料。

所以Scrum或是Agile等方法的核心概念就是 - 既然使用者很可能無法一下子定義出自己的真實需求，很多東西也很難紙上靠流程圖或規格書來解釋清楚，那為何我們不盡快的做個Prototype？

這Prototype不用很完美，也不用一次就完整，只要能每次精進一些。 每次都讓使用者能多看到些東西、能按些按鈕、能有些反饋，這才會知道產品到底跟他想像的有沒有任何差異。 然後隨著逐次使用者的回饋，每次重新計畫，讓下一階段的Prototype能越來越朝向正確的方向。

這就有點像雕刻一個雕像一般。 我們一開始是個方形的大理石，我們並不是先精細雕刻出鼻子或眼睛。 而是先把方形大理石的周圍大範圍的敲出一個人型。 看看比例是否OK，型態是否如我們想要的。 沒問題，繼續敲敲打打，這時候看出姿勢與動作。 還是沒問題，那再把五官跟手指的形狀修出來。 臉會不會太寬？ 肌肉線條還需不需要修？ 然後把肌肉的張力以及表情在生動的修上。 換句話說，逐漸的精細化。

聽到這裡，可能有讀者會直覺認為。 如果是逐步修正，表示就避開了一開始做大量計畫的時段了嘛。 因為傳統專案管理方法，很重視前期的訪談、紀錄、與紙上規劃。 以及透過紙上規劃與各利害關係人的交互驗證。 如果我可以直接做個版本去跟利害關係人討論，那不就等於規畫整個被跳過了？

這就是一般人最大的誤解了，所以請仔細看一下我幫大家歸納出的五大重點：

1. 透過短的階段，盡快作需求上的驗證。

這類方法的目的，都是覺得與其前面做很多流程圖與規格書讓User畫押，還不如先根據User模糊的需求，在很短的時間之內(如2周到4周間)，開發出一個可執行的版本。 (根據書中的定義，兩三個循環後，每次完成的版本甚至應該是要能立刻上市的。 這句話的意思是說，如果一些需求沒完成，但若User看完這版本決定那些需求放棄不做，那現在這版本就要立刻能上線。)

而根據每次的版本，使用者(在Scrum中稱為Product Owner的人)將檢視目前版本，調整他手上的需求清單(稱為Product Backlog)。 看哪些需求要再加入，哪些需求的重要性是否要調整。 並據此在跟開發團隊討論，定出下階段要能實現或修改的功能。

換言之，每個循環都要先滿足「首要功能」。 若首要功能及早滿足，這產品甚至有可能可以提早上線。 至於次要功能，則是看時間來決定加入多少。 若開發時間到了，首要功能有達到、但次要功能有些沒完成的，也必須強制犧牲。

2. 時間主導 無法做完的就放棄

這方法另一個考量的重點，在於堅守時間。 每個周期中，必須根據Product Owner定義的需求優先順序開發，沒完成的需求就往後推移。 萬一到的最終的上線日期(或上市日期)，還有一些次要需求未能完成，那這些需求將必須被割捨。 要不是下個案子再放入，要不就是得當成下個版本的需求了。

所以這方法其實跟所有專案管理的手法考量點都相同，就是時間主導。 因為就現實面而言，幾乎9成的專案而言時間其實都是最重要的。 所以這方法的重點在於盡一切力量在時限前，提供一個符合「主要價值」的產出。

3. 提供更多的成員自主性，但也仰賴團隊的成熟度

Scrum的書裏頭，常常會強調Empowerment這個字。 意思是說，在這類方法中，必須放更多的管理責任在團隊身上。 PM將從一個完全主導的腳色，退居成一個Facilitator。 除了主導每日進度會議，做流程改善、解決問題、整合團隊外，倒是不做細節規畫。 而要團隊來根據每個周期的需求，自己來做工作規劃。 (也就是Scrum Backlog)

書裡頭講的好聽，用Empowerment(授權)這個字，但實際上其實意味著工作團隊除了本業工作外，還得了解其他的專業，並得做大量的溝通與合作。

這其實是很多公司要導Scrum第一個會碰到的問題。 因為若你手上有一大批沉默寡言、對於自己以外工作豪不感興趣的一群人時，要一下子導入這樣的方案，常常就會有所衝突了。

4. 團隊整合必須很緊密

Scrum是一個抓大放小的方法。 換言之，我們先解決最核心的需求，行有餘力慢慢把其次的需要加入。

所以從這角度來看，團隊強，有可能在時限內可以完成很多內容。 但團隊若很弱，缺乏跨專業的整合能力時，要就是只完成了少量的關鍵功能，並放棄其他需求。 或是不斷調整做法，最後只完成唯一的首要功能都有可能。

所以並不是說用了這方法，產值會暴增。 產值跟用甚麼方法是毫不相干的。 這方法的目的還是在於確認需求、抓大放小、以及防止Matrix組織中常見資源被抽調的問題(因為Scrum比較像一個小型的Projectized組織，人員是必須Dedicate在專案中)。

5. 需要更多的規畫，而非更少的規畫

最多人有誤解的，在於以為使用這類更機動的管理方法，計畫就可以更機動。 甚至希望可以甚麼計畫都不做，大家機動對抗問題就好。

但這是完全的誤解，也是一個非常嚴重的誤解！

Scrum的方法中，計畫的要求其實恐怕比傳統Waterfall還嚴格。 甚至如果是完全遵照這方法執行的團隊，執行計畫的總人時，會遠比Waterfall還來的多。

這是因為在一般專案管理的方法中，大部分的計畫責任是放在PM身上，極高比例的團隊成員都是「執行者」。 PM把計劃做好後，大家則照著執行。 所以專案的花在計畫的「總人時」並不多。

加上另一個更現實的問題在於，就是呢.. 就算PM想花很長時間規劃，但現今大部分公司的經理人對於專案管理概念都不足，很少老闆會能理解為何PM花個兩三個禮拜，甚麼都不做，只是自己埋頭分析與計畫。

所以一般而言，除非是大型工程的專案、且有業主強制要求做計劃審核。 否則一般專案能有個一周做計劃、寫文件、開會，在很多公司裏頭已經是極限了。

可是對於Scrum來說，他起始的計劃時間雖然看似不多，但每個周期的開始與結束，可是強制要團隊必須根據Product Owner新的需求清單檢視，檢討、重新開會，並做出下一周期的計畫。 而每次計畫都需要安排一到兩個完整工作天。 除了這以外，每天也必須有段時間做Daily Scrum的日回報與日計畫。 所以整個累積起來，其實是很多的。

尤其因為每次計畫都需要所有專案成員加入。 所以若一個團隊有十個人，每投入一天的Sprint Planning Meeting(也就是階段前的計畫會議)就等於10人日的計畫時間。 而如果是個一年的案子，並以每四周做為一個周期的話，表示會跑約十二個周期。 每個周期開始前若都需要一整天來計畫，並全員(10人)都加入。 這表示整個專案生命週期會最少花上120個人日作計畫。

相較傳統以一個PM投入規劃的狀態而言，120個人日等於4個日曆月、等於5.4個工作月。 所以計畫時數其實更多，而非更少。

但這本來就是他的目的。 因為計畫這件事情，本來在任何專案就都很重要。 Scrum把計畫的時數拆散，讓大家感覺好像變少了，但實際其實是變多了。

以上是一些粗淺的概念介紹，若大家有興趣，歡迎在文末留言。

(至於有明確問題的，歡迎到討論區開設主題。 如此將方便其他User能針對您的問題一起參與討論。)