软件模型中经常被提到是瀑布模型、增量模型、迭代开发、敏捷开发,现在主流的就是敏捷开发。敏捷开发的开发过程的核心还是迭代开发,尽量短频快的交付,降低成本,及时得到各方反馈,减少不适用的风险。敏捷开发是项目开发的管理方法,在面对不熟悉领域和需求各种不确定性中,那么敏捷开发几乎是唯一可行的开发方式。敏捷开发的四个价值观和十二条原则是核心思想,是指导实践的关键依据。
在敏捷开发的实践中,最大问题就是缺乏规划,需求管理被淡化,随便乱改需求。虽然敏捷是拥抱变化,但不是随意的变化都拥抱,只要是变化就有成本。要做一个新项目或新产品,最少要知道它的目标和使用场景,相关项目背景,也许起初的项目信息和认识都有限,但也要根据现有资源做出尽可能多的大方向规划,虽然后面会有很多调整,但有方向做比没有方向要好。在开发的架构设计方面也类似,根据使用场景和业务功能演进的大致规划,也想好类似的架构设计上的演进。尽量地去分析确定尽可能多的事情,避免没必要的变化,但也不能把目前不能确定的事情,在迭代周期中提前去做,这样就会过度设计,导致后面实际和预期不一致时,又产生大量返工,反而得不偿失。例如,我们要规划盖一个 100 层的摩天大楼,敏捷开发就是,先搭一层的基地盖一层楼交付给客户,根据客户的反馈,这一层楼再做哪些调整,要不要继续盖第二层,如果要盖第二层,开发团队先要做的是调整基地结构,使其能支持后续几层楼修建,然后再继续加盖。如果后续修建中,要求所有楼层加一个房间,那么就得先调整整个结构,使整个楼能够支撑新的需求。如果新需求发生剧烈变化,与项目定位差距太大,例如,把已经修建 50 层高楼,改成飞机场,此时什么敏捷也无法拥抱这么巨大的变化。敏捷开发对团队人员的要求更高,需要从架构设计及代码编写上,经常保持高内聚低耦合,从而达到各个功能模块、组件之间的灵活性,以快速响应变化,一旦不合适时,能够及时发现并重构调整。在实际当中,这些架构设计上的调整,已有功能的重构优化,客户和市场都不怎么愿意,毕竟不能直接产生业务上的价值,程序员也不愿意,因为眼下能运行就好,多一事不如少一事,但对项目开发又是至关重要的,否则,简单地堆砌代码,导致越来越臃肿,难以维护,最后会浑然倒塌。
敏捷并不总是最好的办法,在一个项目或产品的需求基本是确定的,那么瀑布模式的更好。例如,要开发的系统是代替原先的老系统,所有功能都是一致的,这样新系统必须完全覆盖老系统的所有功能后,老系统才会下线,新系统才能上线。在这种情况下,需求细节都是确定的,此时采用瀑布模式反而效率更高,一开始做好架构设计,从而避免没有必要的返工、重构和频繁的沟通。
敏捷开发过程中,需要更加重视需求分析,项目的架构设计,及时重构保证代码的可维护性,保持项目代码高质量才能做到相应敏捷。虽然敏捷拥抱变化,但要谨慎地审视变化,尽量避免无意义的变化。
国内的一般公司的敏捷开发的落地问题
国内很多公司软件开发团队的素养都很一般,招聘的程序员一般是大专和普通本科并且只有几年工作经验的,多数人员的能力也只是达到刚好能实现功能而已,代码质量非常一般。很多人普遍都很被动,不会积极主动改进,成长的速度也很慢。这些和敏捷所需的团队能力相差很大,不可能实现标准的敏捷,只能用一些变通的办法。每个团队总有一两个能力好的人员,由他们主导需求精细讨论、主要设计(模块划分、API 接口设计、数据库设计)等,其余人员参与讨论,这样能够保证需求和架构设计都不会有多大问题,只是每个人员负责的模块内部编码质量无法保证而已,但总体结构还是不会有多大问题。随着人们不断参与,多多少少会有些成长的,也就能承担更重要的工作。
也许有人说,通过检视来弥补上面代码质量问题。 先不说代码检视工作量很大,就说按什么标准检视,严格标准的话,基本绝大多数不合格,粗略的话对提升代码质量不大。就算按严格标准来,那么发现到处是问题,从结构到命名很多不符合规范,让对方改吧,相当于重写了一遍,即使重写也很难达到标准,有这个时间还不如检视者自己重写,并且让被检视者认可这些代码的质量问题难度也非常大,毕竟这些代码意见的背后牵扯很多开发知识和经验,很难短时间掌握的。总之,如果检视的结果超过 80%不合格,这种检视就没有意义。如果用代码检测工具来规范代码,虽然有一定程度的改善,但多数人都是应付检查,只是想办法让检测通过,而不是从根本上解决问题,曾经我待过某个著名的大厂的一个项目组就是这样干的。如果用结对编程让能力高指导能力低的一起开发,虽然能保证代码质量,但团队中能力高的很少,不足满足这种结对编程。所以一般的软件公司人员素养,没法保证模块内代码质量,只能让能力高的个别人保证核心功能的代码质量。总之,一般的小公司,检视成本很高,收益很低,多数情况下是不可行的。
还有国内很多软件项目,生命周期很短,或者开发资源很有限,这种情况下敏捷开发中的单元测试和自动化测试就可以省掉。如果没有自动化测试和单元测试来支撑来保障,没人愿意重构优化已有的代码,担心出现问题。但测试用例的工作量经常都比业务开发工作量还大,所以很多人不愿意写。再加上,敏捷开发是欢迎需求变化的,这样也就会导致原先写的测试用例的代码也经常变动,维护成本也就很高。如果这个项目生命周期很长,开发时间充足,进行单元测试的确能够降低总体成本,提高开发维护效率。但国内很多软件外包公司,拿项目价格压得很低,所以能够安排的资源也很少,自然不会允许去花时间做单元测试和自动化测试用例的。还有很多项目不靠谱,做出来后上线没几个月就放弃了,这类多数没啥希望的项目也不值得投入过多资源,所以也不会有什么单元测试和自动化测试用例了。万一有不看好的项目上线后变得有希望了,那时再重构或者完全重写,补充单元测试和自动化测试用例,这样反而是更高效的。