這幾年有越來越多的團隊導入「敏捷開發」，覺得只要跟上時代潮流，過去遇到的問題就能迎刃而解。

前些日子跟朋友聚會時，發現大部分的公司都有導入「敏捷開發」；但相比於管理階層的推崇，更多工程師是抱著不情願的心態在參與。

不過在這次的聚會中，有個朋友提出的 Daily Scrum 方案讓大家耳目一新，所以我就特別寫了這篇部落格來分享。

一、真的有 Daily Scrum 的必要性嗎？

Daily Scrum 的目的，是讓團隊成員快速同步彼此的資訊。

但理想很美好，現實很骨感；大部分的人只在意自己要報告的東西，換到其他人報告時，大腦往往處於待機狀態。

當然也是有些人持反對意見，因為他們在 Daily Scrum 時討論的熱火朝天；但其他參與會議的人因為覺得議題跟他們無關，所以陷入休眠狀態。

綜上所述，許多團隊的 Daily Scrum 實際上只是走個形式。

雖然上面這段很殘酷，但可能更符合大多數工程師的心聲。

二、Daily Scrum 背後的時間成本與壓力

原則上每個人在 Daily Scrum 的報告時間都小於 3 分鐘。

但為了這 3 分鐘，許多人要花 10 分鐘以上的時間整理資料，並在會議開始前順一下口條。

我們期望 Daily Scrum 除了可以同步資訊外，還可以凝聚向心力；但對於個性內向的人來說，每次開會都是一場劫難。

就拿筆者舉例，儘管我準備資料的時間通常都在 10 分鐘以內，但在會議開始前的 5~10 分鐘，我是無法做其他事情的，因為我害怕事情做到一半思緒中斷。

也許 Daily Scrum 只花 8~15 分鐘，但對許多人而言可能要付出 30 分鐘以上的時間成本。

三、把 Daily Scrum 改為文字報告有什麼好處？

朋友表示為了改善上面的問題，團隊將 Daily Scrum 改為文字報告，幾個月下來發現大家的效率反而上升了，他說這麼做有以下優點：

1. 文字閱讀的速度遠高於口頭報告。
2. 口頭報告可能會含糊不清，但文字報告因為要附上 Ticket，所以很難打混。
3. 想要討論的人可以私下約，不會打擾到其他人的時間。
4. 除非對專案架構很了解，不然聽別人口頭報告常常有聽沒有懂，而文字就減少了這類情況。
5. 只要在規定的時間繳交文字報告即可，有更完整的時間段可以做事。
6. 對個性內向的人來說是一個福音。

四、我的想法

我聽到這個方案的當下很興奮！因為真的解決了很多實務上的痛點！

而且改成文字後，從管理的角度來看，的確更能了解每個人做了些什麼。

但這個方案也未必適合每個團隊，畢竟文字報告跟實體會議的差異還是挺大的，多互動有助於釐清彼此的觀點；如果只把 Daily Scrum 當成進度報告，沒有後續的話就會失去原有的意義。

不過如果 Daily Scrum 的成員時常處於待機模式，也許可以嘗試推行看看；適合 A 團隊的方案，未必適合 B 團隊；任何的變革的成敗，跟「人」的關係最大，也需要根據「環境」來調整，直接複製貼上容易水土不服。

如果讀者有其他的想法也歡迎留言喔，你的經驗也許能幫助到更多的人。

2022.7.29 補充

有朋友看到文章後跟我分享，對他們團隊來說，早上的 Daily Scrum 更像是一種儀式，從嘴巴說出來要做的東西是一種承諾，會給人完成任務的動力。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？(本篇)
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！

本文提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

大綱
ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言
二、Scrum 淪為形式
三、專案到最後時刻才發現一堆 Bug
四、Tech Lead 沒辦法發揮應有的作用
五、團隊失去成長動能
六、不是每個成員都按照流程走
七、血淚小結

ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言

為了讓每個角色各司其職，在溝通需求時，都是由專案經理跟客戶溝通，得到結論後再跟開發人員說明。

儘管看起來很合理，但在實務上容易遇到以下問題：

1. 名詞定義：同一個名詞，大家的定義都不一樣；這導致 3 者在溝通上雞同鴨講，彼此以為對方懂了，但根本在說不一樣的東西。
2. 專案經理與開發人員都不具備專案的背景知識：如果碰上大型專案，在開發團隊沒有相關背景知識的狀態下，光是架構的設計就很容易出問題；又因為沒有相關背景，所以根本沒有共同語言。
3. 規格書不明確：開發人員按照規格書來開發，但如果規格書很模糊，工程師在開發時會浪費很多時間在額外的溝通。（最悲慘的狀況是工程師放棄溝通，選擇按照直覺來開發）

上面的問題，想嘗試透過以下方法解決：

1. 專案經理與開發人員以「英文」來溝通欄位：資料庫都是英文欄位，如果規格書上的欄位都以中文表達，就不能怪工程師在開發上直接選擇「感覺」意思最接近的欄位。
2. 由專案經理建立一套「中英文名詞定義對照表」：內部可以用英文律定欄位，但跟客戶溝通時，大多情況還是使用中文；所以需要建立一份對照表，避免彼此的誤解。
3. 需求規格參數明確：對客戶來說好像差不多，但對工程師來說，差一個欄位就好似差了一個宇宙。

二、Scrum 淪為形式

我們期待導入「Agile(敏捷)」開發後，可以提升團隊的生產力、向心力，但實際上會遇到以下問題：

1. 只在意自己要講什麼：跑 Scrum 的原意是希望大家瞭解彼此工作的進度，透過資訊透明讓專案更加順利；但很多時候我們只在意自己今天要講什麼，這種狀況在 Scrum Master 為固定人選時更為明顯。
2. 規格不明確導致需求時常變更：在 Sprint Plan 時，我們會先估點來計算每個人工作需要的時間；但在開發階段若發現規格有問題，專案經理就要再跟客戶溝通，這一來一往與程式調整的時間，將會完全破壞這個 Sprint 預計要完成的項目。
3. 安排額外的任務：如果臨時安排不在這個 Sprint 的任務給工程師，又沒有明確告知任務優先度，當這種狀況頻繁發生時，Scrum 就變成單純的個人報告，工作內容逐漸與 Sprint Plan 脫鉤。

上面的問題，想嘗試透過以下方法解決：

1. 讓每個人輪流當 Scrum Master：在這個位置上，就算不願意，你還是得知道每個人的進度、卡住的問題、要做的事。
2. 指派任務前，充分確認客戶需求：如果在商談時就定下明確的需求規格，那工程師就有開發的依據，發現邏輯問題時也能第一時間提出，不至於自由發揮到一半才發現問題。
3. 盡量不要讓突發狀況影響現在的 Sprint Plan：工程師也是人，臨時安排的工作勢必會影響到現在的專案，如果可以，突發的狀況盡量安排到下個 Sprint。

三、專案到最後時刻才發現一堆 Bug

我們花 20% 的時間完成 80% 的功能，卻在最後 20% 的功能上花了 80% 的時間。

如果問題發生不只一次，那肯定要想辦法解決；通常會有這樣的狀況是因為：

1. 架構規劃不良：專案啟動後，一開始大家都是摸著石頭過河，無法確定自己現在的方向是否正確；往往到後期，才發現當初的規劃有某些後遺症。
2. 前期進度按照時程走很安心：因為前期每個 Check point 都很準時，所以產生接下來也會繼續準時的心理預期。
3. 想要一次交卷：有時我們會想等作品完成到某個程度後再給客戶看，但…有時客戶看過後會發現許多與他們理念不合的設計。
4. 新舊系統功能不吻合：就算功能都是 Copy＆Paste，但程式底層的運作邏輯往往不同，部分欄位可能也存在誤會；你以為執行得很順利，殊不知早已偏離方向。

上面的問題，想嘗試透過以下方法解決：

1. 別管架構，先交出 MVP：我們規劃了太多功能，卻沒有一個 MVP，在一切都不明朗的狀態下，能規劃出好架構根本是靠運氣；與其在前期完成那麼多功能，還不如先交一個勉強能動的 MVP，以此向客戶確認是否符合需求。
2. 在一開始規劃時，就把容錯時程拉長：過往的經驗告訴我，意外通常在最後一刻才發生；因為在後期，我們才有辦法用整體的思維去看專案。（如果團隊有經驗非常豐富的架構師，那有機會規避這些問題，筆者目前還不具備這個實力）
3. 開發階段頻繁更新系統：讓客戶隨時體驗最新的功能，如果與預想不合也可以盡快作出調整；避免工程師要砍一堆程式，做無意義的重工。
4. 如果要改寫舊系統，就需要對方提供可以驗證的資訊：通常舊系統程式的參考價值不高，我們只能從操作流程來推估資料間的關聯性，但這些「都是靠想像」的，如果客戶沒有提供足夠的舊系統操作案例給工程師來驗證，就很可能開發出無法與舊系統銜接的系統。

四、Tech Lead 沒辦法發揮應有的作用

我們期待 Tech Lead 可以照顧到整個團隊的技術，但如果開發時程太趕，在 Tech Lead 也投入大量時間在開發時，會衍生以下問題：

1. Code Review 淪為形式：連自己的任務都快做不完了，Code Review 時頂多看一下 Coding Style，沒辦法從整體的架構去判斷他的演算法、邏輯是否合適。
2. 專案程式碼品質下降：因為 Code Review 不確實，很多功能只是為了解決當下的問題，這種時候很容易創造出一堆耦合性高的程式。
3. 沒辦法顧及所有人的進度：如果專案經理與 Tech Lead 配合不夠默契，那很容易發生 Tech Lead 埋頭開發，沒有從整體的視角來看專案的進度。

上面的問題，想嘗試透過以下方法解決：

1. 分配給 Tech Lead 的開發任務，不要超過他 60% 的工作時間：如果把 Tech Lead 當單純的 Developer 來使用，那團隊程式碼的品質就無法保證；為了避免日後要花更多的時間解決後遺症，建議多給 Tech Lead 一些靈活運用的時間。
2. 專案經理與 Tech Lead 訊息流暢：就算有專案管理系統輔助，但每個任務進度的細節、時程還是專案經理最清楚；如果能在發現進度 Delay 前期就做適當的調整與釐清，也許不會走到時程緊繃這一步。
3. 律定專案管理系統操作方式：開發人員 Commit 的內容也需要附註在 Ticket 上面（盡量白話），這樣更方便專案經理掌握實際進度；若該 Ticket 有相依性（後端完成後交付給前端），那開發人員也要將相關的 API doc 附在上面。

五、團隊失去成長動能

我們期待團隊裡的每個人都能夠隨著專案持續成長，但在管理出現問題時，團隊會慢慢轉變為 80/20 法則的模式，也就是 20% 的人完成了 80% 的任務，下面是筆者個人推估的原因：

1. 到 Deadline 時，總有人能幫忙解決問題：如果團隊成員發現沒做完的東西，在接近 Deadline 時就會有其他人來拯救，那很可能就會養成依賴性，喪失自己解決問題的能力。
2. 獎懲機制不夠透明：如果大家發現拼死拼活的結果跟躺平耍廢一樣，那我們為什麼不躺平？
3. 連坐制度：Deadline 就壓在那裡，你幫了，他無法成長；你不幫，專案就爆掉，自己也跟著倒霉，這種狀況到底要幫還是不幫？

上面的問題，想嘗試透過以下方法解決：

1. 幫忙時只給方向：可以提供一些關鍵字、網頁、參考資料、過去的程式碼，但不要直接解決問題。
2. 如果必須親自解決問題，先確認對方已經發揮所有潛能：儘管我們都希望給方向就能解決問題，但每個人的背景知識不同，如果給方向還是無法解決；在親自解決問題前，要先請對方說出自己過去所做出的研究，確保他已經盡力，任務難度真的超過了他的能力範圍。
3. 不影響健康的壓力：如果發現成員的能力有提升的空間，那或許可以提醒他，適度犧牲下班後與放假的時間持續鑽研是必須的，唯有做足功課，在上班時才能更快地趕上大家的腳步。
4. 律定獎懲機制：我們希望每個人都有想成長的自覺，但如果有必要，賞罰機制還是要存在的。

六、不是每個成員都按照流程走

我們秉持互信的原則來合作，就算有些人沒按照流程走，只要不出包，也可以睜一隻眼閉一隻眼；但如果這些行為產出的結果不符預期，甚至導致團隊損失，那勢必要做出改善。

這邊就以程式碼 Commit＆Push 舉例，原則上我們期待每位開發人員一天至少 Push 一版程式，且裡面 Commit 都有詳細紀錄更動的部分。

會有這個要求是因為專案是「協作」的，如果有人憋了一個禮拜才 Push 一大包，會衍生以下問題：

1. Tech Lead 很難 Code Review：因為內容太多、太雜，釐清功能所需的時間反而更多。
2. 如果架構有問題，改善成本太高：如果在 Code Review 時才發現程式的結構問題，那又需要浪費很多時間改寫。
3. 如果把所有更新的內容塞到一個 Commit 裡面，很難對應功能與程式：因為程式往往散落在多個檔案，如果 Commit 內容太多，就很難知道彼此的對應關係。
4. 萬一發生狀況，接手的人會崩潰：如果做完的功能沒有 Push 上去，接手的人等於要重寫。

上面的問題，想嘗試透過以下方法解決：

1. 向開發人員說明定時 Commit＆Push 的重要性：開發人員可能不知道自己這麼做會影響到其他人，需要講清楚問題嚴重性。
2. 如果任務太複雜，盡量做功能上的切分：有時被分配到的任務涉及面太廣，導致遲遲不敢 Push 上去；面對這種情況，可以依據開發的進度來 Commit＆Push，反正有 Git 這種程式碼版控系統，不會影響到主分支。

七、血淚小結

1. 問題是長期沒改善積累而成的，想解決肯定會遇到不少阻力。
2. 只有被攤在陽光下的問題，才有機會被解決。
3. 許多問題互為因果，如果不解決，問題會像病毒般不斷變種。
4. 每個人都在適應自己的角色，專案經理不知道需求規格怎麼寫才能讓開發人員理解，開發人員不清楚遇到問題時要如何解決，Tech Lead 不確定怎麼帶人才是最合適的。
5. 規則律定出來就要執行，如果沒有執行；那其他乖乖遵守規則的人，也遲早會學壞。

工程師血淚史
▋ 團隊在系統開發上遇到了哪些問題(本篇)
▋ 需求不斷變更，到底哪個環節出錯了
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
▋ 如果沒有明確的開發流程，團隊將會無所適從
▋ 你知道對專案來說，README.md 有多麼重要嗎？