敏捷工作流程——由需求到發布的一個迴圈
在一張互動畫布上呈現敏捷工作流程：需求、待辦清單、衝刺、示範、持份者接受、發布，以及餵養下一個迴圈的回顧會議。
敏捷工作流程以短迴圈把客戶需要變成已交付的價值：需求流入一份已排序的待辦清單，一個衝刺把一批工作變成可運作的增量，持份者接受或者退回，然後迴圈重複。
敏捷工作流程——由需求到發布的一個迴圈
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- 由左至右讀四個直欄，就是一個交付迴圈：準備了甚麼、建置了甚麼、由誰判斷，以及發布了甚麼。
- 三列是擁有者——待辦清單歸產品負責人，衝刺歸團隊，接受與否歸持份者。
- 「持份者接受嗎？」這個決策是迴圈的樞紐：「否」指向後方的需求，「是」指向前方的發布。
準備工作
「收集並梳理需求」與「按價值為待辦清單排序」是產品負責人的貢獻：把客戶需要變成一份團隊可以取用的排序清單。「衝刺規劃會議承諾一批工作」由「待辦清單」直欄跨進「衝刺」直欄——由團隊挑出自己將會交付的項目。
執行工作
「每日站立會議令工作保持可見」與「開發、測試並整合」是「團隊」泳道裡的衝刺：簡短的對齊會議，加上朝著一個可運作的增量持續推進的工作。圖解把它們並排放在「團隊」那一列，因為在這裡發揮作用的敏捷原則就是自我組織——衝刺內部要怎樣做，屬於團隊。
判斷與發布
「示範可運作的增量」把成果交給「持份者接受嗎？」——這個決策由「持份者」那一列擁有。接受就導向「發布給用戶」；被退回則導回需求，讓工作被重塑，而不是硬推過去。「回顧會議餵養下一個迴圈」由「團隊」泳道把循環收結：團隊自己的改善，成為下一輪的輸入。
Key relationships and takeaways
- 敏捷是一個迴圈：每一次發布的回饋與每一次回顧會議，都會重塑下一次迭代。
- 產品負責人為待辦清單排序；團隊承諾一批工作；持份者判斷成果。
- 接受是那道關卡——未被接受的增量會回到需求，而不是往前推進。
- 可運作的增量與短迴圈，取代了「長計劃就是好計劃」這個假設。
- 回顧會議是流程本身得到改善的地方，與產品是否被接受分開處理。
When to use this visual
- 向只見過瀑布式做法的團隊或持份者介紹這個敏捷迴圈。
- 審視一套敏捷實踐：接受關卡與回顧會議，是最常被悄悄省掉的兩步。
- 在採用某個工具或者規模化框架之前，先把你團隊的交付流程記錄下來。
運作方式
把角色改成你的團隊
把產品負責人、團隊與持份者換成你真實的角色——一個設計團隊、一個維運團隊、一個客戶委員會——並按情況把泳道合併或者拆開。
加入你實際舉行的儀式
把你的團隊真正會開的會議——需求整理、檢視、成果展示——當成步驟插在各個方框之間，每一個都放進擁有它的泳道。
令回饋迴圈變得具體
在回顧會議上註明你的團隊目前正在追蹤的那項改善，並在發布那一步註明你真實的節奏，令這個迴圈站得住腳。
加入發布的分支
如果你的團隊是按時間表或者按需要部署到生產環境，就加上相應的分支與它的觸發條件，每一條都以一個明確的狀態收結。
常見問題
甚麼是敏捷工作流程？
敏捷工作流程是一種以短而重複的迴圈交付價值的工作組織方式：先收集並排序需求，團隊承諾一批工作，把它建置並測試，示範成果，然後由接受與回顧會議的回饋重塑下一次迭代。它的決定性特質，是每一個迴圈的回饋都會改變下一個迴圈，而不是預先把計劃定死。
敏捷與瀑布式工作流程有甚麼分別？
瀑布式做法會先完成一個階段——需求、設計、建置、測試——才開始下一個，並在最後一次過交付所有東西。敏捷則以短迴圈執行這些階段，頻繁交付可運作的增量，並按回饋調整計劃。畫布的迴圈形狀正是這個結構上的分別：瀑布式的圖是一條直線，敏捷的圖是一個圓，接受與回顧會議都回饋進去。
在敏捷裡，由誰決定工作是否被接受？
由將會使用這份工作的持份者或客戶決定。敏捷的契約是：團隊頻繁交付可運作的增量，而決定一個增量是否夠好的，是客戶的接受，不是一份事先議定的規格。這也是圖解把接受決策放在「持份者」那一列，並且讓退回路徑通回需求的原因。
回顧會議在敏捷工作流程裡扮演甚麼角色？
回顧會議是這個迴圈的自我改善一步：團隊檢討上一次迭代進行得如何，並為下一次承諾一項改變。它與判斷產品的接受檢視是分開的。沒有回顧會議的敏捷，是一個不斷重複自己錯誤的迴圈——回顧會議正是令第二圈比第一圈更好的東西。
用 QueryChart（FlowJam）編輯這張圖解
把上面這張敏捷畫布開啟為你自己的圖表——把角色與階段改成你自己的流程，並加入你真實的關卡。