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

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

不過在這次的聚會中，有個朋友提出的 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 不想告訴你的秘密！