软件分析与设计笔记 03：Agile 与 Scrum：迭代、角色与产出物

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，场景与图示都是自己编、自己画的，参考的主要是敏捷宣言与 Scrum Guide 这类公开资料。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。这一篇讲这套东西怎么被组织起来做出来 —— 尤其是一个 backlog 该怎么排。

0 一次典型的返工

一个五人团队花了三个月，按需求文档一路做完，交付会上片区经理王姐看了十分钟说：

「我要的不是这个。」

团队做的是一套「全片区排期总览」—— 40 位工程师 × 7 天的大表，一屏铺满颜色。他们完全按当初的需求文档做的，文档里写的就是「能看到所有工程师的排期」。

此时回头看，问题不在团队不够努力，而在反馈来得太晚。三个月里团队一直在按自己理解的文档推进，没有任何一个时刻能让小林或王姐指着屏幕说「对，就是这个」或者「不是这个」。

迭代式开发要解决的正是这个问题：把一次长达数月的赌注，拆成一串为期一到四周的小赌注，每次都能拿到真实反馈。

1 瀑布式与迭代式的根本差别

1.1 六个维度的差别

这张表里最该记住的是第三行：迭代不是让风险消失，而是让风险早点暴露。

本例里这个差别有一个具体的对照：如果按瀑布式做，王姐会在第三个月末才知道「总览页不好用」；如果按迭代式做，团队第一周就能做出一个只含「今日待派单 + 3 个候选人」的粗版，让小林实际用两天 —— 那两天里她一定会说「我还要看距离」，于是第一周就改了。

2 Scrum 的三个角色

2.1 三个角色各自负责什么

• Product Owner（产品负责人） —— 代表业务方，负责决定「先做什么后做什么」。他的核心工作产出是产品待办清单的排序。
• Scrum Master（敏捷教练） —— 负责流程本身：移除障碍、保护迭代节奏、把流程跑歪的地方纠正回来。
• Development Team（开发团队） —— 自组织团队（self-organizing team），也是跨职能团队（cross-functional team）—— 自己决定「怎么做」，也自己承诺每个迭代能完成多少。

2.2 一个高频误解

这里有个高频误解：Scrum Master 不是项目经理。项目经理对结果负责、分配任务；Scrum Master 对流程负责，不分配任务，团队自己决定怎么做。这个区别在「谁能决定工期」这件事上体现得最明显。

本例里还有个更实际的难点：谁是 Product Owner？王姐（片区经理）是业务方，但她并不清楚每天的操作细节；小林懂细节，但她不能决定预算。

常见的做法是王姐当 PO，但她的排序意见主要来自小林。这个安排要写在明面上，否则会出现「王姐说要先做看板、小林说先做派单」这类冲突，而团队无从判断该听谁。

3 三种产出物

3.1 三者的分工

3.2 为什么 backlog 是「活的」

关键点是清单的属性：product backlog 是一个持续变化的列表，而不是一份签过字的需求文档。需求分析的工作并没有在项目开始时做完，而是随着每次迭代往前滚动。

本例里这条会真实发生：第一轮做完「看排期 + 派单」之后，小林一定会提出新条目 —— 比如「我要能一次改派三个单」。这一条在做第一轮时根本想不到，但它是真的需求。如果按瀑布式，它只能进「第二期」；按迭代式，它进 backlog 排队即可。

3.3 两个辅助指标

团队通常还会用两个辅助指标观察节奏：velocity（速率）用来估算一个迭代大概能完成多少，burndown chart（燃尽图）用来展示剩余工作量随时间的变化。这两个指标是团队自我观察用的，不该拿去考核个人 —— 一旦变成考核指标，数字就会失真。

顺带解释一个后面的伏笔：backlog 里的条目通常就写成用户故事（user story） 的形式 —— 这是笔记 07 的主题。

4 一个 sprint 里的四次活动

4.1 四次活动分别在回答什么

4.2 Review 与 Retrospective 的分工

Review 和 Retrospective 最容易混。一句话区分：Review 看产品，Retrospective 看流程。Review 上讨论「这个功能对不对」，Retrospective 上讨论「我们为什么老是延期」。

本例里这个区别有个具体的体现：Review 上小林说「候选人按距离排序不对，我要按技能匹配度排」—— 这是产品问题；Retrospective 上团队说「这轮需求变了三次，因为王姐直接找了开发」—— 这是流程问题。

两个问题如果混在一起讨论，结果是产品改了但流程照旧，下轮还会重演。

这四个活动都有时间盒（timebox）：到点就结束，不因为讨论没完而延长。这不是形式主义 —— 时间盒保证的是迭代节奏本身不被侵蚀。

5 「完成」的定义

5.1 为什么需要一份完成定义

一个迭代结束时，什么算「完成」？如果不事先说清楚，就会出现「90% 完成」这种状态（而 90% 完成约等于没完成）。

所以团队需要一份 Definition of Done（完成定义），例如：

• 代码通过评审并合并；
• 有自动化测试，且全部通过；
• 部署到测试环境并验证过；
• 文档更新到最新。

这份清单是团队自己定的，但它必须是能被检验的。「基本上做完」不属于完成定义。

本例里这份清单还要多加两条，因为派单系统的特殊之处：

• 小林能在测试环境里用真实数据派出 10 个单，不报错；
• 供应商接口超时的情况下，流程能降级继续（对应 15 篇那条降级策略）。

第一条的价值在于：它把「用户能不能用」写进了完成定义。否则会出现「功能都做完了，但小林说没法用」这种情况。

6 几个常见误解

• 「敏捷就是不用写文档」 —— 敏捷宣言说的是「可工作的软件重于详尽的文档」，不是「不要文档」。该留的设计说明还要留，只是不写没人看的那种。本例里那张数据字典必须留，因为开发天天要看；
• 「每日站会是汇报进度」 —— 站会是团队对齐用的，不是给上级汇报的。一旦变成汇报，问题就会被藏起来；
• 「迭代就是加班冲刺」 —— 迭代的节奏应该是可持续的。靠加班填坑，下一轮坑会更深；
• 「敏捷等于没有计划」 —— 迭代背后有清晰的优先级和验收标准，只是不假装能预知三个月后的一切。

7 这套东西和需求分析的关系

7.1 渐进明细

前面几篇讲的需求分析，在敏捷语境里并没有消失，而是改变了发生的时间：

• 高优先级的条目要在进入迭代前细化到可开发的程度（用例、字段、边界条件）；
• 低优先级的条目可以先只写一句话；
• 每一次 Review 都是一次需求验证的机会。

这种「先粗后细、按需细化」的做法通常叫渐进明细（progressive elaboration）。它对应的风险是：如果永远不细化，backlog 就变成一张愿望清单。

本例里第一轮的细化程度可以做个对照：

注意最后一行：虽然本轮不做，但「数据能不能拿到」这件事要提前确认 —— 因为 06 篇发现「只有 8 个月数据、做不到 Predictive」。如果等做的时候才发现，时间就白排了。

这就是「渐进明细」里最容易被忽略的一条：细化的不只是需求，还包括「前提是否成立」。

本节自测

1. 迭代式开发和瀑布式开发，风险暴露的时间点有什么不同？这个差别为什么重要？
2. Scrum Master 和项目经理的职责差别是什么？
3. Product Backlog 和 Sprint Backlog 分别由谁维护？内容有什么不同？
4. Sprint Review 和 Sprint Retrospective 分别在讨论什么？本例中各举一个例子。
5. 为什么需要一份「完成定义」？没有它会出现什么典型问题？
6. 本例里「谁是 Product Owner」为什么需要一个明确的安排？不明确会出什么问题？
7. 「渐进明细」里最容易忽略的是哪一条？本例怎么体现？

参考答案

1. 瀑布式在项目末期才暴露风险，迭代式每个迭代都暴露。重要是因为越晚改代价越高 —— 本例按瀑布式王姐第三个月末才知道总览页不好用；按迭代式第一周就能让她用上粗版并当场改（§1.1）。
2. 项目经理对结果负责并分配任务；Scrum Master 对流程负责、不分配任务，团队自己决定怎么做。区别在「谁能决定工期」上最明显（§2.2）。
3. Product Backlog 由 PO 维护（全部条目、按价值排序、永远不完整）；Sprint Backlog 由开发团队维护（本次承诺的条目 + 拆解出的任务）（§3.1）。
4. Review 看产品，Retrospective 看流程。本例：Review 上小林说「候选人要按技能匹配度排」是产品问题；Retrospective 上团队说「这轮需求变了三次，因为王姐直接找了开发」是流程问题（§4.2）。
5. 因为不写清就会出现「90% 完成」这种状态（约等于没完成）。这份清单必须能被检验，「基本上做完」不算（§5.1）。
6. 因为王姐是业务方但不清楚操作细节，小林懂细节但不能决定预算。需要明确「王姐当 PO，排序意见主要来自小林」，否则会出现「王姐说先做看板、小林说先做派单」而团队无从判断（§2.2）。
7. 最容易忽略的是 「前提是否成立」也要一起细化。本例：配件预测本轮不做，但 06 篇已经确认「只有 8 个月数据、做不到 Predictive」—— 这个结论要提前有，否则等做时才发现，时间就白排了（§7.1）。

术语表