敏捷導入的真相
這天 Azure DevOps 課程下課後，又有位學員留下來找我。
事情是這樣的…
他們公司政策規定要導入敏捷和ADO，但上完我的課程後，覺得有點困惑…
(我內心OS: 呃? 怎麼會呢? 🤔 你不是應該上完我的課程後豁然開朗的嗎?)
他說，因為公司很多專案還是瀑布式在跑。需求從客戶那邊來的時候，動不動就是三個月、五個月這麼大包的東西。PM 離開技術圈一段時間了，也不知道該怎麼 end-to-end 切出一個迭代(兩周)內可以完成、又有價值的 PBI。
(我一邊聽，一邊想，覺得這是個難題沒錯，但其實最大的挑戰是心理障礙和習慣，因此…)
我跟他說：「其實把需求顆粒度切小，對每個人都有好處。對 PM、對客戶、對開發人員，全是利多。」
他笑的很無奈。
「這道理我可以理解，但我們的開發人員同時身兼好幾個專案，很難專注在某一個案子上。這時候，大家心態上就不想把顆粒度切小，因為怕時時刻刻被盯著要看進度。」
他停頓了一下，接著說：「所以開發人員寧願維持以前那樣一個功能做一個月、兩個月的顆粒度。這樣開發人員可以先去忙別的事情，最後幾天再來趕工。」
聽完，換我沉默想了幾秒。
因為這根本不是技術問題，也不是工具問題。這是整個組織的心態問題。
更深層的，是大家對「敏捷」的誤解。
很多人以為敏捷就是迭代、就是 Scrum、就是看板或站立會議。
但其實，真正的敏捷有一個很明顯的照妖鏡：需求的顆粒度。
沒有小的需求顆粒度，就沒有頻繁交付；沒有頻繁交付，就沒有敏捷。
我幾乎可以說，如果團隊無法把需求顆粒度變小，那敏捷導入十之八九是假的。
粗顆粒度的惡性循環
你在 Board(看板) 上看過那種預估要做三、五週的需求卡片嗎？
- 「完成訂單管理功能」（預估五週）
- 「優化報表系統」（預估三週）
- 「整合第三方金流」（預估兩週）
每次看到這種，我就知道這個團隊有問題。
為什麼？因為一個需求如果要做兩週，在這兩週裡，這張卡片的狀態是什麼？「In Progress」?
但 In Progress 告訴了我們什麼？什麼都沒有。你不知道他做到哪裡了，可能才剛開始，也可能快做完了，也可能卡住了但不好意思說。
更慘的是，開發者在自己的 branch 上悶著頭寫了兩、三週的程式碼。等到要 merge 的時候，衝突、錯誤、邏輯不一致，問題才一個一個冒出來。然後就是沒完沒了的 code review、修改、測試、再衝突…
等真的能 merge，Sprint 早就結束了。
所以每次 Sprint review，團隊永遠都在 demo「做了一半的東西」，或是「看起來快好了但還不能用」的功能。久了，大家就習慣了。反正每次都做不完，那就算了吧，反正下個 Sprint 繼續做就好。
這絕對不是敏捷!
細顆粒度的真相
同樣是「完成訂單管理功能」，如果切成這樣呢：
- 建立訂單資料表
- API：建立訂單
- API：查詢訂單列表
- API：取消訂單
- 前端：訂單列表頁
- 前端：訂單詳細頁
看起來變小了，但也不對，因為上面這些都不是 end-to-end的需求，做完了，對用戶來說也看不到價值(無感)。
但如果是底下這樣呢?
- 使用者可以成功建立一筆訂單並看到確認畫面
- 使用者可以在訂單成立後立刻看到訂單編號
- 使用者可以在列表中看到自己剛建立的訂單
- 使用者可以取消「尚未出貨」的訂單
- 使用者可以在訂單中看到目前處理狀態（已成立 / 處理中 / 已取消）
每個 item 都很小，一個開發者半天到一天就能做完一個。做完之後呢？馬上 merge、馬上部署、馬上測試、馬上拿到 feedback。不用等一週，不用擔心方向錯了，不用累積一堆衝突。
而且，當需求變小了，整個 Board(看板) 的「流動感」就出來了。你會看到卡片不斷從 New 移到 Active，再移到 Closed，一張接一張，像流水一樣。這種感覺，會讓整個團隊覺得：「我們正在前進。」
反過來說，如果 board 上永遠都是那幾張大卡片，卡在 Active 好幾天動都不動，團隊看了只會覺得：「我們到底在幹嘛？」士氣，就是這樣一點一點被消磨掉的。
還有更關鍵的。當需求顆粒度夠細，你根本不需要搞一堆 feature branch。為什麼？
因為每個需求都很小，開發者可以很快做完，然後很快 merge 回主線，下一個需求再從主線拉出來，做完再 merge 回去。
這才是頻繁交付。
而頻繁交付才是敏捷最大的意義!
大家都在同一個最新的 codebase 上工作，衝突自然就少了。每次 merge 的量都很小，Code Review 變輕鬆，Reviewer 不用一次看幾百行 diff。整合變成「每天都在做的事」，而不是「Sprint 最後的卡關大魔王」。
這才是真正的持續整合（Continuous Integration），不是嗎？
最近這兩年，我喜歡在上課的一開始，就把敏捷的精神和DevOps的目標先跟學員破題，大部分學員會發現，真正的敏捷似乎跟你公司導入的不一樣！
但沒有關係，我能接受你一步一步前進。
但我不太接受你搞錯了敏捷的真相。
如果你的需求顆粒度總是很粗，一個需求要做超過三五天，你就不可能做到持續整合。你做的是「持續隱藏(程式碼)」和「延遲整合」，然後在 Sprint 最後，持續承受著整合衝突的地獄痛苦。(這不就是CI要避免的事情?)
所以，需求顆粒度這件事，不只是「切細」而已。它背後影響的是：整合頻率、部署頻率、回饋速度、團隊士氣、開發節奏…它就是敏捷的照妖鏡。
知道了，但為什麼做不到？
既然細顆粒度這麼好，為什麼很多團隊做不到？這幾年我觀察下來，主要有幾個原因。
1. 不知道怎麼切
很多 PO 或 PM、End-User 習慣用「完成一個功能」的角度思考，所以會寫出「完成會員系統」、「優化報表」這種需求。但敏捷的需求應該用「價值」的角度切。什麼叫價值？就是「做完這個，使用者可以得到什麼？」 舉例來說，「完成會員系統」太抽象了，但如果改成「使用者可以用 email 註冊帳號」，這就清楚了。做完這個，使用者就能註冊了，就能開始用系統了。
2. 怕麻煩
有些團隊覺得，切細了很麻煩。本來一張卡片搞定的事，現在要切成十張，光是 work item 就要建十次。但你有沒有想過，切細了看起來麻煩，實際上是「前期花時間，後期省時間」。因為需求切細了，每個需求的範圍很明確，開發者不用猜「這個到底要做到什麼程度」。Code review 變輕鬆、整合變快速、測試變簡單、部署變頻繁。這些省下來的時間，遠遠超過前期多花的那點時間。
3. 技術債
如果系統架構很糟、程式碼很亂、測試覆蓋率很低，你就算想切細，也切不下去。為什麼？因為改一個小功能，可能牽一髮動全身。你本來只想改一個 API，結果發現要動到十個檔案。本來以為半天能做完，結果做了三天還沒搞定。這時候你就會發現，「切細顆粒度」根本是奢望。所以技術債的問題，不處理是不行的。
4. 刻意不想切小
還有一個原因，很多團隊其實不太願意承認。不是不會切，而是不想切。 為什麼？因為一旦需求切小了，進度就會變得非常透明。每一張卡片兩、三天就應該完成，看板上的流動會很快。 誰做完了、誰卡住了、誰的工作一直停在 Active，一眼就看得出來。而這對於那些同時身兼多個專案、長期在多工狀態下工作的開發人員來說，這其實是一種壓力。
怎麼開始？
那該怎麼辦？其實不難。
先從心態上著手，接受小顆粒度的需求，才是敏捷的核心目標。下一個 Sprint planning開始，試著把需求切細一點。不用一次到位，慢慢來。本來一個需求要做兩週，試著切成兩個一週的。下個 Sprint，再試著切得更細，變成三、四天能完成的。然後開始注意每個需求都要為用戶(End-Users)帶來價值(Vaule)。再下個 Sprint，繼續切，變成兩、三天能完成的。慢慢地，你會發現整個開發節奏變順了。而且這時候，你已經贏過台灣 80% 以上的開發團隊了。
另外，留意你的 Definition of Done。
很多團隊會覺得自己的 DoD 寫得太理想化：「必須通過所有測試」、「必須完成文件」、「必須經過 code review」……
然後得出一個結論： 是不是 DoD 設太高了？
但老實說，多數時候問題不在 DoD。
真正的問題是：需求太大了，卻硬要在一個 Sprint 裡把它做到 Done。
DoD 本來就應該是一條穩定的品質底線，而不是隨著時間壓力上下浮動的標準。如果一個需求大到要花好幾天、甚至一兩週，才能同時滿足測試、文件、review 的要求，那代表這個需求一開始就切得不夠好。
所以正確的做法不是放鬆 DoD，而是讓需求小到「自然就能在 DoD 之內完成」。
當需求顆粒度變小，每一個需求的影響範圍很明確，測試不再是一大包、文件也不需要一次補齊一整個模組，Code review 看到的 diff 也變得很乾淨。這時候，Done 不再是一個遙不可及的狀態，而是每天都在發生的事情。
最後，縮短整合週期。當需求變小了，你就有機會做到「每天整合」，甚至「每幾小時整合一次」。這需要你的 CI/CD pipeline 夠快、夠穩定。如果你的 pipeline 跑一次要 30 分鐘，確實很難做到高頻整合。但如果你能優化到 5 分鐘，那就不一樣了。開發者改完 code，提 PR，幾分鐘後看到測試結果，然後 merge，然後部署。整個流程順到不行。
最後
回到一開始那個學員的問題。
他們為什麼不敢把需求切細？因為不熟、不習慣、因為開發者多工(同時參與多個專案)、怕被盯進度。但這根本是惡性循環。需求越粗，進度越不透明，主管越焦慮，就越想盯。需求越細，進度越清楚，主管反而不用盯，因為 board(看板) 上的流動一目了然。
另外，在多專案的環境裡，開發人員很少能夠「專心只顧一張卡片」。今天被 A 專案拉走救火，明天又要幫 B 專案修 bug，後天還要開 C 專案的會。這種情況下，如果需求被切得很小、節奏又很快，進度很容易「看起來不漂亮」。
於是，需求顆粒度最後被刻意維持在一個「模糊的大小」。
一張卡片可以合理地待在 In Progress 一兩週，
今天沒動，看起來也很正常；
被別的專案打斷了幾天，也說得過去。
顆粒度越粗，進度就越不透明；進度越不透明，被追問的機率就越低。
多專案帶來的問題，顯而易見，但很都企業卻依然樂此不疲。以為自己跑的是敏捷，但不是!
所以，怎麼判斷一個團隊有沒有真正在實踐敏捷？
我的答案很簡單：看他們的需求顆粒度。
如果他們的需求都是大包大塊的功能，每個都要做好幾天甚至好幾週，那十之八九就是假敏捷。形式上再怎麼完美、會議再怎麼正常，也是在自欺欺人。
但如果他們的需求都很小，大部分兩、三天甚至一天內就能完成，能快速整合、快速部署、快速拿到用戶的 feedback，那你就知道：這是一個真正理解敏捷精神的團隊。
因為敏捷不是會議，不是工具，不是流程。敏捷是「快速回饋、持續改進、頻繁交付價值」。而這一切的前提，就是需求的顆粒度夠細。
所以下次如果有人問你：「我們公司到底有沒有在做敏捷？」你可以問他一個簡單的問題：「你們的需求平均多久能做完一個？」(咦? 這不就剛好對應到了 DORA 指標中的 Cycle Time嗎?)
答案，自然就出來了。
後記
需求顆粒度不只是切割方式的選擇而已，它反映的是團隊對價值交付的理解深度。
當你能把需求切得夠細，你才有機會做到真正的持續整合、持續部署、持續回饋。而這些「持續」，正是高績效團隊跟一般團隊最大的差別。
記住一件事：
不是工具決定了你的敏捷程度，是你對價值交付的態度，決定了團隊的速度。
留言