敏捷开发的思考

        软件模型中经常被提到是瀑布模型、增量模型、迭代开发、敏捷开发，现在主流的就是敏捷开发。敏捷开发的开发过程的核心还是迭代开发，尽量短频快的交付，降低成本，及时得到各方反馈，减少不适用的风险。敏捷开发是项目开发的管理方法，在面对不熟悉领域和需求各种不确定性中，那么敏捷开发几乎是唯一可行的开发方式。敏捷开发的四个价值观和十二条原则是核心思想，是指导实践的关键依据。

        在敏捷开发的实践中，最大问题就是缺乏规划，需求管理被淡化，随便乱改需求。虽然敏捷是拥抱变化，但不是随意的变化都拥抱，只要是变化就有成本。要做一个新项目或新产品，最少要知道它的目标和使用场景，相关项目背景，也许起初的项目信息和认识都有限，但也要根据现有资源做出尽可能多的大方向规划，虽然后面会有很多调整，但有方向做比没有方向要好。在开发的架构设计方面也类似，根据使用场景和业务功能演进的大致规划，也想好类似的架构设计上的演进。尽量地去分析确定尽可能多的事情，避免没必要的变化，但也不能把目前不能确定的事情，在迭代周期中提前去做，这样就会过度设计，导致后面实际和预期不一致时，又产生大量返工，反而得不偿失。例如，我们要规划盖一个 100 层的摩天大楼，敏捷开发就是，先搭一层的基地盖一层楼交付给客户，根据客户的反馈，这一层楼再做哪些调整，要不要继续盖第二层，如果要盖第二层，开发团队先要做的是调整基地结构，使其能支持后续几层楼修建，然后再继续加盖。如果后续修建中，要求所有楼层加一个房间，那么就得先调整整个结构，使整个楼能够支撑新的需求。如果新需求发生剧烈变化，与项目定位差距太大，例如，把已经修建 50 层高楼，改成飞机场，此时什么敏捷也无法拥抱这么巨大的变化。敏捷开发对团队人员的要求更高，需要从架构设计及代码编写上，经常保持高内聚低耦合，从而达到各个功能模块、组件之间的灵活性，以快速响应变化，一旦不合适时，能够及时发现并重构调整。在实际当中，这些架构设计上的调整，已有功能的重构优化，客户和市场都不怎么愿意，毕竟不能直接产生业务上的价值，程序员也不愿意，因为眼下能运行就好，多一事不如少一事，但对项目开发又是至关重要的，否则，简单地堆砌代码，导致越来越臃肿，难以维护，最后会浑然倒塌。

        敏捷并不总是最好的办法，在一个项目或产品的需求基本是确定的，那么瀑布模式的更好。例如，要开发的系统是代替原先的老系统，所有功能都是一致的，这样新系统必须完全覆盖老系统的所有功能后，老系统才会下线，新系统才能上线。在这种情况下，需求细节都是确定的，此时采用瀑布模式反而效率更高，一开始做好架构设计，从而避免没有必要的返工、重构和频繁的沟通。 

        敏捷开发过程中，需要更加重视需求分析，项目的架构设计，及时重构保证代码的可维护性，保持项目代码高质量才能做到相应敏捷。虽然敏捷拥抱变化，但要谨慎地审视变化，尽量避免无意义的变化。

国内的一般公司的敏捷开发的落地问题

        国内很多公司软件开发团队的素养都很一般，招聘的程序员一般是大专和普通本科并且只有几年工作经验的，多数人员的能力也只是达到刚好能实现功能而已，代码质量非常一般。很多人普遍都很被动，不会积极主动改进，成长的速度也很慢。这些和敏捷所需的团队能力相差很大，不可能实现标准的敏捷，只能用一些变通的办法。每个团队总有一两个能力好的人员，由他们主导需求精细讨论、主要设计（模块划分、API 接口设计、数据库设计）等，其余人员参与讨论，这样能够保证需求和架构设计都不会有多大问题，只是每个人员负责的模块内部编码质量无法保证而已，但总体结构还是不会有多大问题。随着人们不断参与，多多少少会有些成长的，也就能承担更重要的工作。

        也许有人说，通过检视来弥补上面代码质量问题。 先不说代码检视工作量很大，就说按什么标准检视，严格标准的话，基本绝大多数不合格，粗略的话对提升代码质量不大。就算按严格标准来，那么发现到处是问题，从结构到命名很多不符合规范，让对方改吧，相当于重写了一遍，即使重写也很难达到标准，有这个时间还不如检视者自己重写，并且让被检视者认可这些代码的质量问题难度也非常大，毕竟这些代码意见的背后牵扯很多开发知识和经验，很难短时间掌握的。总之，如果检视的结果超过 80%不合格，这种检视就没有意义。如果用代码检测工具来规范代码，虽然有一定程度的改善，但多数人都是应付检查，只是想办法让检测通过，而不是从根本上解决问题，曾经我待过某个著名的大厂的一个项目组就是这样干的。如果用结对编程让能力高指导能力低的一起开发，虽然能保证代码质量，但团队中能力高的很少，不足满足这种结对编程。所以一般的软件公司人员素养，没法保证模块内代码质量，只能让能力高的个别人保证核心功能的代码质量。总之，一般的小公司，检视成本很高，收益很低，多数情况下是不可行的。

        还有国内很多软件项目，生命周期很短，或者开发资源很有限，这种情况下敏捷开发中的单元测试和自动化测试就可以省掉。如果没有自动化测试和单元测试来支撑来保障，没人愿意重构优化已有的代码，担心出现问题。但测试用例的工作量经常都比业务开发工作量还大，所以很多人不愿意写。再加上，敏捷开发是欢迎需求变化的，这样也就会导致原先写的测试用例的代码也经常变动，维护成本也就很高。如果这个项目生命周期很长，开发时间充足，进行单元测试的确能够降低总体成本，提高开发维护效率。但国内很多软件外包公司，拿项目价格压得很低，所以能够安排的资源也很少，自然不会允许去花时间做单元测试和自动化测试用例的。还有很多项目不靠谱，做出来后上线没几个月就放弃了，这类多数没啥希望的项目也不值得投入过多资源，所以也不会有什么单元测试和自动化测试用例了。万一有不看好的项目上线后变得有希望了，那时再重构或者完全重写，补充单元测试和自动化测试用例，这样反而是更高效的。