对敏捷开发的一些思考
作者: 顾翔
一、简介
敏捷软件开发（Agile software
development），又称敏捷开发，是一种从上世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法，它是应对快速变化的需求而产生的。它的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，共同点是更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档沟通更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队等等，它能够很好地适应需求变化的代码编写和团队组织，更注重软件开发中人的作用。
"敏捷"（Agile）一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。敏捷开发是软件工程经过原始模型，大棒模型，瀑布模型，迭代模型后产生的。
敏捷组织有自己宣言：
人和（人与人的）交互：优先于过程和工具。
可以工作的软件：优先于求全责备的文档。
客户协作：优先于合同谈判。
随时应对变化：优先于循规蹈矩。
二、敏捷开发的优点
我认为敏捷开发有以下优点：
1，采用敏捷，可以快速提高软件发布周期。许多软件公司以前采用瀑布模型：从业务建模，需求调研，需求分析，设计，编码，测试到最终送交给客户使用，需要经历很长的周期。而采用敏捷开发，可将一个产品或项目分解为多个sprint，开发小组每周或每两周提交一部分产品，而这部分产品都要保证可运行，可使用的。经过多模块集成及集成测试，客户每一到两个月就可拿到产品，这样可保证客户尽早发现产品问题所在，及时反馈回来。此外客户对产品的重要部分可优先使用起来。敏捷开发提倡客户参与到项目中去，尽管实施起来比较困难，但若能够真正做到这一点，这样就可更加体现这个优点。另外若再采用火车模型[1］进行产品发布，则更可缩短产品发布的周期。
2，采用敏捷开发，测试能够尽早参与进项目中来。缺陷预防优于缺陷发现，缺陷发现是亡羊补牢，虽说为时未晚，但是软件测试能够尽早参与，可把众多的缺陷消灭在萌芽状态，这一直是软件测试人员梦寐以求的事情，就像中医所说的：上工治未病，让疾病隐患消灭在萌芽状态，不让它发出来。釆用敏捷开发，测试人员可以在第一时间内参与产品在这个sprint的需求，由于每一个sprint的功能被细化得比较简单，
测试与开发可比较清楚地了解这个sprint的需求，并与开发人员达成一致的观点。在开发人员写功能代码的时候，测试人员就可以设计测试案例。当开发代码写完，测试案例设计也完成以后就可执行测试案例了，与此同时可以进行探索性测试(ET)[2]，及早发现问题并反馈给开发人员，以便及时解决，及时总结。对于一些问题可避免在下一个sprint中再犯;而对于系统架构体系中的问题，可以在第一时间内进行优化，重构或重建，缩短了开发时间，从而达到了敏捷开发的目的。
3，釆用敏捷开发，可以减少许多不必要的文档。记得我当时作QA工作的时候，领导要求我和我的同事撰写《公司产品开发测试流程规范》，这要涉及到流程，干系人与文档这三个部分。
在文档部分就要从业务建模，
需求调研，需求分析，概要设计，详细设计，单元测试，集成测试，系统测试，验收测试到软件部署，共定义了五十几个模版。但在实施过程很困难，大部分文档开发，测试人员写得很草率甚至不写，问及原因，无非是时间紧或者是没必要，他们会说：＂设计和开发都是我个人一个人，一切都在我脑子里＂。敏捷宣言中说：＂可以工作的软件：优先于求全责备的文档＂。敏捷小组中的员工可以根据产品或项目的具体情况来决定应该写哪些文档，不应该写哪些文档，灵活决定。但并不是说敏捷开发不需要写文档，否则员工休假甚至离职，接手的员工如何工作？
4，采用敏捷开发，结对编程与结对测试是有利于提高产品质量并且有利于培养新员工很好方式。结对编程与结对测试，一个人工作，另一个随时检查，及时沟通，遇到问题立即解决。
5，采用敏捷开发， 日立会（Standup
meeting）是一种很好的沟通形式。日立会既每天早上开发小组内的所有同事在一起，每人各自介绍昨天做了哪些工作，今天计划做哪些工作以及工作中所遇到的各种问题。日立会是敏捷开发中的一项重要内容，它是一项很好的沟通活动。通过日立会，开发小组内的同事可以及时了解小组的工作情况。对于遇到的问题，若小组内其他同事可以帮助解决，这个问题可交给这位同事处理；
若小组内其他成员都无法解决的问题， 可由小组负责人上报给上级领导，
让上级领导来决定如何处理。这样可以有效提高工作效率。
任何一种方法有优点也会有不足之处,下面来谈一谈敏捷开发的缺点,这是本人的一些体会，不一定正确。
三、敏捷开发的缺点
1，采用敏捷开发，开发团队的人员素质要求比较高。敏捷开发的首要任务是快速，目前提出的"全栈软件工程师"[3]，它要求软件开发人员在开发的各方面：从需求，设计，编码，测试一直到部署都要求是行家里手，可以减少因彼此沟通带来的时耗，这才能保证他在一个Sprint中能独立完成产品中某个特定的任务。显然这样的软件开发人员的素质一定要求很高的，而在软件开发行业中，人员流动率高，新手多的情况下，要做到这一点是比较困难的。
2，采用敏捷开发，开发人员与测试人员混为一体，彼此分工不明晰。敏捷开发要求软件人员会测试，测试人员会开发，这在实施起来是比较困难的。这是因为开发和测试人员关注的重点是不同的：开发关注与技术实现比较多，一般都采用正向思维；而测试关注业务比较多，多采用逆向思维。所以一个产品要保证有高的品质，就必须要有专门的测试人员，应该把测试和开发有比较清晰的分工。正如古话所说："术业有专攻，问道有先后"。
3，采用敏捷开发，是"短平快"的开发方式，由于产品发布周期短，所以产品的维护，升级等操作的频率也增加了。这必然增大开发人员，测试人员以及运行维护人员的工作压力，在高压的环境下工作容易出错，影响产品的质量。
4，采用敏捷开发，不利于文档的建立和修改。敏捷开发有一句口号："拥抱变化"。然而客户需求的变更是经常变化的，这正如当今社会流行所谓"唯一不变的是变化"。为了缩短版本发布周期，特别是在版本发布的之前，当客户的需求发生了变更时，敏捷开发团队仅是修改代码而没有时间修改所对应的文档，这就造成产品和文档的开发不一致性。给产品后期优化，调整或二次开发带来极大的麻烦，在人员频繁流动中更是灾难性的。
四、总结
软件工程无非好坏，先进与落后。敏捷开发是个新方法，存在优点，也存在缺点，我们不要一味赶时髦，凡事都一窝蜂。我们要根据自己的企业现状和产品特性，选择符合自己的软件工程方法论，只要这个方法可以给企业提高质量，带来效益，就是一个好的方法。敏捷的特点是版本发布速度快，然而中国又有一句古话："慢工出细活"。活干得快，往往会影响质量，所以我认为对于一些版本发布频率要求不高，或者涉及到严格质量要求的产品，比如航空，航天，金融等领域的产品，不一定采用敏捷开发的方法，可采用更适合于自身产品特性的软件开发方法。我有一位同行，在美国工作，从事金融软件的开发业务，可以想象，这种产品的质量要求是很高的容不得半点差错，所以他们仍旧采用传统的瀑布模型开发方法，他每天从设计师处拿到设计文档，该文档写得很详细，然后按照设计文档进行编码，可以在家里通过互联网工作（公司省去了为员工租用Office的开销），公司效益很好，已经维持了近二十年。
[1] 火车模型：软件发布像火车一样，有固定发车时间，新功能是否可发布取决于它是否可赶上这班火车。
[2] 探索式测试（Exploratory
Testing）：是一种自由的软件测试风格，强调测试人员展开测试学习、设计测试、测试执行和测试结果评估等活动，以持续优化测试工作。
[3］全栈工程师：软件从建模，需求，设计，开发，测试到部署，维护都由一个工程师承担。
【投稿】【关闭窗口】【打印】