[{"data":1,"prerenderedAt":666},["ShallowReactive",2],{"article-\u002Farticles\u002Fevent-storming-in-scrum":3},{"id":4,"title":5,"body":6,"date":650,"description":651,"excerpt":652,"extension":653,"meta":654,"navigation":655,"path":656,"seo":657,"stem":658,"tags":659,"__hash__":665},"articles\u002Farticles\u002Fevent-storming-in-scrum.md","在 Scrum 中加入 Event Storming：Big Picture 建立 Product Backlog，Process Modeling 拆出 User Story",{"type":7,"value":8,"toc":634},"minimark",[9,23,40,46,51,58,154,158,161,172,175,206,213,217,220,225,232,238,313,316,342,345,348,351,371,374,419,432,436,439,458,461,482,485,488,514,517,542,545,628,631],[10,11,12,17,18,22],"p",{},[13,14,16],"a",{"href":15},"\u002Farticles\u002Foverview-of-scrum","Scrum 流程整理"," 那篇整理了 Scrum 的角色、事件和產出物，",[13,19,21],{"href":20},"\u002Farticles\u002Fevent-storming-workshop","Event Storming 怎麼跑"," 那篇整理了工作坊的做法。兩者各自都清楚，但放在一起時有個落差：",[24,25,26,34],"ul",{},[27,28,29,33],"li",{},[30,31,32],"strong",{},"Scrum 沒有說需求從哪裡來","：Product Backlog 要「排好優先順序、上面的項目要清楚」，但 PO 怎麼知道該有哪些項目？一個個獨立寫出來的 User Story，很容易看不出彼此的關係，Refinement 變成 PO 逐張念卡片",[27,35,36,39],{},[30,37,38],{},"Event Storming 沒有說之後怎麼辦","：牆貼滿了、熱點也找到了，然後呢？如果要先把所有流程都拆到 Software Design 才開始開發，那就變回瀑布了",[10,41,42,43],{},"這篇整理把兩者接起來的方式。核心原則只有一句：",[30,44,45],{},"Big Picture 看全貌只做一次，細節只為接下來一兩個 Sprint 建模。",[47,48,50],"h2",{"id":49},"每種-event-storming-放在哪裡","每種 Event Storming 放在哪裡",[10,52,53],{},[54,55],"img",{"alt":56,"src":57},"Event Storming 在 Scrum 中的位置：產品啟動或設定新的 Product Goal 時，跑一次半天到一天的 Big Picture，產出 Epic、熱點與 Product Goal，進入 Product Backlog；之後每個 Sprint 重複：Backlog Refinement 時針對下一個 Epic 跑 1 到 2 小時的 Process Modeling，拆出 User Story 與驗收條件，放回 Product Backlog；Sprint Planning 時只針對複雜的 Story 跑 30 到 60 分鐘的 Software Design，找出聚合並拆出 Task；開發期間把牆面當參考，新發現的問題貼成熱點；Sprint Review 時在牆面上標出這次完成的事件，和利害關係人對齊全貌；Review 結束後進入下一個 Sprint","\u002Fimages\u002Farticles\u002Fevent-storming-scrum-cadence.svg",[59,60,61,80],"table",{},[62,63,64],"thead",{},[65,66,67,71,74,77],"tr",{},[68,69,70],"th",{},"時機",[68,72,73],{},"Event Storming 層次",[68,75,76],{},"參與者",[68,78,79],{},"產出",[81,82,83,98,112,126,140],"tbody",{},[65,84,85,89,92,95],{},[86,87,88],"td",{},"產品啟動、設定新的 Product Goal",[86,90,91],{},"Big Picture（半天～一天）",[86,93,94],{},"PO、各部門的領域專家、Developers",[86,96,97],{},"Epic、熱點、Product Goal 的方向",[65,99,100,103,106,109],{},[86,101,102],{},"Backlog Refinement",[86,104,105],{},"Process Modeling（1～2 小時）",[86,107,108],{},"PO、相關的領域專家、Developers",[86,110,111],{},"User Story、驗收條件、還沒釐清的熱點",[65,113,114,117,120,123],{},[86,115,116],{},"Sprint Planning 的「How」",[86,118,119],{},"Software Design（30～60 分鐘，視需要）",[86,121,122],{},"Developers，PO 在場回答問題",[86,124,125],{},"聚合、命令、事件的設計，以及 Task",[65,127,128,131,134,137],{},[86,129,130],{},"Sprint 進行中",[86,132,133],{},"不另外跑，牆面當參考",[86,135,136],{},"Developers",[86,138,139],{},"新的熱點",[65,141,142,145,148,151],{},[86,143,144],{},"Sprint Review",[86,146,147],{},"回到牆面更新",[86,149,150],{},"Scrum Team、利害關係人",[86,152,153],{},"已完成的範圍、對全貌的新理解",[47,155,157],{"id":156},"big-picture-product-backlog","Big Picture → Product Backlog",[10,159,160],{},"Big Picture 不需要每個 Sprint 跑，通常在這些時候才跑：",[24,162,163,166,169],{},[27,164,165],{},"新產品或新專案開始",[27,167,168],{},"要設定新的 Product Goal，例如「讓斡旋流程全面線上化」",[27,170,171],{},"團隊接手一個不熟悉的領域",[10,173,174],{},"跑完之後，牆上的東西可以直接對應到 Product Backlog：",[24,176,177,188,194,200],{},[27,178,179,182,183,187],{},[30,180,181],{},"關鍵事件切出來的每一段，變成一個 Epic","：例如「委託與刊登」、「帶看」、「斡旋」、「簽約交屋」。這些段落也是 ",[13,184,186],{"href":185},"\u002Farticles\u002Fddd-subdomains-bounded-context","子域與限界上下文"," 的候選邊界，Epic 和團隊的分工可以一起考慮",[27,189,190,193],{},[30,191,192],{},"投票選出的熱點，決定先做哪個 Epic","：大家最痛的地方通常就是最有價值的地方。例如投票最多的是「斡旋要經紀人逐一打電話通知，常常漏掉」，那斡旋就是第一個 Epic",[27,195,196,199],{},[30,197,198],{},"問題型的熱點，變成待釐清的項目","：「斡旋已接受算不算成交？」不是開發工作，而是要 PO 去和業務、財務確認的事。可以放進 Product Backlog 並指定負責人，或者在需要時排一個探索性的 Spike",[27,201,202,205],{},[30,203,204],{},"Product Goal","：整面牆和投票結果，讓 PO 更容易寫出一個具體的 Product Goal，而不是「優化交易流程」這種口號",[10,207,208,209,212],{},"這時候 Product Backlog 上只有幾個 Epic，",[30,210,211],{},"不需要把每個 Epic 都拆成 Story","。拆得太早，到真的要做時需求可能已經變了。",[47,214,216],{"id":215},"process-modeling-user-story","Process Modeling → User Story",[10,218,219],{},"每個 Sprint 的 Backlog Refinement 中，挑出排在最前面、下一兩個 Sprint 就要做的 Epic，跑一場 Process Modeling。Scrum Guide 2017 版曾建議 Refinement 不要超過 Developers 產能的 10%，兩週的 Sprint 大約一天左右，花 1～2 小時跑 Process Modeling 是合理的。",[221,222,224],"h3",{"id":223},"沿著命令和事件切-story","沿著命令和事件切 Story",[10,226,227,228,231],{},"Process Modeling 的牆貼完後，",[30,229,230],{},"一條「命令 → 事件」或「政策 → 事件」的路徑，就是一個 Story 的候選","：",[10,233,234],{},[54,235],{"alt":236,"src":237},"把斡旋流程的 Process Modeling 切成 User Story：上方是牆面，依序是命令「提出斡旋」與事件「斡旋已提出」組成 Story A 提出斡旋；政策「每當斡旋已提出就通知屋主」與事件「屋主已收到通知」組成 Story B 通知屋主；角色屋主發出命令「接受斡旋」產生事件「斡旋已接受」組成 Story C 屋主接受斡旋；另一條路徑政策「每當期限到就失效」與事件「斡旋已過期」組成 Story D 斡旋到期失效；政策「每當斡旋已接受就通知其他斡旋人」旁邊貼著熱點「多組斡旋時誰優先」，所以 Story E 還沒就緒，暫時不放進 Sprint。下方展開 Story C，把相關的事件寫成 Given When Then 的驗收條件：斡旋已提出且未過期時接受，結果是斡旋已接受；斡旋已過期時接受，結果是拒絕並提示斡旋已過期；斡旋已撤回時接受，結果是拒絕並提示斡旋已撤回","\u002Fimages\u002Farticles\u002Fevent-storming-story-slicing.svg",[59,239,240,253],{},[62,241,242],{},[65,243,244,247,250],{},[68,245,246],{},"Story",[68,248,249],{},"牆上的路徑",[68,251,252],{},"說明",[81,254,255,266,277,288,299],{},[65,256,257,260,263],{},[86,258,259],{},"A. 提出斡旋",[86,261,262],{},"提出斡旋 → 斡旋已提出",[86,264,265],{},"買方能提出斡旋",[65,267,268,271,274],{},[86,269,270],{},"B. 通知屋主",[86,272,273],{},"政策：每當斡旋已提出，就通知屋主 → 屋主已收到通知",[86,275,276],{},"自動通知取代經紀人打電話",[65,278,279,282,285],{},[86,280,281],{},"C. 屋主接受斡旋",[86,283,284],{},"接受斡旋 → 斡旋已接受",[86,286,287],{},"屋主可以接受斡旋",[65,289,290,293,296],{},[86,291,292],{},"D. 斡旋到期失效",[86,294,295],{},"政策：每當期限到，就失效 → 斡旋已過期",[86,297,298],{},"不需要人工處理過期",[65,300,301,304,307],{},[86,302,303],{},"E. 通知其他斡旋人",[86,305,306],{},"政策：每當斡旋已接受，就通知其他斡旋人",[86,308,309,310],{},"有熱點「多組斡旋時誰優先」，",[30,311,312],{},"還沒就緒",[10,314,315],{},"這樣切出來的 Story 有幾個好處：",[24,317,318,324,330,336],{},[27,319,320,323],{},[30,321,322],{},"天生就是垂直切片","：每個 Story 從命令到事件，一定包含畫面、API、規則、資料，完成後就是一個能用的功能，而不是「斡旋的資料表」、「斡旋的 API」這種依技術層切的 Story",[27,325,326,329],{},[30,327,328],{},"大小比較一致","：每條路徑的範圍差不多，估算時比較不會出現一個 3 點、一個 40 點",[27,331,332,335],{},[30,333,334],{},"順序很清楚","：牆上看得出 C 一定要在 A 之後，B 和 D 可以並行",[27,337,338,341],{},[30,339,340],{},"有熱點的就是還沒就緒","：E 牽涉到一個還沒定案的業務規則，不應該放進 Sprint。這和 Scrum 那篇提到的 Definition of Ready 是同一件事",[10,343,344],{},"如果一條路徑太大，例如「提出斡旋」要處理斡旋金的線上付款，可以再沿著事件拆開：「提出斡旋（斡旋金現場收取）」先做，「斡旋金線上付款」之後再做，兩個都是能獨立使用的功能。",[221,346,347],{"id":347},"事件就是驗收條件",[10,349,350],{},"Story 的驗收條件，可以直接從牆上的事件寫成 Given–When–Then：",[24,352,353,359,365],{},[27,354,355,358],{},[30,356,357],{},"Given"," 前面已經發生的事件（狀態）",[27,360,361,364],{},[30,362,363],{},"When"," 這個 Story 的命令",[27,366,367,370],{},[30,368,369],{},"Then"," 應該產生的事件，或是被拒絕的原因",[10,372,373],{},"以 Story C「屋主接受斡旋」為例：",[59,375,376,386],{},[62,377,378],{},[65,379,380,382,384],{},[68,381,357],{},[68,383,363],{},[68,385,369],{},[81,387,388,399,409],{},[65,389,390,393,396],{},[86,391,392],{},"斡旋已提出，且還沒過期",[86,394,395],{},"屋主接受斡旋",[86,397,398],{},"斡旋已接受",[65,400,401,404,406],{},[86,402,403],{},"斡旋已過期",[86,405,395],{},[86,407,408],{},"拒絕，提示「斡旋已過期」",[65,410,411,414,416],{},[86,412,413],{},"斡旋已撤回",[86,415,395],{},[86,417,418],{},"拒絕，提示「斡旋已撤回」",[10,420,421,422,426,427,431],{},"這些驗收條件用的都是牆上的業務用語，PO 看得懂，開發人員也可以直接寫成測試。如果用 ",[13,423,425],{"href":424},"\u002Farticles\u002Fddd-overview-strategic-tactical","DDD 概論"," 裡的聚合設計，這三列幾乎就是 ",[428,429,430],"code",{},"Offer.Accept()"," 的三個單元測試。",[47,433,435],{"id":434},"sprint-planning需要時才跑-software-design","Sprint Planning：需要時才跑 Software Design",[10,437,438],{},"Sprint Planning 的「How」階段，大部分的 Story 直接拆 Task 就好。只有在這些情況，才值得花 30～60 分鐘跑一次 Software Design：",[24,440,441,452,455],{},[27,442,443,444,447,448,451],{},"這個 Sprint 要建立新的聚合，例如第一次做斡旋，要決定 ",[428,445,446],{},"Offer"," 和 ",[428,449,450],{},"Listing"," 的邊界",[27,453,454],{},"Story 牽涉到多個聚合之間的一致性，例如「斡旋已接受」之後，物件狀態要不要立刻更新",[27,456,457],{},"團隊對設計有明顯的分歧",[10,459,460],{},"跑完之後，Task 也很自然地出來了：",[462,463,464,473,476,479],"ol",{},[27,465,466,468,469,472],{},[428,467,446],{}," 聚合加上 ",[428,470,471],{},"Accept()"," 方法與驗收條件對應的單元測試",[27,474,475],{},"「接受斡旋」的命令處理",[27,477,478],{},"「斡旋已接受」事件的發布",[27,480,481],{},"屋主端的斡旋列表畫面（讀取模型）",[47,483,484],{"id":484},"讓牆面活著",[10,486,487],{},"Event Storming 的牆如果貼完就收起來，幾個 Sprint 之後就沒人記得全貌了。幾個讓它持續發揮作用的做法：",[24,489,490,496,502,508],{},[27,491,492,495],{},[30,493,494],{},"轉成線上白板","：實體牆拍照後整理到 Miro，整個團隊都看得到",[27,497,498,501],{},[30,499,500],{},"標出進度","：每個 Sprint 完成的事件，在白板上標記為已完成。Sprint Review 時打開這張圖，利害關係人一眼就能看出這次的 Increment 在整個流程的哪一段",[27,503,504,507],{},[30,505,506],{},"新的發現就更新","：開發過程中發現新的規則或例外，直接加一張便利貼或熱點，下次 Refinement 時一起討論",[27,509,510,513],{},[30,511,512],{},"不要追求完整","：牆面是溝通工具，不是規格書。過時的部分寧可刪掉，也不要讓它誤導人",[47,515,516],{"id":516},"角色分工",[24,518,519,525,531,536],{},[27,520,521,524],{},[30,522,523],{},"PO","：對結果負責，決定哪些熱點要優先處理、哪些 Story 先做。Big Picture 和 Process Modeling 都一定要參加",[27,526,527,530],{},[30,528,529],{},"Scrum Master","：適合擔任主持人，確保時間盒、確保每個人都有參與。如果團隊裡有人更熟悉 Event Storming，也可以由他主持",[27,532,533,535],{},[30,534,136],{},"：一起參與，不是等 PO 把 Story 寫好再看。他們會問出很多業務沒想過的邊界情況",[27,537,538,541],{},[30,539,540],{},"領域專家","：Big Picture 要找齊各部門；Process Modeling 只需要該流程的人。他們不一定是 Scrum Team 的成員，由 PO 邀請",[47,543,544],{"id":544},"常見的陷阱",[59,546,547,560],{},[62,548,549],{},[65,550,551,554,557],{},[68,552,553],{},"陷阱",[68,555,556],{},"結果",[68,558,559],{},"改善",[81,561,562,573,584,595,606,617],{},[65,563,564,567,570],{},[86,565,566],{},"開發前把所有流程都跑到 Software Design",[86,568,569],{},"花了一個月設計，需求已經變了，變回瀑布",[86,571,572],{},"只為接下來一兩個 Sprint 建模",[65,574,575,578,581],{},[86,576,577],{},"只有 Developers 自己跑",[86,579,580],{},"牆上都是開發人員的猜測，沒有真正的業務知識",[86,582,583],{},"PO 和領域專家一定要在場",[65,585,586,589,592],{},[86,587,588],{},"依技術層切 Story",[86,590,591],{},"每個 Story 都無法單獨使用，Sprint Review 沒東西可展示",[86,593,594],{},"沿著命令→事件的路徑切",[65,596,597,600,603],{},[86,598,599],{},"熱點沒有人追",[86,601,602],{},"同樣的問題在下一場又被貼一次",[86,604,605],{},"每個熱點指定負責人，放進 Product Backlog",[65,607,608,611,614],{},[86,609,610],{},"每個 Sprint 都跑 Big Picture",[86,612,613],{},"時間成本太高，參與者開始疲乏",[86,615,616],{},"Big Picture 只在 Product Goal 改變時跑",[65,618,619,622,625],{},[86,620,621],{},"牆面只用一次",[86,623,624],{},"幾個 Sprint 後沒人記得全貌",[86,626,627],{},"轉成線上白板，在 Review 時更新",[47,629,630],{"id":630},"一句話總結",[10,632,633],{},"把 Event Storming 加進 Scrum 的方式，是依照「由寬到窄、剛好夠用」放在不同的時機：產品啟動時用 Big Picture 找出 Epic、熱點與 Product Goal，每個 Sprint 的 Refinement 只為下一個 Epic 跑 Process Modeling，沿著命令與事件切出垂直的 User Story、用事件寫出驗收條件，Sprint Planning 只在必要時跑 Software Design，並讓牆面在每次 Review 時持續更新。",{"title":635,"searchDepth":636,"depth":636,"links":637},"",2,[638,639,640,645,646,647,648,649],{"id":49,"depth":636,"text":50},{"id":156,"depth":636,"text":157},{"id":215,"depth":636,"text":216,"children":641},[642,644],{"id":223,"depth":643,"text":224},3,{"id":347,"depth":643,"text":347},{"id":434,"depth":636,"text":435},{"id":484,"depth":636,"text":484},{"id":516,"depth":636,"text":516},{"id":544,"depth":636,"text":544},{"id":630,"depth":636,"text":630},"2024-12-17","Scrum 流程整理 那篇整理了 Scrum 的角色、事件和產出物，Event Storming 怎麼跑 那篇整理了工作坊的做法。兩者各自都清楚，但放在一起時有個落差：",null,"md",{},true,"\u002Farticles\u002Fevent-storming-in-scrum",{"title":5,"description":651},"articles\u002Fevent-storming-in-scrum",[660,661,662,663,664],"Scrum","Event Storming","DDD","敏捷開發","需求分析","ymb4RS9-jg49dw3-0TenpzRiFqG8-w_H4_INzJS5JNc",1792959150296]