前几天在武可老师的TDD群里，又有人发了那张经典的图：如果你要做一辆汽车，不要先造一个轮子、再造一个轴、再造个车壳子……因为这样造法，直到最后把所有东西拼起来之前，你都不会有一台可用的车。你应该先造一个滑板，俩轮子一块板儿，拿着这玩意你就可以开始用了（比如说，用来运箱子什么的），然后再把滑板变成有扶手的滑板车，再变成自行车，再变成摩托车，最后变成个真资格的汽车。在这个过程中，每一步你都有个“车”可以用。

这图以前的标题叫“什么是敏捷”，现在改成了“怎么建个最小可用产品（MVP）”，道理都是一样的。

群里就有同学说，觉得这图有点误导，不太精准，下半张图给人感觉是不断推倒重来。这位同学说：“其实一开始是跑不出最小可用系统的，只是一些最小可用功能。”

我完全理解他的感觉。比如说你要建一个驾校报名审核系统，你采用了敏捷方法，迭代式交付，

第一个迭代你做好了审核员登录和用户登录。

第二个迭代你做好了报名表录入和查看。

第三个迭代你做好了报名表审核。

你没有按照传统的瀑布式方法那样先做所有的需求分析、再做所有的设计建模、再做所有的编码实现、最后做所有的测试。你每个迭代、甚至迭代内的每一天都能把最新开发出来的功能发布上线，每个小功能都在两三天的周期里走完分析、设计、编码、测试的全过程。每个迭代发布的这些功能本身都是可用的，当所有功能完成以后整个系统也就可用了。所以你会在三个迭代结束时正式发布这个系统。毕竟，功能不完整的系统怎么能给用户使用呢？

这个开发过程已经很敏捷了，不是吗？

他恰恰想错了。很多人看这个图看不明白，恰恰在于他们以为这是个隐喻、不是真的从滑板车到自行车到摩托车再到汽车。然而敏捷软件开发根本的分水岭恰恰就在这张图上。因为软件是软的。自行车真的可以装个引擎变摩托车，而且装上那一刻之前还完全不影响自行车继续使用。甚至我们可以说得再绝对一点：如果你的软件开发过程不是照着这个下半张图的方式在进行，你根本就没有实践敏捷。

仍然用这个驾校报名审核的系统来举例好了。我会怎么来实现这个系统呢？我会先实现这么几个用户故事：

· 作为学员，我要在报名系统中提交个人身份信息（姓名和身份证号），这样我可以启动报名流程；

· 作为审核员，我要查看所有待审核的学员列表，这样我可以选择下一个审核对象；

· 作为审核员，我要查看一个待审核学员的个人身份信息（姓名和身份证号），这样我可以审核该学员的报名材料；

· 作为审核员，我要审核通过一个待审核学员的报名申请，这样该学员可以入学。

没有审核员登录，你可以先把这个软件部署在内网使用，甚至只让有限的几个人知道部署的IP。没有学员登录，你可以先让审核员每审一份纸质报名申请的时候代替学员在线上提交申请。报名申请中只包含两个字段（姓名、身份证号），但是已经足以让审核员把纸质的报名申请与数字化的报名申请对应起来。这几个故事足够简单，一个程序员两三天的时间应该足够做出来，加上别的杂七杂八，一星期上线应该稳稳当当。

“但是这么一个东西，审核还得拿着纸质材料看，上线了有什么用呢？”

它的用处就在于，你可以让一个审核员把整个流程跑通。一开始，审核员要对着纸质材料看，但是审批的结果已经保存下来了。下一步，你可以让学员输入更完整的信息。再下一步，你可以逐步减少这个审核员要对照看的纸质材料。再下一步，你可以加上学员登录功能，把输入信息这一步开放给学员用。再下一步，你可以加上审核员登录，允许其他审核员一起来审核……

在这整个过程中，整个业务系统（不止是IT系统）是随时可用的，对业务系统的修改是随时可控、可撤销的，对业务系统的改进意见随时可以被提出、被包含到后面的功能中。

这才是迭代式交付：软件系统以迭代的方式被逐步部署到业务系统中，逐步改变业务系统（更数字化、更便捷、体验更佳……），且保障对业务系统的每一步变更都是安全可靠的。

是以迭代的方式部署软件系统并改变业务系统，还是以一股脑一大包的方式部署软件系统并改变业务系统，这才是敏捷与非敏捷、伪敏捷的分水岭。你可以自己关起门来搞迭代开发搞得很开心，但是最后给用户使用的软件还是一股脑一大包上线，那就还是瀑布。

要走过这道分水岭，用户故事的划分一定是颗粒度更细的，不会是“查看学员报名信息”这样的粒度，而是“查看学员报名材料中的个人身份信息（姓名和身份证号）”这样的粒度。每个迭代选择的交付范围一定是端到端的，不会是“报名表录入和查看”这样的迭代计划，而是“不需要登录，只提交姓名和身份证号，能走完审核流程”这样的迭代计划。

然后呢，不出意外的话，程序员就要开始反对这样的颗粒度和迭代计划了。“你要做啥一次给我说清楚，不要老是改需求。”他们会这样说。他们会要求产品经理/业务分析师给他们详细的需求文档和界面原型，把所有的功能先考虑好，如若不然他们就要开始写段子嘲笑那些动不动改需求的产品经理了。

为什么呢？因为他们恐惧，因为他们写的代码就像易碎的瓷器，一旦写好了就再也不敢动，动一动就说不好会碎成什么样。所以他们本能地排斥“一段代码写好了回头还要改”这样的事。你跟他说先做个自行车，回头再加上引擎变成摩托车，他不会认为这是逐步逼近结果的过程，他会认为这是“改需求”——先把“改需求”这个帽子给产品经理扣上，那么开发速度越来越慢、质量糟糕这些问题自然也就不是程序员的问题了。

说到底，这是敏捷与否真正的分水岭：软件是逐渐生长的，还是一次写好就不敢再改？而迈过这道分水岭，最关键的能力实际上就是单元测试、持续集成和重构的能力。我一直说敏捷的一切问题都会回归到“会不会TDD”的问题上来，不是瞎说的。