你们团队有限制在制品（WIP limits）吗？效果如何？
看看下面的问题：
- 在制品是指什么？用户故事（User Story）还是任务项（Task）？
- 限制在制品是为了什么？
- 限制在制品要跟什么实践结合？
如果没法很清晰地回答上面的问题，你的团队可能没有真正有效地使用这个实践。建议你往下看。
差不多做完了
“这个用户故事我差不多做完了”，如果一个程序员告诉你这句话，相信我，他可能离真正做完还差很远。
他很可能就是把“差不多做完了的这个 Story”交给 QA 去测，然后开始做下一个 Story。QA 测出来 bug，就改呗，“哪有软件没有 bug 的？”
于是他在 bug 和 新的 Story 之间来回切换，很忙很积极的样子。
放大到整个团队，在 Sprint 结束时，所有 User Story 都“差不多完成了”，但没有几个真正做完。更有甚者，来个 QA Sprint，来测试上一个 Sprint 开发的 Story。
对于这种程序员，有一个更彻底的建议：
领一个 Story 后，一行代码都不要写，直接说“做完了，去测吧！”
QA 一定说：“没看到有什么功能啊。”
“哦，那你提 bug 吧，我有空改一下。”
WIP limits 的根本动机
“差不多做完了”是非常伤害团队生产率的：
- 它增加了团员之间的来回传递时间（hand over）
- 它增加了多任务引起的上下文切换的时间（context switching）
这就是为什么子曰：优秀的团队只是把事情做完（Great teams just get things Done），甚至 GTD 成为一个方法论；也是为什么敏捷团队需要有一份 “完成的定义”（Definition of Done），
限制在制品的根本动机是鼓励“把事情完成”的文化：如果有一件事情“差不多”做完了，那就是没做完，应该先把它做完，而不是开始另一件事情。
Start finishing things, stop starting things.
反馈
“把事情做完”的另一个好处是可以得到有效反馈。把一个有一堆显而易见的 bug 的 story 交给 QA/PO 验收，得到的是一堆的无效反馈。
频繁地寻求有效反馈可谓 VUCA 时代的生存之道，也是很多敏捷实践背后的基本原理。
下面说说跟本文相关的三种制品和它们的反馈：
| 在制品 | 反馈来源 | 反馈手段 | 反馈周期 |
|---|---|---|---|
| 功能（Feature） | 用户 | 发布/Demo | 周/月 |
| 用户故事（Story） | 内部客户（PO/QA） | Demo/验收 | 天 |
| 任务项（Task） | 同伴（Peer） | Peer Review | 天/小时 |
1. 功能（Feature）
功能是指用户会买单的一些用户故事的集合，最重要的反馈来自于用户。
不要：等整个 Feature 发布之后再寻求用户反馈。
要：在每个 Sprint 结束时的 Review meeting 就寻求反馈。
2. 用户故事（Story）
Scrum 团队都会把大的 Feature 分解成若干 Story，Story 虽说是 Valuable (INVEST)的，但往往不是最终用户会买单的，为什么我们还要拆呢？
理由之一就是用它来寻求内部客户（团队，主要是PO/QA）的反馈。
不要：等到 Sprint Review 再给 PO 看。
要：（至少）在 Story 做完后就及时 Demo 给 PO。
3. 任务项（Task）
这边的任务基本上是技术上的任务，通俗来说就是写代码。
一个典型的任务是一个 TDD 循环：一个单元测试 + 让这个单元测试通过的代码。（拆成 “前端”/“后端” task 的实践，是几乎毫无意义的，另文阐述。）
Task 是用户和 PO 都不感兴趣的东西，这边要寻求的反馈是来自同伴（Peer）的 Peer Review。
不要：等一个 Story 做完了再来 Review。
要：（至少）每天 Review，甚至每秒钟 Review （结对编程）。
Batch size 是关键
小结一下，WIP Limits 是为了鼓励“完成”，“完成”的意义是让事情走完该走的流程，以便于收到所需要的有效的反馈。
并且反馈有两个原则：
- 越频繁越好
- 越早越好
为了遵守这两个原则，关键实践是批次（Batch size）要小。小，才能快速和频繁。
总结
当我们说在制品（WIP） 时，至少有三种在制品：Feature，User Story，Task (Code)。
它们都应该得到限制：
- 单个 Scrum 团队的 Kanban 上应该限制的是开发中 User Story 的数量。
- 在大规模的团队中（比如 10 个 Scrum 团队共同开发一个大的产品），有个产品级别的 Kanban，限制开发中的 Feature 的数量。
- 个人看板上应该限制在做 Task 的数量为1。
这一点是比较容易被忽略的。我见过太多程序员的坏习惯，一个方法写一半，又去写别的方法，可以长达几小时让代码通不过编译。这就是没有限制 Task 的 WIP。
其次，它应该跟至少两个实践结合起来：
- 控制 Batch size 到足够小。
- 寻求各制品的及时反馈，极致地：结对做任何事情（Pair everything）。
下篇预告：Task 应该怎么拆分？需要每天更新 Task 的剩余小时数吗？谈谈拆分 Task 的迷思。
