（计算机应用技术专业论文）基于敏捷开发方法的民航基建项目管理系统设计与实现.pdf

西南交通大学硕士研究生学位论文第1 页 摘要 当前软件业的激烈竞争和软件需求的多样性及开发过程中的频繁变化，给软件开 发带来了极大的挑战，对传统的软件工程开发方法的革新也成为必然。敏捷软件开发 方法的出发点就是希望以最高的效率和质量来解决用户眼前的问题，以最大的灵活性 和最小的代价来满足用户未来的需要。它将复杂的开发过程分解为一个个相对比较简 单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非 常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整 开发过程及进度。 敏捷软件开发是当前颇为流行的一类开发方法的统称。极限编程( e x t r e m e p r o g r a m m i n g ) 开发方法作为敏捷软件开发方法的代表，更是让人称道。本文在重点分 析极限编程的基本理论、基本原则、实践模型和敏捷规划的基础上，以民航基建项目 管理系统的研发为例，对敏捷开发方法的应用进行研究。论文深入分析了系统目标、 主要业务及基本功能，描述了系统的非功能需求。随后以需求分析为基础，进行系统 首次迭代前的设计。然后遵循敏捷开发的基本原理，通过主要的两次迭代开发的详细 论述，比较完整地展现了敏捷软件开发的思想、方法和开发过程。 论文通过对系统需求变化和设计演化过程的描述，集中体现了敏捷软件开发应对 变化需求的优势，证明了在规模不大、业务灵活、管理基础相对较弱的中小型系统开 发中，重视敏捷开发方法的应用，可以有效地提高软件质量和开发效率。 关键词：敏捷软件开发；极限编程；实践模型；测试驱动开发 西南交通大学硕士研究生学位论文第1 i 页 a b s 仃a c t t h ec o m p e t i t i o no fc u r r e n ts o f t w a r ei n d u s t r y , t h ed i v e r s i t yo fs o f t w a r er e q u i r e m e n t sa n d f r e q u e n tc h a n g e si nt h ed e v e l o p m e n tp r o c e s sh a v eb r o u g h tg r e a tc h a l l e n g e st o s o f t w a r e d e v e l o p m e n t ，t h ei n n o v a t i o no ft h et r a d i t i o n a lm e t h o d so fs o f t w a r ee n g i n e e r i n gd e v e l o p m e n t b e c o m e si n e v i t a b l e t h es t a r t i n gp o i n to fa g i l es o f t w a r ed e v e l o p m e n tm e t h o d si st os o l v e u s e r s i m m e d i a t ep r o b l e m sw i t ht h eh i g h e s te f f i c i e n c ya n dq u a l i t y , a n dw i t hm a x i m u m f l e x i b i l i t ya n dm i n i m u mc o s t t om e e tt h en e e d so fu s e r si n t h ef u t u r e i td i v i d st h e c o m p l i c a t e dd e v e l o p m e n tp r o c e s si n t or e l a t i v e l ys i m p l e s m a l l c y c l e s ，t h r o u g hp o s i t i v e c o m m u n i c a t i o n ，f e e d b a c ka n do t h e rs e r i e so fm e t h o d s ，d e v e l o p e r sa n dc u s t o m e r sc a r lb ev e r y c l e a ro ft h ep r o g r e s so fc h a n g e ，t h ep r o b l e mt ob es o l v e da n dt h ep o t e n t i a ld i f f i c u l t i e sa n ds o o n ，a n dt i m e l ya d j u s tt h ed e v e l o p m e n tp r o c e s sa c c o r d i n gt oa c t u a ls i t u a t i o n a g i l es o f t w a r ed e v e l o p m e n ti sc u r r e n t l yaq u i t ep o p u l a rt e r mf o ra k i n do fd e v e l o p m e n t m e t h o d e x t r e m ep r o g r a m m i n gd e v e l o p m e n tm e t h o d o l o g ya sar e p r e s e n t a t i v eo fa g i l e s o f t w a r ed e v e l o p m e n tm e t h o d si sp r a i s e d e x t r e m ep r o g r a m m i n g ，b a s e do nt h ea n a l y s i so f t h eb a s i ct h e o r i e s ，b a s i cp r i n c i p l e s ，p r a c t i c em o d e l sa n da g i l ep r o g r a m m i n g ，t h i sp a p e rt a k e s t h ep r o j e c tm a n a g e m e n ts y s t e mi na v i a t i o ni n f r a s t r u c t u r ed e v e l o p m e n ta st h ee x a m p l e ，a n d r e s e a r c h e st h ea p p l i c a t i o no fa g i l ed e v e l o p m e n tm e t h o d o l o g i e s t h i sp a p e rd e e p l ya n a l y z e t h es y s t e mo b j e c t i v e s ，k e yb u s i n e s sa n db a s i cf u n c t i o n s ，d e s c r i b e st h es y s t e mn o n - f u n c t i o n a l r e q u i r e m e n t s ，s u b s e q u e n t l yb a s e do nt h ea n a l y s i so ft h ed e m a n d ，t h i sp a p e rd e s i g nt h e s y s t e mb e f o r et h ef i r s ti t e r a t i o n t h e nb a s e do nt h eb a s i cp r i n c i p l e so fa g i l ed e v e l o p m e n t ， t h r o u g ht h ed e t a i l e dd i s c u s s i o no ft o wi t e r a t i v ed e v e l o p m e n t ，t h i sp a p e rr a t h e rc o m p l e t e l y d e m o n s t r a t e st h ei d e a ，m e t h o d sa n dd e v e l o p m e n tp r o c e s so fa g i l es o f t w a r ed e v e l o p m e n t 。 t h r o u g ht h ed e s c r i p t i o no f t h ep r o c e s so ft h ec h a n g e so fs y s t e mr e q u i r e m e n t sa n dd e s i g n ， t h i sp a p e rs h o w st h ea d v a n t a g e st h a ta g i l es o f t w a r ed e v e l o p m e n td e a l sw i t ht h ec h a n g i n g r e q u i r e m e n t ，p r o v e st h a ti nt h ed e v e l o p m e n tp r o c e s so fs m a l la n dm e d i u ms y s t e m st h a ti s o f s m a l ls c a l e ，o ff l e x i b l eb u s i n e s sa n do fr e l a t i v e l yw e a km a n a g e m e n t ，t h ee m p h a s i so na g i l e d e v e l o p m e n t m e t h o do f a p p l i c a t i o n c a n e f f e c t i v e l yi m p r o v e s o f t w a r e q u a l i t y a n d d e v e l o p m e n te f f i c i e n c y k e y w o r d s ：a g i l es o f t w a r ed e v e l o p m e n t ；e x t r e m ep r o g r a m m i n g ；p r a c t i c em o d e l i n g ； t e s t d v e nd e v e l o p m e n t 西南交通大学 学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并 向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授 权西南交通大学可以将本论文的全部或部分内容编入有关数据库进行检索，可以采用 影印、缩印或扫描等复印手段保存和汇编本学位论文。 本学位论文属于 1 保密口，在年解密后适用本授权书； 2 不保密醇使用本授权书。 ( 请在以上方框内打“扩) a 哆 虼 二 彩 色 彩 叼、反k 蕾 奠刁。 名 卅 签 入 一 如 作 小 姘 瑚 扔 日 位爹 西南交通大学硕士学位论文主要工作( 贡献) 声明 本人在学位论文中所做的主要工作或贡献如下： 本文从概述敏捷软件开发的基础理论知识入手，重点研究敏捷方法中的极限编程 ( x p ) 开发方法，然后针对本系统给出一般中小型软件项目敏捷开发流程及实践模型。 本文以民航基建项目管理信息系统开发为例，主要通过前两次的迭代开发来展示敏捷 开发过程的具体实施，依照x p 实践模型进行设计，迭代开发；最后交付用户满意的系 统功能版本。该系统具有良好的扩展性和稳定性，为基于敏捷开发的中小型软件项目 的开发的成功提供范例参考。 本人郑重声明：所呈交的学位论文，是在导师指导下独立进行研究工作所得的成 果。除文中已经注明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰 写过的研究成果。对本文的研究做出贡献的个人和集体，均已在文中作了明确说明。 本人完全了解违反上述声明所引起的一切法律责任将由本人承担。 学位论文作者签名： 日期：0 历f 矿 西南交通大学硕士研究生学位论文第1 页 1 1 研究背景 第1 章绪论 大型工程建设项目通常投资大、周期长、应用技术复杂、产生的工程信息量大而 繁杂，因此，如何及时、准确地利用工程项目建设信息，为工程监督管理提供依据、 手段，掌握工程建设实施情况，并为工程建设保存完整的建设资料，是一个必须解决 的问题。实践证明：不在工程项目管理中有效利用i t 技术，可以说就无法实施科学化 的项目管理【1 】。另外，软件系统的开发是根据客户的具体情况，具体要求来设计专用软 件，提供相应的服务。大多数客户由于自身的历史和业务状况，对于软件系统会有自 身特殊的要求。随着我国信息化水平的提高，越来越多的企事业单位会使用专用的软 件，这无疑对软件企业来说是种挑战。然而，我国不少小中型软件企业在软件开发的 过程中还是面临着不少问题，如软件项目的超支、超时及如何提高软件质量等。如何 能成功高效的开发出软件项目的问题归结为寻找更为有效的软件开发方法上，这也是 研发人员必须要面对的问题。总结以往开发过程，失败因素可归咎于以下几点： 1 项目的亟需性。项目的亟需性决定了项目开发周期，在某些方面也决定了项目 中要使用的技术；开发团队在开发中稍有技术或项目管理上的失误都会导致项目开发 周期的缩短，不能按时交付项目产品，从而致使项目以失败告终。 2 项目的质量要求高。部分实际业务的处理对软件的质量有很高的要求，丝毫的 差错都可能会影响到实际业务的顺利进行，导致流程的滞后，带来不可估量的经济损 失。所以软件的质量一定要有可靠的保证。 3 项目需求的模糊性。在项目调研中，常发现：一次性扑捉到客户的大部分真实 意图是相当困难的，客户不能很好的表述自己的需要，大多数时候是调研人员在提出 问题，然后由客户来确定答案。调研人员尽可能多的去提出问题来供客户回答，结果 无疑是丧失了客户对自己需求提出的主导性地位。系统从研发到试用再到投入真正使 用，很多时候会历经多次的变更，也正是需求的多次变更调整，从而使项目开发在时 间上的没有保证，这样也会导致项目的失败。 4 项目设计缺陷与后期需求变更的矛盾。由于前期设计上的缺陷，在后期需求的 变动会使系统有较大的变动，费力费时，导致开发过程中和维护变得相当麻烦。 5 繁琐的开发过程以损伤开发效率为代价。传统重量级的开发方法在开发的过程 中过于注重某些开发环节，如过于细致而又繁重的开发文档，开发人员的精力往往不 能高效的集中在编码上；在某些项目上，传统的开发过程方法会使开发变的越来越复 杂，这样势必会折伤开发效率，严重的必然会导致项目的失败。 相对于传统的方法，敏捷方法可谓是轻量级的开发方法，其诸多的开发优势逐渐 西南交通大学硕士研究生学位论文第2 页 的被业界认可；当然敏捷开发方法也存在一些不足，如何更好的实践敏捷开发方法， 将其运用在项目的开发过程中，更大限度的发挥敏捷方法的优势，在实际的软件开发 中去逐渐认识敏捷开发方法，使的这一开发方法得以发展。 1 2 敏捷方法现状概述 近几年，敏捷软件开发在软件工业界有了良好的发展势头并逐渐被推广开来。一 些著名的公司如g o o s e ，m i c r o s o f t 和y a h o o 和众多的中小公司都已经开始采用敏捷 开发。目前大公司对敏捷的接受正呈现出上升趋势。近年来，己有一些大公司将敏捷 开发方法应用到了全球软件开发( g l o b a ls o f t w a r ed e v e l o p e m e m ，g s d ) 这样一个分布式 开发环境【3 7 】，也有些公司正尝试在开发过程中混合使用传统方法和敏捷开发方法脚【3 8 】。 近年来，随着敏捷软件开发( a 西l es o f t w a r ed e v e l o p m e m ，a s d ) 在国j , l - j , i - 企的 大行其道，a s d 是否满足c m m i 实施评估要求等问题，在业界一直是争论不休，备受 人们关注。据统计，我国目前绝大多数软件企业属于中小型企业( 5 0 人以下，9 0 以 上) ，绝大部分开发团队是小规模的( 1 0 人以下) 1 5 3 。 敏捷在中国刚刚开始被采纳。中国的软件开发群体在近几年开始使用敏捷方法， 所以只有很少的一些有关组织和公司，如腾讯等率先推广了敏捷开发。可以说中国的 敏捷采用率仍然停留在技术采纳生命周期的初期试用阶段。尽管如此，中国的软件工 业中存在着敏捷方法迅速发展的契机。在国内，很多经理和工程师都在深思现在出现 的另一个趋势：敏捷软件开发。在当今不断变化的商业环境中，缓慢的“重量型”方 法无法满足要求，现在需要用更少的投入产生更大的利润。敏捷方法的优势在于它的 协作、灵活性，以及它对软件的商业价值作出的贡献。 未来的几年，中国的软件市场将比其他国家和地区发展得更为迅猛，以满足中国 自身的需要和面对世界各国加剧的商业竞争和挑战。敏捷开发会为中国的软件服务和 产品带来我们最需要的质量和效率的提高，这为敏捷模式在中国的迅猛发展提供了难 得的时机。 1 3 本文研究的内容 本文具体工作有以下几个方面： 1 深入分析敏捷软件开发相关理论知识，重点对极限编程( x p ) 进行剖析，针对实 际项目给出基于x p 的一般中小型软件项目开发实践模型。 2 依据敏捷实践模型，研发了民航基建项目管理信息系统，详细描述系统的在开 发过程中的敏捷方法的应用，包括：系统需求的演化过程，详细设计过程及实现。 3 在迭代开发中，运用场景技术来获取用户故事，阐述需求细则及开发时间安排， 使项目开发任务颗粒化。 西南交通大学硕士研究生学位论文第3 页 1 4 本文研究的意义 软件开发活动是一个探索的过程，探索过程存在着不确定性，不能产生已知的预 先规定的结果，而应该是不断地适应开发活动【lo 】。当前许多中小型软件项目面临着开 发时间紧迫、需求不断变化、人员缺乏的难题。而传统的重量级软件工程方法认为j 所有需求的确定只在于开发人员的积极努力工作，即可缩减或避免后期需求变动所带 来的研发成本的增加。 敏捷是为了在动荡的业务环境中获益而创造变革和响应变革的能力【13 1 。敏捷开发 是一个较新的软件开发思想，近年来兴起的敏捷软件开发方法为以上传统软件工程的 问题提供了良好的解决方案它作为轻量级的灵活的软件开发方法，强调对变化的快 速响应能力，通过引入迭代式的开发手段，较好地解决了如何应对变化的问题【4 】。但是 原理如何能有效的应用实践上，不能停留在理论的探讨上，而需要研发人员在实际的 项目中基于原理给出富有成果性的应用，发挥出敏捷方法的效力。 本文从空管局基建处项目管理系统实际项目开发出发中，探讨这些问题，摸索行 之有效的开发方法，以提高开发效率及系统的质量为目的，更好更早的交付客户满意 的软件。 1 5 论文组织 本文共分六章，各章的主要内容如下： 第1 章，绪论。本章依次阐述课题研究的背景，概述敏捷开发方法的现状，课题 研究的内容及意义，最后介绍本论文的组织结构。 第2 章，敏捷方法理论概述及实践模型。介绍敏捷开发方法。主要介绍敏捷宣言， 敏捷开发的价值观和原则，尤其阐述敏捷方法中的极限编程x p 方法，给出具有一般且 操作性强的敏捷实践模型；然后主要从迭代规划和发布规划两个方面来简单介绍敏捷 规划。 第3 章，系统初步需求分析。以实现系统的目标为基点，对民航基建项目管理信 息系统项目进行初步分析。分析项包括项目的设计目标，用户的组织结构及职能分析、 系统主要业务分析、基本功能需求分析、系统的主要非功能需求、需求约束及关联系 统之间的联系。 第4 章，首次迭代前的设计。基于上一章节的系统业务分析，从几个方面对系统进 行架构设计上的详细阐述，然后对系统三层开发框架的设计进行逐一分析描述，为系 统迭代开发做好准备。 第5 章，第一次迭代交付。从系统的核心业务需求分析入手，采用场景分析方法 来获取用户需求，然后针对需求进行简单设计，实现首次迭代任务单，并对系统进行 功能测试和性能测试，最后向客户发布首次迭代系统版本。 西南交通大学硕士研究生学位论文第4 页 第6 章，第二次迭代交付。描述迭代后的项目组会议讨论内容，反思开发过程及 总结个人工作方法，获取并分析客户反馈意见，调整迭代需求优先级，进行重构设计 优化系统功能结构，实现功能调整任务及客户新需求功能，然后进行系统测试，发布 本次迭代产品。 最后对课题的研究工作进行全面总结，并指明下一步的研究内容和方向。 西南交通大学硕士研究生学位论文第5 页 第2 章敏捷方法理论概述及实践模型 2 1 敏捷软件开发概述 敏捷软件开发又称敏捷开发( a g i l ed e v e l o p m e n t ) ，目的就是成为适应变化和推动 变化的过程，甚至允许改变自身来适应变化【1 4 】。它是一种应对快速变化的需求的一种 软件开发能力，是一种以人为核心、迭代、循序渐进的开发方法。 2 1 1 敏捷革命及开发宣言 软件开发经历了5 0 多年的发展历程，软件工程的发展可简单概括为从无到繁重， 再到敏捷的过程【8 1 。2 0 世界9 0 年代涌现了一些新的，轻量型的开发方法，同时也掀起 了一场软件革命，敏捷软件开发就时崛起。敏捷开发是一种相对于传统软件开发而言 的轻型开发，正逐渐成为软件开发的新模式【2 】。 2 0 0 1 年2 月，在犹他州w a s a t c h 山的滑雪胜地s n o w b i r d 的一栋大楼里，1 7 个软件 专家聚集在一起交谈、滑雪、试图找到某些共同的话题。这次会议形成了敏捷软件开 发运动，会议的最终结果是：与会者共同签署一份题为敏捷软件开发宣言( t h e m a n i f e s t of o ra g i l es o f t w a r ed e v e l o p m e n t ) 的声明文件【8 】，这份宣言的产生，标志着敏捷 开发方法的诞生。 2 1 2 敏捷价值观和原则 敏捷开发的价值观可以综述为以下四点： 1 个体和交互胜过过程和工具。敏捷方法认为团队的构建要比项目环境的构建重 要的多，人是软件项目获得成功最为重要的因素。团队的合作、沟通以及交互能力要 比单纯的软件编程能力更为重要。 2 可以工作的软件胜过面面俱到的文档。软件开发的主要目标是交付给用户可以 工作的软件而不是文档，否则就称之为文档开发而不是软件开发，敏捷软件开发则避 免了这种浪费 l0 1 。编制众多的文档需要花费大量的时间，并且要使这些文档与代码保 持同步就会花费更多的时间，导致进度拖延。 3 客户合作胜过合同谈判。为了全方位地满足客户不断变化的需求，切实可行的 途径就是开发团队与用户紧密协作，而那些为开发团队和客户的协同工作方式提供指 导的合同才是最好的合同。 4 响应变化胜过遵循计划。变化是软件开发中存在的现实，一个软件过程必须反 西南交通大学硕士研究生学位论文第6 页 映现实，有足够的能力及时响应变化。 从上述的价值中引出了下面的1 2 条原则【4 】，它们是敏捷实践区别于重型过程的特 征所在。 1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争 优势。 3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的 时间间隔越短越好。 4 在整个项目开发期间，业务人员和开发人员必须每天都在一起工作。 5 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任 他们能够完成工作。 6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7 工作的软件是首要的进度度量标准。 8 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长 期的，恒定的开发速度。 9 不断的关注优秀的技能和好的设计会增强敏捷能力。 1 0 简单是根本的。 1 1 最好的构架、需求和设计出自于自我组织的团队。 1 2 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对 自己的行为进行调整。 2 2 敏捷方法之极限编程理论分析 极限编程( e x t r e m ep r o g r a m m i n g ) 是- - 种轻量方法论，适用于面临不明确或快速变化 需求的小型到中型软件开发团队【6 】。与传统的瀑布式方法或r a d 方法的区别在于：承 认充满变化。 2 2 1 ) ( p 核心观念及指导原则 在x p 创始之前，极限编程鼻祖k e n tb e c k 就在思考更好的软件开发方法。在实 际的合作的项目中，他亲身验证了一种新的开发观念，应用这一开发观念使得开发途 径变得简洁高效，这就是后来的极限编程( x p ) 方法。极限编程是让开发者的一些人性 需求在软件开发中得到满足【5 】，包括基本的安全感、归属感、成就感、成长以及亲切感 等。k e n t 逐步认识到改进任何软件项目，都有四个方面的因素着手。需要改进沟通、 需要力求简洁、需要工作成效的反馈，以及需要一直勇往直前，也就是x p 的四大核心 观念：沟通、简洁、反馈和勇气，如表2 1 所示【3 1 ，它们也是x p 程序员所追寻的四大 西南交通大学硕士研究生学位论文第7 页 价值。 表2 - 1x p 四大核心观念及描述 核心观念 描述 x p 建议在考虑过程和编写代码时，永远都要使用尽可能简单的方式工作。 简单在管用的前提下，做最简单的事情。在考虑到简单性时，开发小组实现客户 实际需要的，而不是他们预期可能需要的。 所有的方法都包含交流的过程，这是x p 得核心价值观。它侧重口头交流， 交流 而不是文档、报表和计划。小组不进行持续的交流，协作将无从谈起。 及时经常地从客户、团队以及真正的最终用户那里听取具体的反馈意见，会 反馈 让开发者有更多的机会尽可能早地改进其工作质量。 x p 使得开发人员改变了尝试性、不确定编码的开发思想，采用以最快速度、 勇气 充满信心进行开发的做法。 建立在x p 核心价值观之上的是5 项指导软件开发的主要原则【3 】： 1 快速反馈。快速反馈是开发人员通过简短的反馈循环迅速了解其当前产品是否 满足了客户的需求。 2 简单性假设。每一个问题都视为很容易解决。这意味着只需要当前迭代打算， 而无需洞察未来可能需要什么。 3 逐步修改。通过一些列的修改来解决问题。 4 拥抱变化。采用保留选项，同时解决紧迫问题的策略。 5 高质量的工作。工作质量决不可打折扣。x p 采用测试先行的编程方式，强调编 码和测试的重要性。 2 2 2x p 项目需求分析 传统需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终 在验证的基础上冻结需求【2 2 1 。而敏捷开发方法更注重口头上的沟通交流来获取需求， 敏捷需求以更好的处理方式来指导系统的开发，在开发的过程中，能够让开发人员步 步为营，踏实的去做好自己的工作，以更好的协作方式来共同完成系统的开发目标。 x p 从始至终都在贯彻密切合作交流的主旨。在开发的过程中有现场客户在场，以 便与开发人员进行面对面的交流；在团队的开发过程中客户和开发人员在一个大的房 间中一同工作【l9 1 ，这些都是为了更好的沟通合作。x p 主张开发过程中有现场客户驻留， 参与开发人员的开发中来，以方便开发小组与客户之间进行需求方便的交流沟通。但 在实际项目中，无法做到这一点，不能时常进行面对面的沟通，但我们可以采用邮件， 传真，电话等多种联系方式，同样达到沟通的目标。可是有些时候利用这些交流手段 进行沟通也是比较费时费力，这就意味着，开发人员可能要承担更多的工作任务，毕 西南交通大学硕士研究生学位论文第8 页 竟一切都要以服务客户为主。 x p 以用户故事的方式描述客户需求，考虑到需求的演进过程，不要求客户预先明 确地定义需求。客户同开发小组谈论其需求，并将用户故事作为起点。需求将随开发 人员对业务域的深入了解以及客户对可能性和受到的约束的认识而演变。通过场景来 进行用户故事的获取，场景能突出表现客户的功能需求意图。场景由开发人员进行编 写，如果客户愿意，也可以进行编写。在与客户进行尽可能详细的沟通后，填写故事 单。一个故事单通常有以下一些元素组成：场景编号，人物，故事故事概述，备注， 编写者，编写时间，时间估算。在编写的过程中可以灵活的去添加一些元素进去，完 成更详备的场景细节。事件是场景核心元素，它是描述事件及其发展，也是在迭代过 程中要开发的业务或者功能项，可以粗略的进行书写，也可以进行细致的描述，即对 场景进行事件分割，如事件一，事件二等，进行更详细的功能项的描述。一个场景所 描述的用户故事如果过于复杂，那么有必要把这个场景进行分割。分割的依据一般来 说，以小型发布所需要的时间、规模为据【9 】。这些都由项目组跟客户的需求交流的细致 程度来决定，这也是一个逐步演化的过程。 基于场景的分析方法有利于在开发顺序上的编排，即最初的场景编号并不是最后 的编号顺序，随着需求的调整变化，保持场景编号的重新编排，从而确定新的任务优 先级，调整迭代开发任务。在获取用户需求后，先编写场景事件，然后根据需求的优 先级别来进行事件场景的顺序编号编排，进而进行迭代任务的统筹分配。在开发的过 程中，优先实现级别高的场景，在迭代周期内允许按着优先级别在开发顺序中插入新 的场景或剔除已存在的场景。基于场景分析需求变更过程如图2 1 所示： 0 r 墨 器 一 毯 m t i m efd a y h o u r ) 图2 - 基于场景分析需求变更过程 西南交通大学硕士研究生学位论文第9 页 在x p 的需求过程中，不排斥使用用例的需求分析手段，虽然采用场景的分析方法 来获取用户故事能够保证绝大多数开发业务能够被开发人员熟知，但同样需要一种辅 助手段来帮组软件开发过程中的理解沟通。用例图、活动图和序列图等各种模型不失 为好的辅助手段，但同样主张在运用的过程中要简单，易于理解交流的原则，创建刚 好够用的模型来协助理解和沟通。 2 2 3x p 项目的开发 需求决定设计，需求的变更必然导致设计的不确定，如何进行系统设计是实施敏 捷软件开发必须面对的问题。传统开发方法主张采用预先设计( p l a n n e dd e s i g n ) 的方式， 希望通过前期的投入来降低未来的投入，但在现实中，由于需求的不确定性，设计也 不可能一蹴而就【l0 1 。x p 主张演化设计( e v o l u t i o n a r yd e s i g n ) 或迭代设计，认为好的设计 是通过多次演化而来的。即不做大型的预先设计，快速进入编码阶段，然后通过重构 来持续改进设计。它强调代码对软件的重要性，并通过一些技巧来解决缺乏设计的问 题，但是一定程度上的预先设计是必须的，因为重构也需要代价( 不能从一个设计轻 松重构到另一个设计) ，避免后期增加需求导致开发成本的急剧上升，这是迭代开发的 必要前提，所以敏捷软件开发也需要架构设计。 x p 主张简单设计，简单的意义就是不要把未来的、或不需要实现的功能加入到目 前的软件中，相应的架构设计也不需要考虑这些额外的需求，只要刚好能够满足当前 的需求就好，从而避免因预测失准而造成浪费。 在软件开发初期应该从客户主要的、高风险的、具有架构意义的需求入手进行架 构设计。其中系统结构穿刺只是在必要的情况下进行，毕竟穿刺时需要付出时间上的 代价。首次迭代的架构是后续设计、编码过程中依赖的基础，但是，改进架构设计的 问题依然存在。x p 主张“团队设计”，即所有团队成员都参与设计，这种方式减少沟 通成本，增加了团队应对变化的敏捷性。团队一起制定高级别的设计，子系统的设计 可能由几个人共同完成，更细的设计可能由某个程序员负责。在设计改进中，如果要 改变子系统的接口，需要整个团队的同意。这种情况下，迭代设计是在控制之下进行， 每一次改进都朝着一个稳定的目标在前进，从而避免迭代设计退化成边写边改模式。 经验证明：把本该解决的问题拖后是造成这一问题的主要原因。因此，要严格的对待 每次的迭代，即使要做较大的改动，也要有勇气对设计进行无情的重构、确保软件 的质量，满足用户的需求。 敏捷开发强调及时反馈，无论是人层面，还是技术层面。在开发中，测试、设计 和编码交替进行。迭代周期要尽可能的短，完成一个小的功能模块，可以快速测试、 并及时展现给客户，以便及时获取客户的反馈。 x p 开发流程如图2 2 所示1 2 2 】： 西南交通大学硕士研究生学位论文第1 0 页 旧象丕蠢麓 i 用户故褰 、 故事 b n 然 述厶一盏主 l 结构穿刺l | 版本趣娥h 迭代l | 验收测试 _ i 小型发布l j 准确的 不猴确 的评估评估 下次迭代开发 r iv ；v ，z 穿裁 2 3x p 实践模型 图2 2 x p 开发流程图 最近随着软件技术的不断发展，开发模型也在不断的进行变化，由最开始的瀑布 模型，演化模型等向更适应需求变化的改进型瀑布模型，r u p 模型等转变。从重型的 r u p 统一过程模型向轻量级的特征驱动开发模型，x p 极限模型等转变。在所有的敏捷 方法中，x p 方法是最为著名的一种轻型开发方法。它不仅适应变革，而且拥抱变革， 同时留意保持代码的质量【1 5 】。其核心思想是交流、简单、反馈和勇气，将开发阶段的4 个活动( 分析、设计、编码和测试) 混合在一起，在全过程中采用迭代增量开发、反 馈修正和反复测试。消除了大多数重量型方法的不必要产物，建立了一个渐进的开发 过程。x p 是由一系列简单却互相依赖的实践组成。x p 的实践如下【1 2 】： 1 完整团队：x p 项目的所有参与者( 开发人员、客户、测试人员等) 一起工作在 一个开放的场所中，他们是同一个团队的成员。 2 计划游戏：计划是持续的、循序渐进的。每2 周，开发人员就为下2 周估算候 选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。计划游戏容易产 生误解，所以本文把它表述为“自适应计划”。 3 简单设计：团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试， 不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。 4 结对编程：所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上 构建的。 5 测试驱动开发：编写单元测试是一个验证行为，更是一个设计行为。同样，它 更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验 证方面的反馈循环。 6 重构：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有 表达力。 7 持续集成：团队总是使系统完整地被集成。一个人拆x ( c h e c ki n ) 后，其它所有 西南交通大学硕士研究生学位论文第1 1 页 人责任代码集成。 8 集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码。没有程 序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。 9 编码标准：系统中所有的代码看起来就好像是被单独一人编写的。 1 0 隐喻：将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所 有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就 知道该模块是错误的。 1 1 可持续的速度：团队只有持久才能获胜。他们以能够长期维持的速度努力工作， 他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。 1 2 小型发布：整个软件开发活动被划分成一系列短的迭代过程。每个迭代完成一 定数目的功能，产出一个经过验证的可用产品。 这1 2 个实践构成了x p 团队的指导原则，但是受于现实条件的限制，并不是每个 实践都能实现和有效，为加强敏捷软件开发的可操作性，有必要对敏捷开发实践进行 调整或寻找更好的替代方案。 x p 把需求的获取、表示和验证变得更简单和快捷，因为有现场客户的存在，开发 人员可以和客户直接的交流来获取需求。但是，在现实的项目中现场客户很难实现， 毕竟客户有自己的工作任务，很难驻留开发现场和我们一起工作。解决这些问题的最 实用方法是在团队中设置业务分析师，由其负责与客户的沟通，需求的调研与讨论， 并负责业务规则和流程的制定，参与系统架构的设计。业务分析师是联系开发人员和 客户的桥梁，开发人员快速开发出来，业务分析师代替客户负责功能验收测试，快速 验证需求。这样就大大提升了实际开发中的可行性。 敏捷软件开发也需要高层设计。在这之前，首先要考虑软件设计的目的，其目的 是控制软件复杂性。在这方面“以架构为中心的开发方法”为我们提供了指导。先确 定软件架构，而后基于软件架构进行并行开发的做法，利于控制复杂性，提高开发效 率。架构设计具体要做到什么程度还要考虑到团队的能力，在项目中的重要性等因素。 总之前期设计应当为开发人员提供足够的指导和限制。 结队编程要求两个程序员一起编程，代码由两个人共同维护，这种方式在一定程 度上能提高代码质量并缓解人员流动的风险，同时还可以促进开发人员的交流学习。 所谓重构( r e f a c t o r i n g ) 是这样一个过程：在不改变代码外在行为的前提下，对代码 做出修改，以改进代码的内部结构，使得代码更易维护【1 7 】 【1 8 】。重构的时机很多，可以 是在给软件添加新功能时，也可以是在调试修补错误时，还可以是在复审代码时重构【7 】。 集体代码所有权是为了加强交流，避免出现一段代码只有一个人了解的情况，但 也存在问题，不同人修改代码要比单人修改代码更容易导致代码质量的下降，引起代 码混乱。更严重的问题是代码集体所有可能会变成代码无人负责，所以集体代码所有 西南交通大学硕士研究生学位论文第1 2 贾 可】三【采用折中策略，同一段代码先由几个人负责，逐步实现代码集体所有。 测试驱动开发、重构、持续集成和统一的编码标准都是被证明了的有效的开发实 践，在开发过程中应当严格执行。 根据x p 的软件开发过程以及所获取的基本资料，制定整个软件开发的流程。其 中系统基础架构的确立时关键，然后制定发行版计划，它以场景获取需求为基础。计 划分几次迭代开发，运步实现客户的功能需求，也即系统业务逻辑的划分，每一次迭 代开发都是在上一次基础上再进行功能需求的扩充和完善，完成系统框架的搭建到业 务的开发，再到测试的完成，并且在整个开发实施过程中，项目组简单制定了一些基 本的编码规则和文档规范。根据项目组各个成员开发角色，我们制定了如下的项目开 发实施过程，如图2 3 所示： r jo ”“*一慢 ， h t 。： 4 * t + r ”t r “) 彳孓、 雾l y 鑫：捻 q 3 j 。、 y l 雾鬏 2 4 敏捷规划 圈2 - 3i 勇目开发具体实施过程 无论一个软件开发项目的规模和重要性如何，估计和规划对它的成功都是至关重 要的m 】。规划可以帮助项目组交付用户需要和期望的功能。好的规划过程通常能为软 件项目带来以下价值：减少风险、降低不确定性、提供更好的的决策支持、建立信任 及传递信息。在实际的开发过程中，我们通常更注重两个方面的规划：迭代规划和发 布规划。 西南交通大学硕士研究生学位论文第13 页 2 4 1 迭代规划 好的规划过程通过以下活动来支持这种对价值的探求【9 】：减少风险；减低不确 定性；提供更好的决策支持；建立信任；传递信息。敏捷开发过程也是“规划 一执行一调整”的过程，一个项目的不确定性越高，敏捷开发方法对取得成功就越是至 关重要。 迭代开发是团队工作的重中之重。迭代开发的目标是允许团队及早并经常性地从 相关人员( 客户、产品所有者和其他人) 处获得反馈。这允许团队为下一个发行版安排早 期的调研( 也称为架构研究) 、原型化或用户描述创建。在实际进行发行版的“正式”迭 代开发之前，执行上面这些工作可以帮助您及早发现风险并在需要时制定迁移计划。 为了很好地把握项目开发的进程，在依据x p 实践模型和项目开发流程的基础上， 制定了一定的迭代进度控制计划。图2 4 所示为迭代开发项目进度模型图，该图只是 突出展示了前五次迭代的进度情况，随着在后续软件项目的进展，需求情况的变化及 系统用户满意的程度，项目组会进行增加迭代次数，直至系统彻底交付使用。 财同 图2 _ 4 迭代开发项目进度模型图 常见的迭代开发的时间长度为两到四周( 有时长达6 周) 。时间较短的迭代开发往 往更容易进行规划，因为快速的修改意味着一定的紧急性。较长时间的迭代开发容易 让人误认为有大量时间可供使用，更容易产生问题。 敏捷开发模式是拥抱变化的，计划的制定只是便于我们对于系统进行更好地管理 与控制，使得系统的开发过程尽可能地朝着计划进行。计划不可能是一层不变的，需 求的变动性也带到了项目计划的变动性，因此，在实际开发过程中，我们并不排斥计 划的变更，并且对于变化持有欢迎的态度，这也是敏捷开发一直都倡导的理念。 西南交通大学硕士研究生学位论文第14 页 2 4 2 发布规划 发布规划是对整个产品发布过程的展望，通常是从新项目启动开始3 - 6 个月的时 间【9 】。发布规划是建立在高层次的，覆盖超过一次迭代周期长度的计划的过程。 在发行版的早期，产品所有者将查看产品计划安排并确定将被包含到下一个发行 版的用户描述。这些内容随后被移动到发行版计划安排中。通常，在这个时候会出现 一些来自各方面的压力。开发团队必须与产品所有者紧密合作，确保已确定的内容适 合发行版的大小和发行期限。在发行期间，跟踪团队的开发进度将能够使您更清晰地 了解最终将要实现的工作量。 在创建发行版计划安排时，将任何高级用户描述分解为多个更小的用户描述。在 执行这项任务时，考虑组建一个客户团队，成员包括产品经理、测试人员、实际用户 和交互设计师。 发行版计划安排具有动态特性，但是一旦开始了迭代开发后，产品所有者就不能 再修改已经为迭代开发选定的工作了。在开始这些工作后，如果团队获取的知识表明 某些内容并不适合发行版或迭代开发，那么这就另当别论了。在迭代开发期间，开发 团队必须能够关注他们的可交付任务。 2 5 本章小结 本章介绍了敏捷革命的发起和敏捷宣言的具体内容，其次详细介绍了敏捷方法价 值观。然后着重分析极限编程方法，对x p 方法的三个方面：核心观念及指导原则开始， x p 项目需求