敏捷计划:团队的节奏
这一章讲三件事: 敏捷到底是什么(比你想的短——四行价值观); 一份工作怎么被拆成可预估、可跟踪的小块; 以及站会、评审、回顾这三个会各自在回答什么问题。 读完你会看懂你所在团队的每一个仪式背后想解决什么。
1. 这一章讲什么
第 01-10 章讲的都是「一个人的手艺」;从本章开始是「一群人的节奏」。原书的出发点:软件开发应该有计划和跟踪——队友需要知道你在做什么才能配合,团队需要看到进度才能纠偏;没有深思熟虑的过程,项目拖延、外部需求抢走关注、运维问题分散精力1。
本章在全书链条里的位置:它是原书「软技能三部曲」(12-14 章)的第一部——先讲团队的节奏(本章),再讲你和管理者的通道(第 12 章),最后落到你自己的职业路线(第 12 章后半)。
2. 顶层全景
┌────────────── 一个冲刺(通常两周) ──────────────┐
│ │
积压梳理 → 冲刺计划(选故事、定容量) → 锁定 → 开发+每日站会
↑ │
│ 评审(演示+对照目标) → 回顾(修流程) │
└────────────────── 反馈回到下一轮计划 ←────────┘
图说:这是一个闭环;每一步回答一个问题——
做什么(计划)/在吗(站会)/做完了吗(评审)/下次怎么更好(回顾)。
主走查:一个重试参数从用户故事到上线的全程。
3. 核心原理
3.1 敏捷的内核只有四行
2001 年,几位老式开发流程(极限编程、Scrum 等)的领导人合写了《敏捷软件开发宣言》,核心是四行价值观2:
个人和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
原书提醒两点。其一,宣言是拿左边的价值观对比右边——右边「有其价值」,只是左边更重;它反对的对照物是瀑布流模型(项目开始时就做详尽计划的开发方式)3。其二是一个讽刺:敏捷流行之后,黑带忍者式的认证、权威证书和流程顾问笼罩了一些组织,人们迷恋「做敏捷」的正确方法,恰恰损害了第一条原则4。这句话是你读本章其余内容时的解毒剂——包括 Scrum、看板在内的一切都是工具:
- Scrum:把开发切成冲刺(固定周期,最常见两周),每个冲刺开头有计划会,期间每天有简短站会,结尾有回顾5;
- 看板:不用固定周期,把工作流切成阶段(待着手/实施中/测试中/部署…),靠限制每阶段的工作条目数(限制 WIP,work in progress)逼团队先完成再开新6;
- 现实中几乎没有团队实施「柏拉图式的理想」——两者的混合体 Scrumban 真实存在7。原书的落点:把心思放在目标上,而不是机制上;实验、测量、只留有效的8。
3.2 主走查:一个重试参数的完整旅程
Scrum 的一切机制,都是为了让「一件工作」变得可讨论、可预估、可跟踪。原书挑了一个最小的工作 当例子——给 postProfile 这个接口添加重试参数——我们跟着它走完全程9。
第 1 站:用户故事。 工作进入「积压」(候选工作列表)时写成用户故事,格式是「作为一名<用户>,我<想><这样>」10。常见误用是把普通任务硬套格式(「作为一名开发者,我需要把着色器插件升级到 8.7 版本」)——既说不出用户价值,也说不清是谁想要11。postProfile 这个故事的用户价值很清楚:作为 API 的调用方,我希望网络超时时配置文件最终能保存成功。故事还要带两样东西:预估工数(对所需努力的猜测)和验收标准(什么叫做完了)——验收标准要能写成明确的测试,原书给的是另一组例子:管理员权限页列出「账单报表」选项、被授权者能看到所有账单、「编辑」按钮被隐藏……12。含糊或需要设计的故事会被「尖峰」——一段限时调查,产出设计文档或利弊评估(第 09 章的设计尖峰就是它的亲戚)13。
第 2 站:任务分解。 「加重试参数」听起来是一句话, 拆开看是一串14:
① 与产品经理确认:愿意等多久、重试上限设多少(规范)
② 编码实现重试 + 指数退避(第 03 章的机制在这里用上)
③ 单元测试
④ 集成测试(模拟真实网络超时,验证退避真的工作)
⑤ 部署到测试环境,再上生产
⑥ 生产环境小流量放开,逐步加大(第 07 章的展开策略)
分解的意义:多个人可以并行、进度可跟踪、每步的完成可验证。
第 3 站:故事点与冲刺容量。 团队的产能用故事点(约定的度量单位)算:例如 4 名工程师、每人 10 个故事点,本轮冲刺容量 40 点;所有故事点数之和不得超过容量15。基于时间的团队按「1 个故事点 = 1 个工作日」折算,但要扣掉会议、中断、评审——所以一个 工作日按 4 小时算16。更常见的是用复杂度计:原书举的 T 恤尺码法,点数取 1、2、3、5、8——这正是斐波那契数列,点与点之间的间隙逼你表态「这是 5 还是 8」,而不是含糊的「3.5」17。预估不准怎么救?相对大小:拿已完成的任务当参照系,新任务和它们比——比那个 5 点的更费劲就是 8 点;要不要玩计划扑克(全团同时亮牌的预估游戏)随意,看历史完成量的收益是稳定的18。
第 4 站:计划与锁定。 冲刺计划会上,团队对照高优先级的故事和容量,决定本轮做什么;冲刺开始后即锁定——期间冒出的新工作不拉进来,进积压等下一轮(这样开发人员才专注,进度才可预测;总被计划外工作打断,回顾会上要查原因)19。
第 5 站:站会。 每天早上 15 分钟:上次站会后做了什么、接下来做什么、有没有拖累冲刺目标的问题20。原书的比喻很准:站会是看一眼汽车仪表盘——确认有油、「检查引擎」灯没亮;它不是排障的地方,深讨论「留到停车场」(站会结束后 相关者再聊)21。
第 6 站:评审与回顾。 冲刺结束后先评审:每人演示成果(非正式,别准备 PPT),再对照冲刺目标评估完成度——标准做法是每个冲刺周不超过一小时评审时间22。然后回顾:只讨论流程和工具——哪些做法要保留、哪些造成了痛苦、怎么解决;会议分三段:分享、确定优先级、解决问题23。两者的分工一句话:评审看的是这个冲刺做出来的工作,回顾看的是团队干活的方式——别混24。
3.3 超出两周的尺度:路线图
冲刺管两周,公司还活在季度和年度里。路线图是长期规划工具,通常按季度组织;工程经理、产品经理、工程师一起在季度开始前规划25。原书引了艾森豪威尔的话定调:「在准备战斗时,我总是发现计划是无用的,但计划是 不可缺少的」——没人见过一个季度路线图 100% 准确,这不是重点;路线图的功能是逼所有人长期思考,「更远的地方应该更模糊,而更近的地方应该更准确」26。和锁定的冲刺相反,路线图是活的:需求变了就改,但必须尽早告知受影响的团队27。年度规划则常常是「讨价还价的交易场」,核心议题是 head count(人头数,新雇工程师的去向);你感兴趣的项目没进规划,直接去问你的管理者28。
4. 作者的判断与证据
- 「敏捷过度仪式化是对宣言的背叛」:作者判断,论据是「黑带忍者」的行业观察;与原书「这是本有态度的书」的立场一致。
- 「故事点用复杂度还是时间」:原书明确说没有找到特别有效的论据,建议用对团队最有效的方法——这是本章少见的「作者拒答」处,照实转述。
- postProfile 分解:原书自带的示例,本章主走查沿用;六步分解是作者的教学构造,不是某公司的真实项目记录。
- 「站会 15 分钟」「评审每周冲刺 1 小时」:原书给出的常见值,注明为「通常」「标准的做法」,不是规范。
5. 边界与局限
- 敏捷适合「快速交付优质软件」的场景——原书第一章就限定了适用域;车载与医疗设备软件、长周期硬件项目常常需要别的节奏,书里不讨论。
- 产品经理角色被默认存在:没有 PM 的团队(原书也承认很多)谁来写故事、定优先级,书里只在句末带过。
- 看板讲得薄:只一段;限 WIP 的经典度量(周期时间、累积流图)没进书。
- 书出版于 2021 年;后疫情混合办公下的异步站会只提了一句「有些团队采取了异步的形式」29。
6. 可带走的
- 敏捷的验收标准是那四行价值观;任何流程和它冲突,流程错;
- 用户故事三要素:用户视角、用户价值、验收标准——「作为一名开发者我需要…」不是用户故事;
- 工作拆到「可并行、可跟踪、可验证」为止;postProfile 式的一句话任务,拆开是六步;
- 故事点用相对大小估:拿已完成的任务当尺子;1、2、3、5、8 的间隙是特性不是缺陷;
- 冲刺容量 = 人数 × 人均点数;点数总和超容量就是过度承诺;
- 冲刺锁定后新需求进积压;计划外工作在回顾会上要交代原因;
- 站会是仪表盘不是维修站;深讨论进「停车场」;
- 评审展示工作,回顾修改流程——两个会别开成一个;
- 路线图「更远更糊、更近更准」,改动要尽早告知受影响的人;
- 团队如果还没有这一切,先从「每天同步 + 每两周回顾」起步,别先买证书。
7. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 计划与跟踪 | 第12章 敏捷计划 | text/21-ch12.txt:3(搜「相应的跟踪」) |
| 宣言四行 | 第12章 敏捷计划 | text/21-ch12.txt:26(搜「个人和互动高于流程和工具」) |
| 瀑布对照 | 第12章 敏捷计划 | text/21-ch12.txt:35(搜「瀑布流模型」) |
| 黑带忍者讽刺 | 第12章 敏捷计划 | text/21-ch12.txt:38(搜「权威认证和流程顾问」) |
| Scrum 节奏 | 第12章 敏捷计划 | text/21-ch12.txt:46(搜「几个冲刺阶段」) · text/21-ch12.txt:46(搜「最常见的是两个」) |
| 回顾闭环 | 第12章 敏捷计划 | text/21-ch12.txt:51(搜「一次回顾总结」) · text/21-ch12.txt:54(搜「闭环」) |
| 看板与 WIP | 第12章 敏捷计划 | text/21-ch12.txt:55(搜「看板不像」) · text/21-ch12.txt:59(搜「正在进行中的工作」) |
| Scrumban | 第12章 敏捷计划 | text/21-ch12.txt:70(搜「Scrumban」) |
| 目标非机制 | 第12章 敏捷计划 | text/21-ch12.txt:72(搜「而不是机制上」) |
| 主走查:用户故事 | 第12章 敏捷计划 | text/21-ch12.txt:90(搜「作为一名<用户>」) · text/21-ch12.txt:91(搜「授予查看权限」) |
| 误用 | 第12章 敏捷计划 | text/21-ch12.txt:95(搜「着色器插件」) |
| 验收标准 | 第12章 敏捷计划 | text/21-ch12.txt:102(搜「预估工数和验收标准」) · text/21-ch12.txt:106(搜「账单报表」) |
| 尖峰 | 第12章 敏捷计划 | text/21-ch12.txt:113(搜「含糊不清或需要设计」) |
| 主走查:分解 | 第12章 敏捷计划 | text/21-ch12.txt:125(搜「postProfile」) · text/21-ch12.txt:140(搜「梯度升级」) |
| 故事点容量 | 第12章 敏捷计划 | text/21-ch12.txt:150(搜「10 个故事点」) |
| 4 小时工作日 | 第12章 敏捷计划 | text/21-ch12.txt:155(搜「4 个小时」) |
| 斐波那契 | 第12章 敏捷计划 | text/21-ch12.txt:158(搜「斐波那契数列」) |
| 相对大小与扑克 | 第12章 敏捷计划 | text/21-ch12.txt:172(搜「相对大小」) · text/21-ch12.txt:176(搜「计划扑克」) |
| 积压梳理 | 第12章 敏捷计划 | text/21-ch12.txt:183(搜「候选的用户故事列表」) |
| 锁定冲刺 | 第12章 敏捷计划 | text/21-ch12.txt:204(搜「进入了已锁定」) · text/21-ch12.txt:205(搜「不应该被拉进来」) |
| 站会 | 第12章 敏捷计划 | text/21-ch12.txt:223(搜「15 分钟的会议」) · text/21-ch12.txt:231(搜「汽车仪表盘」) · text/21-ch12.txt:242(搜「停车场讨论」) |
| Scrum of Scrums | 第12章 敏捷计划 | text/21-ch12.txt:249(搜「Scrum of Scrums」) |
| 评审时长 | 第12章 敏捷计划 | text/21-ch12.txt:271(搜「不应超过一小时」) · text/21-ch12.txt:275(搜「过度的准备」) |
| 回顾三阶段 | 第12章 敏捷计划 | text/21-ch12.txt:288(搜「12 条原则」) · text/21-ch12.txt:294(搜「确定优先级和解」) |
| 评审 vs 回顾 | 第12章 敏捷计划 | text/21-ch12.txt:306(搜「重点是流程和工具」) |
| 艾森豪威尔 | 第12章 敏捷计划 | text/21-ch12.txt:330(搜「划是无用的」) |
| 路线图精度 | 第12章 敏捷计划 | text/21-ch12.txt:336(搜「更模糊」) |
| 年度人头数 | 第12章 敏捷计划 | text/21-ch12.txt:346(搜「head count」) |
| 异步站会 | 第12章 敏捷计划 | text/21-ch12.txt:229(搜「异步」) |