敏捷开发中原则与过程的分析的办法探讨

中图分类号TP31 文献标识码A 文章编号 1674-6708（2013）83-0197-02
　　从上世纪50年代软件出现开始至今，软件开发方法先后经历了无规则的编码和测试、结构化方法、面向对象的方法、能力成熟度模型CMM和轻量级开发方法等各个阶段。纵观软件开发的发展史，软件开发方法的演变是有规律可循的，遵循着一条从“计划和预测”到“反馈和适应”的历程。造成这一演变过程的原因如下：
　　1）软件使用者的主体从大型尖端领域逐渐向广泛的企业应用领域转变；
　　2）人们对软件系统需求的认识提高；
　　3）市场经济的发展，以及市场需求的频繁变化；
　　4）面向对象技术的应用和普及。
　　而今，企业面对的是快速变化的市场，在这样的市场环境下，收集用户完整的、稳定不变的系统需求是不可能的。面对无法预知和不断变化的需求，传统的软件开发流程明显已无法适应，而敏捷过程将程序代码和系统需求紧密的联系在一起，将系统需求视作流动和变化的需求的思想，则正符合现今软件开发的现状。
　　1 敏捷开发的兴起
　　敏捷方法诞生于2001年，由ith和发起，由一批业界专家参与成立了敏捷联盟，并概括出了一系列让软件开发团队具有快速工作、相应变化能力的价值观和原则。
　　在敏捷联盟的官方网站上，可看到敏捷宣言的完整内容：
　　1）个人与沟通胜过过程与工具；
　　2）可工作的软件胜过面面俱到的文档；
　　3）客户协作胜过合同谈判；
　　4）相应变化胜过遵循计划。
　　具体来说，传统的顺序开发模型（瀑布模型、V模型、W模型）的一个重要的特点就是所有的活动都是有顺序的。顺序开发模型成功使用的一个前提是软件系统具备完善和明确的需求。如果在项目开始阶段无法进行完善的需求分析和设计，则顺序开发模型就很难被成功的使用。为了解决顺序模型的不足，出现了增量迭代模型。从本质上说，敏捷开发就是一种迭代的增量的开发模型。这种模型的优点如下：能很好的适应需求的变化；早期的迭代可以降低风险；集成是持续的而不是在项目后期进行的“大动作”；在每次迭代中发现和更正缺陷并能不断反馈并改进开发过程[1]。
　　如果要用一句话来描述敏捷开发，那么敏捷开发应该是：以人为本、轻载、基于时间、just Enough、并行并基于构件的迭代和增量的软件开发过程。
　　2 敏捷开发的原则
　　敏捷联盟成立后，又陆续形成了敏捷的十二项原则（本文不在详细展开，详细描述见敏捷联盟官方网站），其主旨思想大体如下：敏捷开发中需求是逐渐展开的，在项目初期不提倡过渡的需求分析，对需求变化的响应是动态的；敏捷项目应该分成从几周到几个月间隔的迭代周期，每一个迭代周期尽量产出潜在可交付的软件产品，用户的反馈作为下次迭代的基础；可工作的软件是衡量项目进展的主要依据；敏捷开发整个过程是持续的，带有反馈的和自我完善的轻量级的过程。
　　基于敏捷指导思想，形成了不少敏捷软件开发方法(例如XP、scrum等)，它们大都强调适应性而非预测性、强调以人为中心，而不以流程为中心，以及对变化的适应和对人性的关注。以XP（extreme programming）方法为例，它消除了大多数重量型过程的不必要产物，建立了一个渐进型开发过程。该方法将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。并且它作为一种面向客户的开发模型，开发过程中对需求改变的适应能力较高，即使在开发的后期，也可较高程度地适应用户的改变。XP开发模型与传统模型最大的不同是其核心思想是交流（Communication）、简单（Simplicity）、反馈（Feedback）和进取（Aggressiveness）[2]。这种开发模型的主要优点如下：
　　1）采用简单计划策略，不需要长期计划和复杂模型，开发周期短；
　　2）在全过程采用迭代增量开发、反馈修正和反复测试的方法，软件质量有保证；
　　3）能够适应用户经常变化的需求，提供用户满意的高质量软件。
　　纵观所有敏捷开发方法，其基本都具备轻载、基于时间、Just Enough、并行并基于构件的迭代和增量的特点，而且具有类似的敏捷项目交付模型。
　　3 敏捷项目交付模型
　　敏捷项目交付模型是一种敏捷软件项目管理的生命周期模型，它是基于敏捷开发迭代和增量特点的过程模型[3]。该模型把敏捷软件项目的生命周期大体可分成项目规划、项目启动、迭代开发与发布三个阶段。各个阶段分别介绍如下：
　　1）项目规划阶段
　　敏捷开发中的项目规划阶段类似于传统开发过程中的项目可行性分析和早期的需求收集阶段，该阶段的主要工作如下：
　　（1）就要开发系统的战略目标、业务愿景和初始项目需求等与关键涉众达成共识；
　　（2）根据收集到的资料，设计与决策系统开发的关键技术架构问题；
　　（3）评估项目的工作量与成本，辅助客户决策项目的可行性；
　　（4）进行项目的初始发布计划制定。
　　2）项目启动阶段
　　该阶段是一过度阶段，处于项目规划后正式开发前，主要工作是为项目开启准备各种所需资源，包括开发场地布置、软硬件环境的准备和项目团队的组建等。另外，通常为了使此后的迭代开发阶段能够顺利进行，还有为第一次迭代进行详细的需求分析工作。
　　3）迭代开发与发布阶段
　　该阶段是敏捷项目交付模型的核心部分，基本上所有的开发工作都在该阶段展开与实现。在迭代开发与发布阶段，项目组会根据目标系统的正式发布版本将该阶段分解成多个重复的过程，并且每次过程基本上都是一次目标系统的增量在开发环境中实现，并从开发环境到生产环境的迁移。每次迭代开发与发布又可细分为迭代开发、用户验收测试（UAT）和发布三个小阶段。各阶段的介绍如下：
　　（1）迭代开发是一个有固定时间周期的、在开发和测试环境上完成系统增量的过程，增量流程大体由需求分析活动、设计实现活动、集成测试活动、客户测试活动组成。每次迭代都会产生潜在可交付的产品；
　　（2）多次迭代开发对应一次发布，多次迭代后每次发布前，会根据项目需要进行用户验收测试。目标是让客户代表从系统最终运营的角度测试系统行为，另外，该阶段也可作为项目团队完成发布目标的缓冲区；
　　（3） 发布过程在敏捷开发中有里程碑的作用，其业务意义大于技术意义。使用敏捷软件交付模型，第一次发布会在较早的时间发生，这对于提升客户投资收益，根据市场反馈调整项目走向都有帮助。
　　4 敏捷开发中的测试
　　对于敏捷的理解，一般认为最为关键的是需要注意两个方面，即“高速迭代”和“持续不断的客户反馈”[4]。而要达到这样的要求，传统的注重流程的规范，文档的齐备，走完整的bug处理流程的测试过程，明显已不符合敏捷的初衷。
　　那么敏捷开发中测试有何特点？，简要来说，如下所述：
　　首先，就测试的阶段来说，敏捷开发中的测试贯穿于整个软件开发生命周期中（传统软件开发模型中，测试只是作为编码后的一个独立阶段出现）。其次，敏捷开发是迭代和增量的过程，这就意味着测试人员在每个代码增量完成时，都要测试它，测试工作也是迭代的展开，并且时间更紧，压力更大。开发和测试是并行进行的，程序员从来不超前于测试人员（在传统软件开发模型中，编码和测试过程是串行的，先编码后测试）。再次，敏捷开发中，测试人员需要紧密的与客户合作来定义每一个需求的接收标准；而且测试过程还可以向项目组随时反馈开发中遇到的问题。而不像传统测试中，测试由详细的需求驱动，并且发生在编码之后。最后，敏捷测试中，提倡持续集成和构建，集成的频率较高，并且可为开发提供持续的反馈。
　　5 结论
　　其实，不管正在使用的是哪种开发模式，都会经历几乎同样的软件开发生命周期元素。敏捷的不同之处在于时间段明显变短，而且活动同步进行。因此，参与者、测试和工具都需要适应这一变化。同时，也应该看到没有哪种开发模式可以放之四海而皆准，只有不断的被实践和验证才能持续完善[5]。目前，敏捷还在不断发展，更多的项目在实践敏捷，应用的普及和成功的案例正在不断扩大。
　　参考文献
　　[1]郑文强，马均飞.软件测试管理[M].电子工业出版社，2010.
　　[2]张友生，李雄.常用软件开发模型比较分析.中国系统分析员，2005(1).
　　[3]桑大勇，王英，吴丽华.敏捷软件开发方法与实践[M].西安：西安电子科技大学出版社，2010，5.
　　[4]唐亚男，王振一.敏捷测试综述[J].硅谷，2011(5).
　　[5]张林，刘德永.敏捷开发在软件产品项目中的应用实践[J].硅谷，2011(7).