敏捷的本质在于短和小

预计阅读时间：3分钟

“敏捷开发有什么特别的？早几十年前就有迭代开发的概念了。”

“用户故事和需求文档里的功能点有什么区别？瀑布模式也是一个个功能点做的呀。”

“持续交付有什么特别？就算是瀑布模式，也经常分阶段（Phase）发布。”

“产品小分队（Pod）和传统的团队（Team）有什么区别？所有的IT团队都是对齐业务的边界，对接一个大的产品或服务范围的啦。”

以上问题都忽略了一个重要问题，就是规模（Size）。

不错，迭代开发真的不是新的概念，其历史几乎跟瀑布模式一样久远，但是敏捷开发的不同之处就在于它是短迭代开发。短迭代意味着反馈周期短，从而实现快速试错，持续演进，确保产品完全满足业务需要。如果可以，迭代的周期应该越短越好，可以一周一个迭代就不要两周（当然需要根据实际平衡相应带来的开销）。每日站会、持续集成、测试驱动编程等实践也是为了把反馈周期缩到最短，实现快速反馈。

用户故事最重要的特点之一就是小。它应该是可以实现一定业务价值的最小可交付工件，是一个短迭代内能够交付的东西，否则就需要进一步拆分。用户故事是否足够小，也是实现真正敏捷和持续交付的重要条件之一。

在瀑布模式下确实也经常分阶段发布，但每个阶段的间隔可能是一个月甚至几个月，每次发布的范围依然很大，风险很高，其惊吓程度和一次性发布（Big Bang）不相伯仲。持续交付的不同之处就在于把发布周期缩短到每月、每周甚至每日，由于每次发布的范围非常小，风险小，回滚也容易，这也是最有效的风险控制手段。

产品小分队也必须是可以独立交付特性的最小队伍，也就是所谓的“两个烧饼团队”（2-pizza team，两块披萨能喂饱这个团队）。队伍越大，沟通成本就越高，步伐也越慢（同样到达一个地方，5个人一同前进一定比20个人要快得多，也灵活得多）。在满足能够独立交付一个特性，对外依赖小，具备自治能力的前提下，维持最小的队伍规模，保持内部沟通和交付的高效率。

因此，要说敏捷和传统模式有什么最本质的区别，答案就是短和小（不要想歪）。所谓量变带来质变，不要小看这个“规模效应”。如果你的交付效率出了问题，请审视：

你的迭代周期和反馈周期是否太长了？

你的用户故事是否太大了，能不能进一步拆分？

你的发布周期是否太长了，每次发布范围是否太大了？

你的队伍是否太大了，有没有进一步拆分的余地？

关于作者

早期敏捷践行者

起步于极限编程

熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发

关注公众号