敏捷 (Agile) 開發與Scrum：個人與互動重於工具與流程，站著開會才不是重點！

敏捷 (Agile) 開發與Scrum：個人與互動重於工具與流程，站著開會才不是重點！

敏捷 (agile) 開發與 Scrum可以說是現在大量軟體開發團隊在採用的方法與框架。敏捷的精神在於因應變化，能夠快速進行調整，而 Scrum是迭代式增量軟體開發的過程，與精實開發 (LEAN)、與極限程式開發 (XP) 都是敏捷軟體開發中最常見的實踐框架。

或許很多人都曾經參與過一個或多個採用 Scrum的團隊，這時候就會發現每個團隊的 Scrum其實都有許多不同之處。依據敏捷精神－個人與互動重於工具與流程，其實沒有所謂最正確或是對錯的問題。但另一方面敏捷開發希望因應變化調整，因此本篇文章內容是筆者個人在不同團隊的開發經驗與《敏捷與scrum軟體開發速成》結合，希望可以在客觀介紹的同時，也提供一些實務經驗的眉批。

閱讀建議： 這篇文章會從敏捷開發精神開始，而後介紹 Scrum框架，主要著重於角色與流程兩個部分。文章內容會以《敏捷與scrum軟體開發速成》一書為依據，同時會佐以一些個人的實務經驗。

推薦背景知識： Product Development Process, Waterfall Development, Scrum, LEAP, Extreme Programming, Microservices,DevOps (Development & Operations).

敏捷 (Agile) 的革命

要說起敏捷開發，或許從瀑布開發開始說起會更容易理解。

瀑布開發是 1970年首次在論文 [1] 中被「正式提出」，其實論文中並沒有使用到 waterfall這個詞，只是很單純地描述一個軟體的線型開發流程，其中每一個階段都要等待前一個階段完成後，才能夠開始運行。

有趣的是，作者 (Winston W. Royce) 提出瀑布式開發是要做為一個負面教材，告訴大家不要用瀑布式開發。接著 Royce在文章中提出了一種迭代式開發流程，與後來敏捷開發蠻相似的 (有興趣讀者可參考論文 最後一頁)。

但不知為何，反而是他在瀑布式開發的描述，頗受大眾青睞。甚至後來美國國防部宣布要以瀑布式開發作為旗下專案的經典模式，這些都一步步鞏固了瀑布式開發的地位。

其實對於這些方法論 (不論是瀑布、敏捷或是 Scrum)，「提出」通常都不是一個相當好的動詞描述。因為都是流程先形成，而後才有人 (可能是高大上的研究員或是深陷其中的開發者) 慢慢從終統整出一些說法。

總之，瀑布式開發的支持者可以說是堅信事前設計 (BDUF, Big Design Up Front) 的哲學，白話地說就是

生產前，「完美化」的產品設計是可以做到的。

在《敏捷與scrum軟體開發速成》書中語帶揶揄地說：或許就生產汽車擋泥板，這是做得到的。但是開發複雜軟體系統並不是靜態物件，這樣的流程當然是不適合。

當然我們不能絕對否定瀑布式開發的優點 (比如說整體性的考量)，當今一定也有許多產品、甚至軟體產品是以瀑布式開發為本生產出來的。

敏捷開發所做的事情跟瀑布開發沒有麼不同，都是蒐集需求、設計、實作程式、測試與維護營運，但是做事方法並不一樣。但差異最大的是，敏捷開發承認無法在一開始就掌握所有的情勢變化，但仍然想要盡量減少變化拖累開發進度的可能性。

「變」是唯一不變的事情。

簡單來說，瀑布式開發是依序地從蒐集需求開始執行，一步一步地由上往下、不回頭地前進。而敏捷式開發則是先一點點地蒐集需求、一點點地設計、實作、測試，並先交付一點點價值給客戶。然後在重複這個過程。

聽起來敏捷式像是把一個大瀑布拆成多個小瀑布，然後還是執行瀑布式開發。其實

敏捷式開發的精神是將希望開發過程更加地整合與透明，比如說：需求蒐集與設計可以一起做，又或是程式實作與測試可以一起做。

因為當專案或題目的規模很大時，如果要程式實作與測試一起做會很困難，所以把大的任務 break down可以說是一種務實的方法而已。

而Scrum只是敏捷式開發的一種實踐框架。但總體來說，不論是 Scrum、精實 (LEAN)、極限程式設計，以下幾件事都是重要的：

• 邊做邊測試：及早發現 bug，不然放越久，修復越花時間。
• 及早及頻繁地交付產品：除了一點一滴的產生產出外，更可以跟後級 (或客戶)提早互動，得到回饋以及更明確的需求。
• 文件便寫邊做： Agile重視可使用的code，勝過詳盡的文檔，但不代表 Agile不重視文檔。其實敏捷開發很重視文檔，但要求文檔精簡並且有效，所以邊寫邊做文件是最實在的。
• 打破隔閡，建立跨職能團隊： 增加團隊成員間的互動，維持透明沒有隔閡。盡量避免個人造成團隊瓶頸的狀況。

Scrum

Scrum是一種迭代式增量軟體開發的過程，也是敏捷軟體開發中最常見的實踐框架。

Scrum的起源可以說來自Jeff Sutherland ，他當初的說法有幾個重點：

• 在 Sprint開始時設定目標。選擇最佳方法以達成目標是團隊的責任。
• 在 Sprint執行期間，任何人都不可以勞煩團隊成員。
• 在 Sprint結束時將會展示工作程式碼，因此是看的見的進展。
• 任何時候成員都可以決定是否交付，或是再做一個 Sprint。
• 與有大量文件卻沒有可運作系統的情況相比，可見的程式碼更可靠。

然而，其實沒有人有資格可以宣稱擁有 Scrum，也沒有人可以證明什麼是最好的 Scrum。可以發現的真相是，在不同的公司、不同的團隊，他們所運行的 Scrum都或多或少有些不一樣。

這之中或許真的沒有存在誰對誰錯，畢竟重要的是能夠找出開發過程中的問題加以改善，逐步地優化團隊開發的狀態。因此理解原始的 Scrum與借鏡不同團隊的開發流程，其實是很重要的事情。

在了解 Scrum時，重點不外乎三者：角色、週期、以及產出物 (artifact)。但以下為了避免篇幅過長，僅著重介紹角色與週期兩者。

Scrum角色

Scrum團隊中，角色大致可以分成三種。第一種是產品負責人 (Product Owner)，負責把關產品的價值、呈現方式，並管理跟產品有關的 backlog (工作項清單)。第二種是團隊成員，負責完成工作項的實現。這兩種都是蠻常見的角色，而第三種就是 Scrum中比較特別的 Scrum Master，主要負責維持 Scrum的運行，作為團隊的障礙清除者與協調者，要善於傾聽與回應成員的聲音，有時也要獻計解決移除團隊在行徑過程中踢到的小石頭。

以更現代的軟體開發角度，或許 Product Owner這個名詞容易讓人往時值的產品思考，但這個名詞當然是包括 SaaS這類的 service。

產品負責人是產品願景的守門人，負責把關最終交付出去的價值。產品負責人需要能夠撰寫使用者故事與驗收測試，按照價值排定開發順序，才能有效地推動專案的進行。

具體上產品負責人需要讓團隊理解客戶或是使用者的使用需求，同時引導團隊做最有價值的事情，換句話說，產品負責人控制著團隊代辦清單上的優先順序。

產品負責人是唯一有權要求團隊做是以及改變代辦清單優先順序的人。

因此，產品負責人一個很重要的任務是要做為團隊成員協調工作順序的橋樑。有些開發者 (比如說A) 可能習慣直接去跟其他成員 (比如說B) 提要求，這時候 被提要求者 (B) 就可已搬出產品負責擋下這些請求，或是說要求產品負責人協調。

在〈敏捷與 Scrum: 軟體開發速成〉中說道，產品負責人不是編寫程式的團隊成員，因為他太忙了，要花更多時間編寫故事與驗收測試。同時，書中也不建議產品負責人兼任 Scrum Master。

Scum Master的目的是凝聚團隊，產生自我組織的團隊。

總體上來說， Scrum Master職責的重點有二：第一個是輔導團隊維持 Scrum運作，包含引導 Scrum會議、幫助團隊理解和使用 Scrum的產出等。另一個重點是為團隊排除障礙，比如說某團隊成員缺乏運算資源等。排除障礙通常會在每日站會的時候發現，並現場或在事後盡快協調排除。

很重要的一點是，Scrum Master不是團隊的老闆，這個職位跟團隊成員是同等的，只是職責不同，但位階是一樣的。

Scrum Master需發展出一種與成員較親密的關係，才能成員可信的建言者與團隊維繫者。

這也是為什麼位階與職權容易破壞這種關係的出現。但其實 Scrum Master也應該跟團隊成員有「適量的距離」，才能夠在傾聽完成員的聲音後，能夠給予令人信服的回覆與回饋，也就是擔任所謂的共響板 (sounding board) 角色。

我個人喜歡的一個例子，Scrum Master有點像是齒輪的潤滑劑，在讓齒輪可以運行順暢的同時，同時減少了齒輪本身的摩擦。

在〈敏捷與 Scrum: 軟體開發速成〉中說道，與產品負責人不同， Scrum Master可以同時兼任程式開發重任，稱為貢獻型 Scrum Master。因為良好的 Scrum團隊發展到後期，通常是不需要一個全職的 Scrum Master來輔導和消除障礙，但通常還是會希望 Scrum Master記得將角色任務看的比自己的開發任務優先。

Scrum強調團隊是高度合作的，同時也是自我組織的。所謂的自我組織指的是團隊能夠自行分配工作，而團隊成員有全權決定要如何完成工作，做事的人決定權最大。產品負責人可以決定故事的順序，但「完成的特性」與「所需的工作時間」是負責開發的團隊成員說的算。

每個團隊成員都會帶來獨特的技能與經驗，協助團隊完成工作。但 Scrum不希望團隊成員將這些專長領域變成一種限制，而是希望可以適當、適時的跳脫原本的領域。

作為團隊成員，要完成的不是「你的」工作，而是「這份」工作。

更精確地描述，Scrum的團隊成員並不是要求可以做到任何成員無縫的互換， Scrum要的是團隊生產力最大化。所以成員只要在團隊需要的時候，願意選擇舒適圈以外的工作即可。

這也是為什麼 Scrum團隊要求透明，追求跨職能團隊。

依照經驗法則，通常 Scrum團隊通常是7個人，上下加減2個人左右，也就是7到9個人，這點與 Jeff Bezos倡導的 Two Pizza Team是差不多的概念。太少會欠缺團隊的多元性，太多則會過度增長溝通成本。

Sprint週期

還記得前面說過，敏捷開發的一個特色是先一點點地蒐集需求、一點點地設計、實作、測試，並先交付一點點價值給客戶，然後在重複這個過程。所以所謂的 Sprint週期就是一個不斷重複的節奏。

Sprint的週期常見為兩周為限的 Sprint，但也有一周為限，或是更長的Sprint，但通常上限是四周。這個週期的長度與團隊的任務有關，如果團隊任務是容易拆分的，週期通常就會短些。反之，週期就會較長。

在 Sprint週期中常見的會議包含：

• Spint規劃會議：代表 Spint的開始，討論要做什麼以及怎麼做。
• Daily Scrum (Standup): 通常是站立開會，保持溝通與開發的暢通。
• 故事時間：清單修整會議，及早修正方向。
• Sprint Review：Sprint結束前的成員報告時間，也可以說是炫耀時間。
• Sprint Retro: 在Sprint的最後召開，調整sprint的體驗與策略。

Sprint規劃會議代表每個的開始，這個會議的重點是決定「要做什麼」以及「要怎麼做」。以工程人員的角度聽到「要怎麼做」會覺應該是一件很實際的實情，但其實有的時候是很抽象的。更具體地說：

• 要做什麼：承諾團隊這個Sprint的產出，是「使用者故事」的層級。
• 要怎麼做：羅列交付使用者故事所需的「工作項目」。

**Daily Scrum就是通常跑 Scrum時最常發生的「站著開會」的日常。**通常 (或者說定義上) 為每日，找到適合團隊每日開會的時間很重要，大部分團隊會選擇在一天的開始時進行。每位團隊成員會報告：

• 在上一次的 Daily Scrum後，已經完成的內容。
• 到下一次的 Daily Scrum前，期望完成的內容。
• 遇到的困難與造成延誤的問題。

整體上每個成員不應該花超過3分鐘在報自己的東西(這也是為什麼要站著)，這個會議不是真的拿來處理問題，而是

快速地同步成員的資訊，並避免團隊的重工。

比如說，成員 A在在會議中報過某個開源程式中有一個容易遇到的 bug，那之後的成員遇到這個 bug，就可以知道要找誰來協助。

故事時間是Scrum中容易被忽視的一個會議，具體上故事時間會在 Sprint過程中招開，但主要目的跟目前的 Sprint無關。在故事時間會議中，團隊關注的事情是之後要使用的的故事，而不是當前 Spirnt正在處理的故事。

這個會議主要是在「整修」未來的故事清單，所以也可以說是「清單整修」，除了可以讓一些成員提早思考或準備未來的故事，同時也可以維持團隊成員對故事的理解度。

Sprint結束前，團隊成員可以在 Sprint Review中豪爽地炫耀他們的成果，所以這個會議也會被叫 Sprint Demo。這個會議很常帶有慶祝的味道，但附屬價值其實很多，可以提升團隊的成就感，又可以透過分享過程，快速地得到其他專業人員的重點知識或關鍵字。

總之， Sprint Review就是把這個 Sprint完成的成果拿出來秀一下。但有些前瞻的團隊常常會有成員不一定會有完成的成果，反而會有完成的「反向例子」，這個時候其實分享這些也對團隊很有幫助，至少可以讓團隊成員知道這條路很高機率是沒有效果的。畢竟，透明是 Agile與 Scrum很根本的精神。

Sprint Restro也是一個容易被忽略的會議， Scrum的設計精神就是希望團隊能夠持續檢驗與調整。Sprint Restro是在 Sprint的最後召開，專注討論這個 Spirnt的體驗心得，並改善下個 sprint的體驗。具體來說，就是找出問題、洞悉問題、提出改進方案。

以ML團隊常見的問題來說，問題可能是「我們的開發又一次卡在資料集的傳輸過慢」，或者是「我們的模型上線前的測試時間還是很不夠」。當問題被提出後，團隊可以在自省會議中找出這些問題背後的癥結點，然後提出方案，試著在下一次的 Sprint中優化。

以工程人員的角度來看 Sprint Retro，個人是覺得有點像是軟體開發的 Infrastructure的感覺。沒有好像不影響產品，但是有開發起來速度跟爽感都會飛上天。

**軟體開發流程可以說是軟體團隊的原則，是流程也是文化。**好的軟體開發流程在提升開發效率的同時，可以提升團隊成員開發的樂趣性與幸福感。

不過提升團隊成員開發的樂趣性與幸福感是建立在團隊成員心態開放與積極的情況。敏捷開發在進度感受會比瀑布開發來的緊湊，雖然不論哪種框架都有提供延遲交付的機制，但在高度透明的團隊中，進度落後的人是很容易被發現的。如果團隊成員心態不是開放與積極的，敏捷開發反而可能會增加工作上的不愉快。

因此，在帶動或改變開發流程時，通常都不是發個公告或寫個 email來昭告天下這麼簡單，而是**需要從根本、從文化開始慢慢改變。**這點與 DevOps挺像的。

老話一句，我的觀點可能也會存在瑕疵，若有發現什麼錯誤或值得討論的地方，歡迎回覆文章或來信一起討論 :)

Reference

1. Managing the Development of Large Software Systems[Paper]