一、简介

　　敏捷软件开发（Agile software development），又称敏捷开发，是一种从上世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法，它是应对快速变化的需求而产生的。它的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，共同点是更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档沟通更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队等等，它能够很好地适应需求变化的代码编写和团队组织，更注重软件开发中人的作用。 "敏捷"（Agile）一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。敏捷开发是软件工程经过原始模型，大棒模型，瀑布模型，迭代模型后产生的。

　　敏捷组织有自己宣言：

　　人和（人与人的）交互：优先于过程和工具。

　　可以工作的软件：优先于求全责备的文档。

　　客户协作：优先于合同谈判。

　　随时应对变化：优先于循规蹈矩。

　　二、敏捷开发的优点

　　我认为敏捷开发有以下优点：

　　1，采用敏捷，可以快速提高软件发布周期。许多软件公司以前采用瀑布模型：从业务建模，需求调研，需求分析，设计，编码，测试到最终送交给客户使用，需要经历很长的周期。而采用敏捷开发，可将一个产品或项目分解为多个sprint，开发小组每周或每两周提交一部分产品，而这部分产品都要保证可运行，可使用的。经过多模块集成及集成测试，客户每一到两个月就可拿到产品，这样可保证客户尽早发现产品问题所在，及时反馈回来。此外客户对产品的重要部分可优先使用起来。敏捷开发提倡客户参与到项目中去，尽管实施起来比较困难，但若能够真正做到这一点，这样就可更加体现这个优点。另外若再采用火车模型[1］进行产品发布，则更可缩短产品发布的周期。

　　2，采用敏捷开发，测试能够尽早参与进项目中来。缺陷预防优于缺陷发现，缺陷发现是亡羊补牢，虽说为时未晚，但是软件测试能够尽早参与，可把众多的缺陷消灭在萌芽状态，这一直是软件测试人员梦寐以求的事情，就像中医所说的：上工治未病，让疾病隐患消灭在萌芽状态，不让它发出来。釆用敏捷开发，测试人员可以在第一时间内参与产品在这个sprint的需求，由于每一个sprint的功能被细化得比较简单， 测试与开发可比较清楚地了解这个sprint的需求，并与开发人员达成一致的观点。在开发人员写功能代码的时候，测试人员就可以设计测试案例。当开发代码写完，测试案例设计也完成以后就可执行测试案例了，与此同时可以进行探索性测试(ET)[2]，及早发现问题并反馈给开发人员，以便及时解决，及时总结。对于一些问题可避免在下一个sprint中再犯;而对于系统架构体系中的问题，可以在第一时间内进行优化，重构或重建，缩短了开发时间，从而达到了敏捷开发的目的。

　　3，釆用敏捷开发，可以减少许多不必要的文档。记得我当时作QA工作的时候，领导要求我和我的同事撰写《公司产品开发测试流程规范》，这要涉及到流程，干系人与文档这三个部分。 在文档部分就要从业务建模， 需求调研，需求分析，概要设计，详细设计，单元测试，集成测试，系统测试，验收测试到软件部署，共定义了五十几个模版。但在实施过程很困难，大部分文档开发，测试人员写得很草率甚至不写，问及原因，无非是时间紧或者是没必要，他们会说：＂设计和开发都是我个人一个人，一切都在我脑子里＂。敏捷宣言中说：＂可以工作的软件：优先于求全责备的文档＂。敏捷小组中的员工可以根据产品或项目的具体情况来决定应该写哪些文档，不应该写哪些文档，灵活决定。但并不是说敏捷开发不需要写文档，否则员工休假甚至离职，接手的员工如何工作？

　　4，采用敏捷开发，结对编程与结对测试是有利于提高产品质量并且有利于培养新员工很好方式。结对编程与结对测试，一个人工作，另一个随时检查，及时沟通，遇到问题立即解决。

　　5，采用敏捷开发， 日立会（Standup meeting）是一种很好的沟通形式。日立会既每天早上开发小组内的所有同事在一起，每人各自介绍昨天做了哪些工作，今天计划做哪些工作以及工作中所遇到的各种问题。日立会是敏捷开发中的一项重要内容，它是一项很好的沟通活动。通过日立会，开发小组内的同事可以及时了解小组的工作情况。对于遇到的问题，若小组内其他同事可以帮助解决，这个问题可交给这位同事处理； 若小组内其他成员都无法解决的问题， 可由小组负责人上报给上级领导， 让上级领导来决定如何处理。这样可以有效提高工作效率。

　　任何一种方法有优点也会有不足之处,下面来谈一谈敏捷开发的缺点,这是本人的一些体会，不一定正确。