最近在重新看《软件工程》，看到敏捷这一章，有一些疑惑和思考，记录一下
书里面讲敏捷的好处： 越到后期，变更的成本越低
我比较困惑，假设两种情况，敏捷和传统模式开发同一个产品的情况下，来从逻辑上看成本：
情况1： 敏捷和传统模式采用同样的技术设计，不同点是： 敏捷迭代逐步交付功能；传统模式把所有功能都做好再交付功能
总成本： 因为是一摸一样的功能，一模一样的技术设计，一模一样的团队，那么开发的总工作量应该是一样的，不过因为敏捷是迭代交付的，所以测试、发布过程会重复多次，从总体成本上面来看，敏捷模式比传统模式要多
变更成本： 因为一摸一样的功能，一摸一样的技术设计，一摸一样的团队，同样的变更，变更的开发工作量应该也是一摸一样的，所以，在这种情况下，敏捷的变更成本会比传统模式低，反而总成本是高的
情况2： 敏捷和传统模式采用不一样的技术设计，不同点在于： 因为传统模式尽量在最早期统计了所有的需求，所以技术团队可以针对尽量多的信息提前做一些统一性的设计，提高扩展性和复用性；敏捷模式由于希望快速交付可用功能，所以在早期版本的时候没有过多的考虑未来的扩展性，复用性，而是尽量用简单的方案快速实现功能，在后期接到新需求的时候，会采用两种方法：1. 在现有系统上打补丁；2. 重构现有系统来适用于新的变化。按照我的经验，打补丁只会增加技术债务，时间久了重构不可避免
总成本： 如果是实现了相同的功能，因为在迭代的过程中，敏捷为了快速交付，不得不打补丁直到重构，而传统模式可以提前计划好所有功能，省去了重构的成本，所以从总成本上来说，敏捷开发增加了总成本
变更成本： 因为传统模式会提前应对于可能的变化，所以只要产品没变（核心逻辑没有变），传统模式的提前设计会让后续的变更成本更小，而敏捷快速交付的方式，会因为打补丁重构的过程导致后续变更成本更高
这就是我的困惑，然后我思考了一下，为什么敏捷还这么流行呢？到底敏捷的优势在哪里呢？我的结论是： 因为敏捷可以更快的发现你做的是错误的产品，也就是： 敏捷在应对“产品核心逻辑变更”或者说是“老产品废弃”的情况下，比传统的模式有更大的优势，因为它更早的让用户看到了可用的产品，可以更早的知道产品是不是“做对”了，而且省成本的前提是： 采用快速实现+打补丁+技术重构的方式
所以，敏捷适用的场景是： 不知道自己产品核心逻辑是不是正确的情况。如果明确的知道产品核心逻辑就是对的，那就应该在最开始把产品核心模型设计好，考虑到后来的扩展性和复用，而不要用敏捷的模型
敏捷的正确实践也应该是：快速交付+打补丁+重构的循环，要不然也没办法避免产品核心逻辑错误带来的更大的变更成本
网友评论