敏捷開發導入：從工作坊到陪跑 Sprint，讓團隊每兩週交出看得到的成果

成果重點

• 我們的顧問曾在大型企業擔任敏捷教練與內部講師，敏捷工作坊培訓超過 300 人次，陪 5 個傳統開發團隊轉型敏捷。
• 不只上課。我們陪團隊實際跑 Sprint，把常態維運、臨時插單、一人身兼多職這些「教科書沒寫」的狀況，都排進看得見的流程。
• 我們自己接案也照這套節奏交付：每一版先確認需求，交付時附驗收清單與更新說明，客戶隨時知道做到哪裡。

團隊面臨的問題

我們輔導的多半是「已經在做事、但做得很累」的開發團隊：

• 需求一直插進來，原本排好的工作被打亂，交期一延再延。
• 每天都有來電協查、小 bug 要處理，這些工作不在計畫裡，卻佔掉大半時間。
• 很多子系統只有一個人在顧，他既是需求窗口、也是開發者，不知道敏捷要怎麼套。
• 主管看不到真實進度，只能一直問「還要多久」。

上過敏捷課的團隊不少，但課程大多在講「標準的 Scrum」，回到現場一碰到這些狀況就卡住，最後又回到原本的做法。

我們怎麼做

先建立共同語言，再談流程。 工作坊先讓團隊、產品負責人（PO）和主管對齊：Scrum 有哪些會議、各自多久、誰該出席。以兩週一個迭代為例，需求梳理、規劃、每日站立會、審查與回顧各花多少時間，事先講清楚，大家才排得出行事曆。

Scrum 活動節奏：以兩週迭代為例，每種會議多久、在第幾天開（輔導課程教材）

依工作性質選方法，不硬套 Scrum。 我們用 Cynefin 框架幫團隊分類：來電協查、小 bug 修正這類「明顯」的工作，因果清楚、照既定程序處理，適合放進看板或待辦清單；新功能、新系統這類「複雜」的工作，才用 Scrum 的短迭代邊做邊驗證。

Cynefin 框架：先判斷問題屬於哪一類，再決定用 Scrum、看板還是既定流程（輔導課程教材）

先盤點人力，再承諾工作量。 每個 Sprint 開始前，扣掉假期、會議、例行維運，算出每個人真正可投入的人天，再決定這一輪能做多少，並預留一部分緩衝給臨時插單。主管看到的是「這兩週能交付什麼」，而不是一張永遠做不完的清單。

一起訂「完成的定義」。 什麼叫做完？程式寫完、通過測試、整合完成、在驗收環境跑過，還是要上正式環境？我們陪團隊把標準寫下來（Definition of Done），之後每個工作項目都照同一把尺驗收，減少「我以為做完了」的爭議。

完成的定義（DoD）：從分析、開發到驗收，每一關的標準事先寫清楚（輔導課程教材）

用故事地圖排出上線順序。 把使用者會做的事攤開成一張地圖，依價值、風險、成本與相依性排序，先切出最小可行產品（MVP），再規劃第二、第三版。主管一眼就看得懂每一版會有什麼。

故事地圖：上方是使用者活動，往下拆成任務與用戶故事，左側標出每一版的範圍（輔導課程教材）

回顧會議是改善的引擎。 每個 Sprint 結束都開回顧：哪裡卡住、任務拆得好不好、下一輪要改什麼。我們認為這是整個 Scrum 裡最重要的會議，因為團隊會在這裡自己長出改善的習慣，之後不需要教練也能持續下去。

輔導時團隊最常問的五個問題

這些都是我們在輔導現場實際被問過的問題：

1. 維運的小工作能不能納入敏捷？ 可以。把它們當成待辦事項放進 Sprint，產出就是「修好、改善過的系統」，只要符合完成定義就算是有價值的成果；Sprint 規劃時依可用人天預留這部分的產能。

2. 一個人同時是 PO 又是開發，還能做敏捷嗎？ 最好的做法是把角色分開，這需要主管的決心。真的分不開時，就用固定的短迭代、看板管理待辦，並且自己定期回顧，確保每一輪都有可交付的成果。

   

   角色能不能合一：PO 是團隊成員、或 PO 與 Scrum Master 是同一人時，各有什麼風險（輔導課程教材）

3. Sprint 的成果一定要上正式環境才算完成嗎？ 看團隊的完成定義。通常「程式能執行、符合品質要求」就算完成；如果上版是另一道發行流程，就在定義裡明確分開。

4. Sprint 中途來了重要又有時限的工作怎麼辦？ 用需求梳理會議，跟產品負責人一起重新排優先順序；規劃時預留緩衝人力，並且即時跟相關的人溝通影響範圍。

5. 有相依關係、必須跨好幾個 Sprint 的工作，前一輪的成果算完成嗎？ 盡量把任務重新拆成每一輪都能獨立有用的結果；真的拆不開，就讓團隊和相關的人先達成共識，並在回顧會議檢討下次怎麼拆得更好。

團隊與主管得到什麼

• 進度看得見：待辦清單、看板與每個 Sprint 的目標都攤在桌上，主管不必一直追問。
• 插單有規則：臨時需求不再直接打亂所有人的工作，而是經過梳理、重新排序，並且知道會影響什麼。
• 固定節奏交付：每一到兩週就有一個符合完成定義、看得到的成果。
• 角色分工清楚：產品負責人負責排優先順序，團隊專心把事情做完。
• 團隊能自己走下去：回顧會議養成改善的習慣，教練離開後流程不會跟著消失。

我們自己也這樣交付

我們接案時用的是同一套節奏。以鴻陽崴勝跆拳道館場館系統為例，館方每一次回饋，我們都先整理成需求確認表、附上衝擊分析，館方確認後才開發，交付時再給驗收清單與更新說明；客製化服飾進銷存上線半年來推出 14 個版本，每一版都有規格書、驗收計畫與發佈計畫。

我們通常這樣進行

1. 現況訪談與觀察：跟主管、PO、團隊各聊一次，並觀察現在的工作方式，找出最卡的地方。
2. 工作坊：依團隊的情況調整內容，建立共同語言與第一版完成定義。
3. 陪跑兩到三個 Sprint：一起做規劃、梳理與回顧，現場遇到問題當場調整。
4. 交棒：團隊能自己跑完一輪，我們就退到旁邊，只在需要時協助。

適合誰

• 專案常延期、需求一改再改，想讓交期變得可預期的開發團隊。
• 上過敏捷課，回到現場卻跑不起來的團隊。
• 想看到真實進度、又不想天天追問的主管。

我們的顧問具備 PMP 與 CSM（Certified ScrumMaster）認證。