敏捷工作流图解——从需求到发布，不断循环
敏捷工作流，在一张交互式画布上讲清楚：需求、待办列表、Sprint、演示、干系人验收、发布，以及为下一个循环提供输入的回顾会议。
敏捷工作流用短循环把客户需求变成已交付的价值：需求汇入一份排好优先级的待办列表，一个 Sprint 把一批工作变成可用的增量，干系人决定接受还是退回，然后循环重来。
敏捷工作流图解——从需求到发布，不断循环
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
- 把四列从左往右读成一个交付循环：准备了什么，造出了什么，被怎样评判，最后发布了什么。
- 三行就是归属——产品负责人管待办列表，团队管 Sprint，干系人管验收。
- “干系人验收通过？”这个决策是循环的铰链：“否”指向后方的需求，“是”指向前方的发布。
准备工作
“收集并梳理需求”和“按价值给待办列表排定优先级”是产品负责人的贡献：把客户需求变成一份团队可以从中取用的排序清单。“Sprint 计划会议承诺一批工作”从“待办列表”列跨进“Sprint”列——由团队挑出自己要交付的条目。
把工作做出来
“每日站会让工作保持可见”与“开发、测试与集成”构成团队泳道里的 Sprint：简短的对齐会议，加上朝着可用增量持续推进的工作。图解把它们放在相邻位置、放进“团队”这一行，因为这里起作用的敏捷原则是自组织——Sprint 具体怎么做，属于团队。
评判与发布
“演示可用的增量”把结果交给“干系人验收通过？”——这个决策归干系人那一行所有。通过就走向“发布给用户”；不通过则退回需求，让工作被重塑，而不是硬推过去。“回顾会议为下一个循环提供输入”从“团队”泳道合上这个循环：团队自己的改进，成为下一轮的输入。
Key relationships and takeaways
- 敏捷是一个环：每一次发布的反馈和每一次回顾，都会重塑下一次迭代。
- 产品负责人给待办列表排序；团队承诺一批工作；干系人裁定结果。
- 验收是那道关卡——没通过的增量退回需求，而不是继续往前。
- 可用的增量加上短循环，取代了那种认为长计划才是好计划的假设。
- 回顾会议是流程本身变好的地方，与产品的验收分开。
When to use this visual
- 向只见过瀑布模式的团队或干系人介绍这个敏捷循环。
- 审视一套敏捷实践：验收关卡和回顾会议，是最常被悄悄省掉的两步。
- 在引入某个工具或规模化框架之前，先把你们团队的交付流程记录下来。
运作方式
把角色改成你的团队
把产品负责人、团队和干系人换成你们真实的角色——设计团队、运维团队、客户委员会——并相应地合并或拆分泳道。
加上你们真实的仪式
把团队真正在开的会议——梳理会、评审会、成果展示——作为步骤插到方框之间，每一个都放进拥有它的那条泳道。
让反馈闭环变具体
在回顾会议上标注团队当前正在跟踪的那项改进，在发布步骤上标注你们真实的节奏，让这个环落到实处。
补上发布的分支
如果你的团队是按计划或按需部署到生产环境的，就加上对应的分支及其触发条件，每条都终止于一个明确的状态。
常见问题
什么是敏捷工作流？
敏捷工作流是一种组织工作的方式，用短小且不断重复的循环交付价值：收集需求并排定优先级，团队承诺一批工作，把它构建并测试出来，演示结果，验收和回顾得到的反馈再重塑下一次迭代。它的决定性性质在于，每一轮的反馈都会改变下一轮，而不是预先把计划钉死。
敏捷和瀑布式工作流有什么区别？
瀑布式会先做完一个阶段——需求、设计、构建、测试——再开始下一个，最后一次性交付全部。敏捷则用短循环跑完这些阶段，频繁交付可用的增量，并根据反馈调整计划。画布的环形结构就是这个结构性差别：瀑布图是一条直线，敏捷图是一个圆，验收和回顾都会反馈回它自身。
在敏捷里由谁决定工作是否被接受？
由将要使用这些成果的干系人或客户来决定。敏捷的约定是团队频繁交付可用的增量，而一个增量是否够好，由客户的验收决定，而不是由事先商定的规格说明决定。这也是图解里的验收决策落在干系人那一行、并带着一条退回需求的路径的原因。
回顾会议在敏捷工作流里起什么作用？
回顾会议是这个循环的自我改进步骤：团队回看上一次迭代的过程，并为下一次承诺一项改动。它与判断产品的验收评审是分开的。没有回顾会议的敏捷，只是一个不断重复自身错误的循环——回顾会议才是让第二圈比第一圈更好的东西。
在 QueryChart（FlowJam）中编辑这张图解
把上面这张敏捷画布原样打开成你自己的图表，把角色和阶段改成你的流程，再加上你真实的关卡。