探讨如何进行敏捷软件开发

探讨如何进行敏捷软件开发

软件工程自诞生以来,一直试图通过技术和管理的手段来降低软件项目的不确定性。在这个美好的愿望指导下,专家们发明了结构化、发明了面向对象、发明了CMM,这些新的技术和方法的确有助于“软件危机”的解决,促进了软件业的发展;然而,超支、超时、低质量的老问题并未得到根本解决多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改”(code and fix)。设计过程充斥着短期的、即时的决定,而无完整的规划。这种模式对小系统开发很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。错误故障也越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。2001年2月在美国犹他州,敏捷软件开发联盟(Agile Software Development Alliance)成立。在这之前,联盟的成员们在轻型方法的探索与实践方面做了很多有益的工作,知名的XP(Extreme Programming,极端编程)方法就是众多Agile方法论中的一种。敏捷(Agile)方法是对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。

1敏捷方法将拥有大量artifact(软件开发过程中的中间产物,如需求规约、设计模型等)和复杂控制的软件开发方法称为重型(Heavy Weight)方法,而把artifact较少的方法称为轻型(Light Weight)方法。敏捷方法(Agile Methodologies)汲取了众多轻型方法的“精华”,恰当地表达了这些轻型方法的最根本之处。首先,敏捷方法强调适应,而非预测。重型方法花费大量的人力物力,试图制订详细的计划来指导长期的工作,而一旦情况变化,计划就不再适用。因此重型方法本质上是抵制变化的,而敏捷方法则强调适应变化。其次,敏

捷方法以人为中心,而非以流程为中心,强调对变化的适应和对人性的关注[2]。XP、Cockburn的水晶系列方法、开放式源码、High smith的适配性软件开发方法(ASD-Adaptive Software Development)、SCRUM、Coad的功用驱动开发方法(FDD-Feature Driven Development)、动态系统开发方法(DSDM-Dynamic System Development Methods)等方法都可以归入敏捷方法,它们有许多的共同特征,但也有一些重要的不同之处。以下介绍的是一些知名的敏捷方法。

1.1XP

XP是一种轻型方法。它规定了一组核心价值和方法,消除了大多数重量型过程的不必要产物。建立了一个渐进型的开发过程,它依赖于每次迭代时对源码的重组(refastening)。所有的设计都是围绕着当前这次迭代,而不管将来的需求。这种设计过程的结果是"纪律性"与"适配性"的高度统一,使得XP在适配性方法中成为发展的最好的一种方法。

1.2Cockburn的水晶系列方法

水晶系列与XP一样,都有以人为中心的理念,但在实践上有所不同。Cockburn 考虑到人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度纪律性不同, Cockburn探索了用最少纪律约束而仍能成功的方法,从而在产出效率与易于运作上达到一种平衡。虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。

1.3High smith的ASD方法

该方法把一些起源于复杂适配性系统(通常称之为混沌理论——chaos theory)的思想在软件开发中加以应用。ASD的核心是3个非线性的、重迭的开发阶段即猜测,合作与学习。在一个适配性环境中,因为结果是不可预测的,偏离计划则是在引导开发人员向正确的目标迈进。在管理上,其重点不在于告诉大家做什么,而

是鼓励大家交流沟通,从而使他们能自己提出创造性的解决方案。计划和设计都得随开发的推进而改变。

1.4SCRUM

该方法强调明确定义了的可重复的(defined and repeatable)方法过程只限于在明确定义了的可重复的环境中,为明确定义了的可重复的人员所用,去解决

明确定义了的可重复的问题。SCRUM文献多集中论述迭代阶段计划与进度跟踪,特别强调开发队伍和管理层的交流协作。它与其他敏捷型方法在许多方面都很相似,特别是它可以与XP的编程准则很好地结合起来。

1.5Coad的FDD方法

它致力于短时的迭代阶段和可见可用的功能。FDD有以下五项任务:建立总体模型、提出功用清单、针对功用逐项制订计划、针对功用逐项进行设计、针对功用逐项开发实现。编程开发人员分成两类:首席程序员和"类"程序员(class owner)。首席程序员负责开发实现系统的各项功能。对每一项功能,首席程序员要定出需要哪些类(class)来实现这项功能,并召集“类”程序员们组成一个针对这项功能的开发组。首席程序员作为协调者,设计者和指导者,而“类”程序员则主要作源码编写。

2敏捷建模(AM,Agile Modeling)

AM是一组软件建模阶段的指导性原则。是针对基于软件系统的有效建模和编写文档的一个混乱而有序的、基于实践的方法[3]。是Scott W. Ambler在众多敏捷方法学的基础上发展起来的实践的抽象和总结。AM没有定义创建某种模型的详细步骤,但为怎样做一个有效的建模人员提供了建议。AM是混乱而有序的,因为它融合了简单建模实践的“混乱”和软件建模制品内在的“有序”。当前的建模方法经常被证明有“功能障碍”,一个极端是根本就没有建模存在,当软件被证明是没有经过很好思考的时候,会导致大量的返工;另一个极端是生成过多的模型和文档,使开发工作变得非常缓慢。AM帮助软件专业人员找到建模的最佳点,

这使软件专业人员既进行了足够的建模,以保证有效地研究和记录系统,又没有因过多地建模而减慢项目的进度[4]。因此AM的主要焦点是建模与文档。敏捷文档是尽可能地简单、尽可能地最少,尽可能地最大化用于创建和维护上的投资。AM是面向实践的,它不是一个学术理论,它的目标是描述以有效的方式建模系统的技术,这些技术对所面对的任务是高效而且够用的。它由一组AM人员坚持的价值观、AM人员相信的原则和AM人员使用的实践组成,是对其他建模过程的补充。

3发展前景及其注意事项针对以CMM为代表的重型方法软件过程(还有

RUP,ISO9000等,意味着软件组织在过程定义、维护、度量、质量保证上投入大量的资源,实现这样的开发过程是复杂的、高成本的),敏捷过程表明了完全不同的立场,宣称好的开发过程应该可以在保证质量的前提下,做到文档、度量适度,很容易适应变化并迅速做出自我调整,实现践中,敏捷方法得到了快速的发

展和大量的响应,在美国的调查表明,预计到2003年,大约50%的被调查者预计其50%以上的项目会使用敏捷方法;14%的被调查者认为其所有的项目会使用敏捷方法[5]。同样,敏捷方法学给中国的软件开发者们带来了巨大的心理冲击,那种张扬个性的主张是任何一个软件开发者都无法抵抗的诱惑。当为数不少的中小软件企业在尝试了重型方法并吃到了苦头之后,敏捷方法学将给这些企业提供新的思路,这种新方法将在更多的地方发挥作用。

敏捷软件开发,特别是AM,对大多数的软件组织来说都是新生事物,是一种新的工作方式。在学习、尝试新技术的时候应注意以下问题:

1) AM技术在是在采用敏捷方法的基础上提高建模效果的。它不是一门完整的方法学,只是某个软件开发流程中的一部分应用。要成功应用AM,所采用的开发流程的观念必须要与AM的观念相匹配(如:XP与AM匹配,而CMM与AM就不匹