基于敏捷软件开发模型的研究与实践

齐山松

(中国航工业西安航空计算技术研究所第8研究室，陕西西安 710068)

敏捷方法是软件工程的重大革新，即由传统结构化编程向新型结构化编程技术的转变。

1 传统软件开发流程所面临的挑战

随着企业竞争的日益激烈，客户对于软件产品的要求和期望日益提升，现实条件下应用的复杂性日益提高，带来了软件需求的频繁变动，使得当下的软件项目面临着严峻的挑战。采用传统的软件开发流程往往使得测试人员面临时间短、任务重、质量难保证的尴尬处境，这也正是近年来敏捷开发过程逐渐兴起和不断发展的主要原因。

敏捷软件开发是基于一种更接近人类活动现实情况的方法论，主要提倡随时都能提供可以交付的软件，并注重权利的下发，充分发挥团队中人的主观能动性。敏捷开发模型与传统的瀑布模型相比更容易在项目的早期控制缺陷数目。在传统的瀑布模型下，某个控制点前系统测试不能开始测试。所以在这之前不能发现缺陷，过了这个控制点后，突然增加巨大的测试对象以及缺陷数目急剧上升，将导致所有的质量风险在这一刻触发，缺陷收敛时间难以确定，这成为了进度偏差的一个主要诱因。

图1 瀑布软件开发模型

在迭代模式下测试对象平缓持续增加，测试始终对可用系统进行测试，质量水平是真实可衡量可控的，质量风险不会累计到最后阶段，同时发现问题的成本也较低，如图2所示。

图2 两种模型的缺陷数目统计曲线

2 敏捷开发与其现实意义

2.1 敏捷开发的兴起

软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。软件开发不仅是代码编写，而是人员的有效组织。如何既发挥人的主观能动性，避免不利因素对工作的干扰，又可以使大家有效地沟通与交流，让多个大脑的思路统一，快速完成目标，多年来软件企业的管理者一直在不断地探索。此外软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。而近年来兴起的敏捷开发却矫正了繁琐的软件开发过程。敏捷的目的在于加强开发者与用户的沟通，保证变化的需求及时得到修正［1］。

与传统软件过程、传统管理和开发方法相比，敏捷方法具有以人为本、轻载而灵活、成本低、开销小、效率高、见效快等优点，尤其适合中小软件研发企业或组织的软件过程改进和软件需求比较发散及频繁变动，且复杂性较高时间要求紧的项目。敏捷方法弥补了CMM/CMMI、ISO 9001等体系的不足，在过去10年中看到CMMI专家一直在研究敏捷，学习和吸收敏捷的长处，出现了CMMI主动拥抱敏捷、与敏捷集成或融合的显著趋势。既然CMMI要拥抱敏捷，就说明敏捷有CMMI所缺少的东西，如此庞大的 CMMI体系仍然是不全面的。敏捷能力是所有优秀企业/组织、优秀团队和优秀个人都具有的一种基本特质。因此，敏捷软件工程、敏捷过程和方法，也率先被世界上优秀的一批软件研发领导企业、组织、团队所采用，目前业界熟知的有微软、IBM、诺西、爱立信、华为等。

2.2 敏捷开发的价值观

敏捷开发过程摆脱了一切对软件开发不合理的约束，采用一种以人为本的方式，注重人在具体实践当中的活动，以便满足逐渐变化的需求。敏捷强调构建能够随时交付的软件，开发过程类似植物的自然生长，通过迭代开发实现软件功能的不断完善，并且结合了尽可能多的客户反馈。相对于传统的软件开发模式来讲，敏捷开发过程具有更大的优势，主要体现在更能适应不断变化的客户需求，团队中的成员更有激情，以及能够创造出更大的价值。

Kent Beck等编写的《敏捷软件开发宣言》中，陈述了构成所有敏捷方法学的4个核心价值观，如图3所示。

图3 敏捷软件宣言

敏捷软件开发在最近几年逐步得到认可并运用的一个原因是，该运动的发起者在《敏捷软件开发宣言》中明确表明了所信仰的东西，说出了敏捷的核心价值观和持久的目的。团队为何存在，我们要创造什么产品，为谁而创造以及如何共同工作，这些组成了敏捷项目管理的核心原则。如果要创造优秀的产品，就需要有优秀的人，这就需要有优秀的组织，这样才能吸引和留住这样优秀的人。当然，这个唯一的核心价值观并不能创造产品，但核心价值观定义了大多数敏捷主义对自己的认识［2］。

3 敏捷开发实践与应用

3.1 敏捷软件开发框架

敏捷项目管理应用框架是解决复杂性、不确定性和高风险性项目的一系列理念、过程和实践的集合。它是对传统项目管理的批判继承。它源自软件开发领域的敏捷开发运动;随着产品特别是电子产品开发中软件的价值比例越来越高，敏捷的理念和实践在产品开发的项目管理也逐渐发展起来。Scrum是众多敏捷软件开发的框架之一，而且也是被应用最广泛的一种［3］。

Scrum是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程。这个轻量的过程可以作为包装器，也就是说可以把Scrum与其他灵活的过程框架组合起来，比如说RUP。RUP(Rational Unified Process，Rational统一过程)，是一种被广泛使用的软件过程框架。它可以很好地迎合软件开发过程的需要，还可以容纳其他技术。Scrum是一系列有趣的，用来包装灵活软件项目的项目管理模式。

Scrum提供了一种经验方法，它使得团队成员能够独立地、集中地在创造性的环境下工作。它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化。Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复使得输入和输出参数更加容易预测和描述，但这并不是当今软件工程的有益目标。现代软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。RUP和其他敏捷软件工程过程能够迎接这些挑战。

Scrum的骨干与核心如图4所示。下放循环代表开发活动的迭代，这种循环相继开发。每次迭代的产出成果便成为产品的增量。上方循环代替迭代过程中的每日检查，团队成员举行会议相互检查选出其认为在该迭代结束时能转化为相应完整功能增量的部分。迭代其余时间内，团队不受干扰，努力工作。迭代结束时，团队展示完成的功能，请利益相关者进行检查，以对项目作出及时调整。

图4 Scrum开发的框架

Scrum方法中只有3个角色:产品负责人，团队和Scrum Master。产品负责人代表项目中每位利益相关者的权益，并为项目产品的软件系统负责。产品负责人的职责是利用产品订单，督促团队优先开发最具价值的功能。团队的职责是开发软件功能，其是自我管理、自我组织和跨职能的，他们负责找出可以在一个迭代中将产品待开发事项转化为功能增量的方法，并管理自身工作，达到这一目标。通常团队由5～9个人组成。Scrum Master则需对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需要督促全体成员遵从Scrum规则和实践。

Scrum的流程，可以分为以下部分:(1)将整个产品订单Backlog分解成为若干个迭代订单Sprint Backlog，按照目前的人力物力条件可以完成的。(2)召开Sprint计划会议，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这个任务是以小时计算的，并不是以人天计算，长度不超过8小时。(3)进入Sprint开发周期，每个Sprint迭代周期为2到4周，团队可根据项目特点来选择。在这个周期内，每天需要召开每日Scrum简会，时间为15分钟。在会议中每个团队成员仅就以下3点发言:自上次Scrum会议后做了什么?从现在到下次Scrum会议的时间里你准备做什么?你在工作中遇到了哪些困难?(4)整个Sprint周期结束，召开Sprint评审会议，将结果演示给产品负责人Product Owner，收集与会者的反馈进而可以在下一个Sprint中进行改进。(5)团队成员最后召开Sprint回顾会议，总结经验和发现问题。(6)这样周而复始，按照同样的步骤进行下一次Sprint。

(《四月朔日，牛农、曹(坤)邀予游崇效寺。 牡丹己过，芍药未开。 向惠林上人索观拙庵红杏青松卷，题者甚火。 王渔洋、朱竹垞、查初白皆有手迹。 此卷康熙庚午岁作，百二十年物矣，亦可宝也。》)

Sprint计划会议，每日简会，评审会议，回顾会议共同构成Scrum方法中的经验性检查及适应调整部分。Scrum并非只关注商业价值增量，它更注重交付客户提出的最重要最优先的商业价值。

3.2 如何实施Scrum

通常实施敏捷软件框架Scrum，会用到APAPT模型。在这个模型中包含5个常见活动，这是成功，持续实施Scrum必备的5个活动。

这些活动是，意识，愿望，能力，推广以及传递，使用其英文字母缩写为ADAPT［4］。这些活动中意识，愿望和能力是相互重叠的，而推广和传递在整个转型过程中会重复出现。在开始转型之后，这个循环还会随着持续改进而持续下去。

3.2.1 意识(Awareness)

当前的过程已不能实现可接受的结果。变革始于不满足于现状的意识。尽管如此，意识到过去的工作方式不再有效是困难的。需要变革的时间点和第一次意识到需要变革之间，几乎是有一个滞后区。如果公司经营得良好，这个滞后可能会延长。其他一些个人形成变革意识可能很慢，其原因如下:(1)缺乏对大局观的关注。(2)拒绝关注对与错。(3)行动与进展混为一谈。(4)自吹自擂。

团队成员会在不同的时间意识到变革的需要。很早就有变革意识的人有机会协助和带动其他人形成共识。可以通过一些工具来开发需要变革的意识:(1)通过沟通，说明问题的存在。(2)使用度量数据:作为整体沟通策略的一部分，度量数据为变革个核心原因提供了巨大的支持。看到一些公司使用员工离职率，工作满意度调查结果，人均收益率和其他简单的度量数据来证明变革势在必行。(3)接触新的人与经验:鼓励员工参见一些技术大会或培训，让他们了解一些新的技术和实践。要么送员工参见一个所在行业的行业展会，让他们看到竞争对手在发布什么产品。要么安排客户和团队召开会议，让他们听到第一手的功能需求以及对时间的要求。(4)运行一个试点项目，成功的试点项目证明事情能做的更好。(5)关注最重要的变革理由:要想促使人们树立变革的意识，往往最好使用一个更短的清单。哪两个或3个原因是大多数问题的根源?仅这些原因便足以证明实施Scrum是正确的。通过把一个完整的列表缩小为只包括关键原因的列表，是能使被关注且具有说服力的原因。

3.2.2 渴望(Desire)

3.2.3 能力(Ability)

有能力成功实施Scrum，如果没有敏捷转型的能力，再好的意识和愿望也都是徒劳。Scrum的成功实施不仅需要团队成员学习新的技能，还需要放弃一些旧的技能。并且需要学会用团队的方式思考和工作，以及在一个短的时机箱内造出可以工作的软件。有很多很好的方法可以帮助培养团队这方面的能力:(1)参加辅导和培训:Scrum与传统软件开发的区别在于，通常必须有培训以及现场的教练或指导。最开始的一些培训对大多数公司来说貌似最有效，定位于激发尝试Scrum的意愿和理解它的核心原则。这是一般的培训，随之而来的就是具体的实践培训与指导。(2)赋予个体职责:在提供辅导和培训的同时，员工需要知道他们有责任应用企业花钱使其获得的新技能。(3)共享信息:在开发敏捷能力的时候，团队成员的周围将充斥着新的信息和挑战。为他们提供分享信息和问题的机会。一种方法是使用团队间“相互取经”:鼓励团队成员偶尔参加其他团队的每日站会或Sprint评审会议。另一种选择是使用公司内网，实践社区和阅读小组来传播信息。(4)设置合理的目标:提出目标，成功的转型，需要拆成更小的块。同样，组织必须平衡推动快速改进和推动太多太快带来的风险。通过鼓励团队选择实际可行的目标，有助于消除他们在做任何重大承诺前可能出现的犹豫。(5)立即行动:不要拖延，不要等到知道所有的答案后再开始。开发新技能的最好方式是立即行动。

3.2.4 推广(Promotion)

通过分享经验来推广Scrum，从而记住并能让其他人也看到成功。推广有3个目标。第一，为接下来的ADAPT周期传递打好基础。通过宣传现在的成功，会对创造新一轮的改善意识有一个跳跃性的开始。第二，通过传播其他团队获得成功的一些好消息，加强现有团队的敏捷行为。最后是第3个目标，在直接参与Scrum实施的群体之外创造敏捷意识和兴趣。许多这样的群体如人力资源，销售，市场营销，运维和设备，可以对成功转型产生重要的影响。讲述成功故事发挥着关键作用，特别重要的是在企业内广泛宣传Scrum早期实施者的成功故事。麦肯锡公司的一项研究发现，成功地变革在于鼓励员工立足于成功，而不是让他们去解决问题(2008年)。推广活动有助于转引员工的注意力，让他们远离意识阶段不能解决的问题，而去关注能够取得成功。讲述成功故事一个好办法是使用内部已经实施Scrum的团队经验报告的方式。身边人的实践最有说服力。

3.2.5 传递(Transfer)

把实施Scrum带来的影响扩大到整个公司。可以把Scrum比作火箭。火箭向前推进依靠的是它的发动机功率。但将其拉回来的是重力。如果火箭被推得足够远，它可以进入轨道。但如果它不能进入轨道，必定会被拉到地面，回到起点。Scrum的影响必须推得足够远，使整个转型不会因为“企业重力”而被拉回起点。开发团队只靠自己是不能永久保持敏捷的。如果Scrum效应无法传递到其他部门，这些部门的“组织惯性”最终会使转型所做的所有努力化为灰烬。

4 结束语

综上所述，本文针对传统软件开发流程所面临的挑战，论述了敏捷软件开发的的现实意义。敏捷开发过程摆脱了一切对软件开发不合理的约束，采用一种以人为本的方式，注重人在具体实践当中的活动，以便满足逐渐变化的需求。与此同时，还探讨了敏捷软件开发的框架Scrum以及如何在企业或者公司里运用Scrum。由此可见，相对于传统的软件开发模式来讲，敏捷开发过程具有更大的优势，主要体现在更能适应不断变化的客户需求，团队中的成员更有激情，以及能够创造出更大的价值。

［1］CRAIG L.敏捷迭代开发管理者指南［M］.张晓坤，林旺，曾毅，译.北京:中国电力出版社，2004.

［2］吴丹，史争印.软件工程理论与实践［M］.北京:清华出版社，2003.

［3］ALISTAIR C.敏捷软件开发［M］.苏敬凯，译.北京:机械工业出版社，2008.

［4］MIKE C.Succeeding with agile software development using scrum［M］.廖靖斌，吕梁岳，陈争云，等，译.北京:清华大学出版社，2010.