软件工程发展到今天，一共产生了两个比较经典的流程：瀑布和敏捷。

瀑布是一个现实生活里面有的东西，这个类比就变得很好理解。

敏捷究竟是什么？如果我们忘记那些 story point，站会，sprint，scrum，想一想，「敏捷」这两个字代表什么？

我觉得无非是代表当变化发生的时候，有足够的灵活性。

如果我们以做一双鞋举例。

瀑布可以对应到标准化工厂，每个阶段的专业人士（或者机器）可以用最高的效率进行生产，达到极高的吞吐量。

但是量产的鞋没法满足所有人的需要。比如有的人喜欢脚面宽一点，有的人喜欢鞋带或者鞋帮有一些变化。这个时候如果做鞋的说，都可以满足，那么它就很敏捷。

这通常是一个制鞋的工匠可以做到的：他有大量的工具，足够的技巧，只要多给点时间，可以满足你的各种需求。

工厂的优点很明显是量产的吞吐量，缺点则是生产不同的东西需要花费大量时间来重建机器。 工匠的缺点也很明显，就是生产效率低下，产量低，同时标准化程度低，不能水平扩展。

所以敏捷和效率其实就是跷跷板的两头，因此瀑布和敏捷作为两种侧重点不同的方法论，并没有好坏，也无所谓新旧，两种方法在项目管理的三角形里，一个优化了时间，一个优化了成本。如何选择，其实和软件开发里面大多数时候一样：你得判断做什么样的 tradeoff。在最近的十年，只不过因为软件的发布成本不断降低，复杂度却不断提高，且需求常常不确定，因此程序员倾向于支持更有柔性的敏捷。

理解了敏捷流程的成本有什么意义？

首先要时刻想到，你是牺牲了效率的。要把对效率的影响减小，就要控制项目参与人数，而不是加人。要为这些小团队提供更好的工具和服务，而不是把流程弄得复杂。

其次，要明白即便是推敏捷流程，根据不同项目细节上也可以不同：如果你的团队创建的产品或工具有内外部的用户，使用 Scrum，让他们看到交付的节奏，不要一直干扰开发。相反，如果是提供基础设施或者基础服务，使用 Kanban 等流程来提高 lead time，因为这种情况下用户最在乎的就是效率。

再次，因为敏捷牺牲了效率，光从团队组织架构上做动作，比如把团队规模减小，服务化等等，很难完全把这部分损耗找回来。怎么办？要不断地为更好的工具投资，来对抗复杂度，提高效率。好的工具通常是对问题进行了抽象之后，让关键的信息流动的同时，让关键的步骤被自动化，这其实解决的就是复杂度。

最后，当通过工具提高效率进入瓶颈期时，你可以再尝试从人这方面入手：改进流程，将整个系统或者任务分成更小的部分，让员工成为专家中的专家。同时，良好的流程还有助于并行化工作以提高整体的吞吐量。