月份: 2021 年 4 月

前文原本是想聊聊在筆者經驗中遇到的敏捷式開發議題，不意卻帶出幾個迷思，而透過這些迷思往前推演和找出解答，恰恰也能或多或少讓人更了解敏捷開發的樣貌，所以我決定一一針對先前提出的迷思做延伸探討。

首先是這個:

我團隊的研發速度相當慢，是不是應該導入Scrum ?

說到研發速度慢這件事，在Boss、Engineer兩個族群勢必會掀起一場大戰，為什麼我不提PM呢？因為在我心中，PM應該是跟Engineer同一陣線，換句話說，如果有速度慢這種問題，兩個職位的人都應該一起概括承受。

再回到速度慢這件事情，在開始之前我想說一個歪理，不知道各位重新去審視一個軟體專案從開始到結束的整個過程，像不像是場比賽？我講的不是那種相互較勁、你死我活的鬥爭，而是一場少了一個人都不行的球賽，找個類型來比擬，如果以筆者最喜愛也最熟悉的，那就是非棒球賽莫屬了。

簡單說一下棒球比賽，比賽中有兩個球隊，各有9個球員可以上場，教練團則分別有總教練、首席教練、打擊教練等等等，從投手丟出第一球給對方打擊開始，彼此球員注重的就只有兩件事情，一是想辦法讓自己的球員站上壘包，最後跑回本壘；一是盡量守住壘包，不要讓對方球員跑回本壘；最後，計算兩個隊伍各得了幾分，分數高的獲勝。

撇開軟體專案的最後的付費流程，我們專注在整個案子的進行，從專案經理啟動會議的第一步開始，就好似在球賽丟出第一球，接下來我們要專注地在兩件事情，一是得分、一是避免失分，更好的情況是要得分得的對方心服口服。

當然，我更想告訴你的是，提個發問，如果速度快就等於時間短，那一場時間短的球賽，就篤定是場好球賽嗎？我相信你會有些模擬兩可的答案，若從這個角度回來思考研發速度，那或許你的心中就會有答案了。

一語畢之, 一個好的開發專案, 就像一場精彩的球賽, 速度未必是最重要的！

當然你還是可以說, 有些球賽還是要講究速度, 畢竟早點打完可以早點休息之類的, 但這不是本篇文章的重點, 我相信喜歡看球賽的人並不在乎時間的長短在對, 但是構成一場好球賽的必要條件是什麼？想當然, 要有天時地利人和, 首先球員實力不能相差太大, 再來大家要鬥志高昂, 接著就要對比戰術高下, 團隊默契, 剩下就看棒球之神眷顧誰了！

在軟體開發的世界, 不外乎也是如此, 你的團隊成員之間不會有太大的落差, 當然我指的不是單一樣技能, 而是對事情的掌控和處理能力, 好比在球賽中, 你不能去比較投手和一壘手的全壘打能力, 畢竟他們本身就肩負不同任務, 但你會希望他們有最好默契, 二壘手、游擊手可以攔下每個被打出的球, 減少投手失分的危機, 更快抓到出局數; 寫程式, 差不多也是這樣, 當你把一個功能往下派, 當然希望他能被有效分工, 然後有效率地被執行完成, 讓負責Backend的人, UIUX的人, 處理商業模式的人接到工作後, 知道自己要做什麼, 也大概知道彼此要做什麼。

而游擊手拋球給一壘手封殺跑者的行為, 通常就像我們研發人員之間會有的共同開發介面一樣, 有了共同的溝通管道, 才能合作無間, 不至於漏了球, 然後一路滾到對方休息區去！不過再講下去可能就偏太遠了,回到原點來看。

引入敏捷式開發的其中一個效益, 是讓你的成員可以確實分工, 再來, 磨合彼此間的默契, 讓大家有共通的溝通管道, 當團隊運作到一個熟悉的程度時, 自然是看到工作時, 就能直觀地知道自己該做什麼事情, 畢竟你是投手, 你不會去搶外野的球吧？

所以, 如果你有一個夠敏捷的團隊, 你可以想見的, 是成員之間有默契, 且知道彼此要做什麼, 任務一派下來, 就能各自去執行, 不需要花時間去做多餘溝通, 我這裡會強調多餘溝通, 是因為溝通還是必要的, 但不需要反反覆覆去確認一些沒有意義的垃圾問題, 無形中也浪費大家的時間。

所以你需要一個好的棒球教練, 又或者該說, 在敏捷開發中, 你需要一個好的Product Owner, 請注意, 我講的不是Scrum Master, 因為 SM (Scrum Master)專注處理球賽以外的事情, 確保球賽可以正常運作, 但是比賽該怎麼打下去, 則應該是PO (Product Owner) 的責任。

那在有一個好教練的情況下, 你可以培訓出一個精良的隊伍, 訓練有素、默契十足, 面對問題時可以從容應對, 回到球賽來看, 如果戰況順利, 把對手碾壓過去, 自然打完一場比賽的時間就快了, 但是如果戰況膠著, 雙方你來我往, 速度就難講了, 但可以保證的是, 我們至少可以發揮十足十的實力來面對問題, 對吧？

所以導入敏捷開發, 未必可以加速你的專案時間, 但可以把你團隊的實力發揮到百分之百, 能不能加快速度, 就要看你面對什麼樣的案子了。

寫在前面

從我的自我介紹中，或許很難想像我會和敏捷管理、Scrum開發等聯想起來，最多最多可能就是參與研發時沾上一點邊；實際上，Agile的概念在台灣出現的算早，我也在2009年左右就接觸到此一概念，還記得第一次聽到時，我還打趣地跟同事說，要敏捷開發，那我是不是可以跳著寫?

想必我會這麼說，一方面是因為年輕氣盛，一方面是因為對團隊運作沒有相當足夠的經驗和歷練，所以沒有很深刻的了解這能幫我們解決甚麼問題，在歷經研發系統、管理部門後，再加上一些應用經驗，才能更具體地描述Scrum可以解決甚麼問題，不能解決甚麼問題，故後面我會加入以往運用Scrum的經驗和心得，來述說我對此一方法的看法。

迷思

不管在上海、北京或是台灣，我都曾和當地客戶或IT主管交流過Scrum開發，在這些閒聊過程中，我發現一些很有趣的共性，對於Scrum開發，許多人在還沒真正進入時，總有一些迷思和困惑，甚至在導入一段時間後，仍覺得事實與想像不符，以下說說我遇到的趣事。

我團隊的研發速度相當慢，是不是應該導入Scrum ?

是，但你一開始可能會失望，因為導入後未必速度就會快了起來，事實上，敏捷雖然從字面上看來會讓人聯想到動如脫兔之類的意象，但實則他和「快」這件事情毫無相關，但或許你可以透過Scrum找出你團隊潛在的問題，並進而改善後得到效益。

我們每天都在做例行性的工作，這樣有需要導入Scrum嗎 ?

這沒有標準答案，過往很多人運用Scrum時，強調的是開發，但若是以筆者經驗來看，運用Scrum時應該思考的方向是「解決問題」，若是以解決問題的方向來思考，面對的是不是例行性工作相對就不是那麼重要了。

我們已經有固定的工作模式，Scrum未必適合我們公司的型態。

若你滿意的話，這麼說是也沒錯，但如果閣下總覺得現有工作模式好像有點說不出的點，或是想要再得到更多的效益，那或許你可以嘗試一下Scrum。

導入Scrum後，是否一個團隊就可以滿足多面向的開發工作 ?

這是我們都想要的結果，但不幸的是，就以往經驗看來，在Scrum運作越臻成熟下，該團隊的工作內容應該越趨向單純，耦合度高。

舉個例子來說，一個團隊的工作內容都在撰寫程式、發展邏輯，隨著成員對這些工作內容越趨熟練，你會發現研發效率和品質都相當好，但若團隊工作內容開始參雜了美工設計、介面討論，則慢慢地你會發現成果的品質和效率都會略為受到影響，我曾思考過這問題，在時程固定的情況下，應是或多或少受到學習成本的影響，才會體現這結果，

導入Scrum後，我們是否還要像傳統開發一樣，需關心各階段的狀況。

如果你有一組成熟的團員，那我會說太好了，但我們依舊免不了計畫、執行、驗證和回歸這幾大階段，但這並不是意味著我們要讓成員全部做完計畫，再全部下去執行，最後作全部的驗證和回歸這樣，若是這樣，那你只是把這些人分次使用而已，並沒有對現有流程做多少改變。

如果上述幾個迷思，在閣下心中都有良好答案，那我得說，我們有了一個好的開始。

畫虎不成反類犬的模仿

我也曾看過一個部門的管理者，從網路上看了些文章後，就將所有人叫來後，接著要每個人把手邊工作一五一十交代清楚，接著在牆上或看板畫標出幾個區塊分別代表待進行(To do)、進行中(Processing)、已完成(Completed)。

這是一個常見的雛形，如此一來，所有事情進行到甚麼地步，我們都可以一目瞭然，但是在缺乏良性互動和管理的狀況下，這個看板的生命僅維持了2周。

因為在只做Task進度更新的情況下，執行這件事反而對成員是負擔，對大多數成員來說，在無人打擾的情況下，大夥總是沉浸在自己的工作進度中，在普遍情況下，他們的工作進度和思緒是沒有斷點的。

在照著自己步調走的情況下，每人更新進度的時間不一，也無法協同工作，更不用說許多成員根本就忘了更新進度這件事情，然而當管理者拿起鞭子要大家更新進度時，又會打亂成員思緒，造成思路中斷，無法有好的連貫，相對也拖累了進度。

來例會吧，還是…來野餐吧？

相同狀況也發生在每日例行會議中，有些管理者會透過每日會議來更新自己對進度的掌握，這是一種常見手法，沒有好也沒有不好。

但若沒有良好的管控會議進度、每位成員發出的資訊量，往往容易導致會議方向偏題，甚至過度琢磨在某個成員的某個問題中，這現象很恐怖的是，你會發現一開始只有一兩個人講得特別久，後面則越來越多成員講得很久，大家忙著噴口水，最後開一場會議的時間，從5分鐘暴增到1小時都不算罕見。

也許管理者會沾沾自喜，覺得大家都參與討論，最後問題也得到解答，但需要注意的是，有些問題往往是1~2個成員之間的困擾，為什麼需要大家一起來陪聽呢 ？即便需要大家一起參與討論和找到解答，著實浪費大家的時間，而會議沒有完整主軸，變成一場各聊各的野餐會議。

說了那麼多迷思和常見的錯誤，其實筆者真正想表達的是關於敏捷的四大價值，或許各位在開始之前，可以細想這幾句話的意思，若牢記於心的話，那麼我們就可以開始冒險了 !

「個人與互動」重於「流程與工具」

「可用的軟體」重於「詳盡的文件」

「客戶的合作」重於「合約協商」

「回應變化」重於「遵循計畫」

敏捷的四大價值

再琢磨琢磨以上四大價值，或許你就不難發現，在敏捷開發的思維中，我們更在乎人與人之間的互動，不管是成員和成員，或是成員和客戶，在長久的軟體工作/一般工作發展看來，大家或多或少都會對上述的價值有所體悟。

不過，SOP、計畫、合約和文件都是必要的，我們不能捨棄掉工作上的嚴謹性，更重要的是我們能不能避免工作過於僵化，流於形式，讓專案中每個成員對工作內容有一定的認知和熟悉感，如此才能發揮真正的敏捷彈性。