敏捷工作流程——由需求到發布的一個迴圈 · 心智圖
敏捷工作流程——由需求到發布的一個迴圈. 可編輯嘅心智圖，以彩色分支、子題目同曲線連結呈現概念。 曲線表示關聯；只有方向重要時先用箭嘴。
敏捷工作流程以短迴圈把客戶需要變成已交付的價值：需求流入一份已排序的待辦清單，一個衝刺把一批工作變成可運作的增量，持份者接受或者退回，然後迴圈重複。
敏捷工作流程——由需求到發布的一個迴圈 · 心智圖
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
點樣閱讀呢張心智圖
- 由中央主題開始，沿住彩色分支探索相關概念。
- 曲線表示關聯；只有方向重要時先用箭嘴。
Backlog
呢個分支匯集 “Gather and refine requirements”, “Prioritise the backlog by value”.
Plan the sprint
呢個分支匯集 “Sprint planning commits to a batch”.
Build together
呢個分支匯集 “Daily stand-ups keep work visible”, “Develop, test and integrate”.
Inspect
呢個分支匯集 “Demo the working increment”, “Stakeholders accept it?”.
Adapt & release
呢個分支匯集 “Release to users”, “Agile is a loop, not a line: feedback from the release and the retrospective reshape the backlog for the next iteration.”.
跨分支關聯
敏捷是一個迴圈：每一次發布的回饋與每一次回顧會議，都會重塑下一次迭代。
產品負責人為待辦清單排序；團隊承諾一批工作；持份者判斷成果。
接受是那道關卡——未被接受的增量會回到需求，而不是往前推進。
可運作的增量與短迴圈，取代了「長計劃就是好計劃」這個假設。
回顧會議是流程本身得到改善的地方，與產品是否被接受分開處理。
Key relationships and takeaways
- 敏捷是一個迴圈：每一次發布的回饋與每一次回顧會議，都會重塑下一次迭代。
- 產品負責人為待辦清單排序；團隊承諾一批工作；持份者判斷成果。
- 接受是那道關卡——未被接受的增量會回到需求，而不是往前推進。
- 可運作的增量與短迴圈，取代了「長計劃就是好計劃」這個假設。
- 回顧會議是流程本身得到改善的地方，與產品是否被接受分開處理。
When to use this visual
- 向只見過瀑布式做法的團隊或持份者介紹這個敏捷迴圈。
- 審視一套敏捷實踐：接受關卡與回顧會議，是最常被悄悄省掉的兩步。
- 在採用某個工具或者規模化框架之前，先把你團隊的交付流程記錄下來。
運作方式
調整中央主題
按項目或課堂修改中央主題名稱。
擴展分支
編輯概念並加入例子或註解。
連結相關概念
畫出跨分支連結；只有方向重要時先用箭嘴。
常見問題
甚麼是敏捷工作流程？
敏捷工作流程是一種以短而重複的迴圈交付價值的工作組織方式：先收集並排序需求，團隊承諾一批工作，把它建置並測試，示範成果，然後由接受與回顧會議的回饋重塑下一次迭代。它的決定性特質，是每一個迴圈的回饋都會改變下一個迴圈，而不是預先把計劃定死。
敏捷與瀑布式工作流程有甚麼分別？
瀑布式做法會先完成一個階段——需求、設計、建置、測試——才開始下一個，並在最後一次過交付所有東西。敏捷則以短迴圈執行這些階段，頻繁交付可運作的增量，並按回饋調整計劃。畫布的迴圈形狀正是這個結構上的分別：瀑布式的圖是一條直線，敏捷的圖是一個圓，接受與回顧會議都回饋進去。
在敏捷裡，由誰決定工作是否被接受？
由將會使用這份工作的持份者或客戶決定。敏捷的契約是：團隊頻繁交付可運作的增量，而決定一個增量是否夠好的，是客戶的接受，不是一份事先議定的規格。這也是圖解把接受決策放在「持份者」那一列，並且讓退回路徑通回需求的原因。
回顧會議在敏捷工作流程裡扮演甚麼角色？
回顧會議是這個迴圈的自我改善一步：團隊檢討上一次迭代進行得如何，並為下一次承諾一項改變。它與判斷產品的接受檢視是分開的。沒有回顧會議的敏捷，是一個不斷重複自己錯誤的迴圈——回顧會議正是令第二圈比第一圈更好的東西。
喺 QueryChart 編輯呢張心智圖
喺可編輯畫布開啟心智圖。移動概念、加入分支同畫連結。