你们团队有限制在制品（WIP limits）吗？效果如何？
看看下面的问题：
在制品是指什么？用户故事（User Story）还是任务项（Task）？
限制在制品是为了什么？
限制在制品要跟什么实践结合？
如果没法很清晰地回答上面的问题，你的团队可能没有真正有效地使用这个实践。建议你往下看。
NO.1 差不多做完了
“这个用户故事我差不多做完了”，如果一个程序员告诉你这句话，相信我，他可能离真正做完还差很远。
他很可能就是把“差不多做完了的这个 Story”交给 QA 去测，然后开始做下一个 Story。QA 测出来 bug，就改呗，“哪有软件没有 bug 的？”
于是他在 bug 和 新的 Story 之间来回切换，很忙很积极的样子。
放大到整个团队，在 Sprint 结束时，所有 User Story 都“差不多完成了”，但没有几个真正做完。更有甚者，来个 QA Sprint，来测试上一个 Sprint 开发的 Story。
对于这种程序员，有一个更彻底的建议：
领一个 Story 后，一行代码都不要写，直接说“做完了，去测吧！”
QA 一定说：“没看到有什么功能啊。”
“哦，那你提 bug 吧，我有空改一下。”
NO.2 WIP Limits 的根本动机
“差不多做完了”是非常伤害团队生产率的：
它增加了团员之间的来回传递时间（hand over）
它增加了多任务引起的上下文切换的时间（context switching）
这就是为什么子曰：优秀的团队只是把事情做完（Great teams just get things Done），甚至 GTD 成为一个方法论；也是为什么敏捷团队需要有一份 “完成的定义”（Definition of Done），
限制在制品的根本动机是鼓励“把事情完成”的文化：如果有一件事情“差不多”做完了，那就是没做完，应该先把它做完，而不是开始另一件事情。
Start finishing things, stop starting things.
NO.3 反馈
“把事情做完”的另一个好处是可以得到有效反馈。把一个有一堆显而易见的 bug 的 story 交给 QA/PO 验收，得到的是一堆的无效反馈。
频繁地寻求有效反馈可谓 VUCA 时代的生存之道，也是很多敏捷实践背后的基本原理。
下面说说跟本文相关的三种制品和它们的反馈：
| 在制品 | 反馈来源 | 反馈手段 | 反馈周期 |
|---|---|---|---|
| 功能（Feature） | 用户 | 发布/Demo | 周/月 |
| 用户故事（Story） | 内部客户（QA/PO） | 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 （结对编程）。
NO.4 Batch size 是关键
小结一下，WIP Limits 是为了鼓励“完成”，“完成”的意义是让事情走完该走的流程，以便于收到所需要的有效的反馈。
反馈有两个原则：
尽可能频繁
尽可能早
为了遵守这两个原则，关键实践是把批次（Batch size）变小。小，才能快速和频繁。
NO.5 总结
当我们说在制品（WIP） 时，至少有三种在制品：Feature，User Story，Task (Code 为主)。
它们都应该得到限制，其中 Task 的限制比较容易被忽略：
单个 Scrum 团队的 Kanban 上应该限制的是开发中 User Story 的数量。推荐开发人数 * 1.5 作为开始。
在大规模的团队中（比如 10 个 Scrum 团队共同开发一个大的产品），有个产品级别的 Kanban，限制开发中的 Feature 的数量。
个人看板上应该限制在做 Task 的数量为 1。 我见过太多程序员的坏习惯，一个方法写一半，又去写别的方法，可以长达几小时让代码通不过编译。这就是没有限制 Task 的 WIP。
其次，它应该跟至少两个实践结合起来：
- 控制 Batch size 到足够小。
- 寻求各制品的及时反馈，极致地：结对做任何事情（Pair everything）。
文档信息
- 本文作者：蔡建斌
- 本文链接：https://johncai.github.io/2020/04/21/wip-limits/
- 版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）