广泛应用敏捷开发的分析与研究

王蕾

摘 要 敏捷开发自20世纪90年代提出以来逐渐引起人们的广泛兴趣，近些年来，许多大型知名软件企业对敏捷开发的应用也逐步积累了一定的实践经验。文章主要立足于探索敏捷的优势，探究分析了敏捷为何在充满挑战的软件开发过程中受到青睐。

关键词 敏捷；灵活性；持续性；高效性

中图分类号：TP3 文献标识码：A 文章编号：1671-7597（2014）02-0007-01

同其他生产稳定的工业产品比较而言，参与人员多样化、开发周期灵活、更新速度快的软件产品是一种相对特殊的商业产品。为了适应市场环境以及复杂的用户群体，不论是处于研发期还是已经投入使用的软件都常常面临着变更及升级的需求。因此，变更可以看作是软件的一般属性，正是因为这个特殊的产品属性而使得软件的研发过程变得极具创新性和挑战性。

1 敏捷开发的优势及特点

1.1 简捷性

敏捷开发崇尚简单的建模方案。相比于在建模初期设计一个宏伟的能够实现所有功能的软件开发框架，敏捷开发更倾向于从客户的基础需求出发，并在后续的开发中基于此需求逐步细化并进行扩充。在大多数情况下，客户的需求是频繁变更的，而需求的变更将导致已建立完备的设计框架失去效用，并且失去效用的构件数量将与开发框架的细化程度成正比。也就是说，初期的模型计划得越周全，随着后续开发过程中需求的变更，那些完善的细节设计被修改或丢弃的可能性就越大，从而造成大量的资源浪费。反观框架式的策略模型设计，大多数简洁并且灵活的基础设计在修改时并不耗费过多的资源，甚至在不符合新的需求变更时，由于并不消耗过多的资源而可被轻易的丢弃。

1.2 灵活性及持续性

敏捷开发采用迭代式的开发流程，它将整体开发过程分离成多个逐步细化但相对独立并“完整”的阶段性进程，在每一个阶段中开发人员都能随时调整产品方向。时下较流行的敏捷方法，如极限编程、Scrum等都有助于团队成员随时了解产品的进程，并基于整体的需求对构件进行深入研究并制定相应的修改措施，从而帮助产品及时地适应因需求变更带来的改变。

较之传统的设计模型如瀑布模型，敏捷开发更适用于频繁变更的现代软件产品研发。瀑布模型并不崇尚开发过程中的变更，它要求客户在产品设计初期就提出详尽的需求，并将后续的开发工作，如分析、设计、编码、测试及客户支持都建立于此基础之上。正是因为这种环环相扣的设计开发模式，使得我们不难理解为什么变更不被传统的设计模式所崇尚及接受，也正是由于传统设计模式在处理需求变更时的阻力及粘滞性使得敏捷开发的优势变得尤为显著。基于敏捷的灵活性和可变性，开发团队可在开发过程中及时根据客户的意见对产品做出调整和反馈，而这种时效性是传统设计模式所不能达到的。

1.3 参与性及高效性

敏捷中所涉及的参与并不仅仅是开发团队中各个角色的参与，更重要的是让客户参与到产品开发中来。在传统开发模型中，客户通常是分离在开发过程之外的，因此客户只能在产品交付时感知到期望产品与实际产品的差异。客户作为利益相关者在传统的开发模型中通常作为给予命令的一方而与开发团队对立，但是在敏捷开发中，他们则扮演开发团队中成员的角色。换言之，客户并不只是在产品开发初期提出需求，在最终产品交付时进行检查审核，而是参与整个开发过程并基于对当前工作的深度了解而提供更好的支持和更及时合理的意见。这种合作模式为客户同实施开发人员的意见交流提供了更加便捷的环境，进而帮助开发团队避免在最终产品交付时出现差异化的可能性。

此外，敏捷还十分强调传统开发团队中隶属于不同职能部门中成员间的有效协作和高效沟通。传统的开发模型按照开发过程中的不同需求将开发进程划分为不同的阶段，而每一阶段只负责单一的问题，如需求分析、设计、编码及测试等，分属于不同职能部门的开发人员并不与本部门之外的人员产生交集，由此阻碍了彼此间的交流。迭代式的敏捷开发同时聚集了来自不同领域的专家，并保证其共享开放的工作空间，因此促进了开发团队中成员间的信息流通，继而有效地避免由于信息误解或低效率传播而带来的成本消耗。

敏捷开发更能够帮助利益相关者明确需求并减少无效工作。通常，开发团队需要在开发初期逐步理解并帮助客户精确认识到对于产品的预期目标，该过程会伴随着整个开发过程，在传统的开发模式下，最终可操作产品的交付通常会经历一段相当冗长的阶段，客户只能在最终产品交付时才会发现产品缺陷，这段已消耗的时间很可能影响其后续的工作或是整个项目。敏捷开发避免了缺乏时效性的沟通，从而增强了客户的满意度，继而使得整个开发进程更加高效。

1.4 团队建设

使用敏捷模型的团队成员每天都有可能面对需求变更，这将促使他们保持开放的心态和思想，时刻准备着使用前沿的科技甚至创造新的科技去解决棘手的问题，这样的工作模式可以帮助开发人员提高应对突发问题的技能。此外，由于敏捷开发中团队成员共享工作空间，因而保障了成员间的交流以及知识的传播，与其他部门成员间的学习能够促进和加深对彼此工作的理解，并建立有利于团队建设的隐性情感依附。还需要强调的一点是，敏捷团队中的成员都是作为项目的所有者存在，项目中的所有信息都是对等公开的，无等级制的透明化信息制度能够更好地鼓励项目成员表达自己的观点，在促成项目完成的同时也增加了团队成员的归属感。

2 结束语

敏捷通常被认为适用于小型的开发项目。然而在进行大规模的项目开发时是否应该使用敏捷的方法至今仍是研究者们讨论的要点。从宏观上来看，大型的项目始终可以分离成相对独立的结构构件，那么对这些构件的敏捷即可看作是对整体项目的敏捷反应。也就是说，当把这些适用于敏捷方法的小型构件整合成完整的项目即是在一定程度上对产品的开发使用了敏捷的方法。这种大型项目中构件间的整合并不是简单的构件堆砌，如何划分构件以及如何整合构件这些新的问题仍旧需要更多的实践经历及案例分析来解答。

参考文献

[1]T. J. Lehman， A. Sharma. Software Development as a Service： Agile Experiences. 2011 Annual SRII Global Conference （SRII）， Mar.-Apr. 2011.

[2]L. Cao， B. Ramesh， T. Abdel-Hamid. Modeling dynamics in agile software development. ACM Transactions on Management Information Systems， Vol.1，NO.1， Dec. 2010.

[3]M. Glas， S. Ziemer. Challenges for Agile Development of Large Systems in the Aviation Industry. Proceedings of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications， pp.901-908， Oct. 2009.endprint