课程定位

一条待办写着‘改进订单流程’，产品、设计和开发却可能理解成三种范围。做到一半才讨论验收，容易在原型、接口和实际使用之间来回补充。本课围绕敏捷用户故事，把模糊需求缩到某个使用者能够完成的一段任务，再通过具体例子检查是否可交付。

课程内容与学习重点

围绕角色和工作目标识别待办范围

从用户遇到的问题出发，写明谁在什么场景希望完成什么，结果为什么有用。识别需求中的正常操作、状态变化和暂时无法处理的分支。可先用纸面方式画出原步骤，对照已有反馈，分开用户需要与团队事先设想的界面做法。

把大需求拆成具有独立价值的小故事

以修改一次预约为例，可以先处理已满足条件的正常改期，再分别处理预约已关闭和同一时段被抢占等情况。每条故事都要有可观察结果，明确暂时不做哪些分支。用依赖和使用价值讨论先后顺序，让各岗位知道一轮交付能够验证哪项实际需要。

用可以演示的例子确认验收

为各条故事准备正常、边界和失败情境，写明前提、执行和可观察的结果。请产品和交付人员独立读例子，发现对提示、状态或记录的理解差异。进入评审时用同一组例子检查，尚未完成的范围继续保留在待办，不因一个页面能运行就视为所有场景已经验证。

学完可以尝试形成一组用户故事、一个顺序列表和几条验收示例。选出一条团队常在中途反复改动的需求，先让其他同事根据故事判断范围，再比较他们写出的验收结果，修正表述不清的地方。

遇到一个边界场景仍无法确定时，可先记录负责确认的人与预计时间，不用在故事中猜测规则。评审后将仍不明确的问题交回业务同事，再决定需要补测试数据还是调整任务。

还可选择一个依赖外部环节的故事，用假设数据模拟上游输入晚到、状态缺失或信息更新不一致。练习把由当前团队保证的结果与需要其他岗位共同复核的条件分开写清。

适合人群

适合产品、设计、开发、测试及负责组织产品待办和交付评审的团队成员。

开课与报名咨询

单模块的具体日期、上课地点、学制、学习费用与参加方式请通过下方表单详询。

一条故事写不进一个迭代，怎么办？可以从用户目标、使用场景或处理分支拆分，先交付有独立结果的一段。再记录剩余分支与相关依赖。

验收例子要提前把界面设计定下来吗？可以先确认使用者行为和可观察结果，界面仍可比较。只有影响结果或必要条件时，再把具体表现写到验收说明。

温馨提示：课程内容为拟定，具体实际讲授内容由授课老师根据学员情况灵活调整，最终以课堂授课为准。