[{"data":1,"prerenderedAt":1004},["ShallowReactive",2],{"article-\u002Farticles\u002Foverview-of-scrum":3},{"id":4,"title":5,"body":6,"date":989,"description":990,"excerpt":991,"extension":992,"meta":993,"navigation":994,"path":995,"seo":996,"stem":997,"tags":998,"__hash__":1003},"articles\u002Farticles\u002Foverview-of-scrum.md","Scrum 流程整理：三個角色、三個產出物、五個事件，從 Backlog Refinement 到 Retrospective",{"type":7,"value":8,"toc":949},"minimark",[9,26,31,38,41,184,191,196,199,239,243,247,265,268,281,284,298,302,309,327,331,338,364,371,374,386,389,392,395,401,405,416,420,438,442,445,468,475,478,481,484,495,498,501,510,513,516,536,539,542,548,551,554,592,596,616,623,626,629,648,655,658,661,667,671,685,689,708,715,718,722,748,752,776,787,791,826,833,837,866,873,877,902,905,943,946],[10,11,12,13,17,18,25],"p",{},"換到新團隊後，開發流程改成用 Scrum 運作。剛開始參加會議時，很容易只記得「每天早上要站會」、「每兩週要 Demo 一次」，但說不清楚",[14,15,16],"strong",{},"每個會議為什麼存在、結束時應該產出什麼","。這篇照著一個 Sprint 的順序把流程整理一遍，順便對照 ",[19,20,24],"a",{"href":21,"rel":22},"https:\u002F\u002Fscrumguides.org\u002Fscrum-guide.html",[23],"nofollow","Scrum Guide 2020","，修正一些網路上常見、但其實是舊版或誤解的說法。",[27,28,30],"h2",{"id":29},"全貌3-個角色3-個產出物5-個事件","全貌：3 個角色、3 個產出物、5 個事件",[10,32,33],{},[34,35],"img",{"alt":36,"src":37},"Scrum 一個 Sprint 的循環：左邊是由 Product Owner 負責排序的 Product Backlog，上方是長期的 Product Goal，項目透過持續進行的 Backlog Refinement 拆分與估算，越上面越清楚；Sprint Planning 從 Product Backlog 挑出項目，產生包含 Sprint Goal 與執行計畫的 Sprint Backlog；接著進入固定 1 到 4 週的 Sprint，期間每天有 Daily Scrum；Sprint 產出符合 Definition of Done 的 Increment，在 Sprint Review 中展示並收集反饋，反饋回頭調整 Product Backlog；最後的 Sprint Retrospective 檢討團隊的工作方式，改進行動帶進下一個 Sprint Planning","\u002Fimages\u002Farticles\u002Fscrum-framework.svg",[10,39,40],{},"Scrum 的東西不多，記住下面這張表就有完整的骨架：",[42,43,44,60],"table",{},[45,46,47],"thead",{},[48,49,50,54,57],"tr",{},[51,52,53],"th",{},"類別",[51,55,56],{},"項目",[51,58,59],{},"一句話說明",[61,62,63,79,92,102,113,123,133,144,154,164,174],"tbody",{},[48,64,65,69,72],{},[66,67,68],"td",{},"角色",[66,70,71],{},"Product Owner（PO）",[66,73,74,75,78],{},"決定",[14,76,77],{},"做什麼、先做哪個","，對產品價值負責",[48,80,81,83,86],{},[66,82,68],{},[66,84,85],{},"Developers",[66,87,74,88,91],{},[14,89,90],{},"怎麼做","，每個 Sprint 交付可用的 Increment",[48,93,94,96,99],{},[66,95,68],{},[66,97,98],{},"Scrum Master",[66,100,101],{},"讓 Scrum 真的運作起來，排除阻礙、引導會議",[48,103,104,107,110],{},[66,105,106],{},"產出物",[66,108,109],{},"Product Backlog",[66,111,112],{},"產品所有待辦事項，排好優先順序",[48,114,115,117,120],{},[66,116,106],{},[66,118,119],{},"Sprint Backlog",[66,121,122],{},"這個 Sprint 的目標、選定的項目和執行計畫",[48,124,125,127,130],{},[66,126,106],{},[66,128,129],{},"Increment",[66,131,132],{},"這個 Sprint 完成、可以使用的產品增量",[48,134,135,138,141],{},[66,136,137],{},"事件",[66,139,140],{},"Sprint",[66,142,143],{},"固定長度的開發週期，其他事件都在它裡面",[48,145,146,148,151],{},[66,147,137],{},[66,149,150],{},"Sprint Planning",[66,152,153],{},"決定這個 Sprint 為什麼做、做什麼、怎麼做",[48,155,156,158,161],{},[66,157,137],{},[66,159,160],{},"Daily Scrum",[66,162,163],{},"每天 15 分鐘，檢查離 Sprint Goal 還有多遠",[48,165,166,168,171],{},[66,167,137],{},[66,169,170],{},"Sprint Review",[66,172,173],{},"檢視成果、收集反饋、調整 Product Backlog",[48,175,176,178,181],{},[66,177,137],{},[66,179,180],{},"Sprint Retrospective",[66,182,183],{},"檢視團隊的工作方式，找出要改進的地方",[10,185,186,187,190],{},"Product Backlog Refinement 不在五個事件裡。Scrum Guide 把它定義成一個",[14,188,189],{},"持續進行的活動","，很多團隊會固定排一個會議來做，但它不是必須的事件。",[192,193,195],"h3",{"id":194},"_2020-版的幾個改動","2020 版的幾個改動",[10,197,198],{},"網路上很多文章還是 2017 版以前的寫法，對照時要注意：",[200,201,202,209,227,233],"ul",{},[203,204,205,208],"li",{},[14,206,207],{},"「開發團隊」改成「Developers」","：以前的說法是 Scrum Team 裡面還有一個「Development Team」，2020 版拿掉了這層，Scrum Team 就是一個團隊，裡面有 PO、Scrum Master 和 Developers，避免 PO 和開發人員變成「兩邊」",[203,210,211,214,215,218,219,222,223,226],{},[14,212,213],{},"每個產出物都有對應的承諾","：Product Backlog 對應 ",[14,216,217],{},"Product Goal","、Sprint Backlog 對應 ",[14,220,221],{},"Sprint Goal","、Increment 對應 ",[14,224,225],{},"Definition of Done","。產出物說明「有什麼」，承諾說明「要達到什麼」",[203,228,229,232],{},[14,230,231],{},"Sprint Planning 從兩個主題變成三個","：多了「Why」，也就是先說清楚這個 Sprint 為什麼有價值",[203,234,235,238],{},[14,236,237],{},"Daily Scrum 不再規定三個問題","：「昨天做了什麼、今天做什麼、有沒有阻礙」變成可選的形式，重點改成檢查離 Sprint Goal 還有多遠",[27,240,242],{"id":241},"角色誰負責什麼","角色：誰負責什麼",[192,244,246],{"id":245},"product-owner","Product Owner",[200,248,249,255,258],{},[203,250,251,252],{},"負責管理 Product Backlog：根據市場需求、客戶反饋、商業目標，不斷新增、修改 User Story，並",[14,253,254],{},"排列優先順序",[203,256,257],{},"和 Stakeholder（利益相關者）溝通，理解需求，再把需求轉成 Product Backlog 的項目",[203,259,260,261,264],{},"PO 是",[14,262,263],{},"一個人","，不是一個委員會。其他人可以影響 PO 的決定，但要改變優先順序，得去說服 PO，而不是直接找開發人員插單",[192,266,85],{"id":267},"developers",[200,269,270,273,278],{},[203,271,272],{},"負責把 Product Backlog 的項目做成可用的 Increment，包含設計、開發、測試",[203,274,74,275,277],{},[14,276,90],{},"：技術方案、任務拆分、誰做哪一塊，都由 Developers 自己決定",[203,279,280],{},"對品質負責：每個 Sprint 的成果都要符合 Definition of Done",[192,282,98],{"id":283},"scrum-master",[200,285,286,292,295],{},[203,287,288,289],{},"不是專案經理，也不是 Developers 的主管，",[14,290,291],{},"不分派工作",[203,293,294],{},"負責讓團隊理解並實踐 Scrum：引導會議、確保時間盒被遵守、排除團隊自己解決不了的阻礙",[203,296,297],{},"也要協助 PO，例如整理 Product Backlog 的方法、把 Product Goal 講清楚",[27,299,301],{"id":300},"product-backlog-refinement","Product Backlog Refinement",[10,303,304,305,308],{},"Refinement 的目的，是讓 Product Backlog 上方、接下來幾個 Sprint 可能會做的項目，",[14,306,307],{},"在 Sprint Planning 之前就已經夠清楚","，Planning 時才不會把時間花在釐清需求。",[200,310,311,314,317,320],{},[203,312,313],{},"PO 平常和 Stakeholder 討論需求，把需求轉成 User Story 和其他 Product Backlog 項目",[203,315,316],{},"開發團隊和 PO 定期一起討論 Product Backlog 中的項目，通常在每個 Sprint 內進行",[203,318,319],{},"開發人員會提出技術上的考量和建議，PO 則會澄清和修訂每個 User Story，確保它們準備好了",[203,321,322,323,326],{},"這個過程也包含對 User Story 做初步的",[14,324,325],{},"規模估算","（例如使用故事點），讓 PO 更好排序：同樣價值的兩個項目，成本低的通常先做",[192,328,330],{"id":329},"一個項目準備好了是什麼意思","一個項目「準備好了」是什麼意思",[10,332,333,334,337],{},"很多團隊會定一個 ",[14,335,336],{},"Definition of Ready","（Scrum Guide 沒有這個名詞，是業界常見的做法），常見的條件：",[200,339,340,346,352,358],{},[203,341,342,345],{},[14,343,344],{},"描述清楚","：用「作為＿＿，我希望＿＿，以便＿＿」的格式寫出誰要用、要做什麼、為什麼",[203,347,348,351],{},[14,349,350],{},"有驗收條件","：例如「訂單金額為 0 時不能送出」、「庫存不足時顯示提示」，Sprint Review 時才有依據判斷做完沒有",[203,353,354,357],{},[14,355,356],{},"大小適中","：一個 Sprint 內做得完。太大的就拆，例如把「訂單管理」拆成「建立訂單」、「查詢訂單」、「取消訂單」",[203,359,360,363],{},[14,361,362],{},"已估算","：Developers 對大小有共識",[10,365,366,367,370],{},"拆 User Story 時，要盡量",[14,368,369],{},"依功能切，不要依技術層切","。「建立訂單的前端」、「建立訂單的 API」、「建立訂單的資料表」分開成三個 Story，任何一個單獨完成都沒有辦法給使用者用；「建立訂單（只支援信用卡）」和「建立訂單支援貨到付款」才是各自都有價值的切法。",[192,372,373],{"id":373},"參與者",[200,375,376,378,380,383],{},[203,377,71],{},[203,379,85],{},[203,381,382],{},"Scrum Master（可選，通常只在團隊需要引導時參加）",[203,384,385],{},"利益相關者或領域專家（可選，需要釐清需求時邀請）",[10,387,388],{},"2017 版 Scrum Guide 曾建議 Refinement 通常不超過 Developers 產能的 10%，2020 版拿掉了這個數字，但可以作為參考：Refinement 太少，Planning 會變成需求討論會；太多，會擠壓開發時間。",[27,390,150],{"id":391},"sprint-planning",[10,393,394],{},"在每次 Sprint 開始時，會舉行 Sprint Planning 會議，整個 Scrum Team 都要參加。2020 版把它分成三個主題：",[10,396,397],{},[34,398],{"alt":399,"src":400},"Sprint Planning 的三個主題：第一是 Why，PO 提出這個 Sprint 為什麼有價值，全隊討論後確定 Sprint Goal，例如讓用戶能夠成功建立訂單並保存到系統中；第二是 What，PO 依優先順序提出項目，Developers 依過去的產能預估能做多少，例如建立訂單 5 點、訂單成立通知 3 點，訂單查詢放不下就留在 Product Backlog；第三是 How，由 Developers 把每個項目拆成任務，例如設計前端畫面、實作 API、寫入資料庫、撰寫單元測試，PO 在場回答問題。三者合起來就是 Sprint Backlog","\u002Fimages\u002Farticles\u002Fscrum-planning-topics.svg",[192,402,404],{"id":403},"why這個-sprint-為什麼有價值","① Why：這個 Sprint 為什麼有價值",[200,406,407,410],{},[203,408,409],{},"PO 向團隊說明，如果這個 Sprint 完成，產品會多出什麼價值，比如「這次 Sprint 我們要讓用戶能建立訂單」，並說明背景和重要性",[203,411,412,413,415],{},"全隊討論後確定 ",[14,414,221],{},"，Sprint Goal 必須在 Sprint Planning 結束前定下來",[192,417,419],{"id":418},"what這個-sprint-做哪些項目","② What：這個 Sprint 做哪些項目",[200,421,422,425,428,431],{},[203,423,424],{},"PO 依優先順序提出項目，Developers 評估能不能在這個 Sprint 內完成",[203,426,427],{},"Developers 依實際的開發能力對每個 User Story 估算，並參考過去幾個 Sprint 實際完成的量（Velocity），決定可以拉進 Sprint 的範圍",[203,429,430],{},"某些功能太複雜時，可以當場建議切分或調整範圍",[203,432,433,434,437],{},"這是",[14,435,436],{},"預估（Forecast）","，不是保證。2020 版刻意不說「承諾完成這些項目」，團隊承諾的是 Sprint Goal",[192,439,441],{"id":440},"how要怎麼完成","③ How：要怎麼完成",[10,443,444],{},"開發團隊將選定的 User Story 拆成具體的 Task，並討論如何分工。Task 通常會具體到一個人一天左右可以完成，而且可以互相並行。例如：",[200,446,447,450],{},[203,448,449],{},"User Story：「作為一個用戶，我希望能夠建立訂單，以便購買商品。」",[203,451,452,453],{},"Task：\n",[454,455,456,459,462,465],"ol",{},[203,457,458],{},"設計建立訂單的前端畫面",[203,460,461],{},"實作後端 API，處理建立訂單的請求",[203,463,464],{},"將訂單寫入資料庫",[203,466,467],{},"撰寫單元測試，確保訂單功能正確運作",[10,469,470,471,474],{},"這個步驟由 Developers 主導，",[14,472,473],{},"PO 不決定怎麼做","，但要留在現場：拆任務時常常會冒出「這個情況要怎麼處理？」的問題，這時候需要 PO 當場回答。很多文章說「PO 在這個階段不發言」，比較精確的說法是 PO 不主導技術決策，但要隨時能回答需求問題。",[10,476,477],{},"另外，Developers 不一定要在 Planning 就把整個 Sprint 的 Task 拆完。常見的做法是先把前幾天要做的拆細，後面的在 Sprint 中再細化。",[192,479,480],{"id":480},"產出",[10,482,483],{},"這個過程不需要額外的會議，它就是 Sprint Planning 會議的一部分。Sprint Planning 結束時，應該已經完成：",[200,485,486,489,492],{},[203,487,488],{},"定義好的 Sprint Goal",[203,490,491],{},"明確的 Sprint Backlog（選擇的 User Story）",[203,493,494],{},"至少前幾天要做的 Task，以及團隊對分工和做法的共識",[10,496,497],{},"時間盒：一個月的 Sprint 最多 8 小時，Sprint 較短時通常等比例縮短，例如兩週的 Sprint 約 4 小時。",[192,499,373],{"id":500},"參與者-1",[200,502,503,505,507],{},[203,504,71],{},[203,506,85],{},[203,508,509],{},"Scrum Master（協助引導會議）",[27,511,221],{"id":512},"sprint-goal",[10,514,515],{},"Sprint Goal 是一句簡短而清楚的描述，概括這個 Sprint 要實現的主要成果。它應該回答「這個 Sprint 結束時，團隊要交付什麼價值」，而不只是列出任務或功能細節。",[454,517,518,524,530],{},[203,519,520,523],{},[14,521,522],{},"簡潔明了","：用一兩句話概括，而不是一份工作清單",[203,525,526,529],{},[14,527,528],{},"聚焦於價值","：表達這次 Sprint 要交付的業務價值，而不是技術細節",[203,531,532,535],{},[14,533,534],{},"可衡量","：Sprint 結束時，團隊能清楚判斷目標有沒有達成",[192,537,538],{"id":538},"例子",[10,540,541],{},"以電商的訂單管理系統為例，假設這次 Sprint 的主要工作是「作為一個用戶，我希望能夠建立訂單」，Sprint Goal 可以寫成：",[543,544,545],"blockquote",{},[10,546,547],{},"讓用戶能夠成功建立訂單並保存到系統中，開始購物流程。",[10,549,550],{},"這個 Sprint Goal 沒有描述技術細節（例如設計 API 或連接資料庫），而是強調要交付的業務價值。",[10,552,553],{},"對照幾個不好的寫法：",[42,555,556,566],{},[45,557,558],{},[48,559,560,563],{},[51,561,562],{},"寫法",[51,564,565],{},"問題",[61,567,568,576,584],{},[48,569,570,573],{},[66,571,572],{},"完成 Story #101、#102、#105",[66,574,575],{},"只是把 Sprint Backlog 再抄一次，看不出為什麼要做",[48,577,578,581],{},[66,579,580],{},"實作訂單 API 與資料表",[66,582,583],{},"只描述技術工作，做完了用戶還是不能下單",[48,585,586,589],{},[66,587,588],{},"讓訂單系統更好用",[66,590,591],{},"太模糊，Sprint 結束時無法判斷有沒有達成",[192,593,595],{"id":594},"sprint-goal-的作用","Sprint Goal 的作用",[454,597,598,604,610],{},[203,599,600,603],{},[14,601,602],{},"集中團隊精力","：讓團隊知道這個 Sprint 最重要的是什麼，避免每個人各做各的 Story",[203,605,606,609],{},[14,607,608],{},"衡量進展","：Daily Scrum 時檢查是否朝 Sprint Goal 前進，Sprint 結束時評估是否達成",[203,611,612,615],{},[14,613,614],{},"保留彈性","：開發中發現某個 Story 比預期複雜時，Sprint Goal 是判斷依據。只要不影響 Sprint Goal，Developers 可以和 PO 協商，把部分範圍移出這個 Sprint；反過來，如果拿掉某個 Story 會讓 Sprint Goal 無法達成，就要優先處理它",[10,617,618,619,622],{},"第 3 點是 Sprint Goal 最實際的用處：",[14,620,621],{},"沒有 Sprint Goal，所有 Story 看起來都一樣重要","，遇到變數時只能每個都做一點，最後每個都沒做完。",[27,624,119],{"id":625},"sprint-backlog",[10,627,628],{},"Sprint Planning 會議後產出的 Sprint Backlog 包含三個部分：",[200,630,631,636,642],{},[203,632,633,635],{},[14,634,221],{},"（Why）",[203,637,638,641],{},[14,639,640],{},"從 Product Backlog 選出來的項目","（What）",[203,643,644,647],{},[14,645,646],{},"完成這些項目的執行計畫","，也就是拆出來的 Task（How）",[10,649,650,651,654],{},"Sprint Backlog 是 ",[14,652,653],{},"Developers 的","，而且在整個 Sprint 中會不斷更新：做的過程中發現漏掉的 Task 就加上去、Task 完成就移到完成欄。團隊通常會用看板（待辦、進行中、完成）或燃盡圖讓進度一目了然，Daily Scrum 時也是看著它討論。",[27,656,140],{"id":657},"sprint",[10,659,660],{},"Sprint 是 Scrum 框架的核心，它是一個固定的開發週期（1 到 4 週），在固定的時間內完成一組選定的 User Story，交付可用的產品增量。Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective 都發生在 Sprint 裡面，一個 Sprint 結束後，下一個立刻開始。",[10,662,663],{},[34,664],{"alt":665,"src":666},"兩週 Sprint 的一種排法，共 10 個工作天：第 1 天上午是 Sprint Planning，約半天；第 2 天到第 10 天每天有 15 分鐘的 Daily Scrum；第 1 天下午到第 10 天上午是開發、測試與整合，Sprint Backlog 每天更新；第 7 天排一次 Backlog Refinement，整理下個 Sprint 的候選項目；第 10 天下午依序是 Sprint Review 與 Sprint Retrospective。底部列出 Scrum Guide 以一個月 Sprint 為上限的時間盒：Planning 8 小時、Daily Scrum 15 分鐘、Review 4 小時、Retrospective 3 小時，Sprint 較短時通常等比例縮短","\u002Fimages\u002Farticles\u002Fscrum-sprint-timeline.svg",[192,668,670],{"id":669},"_1-sprint-開始","1. Sprint 開始",[200,672,673,679],{},[203,674,675,678],{},[14,676,677],{},"開始點","：Sprint Planning 是 Sprint 的第一個事件。Planning 結束時，團隊已經確定要完成的 User Story，並拆出了 Task",[203,680,681,684],{},[14,682,683],{},"目標","：達成 Sprint Goal，並盡可能完成 Sprint Backlog 中的工作",[192,686,688],{"id":687},"_2-每日站會daily-scrum","2. 每日站會（Daily Scrum）",[200,690,691,697,702],{},[203,692,693,696],{},[14,694,695],{},"頻率","：每天一次，固定 15 分鐘，在同一個時間、同一個地點，減少協調成本",[203,698,699,701],{},[14,700,373],{},"：Developers。Scrum Master 負責確保會議有舉行、不超時，但不一定要出席；PO 如果也在做 Sprint Backlog 上的項目，就以 Developer 的身分參加",[203,703,704,707],{},[14,705,706],{},"目的","：檢查離 Sprint Goal 還有多遠，必要時調整接下來一天的計畫",[10,709,710,711,714],{},"最常見的形式是每個人輪流說「昨天完成了什麼、今天要做什麼、有沒有遇到阻礙」，但 2020 版已經不規定這個格式。輪流報告最常見的問題是",[14,712,713],{},"變成向主管報告進度","，每個人講自己的事，沒有人在看整體。比較好的做法是看著 Sprint Backlog 的看板，從最接近完成的項目開始討論：「這張卡還差什麼？誰可以幫忙？」",[10,716,717],{},"站會不是解決問題的會議。發現問題時，記下來，站會結束後由相關的人留下來討論，其他人回去工作。",[192,719,721],{"id":720},"_3-sprint-進行中的工作","3. Sprint 進行中的工作",[200,723,724,730,736,742],{},[203,725,726,729],{},[14,727,728],{},"持續開發","：Developers 專注於 Sprint Backlog 中的 Task，並把功能整合到產品中",[203,731,732,735],{},[14,733,734],{},"工作方式","：根據 Daily Scrum 的調整推進 Task，處理 Bug、撰寫測試，並和其他成員協作完成所有 Story",[203,737,738,741],{},[14,739,740],{},"自我管理","：團隊自主決策和分工，Scrum Master 在團隊遇到自己解決不了的阻礙時協助排除",[203,743,744,747],{},[14,745,746],{},"持續 Refinement","：Sprint 中段通常會安排一次 Refinement，為下一個 Sprint 準備好候選項目",[192,749,751],{"id":750},"_4-產出可用的產品增量increment","4. 產出可用的產品增量（Increment）",[200,753,754,764,770],{},[203,755,756,759,760,763],{},[14,757,758],{},"完成的定義","：每個 Sprint 都要產出至少一個可用的 Increment，而且必須符合 ",[14,761,762],{},"Definition of Done（DoD）","。沒有符合 DoD 的工作不算 Increment，也不能在 Sprint Review 中展示成「完成」",[203,765,766,769],{},[14,767,768],{},"DoD 的例子","：程式碼經過 Code Review、單元測試通過、部署到測試環境、PO 驗收過驗收條件。DoD 是整個團隊的品質標準，每個項目都一樣適用",[203,771,772,775],{},[14,773,774],{},"不一定要等到 Sprint 結束","：Increment 可以在 Sprint 中隨時交付、甚至直接上線，Sprint Review 不是唯一的發布時機",[10,777,778,779,782,783,786],{},"DoD 和前面的驗收條件不一樣：驗收條件是",[14,780,781],{},"單一 Story"," 的功能要求，DoD 是",[14,784,785],{},"所有項目","都要達到的品質門檻。",[192,788,790],{"id":789},"_5-sprint-review衝刺檢視會議","5. Sprint Review（衝刺檢視會議）",[200,792,793,799,804,821],{},[203,794,795,798],{},[14,796,797],{},"時間點","：在 Sprint 的最後，一個月的 Sprint 最多 4 小時，兩週的 Sprint 大約 2 小時",[203,800,801,803],{},[14,802,373],{},"：Scrum Team 和 PO 邀請的利益相關者",[203,805,806,809,810],{},[14,807,808],{},"內容","：\n",[200,811,812,815,818],{},[203,813,814],{},"團隊展示完成的 Increment，說明實際的功能",[203,816,817],{},"一起討論這段時間環境有什麼變化（市場、使用者回饋、預算）",[203,819,820],{},"PO 和利益相關者給出反饋，根據反饋調整 Product Backlog",[203,822,823,825],{},[14,824,706],{},"：檢視成果、收集反饋，決定接下來最值得做的事",[10,827,828,829,832],{},"Sprint Review 是",[14,830,831],{},"工作會議","，不是單向的 Demo。如果每次都是團隊展示、台下說「很好」就散會，Product Backlog 沒有任何調整，這個會就沒有發揮作用。",[192,834,836],{"id":835},"_6-sprint-retrospective衝刺回顧會議","6. Sprint Retrospective（衝刺回顧會議）",[200,838,839,844,849,861],{},[203,840,841,843],{},[14,842,797],{},"：Sprint Review 之後，是 Sprint 的最後一個事件。一個月的 Sprint 最多 3 小時，兩週的 Sprint 大約 1.5 小時",[203,845,846,848],{},[14,847,373],{},"：整個 Scrum Team，包含 PO、Scrum Master 和 Developers",[203,850,851,809,853],{},[14,852,808],{},[200,854,855,858],{},[203,856,857],{},"討論 Sprint 中做得好的地方、遇到的問題，涵蓋人、互動、流程、工具和 Definition of Done",[203,859,860],{},"提出具體的改進行動，最重要的那一兩項可以直接放進下一個 Sprint 的 Sprint Backlog",[203,862,863,865],{},[14,864,706],{},"：持續改進團隊的工作方式，提高效率和品質",[10,867,868,869,872],{},"Retrospective 最常見的失敗是「每次都講一樣的問題，但什麼都沒改」。改進行動要",[14,870,871],{},"具體、有負責人、下次 Retrospective 檢查","，例如「Code Review 平均要等兩天」對應的行動是「每天下午 2 點固定看一次 PR，由輪值的人提醒」，而不是「大家要多注意 Code Review」。",[192,874,876],{"id":875},"sprint-的核心特點","Sprint 的核心特點",[200,878,879,885,891,896],{},[203,880,881,884],{},[14,882,883],{},"時間盒（Time-boxed）","：每個 Sprint 都是固定長度，即使有未完成的工作也不會延長 Sprint。沒做完的項目回到 Product Backlog，由 PO 重新排序",[203,886,887,890],{},[14,888,889],{},"Sprint Goal 不變，範圍可以調整","：Sprint 期間不能做出危害 Sprint Goal 的變更，品質標準也不能降低；但在不影響 Sprint Goal 的前提下，Developers 可以和 PO 協商、澄清或調整範圍。常見的說法「Sprint Backlog 完全不能改」並不精確，Developers 每天都在更新它",[203,892,893,895],{},[14,894,740],{},"：Developers 在 Sprint 期間自己決定怎麼做，Scrum Master 協助排除障礙，PO 不干預具體實作",[203,897,898,901],{},[14,899,900],{},"取消 Sprint","：只有在 Sprint Goal 已經失去意義時（例如業務方向改變），PO 可以取消 Sprint，這種情況很少見",[27,903,904],{"id":904},"實務上常見的誤解",[200,906,907,913,919,925,931,937],{},[203,908,909,912],{},[14,910,911],{},"把 Scrum Master 當專案經理","：由 Scrum Master 分派任務、追進度、對外承諾時程，團隊就不會自我管理。分工由 Developers 自己決定",[203,914,915,918],{},[14,916,917],{},"Daily Scrum 變成進度報告","：每個人對著 Scrum Master 或主管講自己的進度，沒有人關心 Sprint Goal。要對著看板、對著彼此說",[203,920,921,924],{},[14,922,923],{},"用故事點比較團隊或個人","：故事點是團隊內部用來預估的相對大小，不同團隊的 1 點不一樣，拿來考核只會讓估算膨脹",[203,926,927,930],{},[14,928,929],{},"Sprint 中途插單","：緊急的線上問題當然要處理，但如果每個 Sprint 都有大量插單，代表 Sprint 太長，或是需要預留處理臨時事項的產能，應該在 Retrospective 中討論，而不是默默加班",[203,932,933,936],{},[14,934,935],{},"沒有 Definition of Done","：每個人對「完成」的認知不同，有人寫完程式就算完成，有人要上線才算，Sprint Review 時才發現一堆項目其實沒做完",[203,938,939,942],{},[14,940,941],{},"Refinement 不足","：項目沒有提前釐清，Sprint Planning 就會拖很久，或是 Sprint 開始後才發現需求不清楚",[27,944,945],{"id":945},"一句話總結",[10,947,948],{},"Scrum 用固定長度的 Sprint 把開發切成一段一段：PO 透過 Refinement 讓 Product Backlog 隨時準備好，Sprint Planning 決定為什麼做（Sprint Goal）、做什麼、怎麼做，Daily Scrum 每天檢查離目標多遠，Sprint Review 檢視產品、調整 Backlog，Retrospective 檢視團隊、調整做法；每個事件都是一次「檢視與調整」，而 Sprint Goal 和 Definition of Done 是讓這些檢視有標準可依的承諾。",{"title":950,"searchDepth":951,"depth":951,"links":952},"",2,[953,957,962,966,973,977,978,987,988],{"id":29,"depth":951,"text":30,"children":954},[955],{"id":194,"depth":956,"text":195},3,{"id":241,"depth":951,"text":242,"children":958},[959,960,961],{"id":245,"depth":956,"text":246},{"id":267,"depth":956,"text":85},{"id":283,"depth":956,"text":98},{"id":300,"depth":951,"text":301,"children":963},[964,965],{"id":329,"depth":956,"text":330},{"id":373,"depth":956,"text":373},{"id":391,"depth":951,"text":150,"children":967},[968,969,970,971,972],{"id":403,"depth":956,"text":404},{"id":418,"depth":956,"text":419},{"id":440,"depth":956,"text":441},{"id":480,"depth":956,"text":480},{"id":500,"depth":956,"text":373},{"id":512,"depth":951,"text":221,"children":974},[975,976],{"id":538,"depth":956,"text":538},{"id":594,"depth":956,"text":595},{"id":625,"depth":951,"text":119},{"id":657,"depth":951,"text":140,"children":979},[980,981,982,983,984,985,986],{"id":669,"depth":956,"text":670},{"id":687,"depth":956,"text":688},{"id":720,"depth":956,"text":721},{"id":750,"depth":956,"text":751},{"id":789,"depth":956,"text":790},{"id":835,"depth":956,"text":836},{"id":875,"depth":956,"text":876},{"id":904,"depth":951,"text":904},{"id":945,"depth":951,"text":945},"2024-10-24","換到新團隊後，開發流程改成用 Scrum 運作。剛開始參加會議時，很容易只記得「每天早上要站會」、「每兩週要 Demo 一次」，但說不清楚每個會議為什麼存在、結束時應該產出什麼。這篇照著一個 Sprint 的順序把流程整理一遍，順便對照 Scrum Guide 2020，修正一些網路上常見、但其實是舊版或誤解的說法。",null,"md",{},true,"\u002Farticles\u002Foverview-of-scrum",{"title":5,"description":990},"articles\u002Foverview-of-scrum",[999,1000,1001,1002],"Scrum","敏捷開發","團隊協作","專案管理","t_s4umTDdZ-hWASJNNRCf_npK2p2OJK-VSs7tU80GpM",1792959150320]