4.2　小批量持续流动的流程

我们前面讲过，软件交付过程要追求快，从改一行代码到把它发布上线，都要尽量快。因为从确定需求到设计开发再到发布上线的整个流程，就是要尽量快。那么如何做到呢？一个重要的策略就是不要等待。

4.2.1　大批量带来等待等问题

观察瀑布模式中的等待：由于大批需求被一起规划设计，所以尽管每个需求可能只需要不多的设计时间，但是需要等待所有的需求都被设计好后才能开始实现。大批需求带来很大的开发工作量，在实现某一个具体小功能时，可能只需要不多的时间，但需要等待所有的功能都实现后，才能进行集成。大量的软件改动带来繁重的集成工作，如果到项目后期才集成和测试，那么就要等问题一个个冒出来并被解决掉，说不定还需要多轮测试。总之，对于软件的一点改动，花在它本身的功能设计、代码实现、质量保证上的时间可能并不多，但是由于总是需要凑齐足够的需求才能往下推进流程，所以等待的时间就会很漫长。最后的效果就是从确定需求到发布上线的整个流程，很慢。具体到本书关注的软件交付过程，也是很慢的。

当总是需要凑齐需求时，还会带来一些连锁反应，让流程变得更慢。其中最明显的问题是，修复一个Bug所花费的时间变长了。比如你改了几行代码，当时就得到了反馈，提示写得有问题，那么你自然就只需要在那几行代码中排查。那几行代码又是刚写的，记忆还新鲜，很快就能找出原因并改正。但是，如果过了很久才得到反馈，那么你就不知道问题是具体哪个地方的改动引起的，从而导致排查困难。而且那段程序的结构和逻辑，你可能也记不清了，又要重新熟悉，重新进入状态。

4.2.2　短周期、小颗粒度、减少在制品

这么看来，等待真不是一件好事儿，要尽量避免。如何避免呢？别凑一大批！也就是说，要在各个方面追求小批量：小批量的设计功能、交代开发任务，小批量的集成，小批量的测试，小批量的发布。这样就有可能让整个流程持续地流动起来，而不是走走停停。

瀑布模式显然违背了这一策略，导致了漫长的交付周期。而如果将四周甚至两周作为一个迭代周期的话，相比之下就好得多。然而这并不是终点，它可以更好：一方面，迭代可以一直延伸到上线，而不是止步于内部演示版本，上线才是真正的Done；另一方面，一次迭代包含了多个需求，它们之间还是会相互等待、相互影响的。所以，更理想的情况是每个需求都可以在精益看板墙上不受干扰自主地往前走：开发、测试直到发布。也就是说，想改就改、想测就测、想发就发。

这里需求的颗粒度也有讲究，不要太大。所以在精益需求分析与管理实践中，要做需求拆分：将大需求拆分成小需求，可以分别独立开发和发布上线。这也符合小批量的原则。

在精益方法中还提到了控制在制品数量，因为在制品数量大意味着排队等待时间长，也意味着一个人可能要并行处理多件事情，需要频繁切换。控制在制品数量，也符合持续流动这个原则。

4.2.3　小批量持续流动的交付过程

以上是从敏捷和精益的视角来看小批量持续流动这个策略的。下面我们来看看持续集成、持续交付是如何践行小批量持续流动这个策略的。

持续集成意味着代码改动要及早和经常提交与合并，这样有利于减少合并冲突和错误，并且在彼此工作有依赖时，能及时获取到别人的改动，及早开工。

持续集成还意味着及早和经常构建与测试。一旦收到提交的代码，就自动进行构建、静态代码分析、单元测试等工作，以便尽早发现问题，而不是非要凑齐再开始。显然，这也符合小批量持续流动的原则。

持续交付更进一步，把及早和经常做的事情扩展到了部署到测试环境并测试，甚至扩展到了及早和经常发布上线。

可见，敏捷、精益、持续集成、持续交付，它们都反映了这个重要的策略：小批量持续流动。

以上讲的是大的方面。根据小批量持续流动这个原则，在集成发布阶段还有不少细节值得注意。比如发布窗口应当尽量去掉，做到无须等待、随时发布。