（计算机应用技术专业论文）敏捷开发方法在长治医学院mis中的研究与应用.pdf

摘要 传统软件开发方法试图在长时间跨度内对一个软件开发项目制定出详尽的计 划，然后严格按照计划进行软件开发。这类方法在计划制定结束后拒绝变化，因 此它不太适应于需求快速变化的情形，并且大量的早期文档在开发过程结束后变 得毫无价值，有些甚至在开发过程中就己毫无意义，这些文档就像枷锁一样注定 了该方法“滞重 ( m o n u m e n t a l ) 的特性。为解决快速开发系统、适应需求变化、 确保质量并控制成本的问题，敏捷开发方法应运而生。 敏捷开发方法是适配性而非预测性，是面向人的而非面向过程，具有短周期 小增量发布的特性，强调经常性交付可以工作的软件，因此也能更快速地获取用 户的反馈信息，缩短校正开发方向的时间；可以提高有效代码的产出率；可以让 开发人员更有效地利用时间进行开发工作；可以节约成本。 本文首先从敏捷开发方法的出现谈起，介绍了敏捷宣言及原则和几种典型的 敏捷开发方法，重点介绍了极限编程方法和s c r u m 方法，并从c m m 角度分析了 极限编程方法，最后得出结论，极限编程与c m m 不是对立的，而是互相补充的， 而且极限编程更适合需求变化的小型项目。在了解了敏捷开发方法后，转向敏捷 开发方法已成必然。所以作者采用极限编程并结合s e r u m 方法进行长治医学院学 生信息管理系统的开发，根据x p 的生命周期，首先进行项目规划和用户故事的整 理，根据用户故事统计数确定迭代周期，并打破传统的任务分配方式，按照用户 故事进行任务分配，并以第一个迭代周期为例，介绍了极限编程的实践方法在迭 代开发过程中的应用，包括编码标准、测试驱动、结对编程、集体代码所有权、 持续集成以及小型发布。极限编程方法在系统开发中的实施是本文的重点。 敏捷开发方法在本系统开发中的成功实施证明了敏捷开发方法在小型项目中 应用的合理性和有效性，通过实践我们也总结出敏捷开发方法的实施中应该把握 其实质，不能生搬硬套，应该灵活运用，选择适合自己开发团队的实践方法，使 项目获得最大的成功。 关键词：敏捷；极限编程；s c r u m ；c m m 分类号：t p 3 9 3 a b s t r a c t t r a d i t i o n a ls o f t w a r ed e v e l o p m e n tm e t h o d ss p e n dl o n gt i m et om a k ead e t a i l e d p r o j e c tp l a n ，a n dt h e ns t r i c t l yi na c c o r d a n c ew i t ht h ep l a nd u r i n gt h ed e v e l o p m e n t s o t h e ya r en o ta d a p t e dt ot h en e e d so ft h er a p i d l yc h a n g i n gc i r c u m s t a n c e s ，a n dal a r g e n u m b e ro fd o c u m e n t se a r l yi nt h ed e v e l o p m e n tp r o c e s sb e c o m ew o r t h l e s sa tt h ee n d s o t h et r a d i t i o n a ls o f t w a r e d e v e l o p m e n tm e t h o d sa r em o n u m e n t a l 姆l ed e v e l o p m e n t m e t h o d sh a v ee m e r g e dt oa d d r e s st h er a p i dd e v e l o p m e n to fs y s t e m s ，a d a p tt oc h a n g e si n d e m a n d ，a n de n s u r eq u a l i t ya n dc o s tc o n t r o li s s u e s a g i l ed e v e l o p m e n t i sn o t p r e d i c t a b l e i t i s p e o p l e - o r i e n t e d r a t h e rt h a n p r o c e s s o r i e n t e d , w i t has h o r tc y c l eo ft h es m a l li n c r e m e n t a lr e l e a s e i ts t r e s s e st h a t r e g u l a rd e l i v e r yo ft h es o f t w a r ea n d ，t h e r e f o r e ，m o r er a p i da c c e s st ou s e rf e e d b a c k i n f o r m a t i o n ，s h o r t e nt h ec o r r e c t i o nt i m ea n di n c r e a s e dt h eo u t p u tr a t eo fe f f e c t i v ec o d e t h i sp a p e ri n t r o d u c e sa g i l ep r i n c i p l e sa n ds e v e r a lt y p i c a la g i l ed e v e l o p m e n t m e t h o d s ，f o c u s i n go nt h ee x t r e m ep r o g r a m m i n ga n ds e r u m t h r o u g ha n a l y s i sf r o mt h e p e r s p e c t i v eo fc m m ，w em a k ea c o n c l u s i o nt h a te x t r e m ep r o g r a m m i n ga n dc m ma r e n o ta n t a g o n i s t i c , b u tc o m p l e m e n t a r y a n de x t r e m ep r o g r a m m i n gi sm o r es u i t a b l ef o r t h es m a l l - s c a l ep r o j e c t s t h e r e f o r e ，w eu s e de x t r e m ep r o g r a m m i n ga n ds e r u mm e t h o d f o rt h e c h a n g z h im e d i c i n ec o l l e g e s t u d e n ti n f o r m a t i o n s y s t e md e v e l o p m e n t a c c o r d i n gt ot h el i f ec y c l eo fx p ，a tf i r s tw e d i dt h ep r o j e c tp l a n n i n ga n dc o l l e c t e du s e r s t o r i e s ，t h e nm a d et h ei t e r a t i o nc y c l eb a s e do nt h eq u a n t i t yo ft h eu s e rs t o r ya n da l s o u s e du s e rs t o r ya st h eu n i to ft h et a s kd i s t r i b u t i o n a n dn e x tt h ep a p e rt a k e st h ef n - s t i t e r a t i o na st h ee x a m p l et oi n t r o d u c et h ei m p l e m e n to fx pd e v e l o p m e n tm e t h o di nt h e s y s t e md e v e l o p m e n t t h ed e t a i lp r a c t i c a lm e t h o d sw h i c hw e r er e f e r r e di n c l u d ec o d i n g s t a n d a r d s ，t e s t i n gi nd r i v e r , p a i rp r o g r a m m i n ga n ds oo n t h ef o c u so ft h ep a p e r i st h e i m p l e m e n t a t i o no fe x t r e m ep r o g r a m m i n gm e t h o d si nt h es y s t e m sd e v e l o p m e n t t h r o u g hp r a c t i c e ，w ec o n c l u d e t h a tt h ei m p l e m e n t a t i o no fa g i l ed e v e l o p m e n t m e t h o d ss h o u l dg r a s pt h e i re s s e n c e i ts h o u l db ef l e x i b l eu s e d a n dw es h o u l dc h o o s e t h er i g h tp r a c t i c em e t h o dw h i c hi sf i tf o rt h ed e v e l o p m e n tt e a mb e s t k e y w o r d s ：a g i l e ；e x t r e m ep r o g r a m m i n g ；s e r u m ；c m m c l a s s n o ：t p 3 9 3 学位论文版权使用授权书 本学位论文作者完全了解北京交通大学有关保留、使用学位论文的规定。特 授权北京交通大学可以将学位论文的全部或部分内容编入有关数据库进行检索， 并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国 家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名： 签字日期：仞邱年 门袭饧 其6b 导师签名： 签字日期：刀p g 年月e l 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的研 究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表或 撰写过的研究成果，也不包含为获得北京交通大学或其他教育机构的学位或证书 而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作 了明确的说明并表示了谢意。 学雠姗糍轹f 锄替醐： 5 3 石月石日 致谢 一转眼到了毕业的时间，在这两年的研究生的时间里，我收获很多。这些收 获和一直关心我，帮助我的人是分不开的，是他们陪伴我渡过了这段美好难忘的 时光。这段岁月必是我人生道路中最宝贵的回忆之一。 本论文的工作是在我的导师罗四维教授的悉心指导下完成的，罗四维教授严 谨的治学态度和科学的工作方法给了我极大的帮助和影响。在此衷心感谢两年来 罗四维老师对我的关心和指导。 谨向恩师致以最诚挚的感激和最由衷的敬意! 在此也特别感谢实验室的同学们给予的各种支持与帮助，他们和我一起渡过 了研究生的这段时光，是他们让我感受到了这个世界的朝气蓬勃，充满希望以及 求实园的求是精神。在他们的身上我学到了很多，在相互交流中，我们都有了很 大的进步。借此机会祝愿全体老师和同学在事业和学习上取得更大的进步。 最后，将深深感谢对我寄予厚望的父母亲人，是他们的无私的支持和关怀给 了我前进的动力1 2 1 绪论 1 1研究背景 一、缓解软件危机的需要 在六十年代末北约组织了一次软件工程学的大会，他们在会议上提出了“软 件危机这个概念。当时大家的印象，软件已经变得如此的复杂，以至于不能以 十分有效的方式来管理。这次会议之后就提出了一种更加有纪律性的软件开发的 方法。这个会议提出的名词就叫“软件工程学。这个概念背后的核心就是从传 统的工程学里面借鉴一些概念，把它应用到软件开发过程当中来。这个概念背后 随之而来的是很多软件开发方面的方法和过程。这些方法至少在七十年代、八十 年代、九十年代变成了大家全部使用的软件开发方法。但是，也是在这段时间， 很多的软件从业人员开始怀疑工程学为基础的方法到底适不适合软件开发。有很 多非常成功的软件项目，并没有完全真正的按照软件工程学的方法来进行开发。 与此同时，很多非常失败的软件项目确实是按照这种方法来进行的。大概在九十 年代开始，我们看到很多人开始使用其他一些不同的方法来开发软件，比较有名 的方法包括极限编程、s e r u m 、c r y s t a l 、f d d 等等。虽然这些方法由不同的入、不 同的项目来开始开发实施，但是他们之间有很多非常相似的地方。敏捷开发这个 概念就是用来描述这一系列比较新的软件开发方法的窿1 。 传统软件开发方法试图在长时间跨度内对一个软件开发项目制定出详尽的计 划，然后严格按照计划进行软件开发。这类方法在计划制定结束后拒绝变化，因 此它不太适应于需求快速变化的情形，并且大量的早期文档在开发过程结束后变 得毫无价值，有些甚至在开发过程中就己毫无意义，这些文档就像枷锁一样注定 了该方法“滞重 ( m o n u m e n t a l ) 的特性。 敏捷开发方法是适配性而非预测性的，是面向人的而非面向过程，具有短周 期小增量发布的特性。采用敏捷开发方法的开发团队能从客户那里迅速得到反馈 信息，可以及时修正自己的开发路线，朝着胜利的终点一步步逼近。敏捷开发方 法的成功项目案例越来越多，有应用于中小型项目的( 如c 3 薪金系统p j ，o r c a 安 全事件响应系统【4 l 等) ，也有应用于大型项目的( 如a t l a s 租赁系统【5 1 ，i d x 的福利系 统【6 】等) 。有些院校甚至将敏捷开发方法纳入到了软件工程的授课内容，如卡尔加 里大学( u n i v e r s i t yo fc a l g a r y ) 署1 1 南艾尔伯塔理工学院( s o u t h e r na l b e r t ai n s t i t u t eo f t e c h n o l o g y ) 7 1 。 ：二、高校信息化的需要 随着高校规模的扩大和业务的扩展，传统的管理模式和手段己经远远不能适应 新的发展需要。主要体现在：n ， 1 易于出错，效率较低 在管理工作中，大部分采用手工填表，这种方式的可靠性不高，因为手工填 表一不小心就会造成数据遗漏，而且手工处理工作量极大，效率低下，进行数据 的维护和检索都非常的不便，不能满足日常的管理工作的要求。 2 数据更新不够及时 以前由于没有采用w e b 结构的网络传送方式，所以在数据的更新上，仍采用 各系部或各班级将数据上报，并由专门的数据录入人员进行手工录入。这种方式 不仅加大了学生信息管理的工作量，而且很容易遗漏信息，并且造成信息的更新 不及时。 3 信息管理规范性不够 由于没有一个完善的系统，学生的相关信息的数据库不够完善，使得对学生 的信息管理上，缺乏规范性。数据分散存放，数据之间没有相应的约束与关联， 在进行数据维护的时候，必须同时更新所有部门的相关数据，非常繁琐，稍不注 意就会引起数据的不一致，很难实现数据的共享。 随着计算机网络和i n t e r n e t 的普及，学生工作管理信息系统应运而生，它是辅 助学校院学生工作部门进行学生工作的得力助手，是以学生基本信息为主体、以 高时效和高质量服务为准则的高校学生工作管理信息系统。通过信息化的手段来 强化学生工作，增强学校对学生情况的掌控，根据学生的实际情况为之提供有针 对性的个性化的管理和服务，既提高了学校培养学生的质量，也提升学校学生工 作的管理水平。学生工作管理系统对于提升学校的学生工作管理水平，增强学校 的影响力，培养高质量的优秀毕业生，构建和谐的校园环境都具有重要的意义。 在信息化的浪潮席卷社会各行各业之际，利用信息化的手段改进和增强管理方式， 提升管理水平，提高管理效率、降低管理成本既符合学校实际情况，又具有现实 可行性和实用性。 1 2 研究内容与目标 认识到高校管理学生信息的网络化在整个高校信息化过程中的重要地位，为 推动长治医学院的校园信息化建设，开发长治医学院学生信息管理系统。软件项 目的最大挑战在于一方面要应付变动中的需求，一方面要在紧缩的时程内完成项 目，所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以 确保团队能够发挥综效。这正是a g i l ep r o c e s s ( 敏捷的软件开发流程) 于近年来兴起 的主要原因。由于长治医学院校园信息化水平的限制，并没有明确的需求提出， 只能仿照本校学生信息管理的流程进行系统的初步设计，所以用户的需求是不确 定，在软件进行了第一阶段的交付时，很可能发生大的需求变动。所以本文主要 研究如何将敏捷开发方法应用到长治医学院学生管理信息系统的开发实践中，并 在实践中摸索出适合自己开发团队的方法。 1 3论文结构 全文共分六章，安排如下： 第一章绪论介绍了本论文的研究背景、研究内容与目标。 第二章敏捷开发概述了敏捷开发方法的出现、敏捷宣言与原则以及几种典 型的敏捷开发方法。重点讨论了极限编程方法和s c r u m 方法，包括 极限编程的四个价值观、十二种实践方法和极限编程生命周期； s c r u m 方法的开发流程、信息交流方式等。 第三章极限编程与c m m 从c m m 角度看极限编程，讨论了c m m 的五种级 别和极限编程中“极限”的表现，并对极限编程与c m m 2 级和c m m 3 级作了详细的比较，最后得出结论，极限编程与c m m 不是对立的， 而是互相补充的。 第四章实践系统概况介绍了长治医学院学生管理系统的项目背景、总体目 标与原则、系统架构和初步的功能需求以及系统的开发环境和开发 中的相关技术。 第五章基于敏捷开发方法的学生信息管理系统的规划设计与实现从任务分 解、人员角色安排和开发进度安排方面对项目进行整体规划，并以 一个迭代周期为例，描述了敏捷开发方法在系统开发中的应用实践 过程，如用户故事获取、简单设计与任务分配、结对编程、持续集 成、小型发布等，并对敏捷开发方法的实践进行小结。 第六章总结与展望总结敏捷开发方法的优点与局限性，得出结论应该根据 具体情况在敏捷与不敏捷之间找到平衡点，并对敏捷方法应用前景 作出展望。 3 2 敏捷开发 2 1敏捷开发概述 2 1 1 敏捷方法的出现 自2 0 世纪9 0 年代，为解决快速开发系统、适应需求变化、确保质量并控制 成本的问题，涌现出一些轻量级的软件开发方法。敏捷软件开发不是一个具体的 过程，而是一个涵盖性术语，用于概括具有类似基础的方式和方法，如x p 、d s d m 、 s c r u m 和c r y s t a l 等，都着眼于快速交付高质量的工作软件，并做到客户满意。 2 1 2 敏捷宣言与原则 2 0 0 1 年初，一些软件开发方法专家聚集在美国犹他州的滑雪胜地s n o w b i r d 的 一幢大楼中，一起交谈、讨论、寻找共同话题。通过交谈，1 7 名与会代表签署了 一份价值观声明，即“敏捷开发宣言( t h em a n i f e s t o f o ra g i l es o f t w a r e d e v e l o p m e n t ) 1 8 1 ，内容如下i l o l ： 1 个体和交互胜过过程和工具 人是软件项目获得成功最为重要的因素，如果项目团队中没有优秀的成员， 那么使用再好的过程和工具也不能从失败中挽救项目。团队的合作、沟通以及交 互能力要比单纯的软件编程能力更为重要。合适的工具对于成功来说非常重要， 但是，工具的作用不可被过分地夸大，使用过多庞大、笨重的工具同缺少工具一 样，都是不好的。简而言之，敏捷方法认为团队的构建要比项目环境的构建重要 的多。 2 可以工作的软件胜过面面俱到的文档 软件开发的主要目标是交付给用户可以工作的软件而不是文档，否则就称之 为文档开发而不是软件开发。编制众多的文档需要花费大量的时间，并且要使这 些文档与代码保持同步就会花费更多的时间，导致进度拖延。如果文档和代码之 间失去同步，那么庞大的文档就会造成重大的误导。所以敏捷方法建议软件开发 的中心活动要集中在创建可以工作的软件，直到迫切需要并且意义重大时，才进 行文档编制。编制的内部文档应该尽量短小并且主题突出。 3 客户合作胜过合同谈判 4 为了全方位地满足客户不断变化的需求，切实可行的途径就是开发团队与客 户紧密协作，而那些为开发团队和客户的协同工作方式提供指导的合同才是最好 的合同。 4 响应变化胜过遵循计划 变化是软件开发中存在的现实，一个软件过程必须反映现实，有足够的能力 及时响应变化。没有计划的项目必然会失败，所以制定的计划必须有足够的灵活 性和可塑性，在形势发生变化时能够迅速调整，以适应商务和技术方面发生的变 化。 敏捷联盟的成员把他们宣言中表达的基本原理精练为1 2 条原则，敏捷软件开 发方法必须遵循这些原则【1 0 l ： 1 最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 以逐渐增加功能的方式经常性地交付系统和最终质量之间有非常强的相关 性，表现为交付得越频繁，最终的产品质量就越高。敏捷过程会尽早地、经常地 进行交付，该过程努力在项目刚开始的几周内就交付一个具有基本功能的系统， 然后努力坚持每两周就交付一个功能渐增的系统。 2 即使到了开发后期也欢迎改变需求，敏捷过程利用变化来为客户创造竞争 优势。 敏捷过程的参与者不惧怕变化，敏捷团队会非常努力保持合同、计划、软件 结构以及其它方面的灵活性，这些灵活性保证了变化对于系统造成的影响是最小 的。 3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交 付的间隔越短越好。 4 在整个项目开发期间，客户和开发人员必须天天都工作在一起。 为了能够以敏捷的方式全方位满足客户可能不断变化的需求，客户、开发人 员就必须要进行有意义的、频繁的交互，持续不断地引入反馈。 5 围绕被激励起来的个体来构建项目，给他们提供所需的环境和支持。 在敏捷过程中，人被认为是项目取得成功的最重要因素，所有其它因素包括 过程、环境和管理等，都被认为是次要的，并且当它们对人有负面影响时，就要 对它们进行改变。 6 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交 谈。 在敏捷过程中，人们之间首要和默认的沟通方式就是交谈。也许会编写文档， 但是只有这些文档是迫切需要且意义重大时才会去编写，并且不会试图在文档中 包含所有的项目信息。 5 7 工作的软件是首要的进度度量标准。 敏捷过程通过度量当前软件满足客户需求的数量来度量开发进度，而不是根 据所处的开发阶段、已经编写的文档的多少或者已经创建的基础设施、代码的数 量来度量开发进度的。 8 敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够保持一 个长期的、恒定的开发速度。 敏捷团队不是以全速启动并试图在项目开发期间维持那个速度，相反，他们 以较快但是可持续的速度行进，跑地过快会导致团队过度疲惫以致崩溃。敏捷团 队工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。 9 不断地关注优秀的设计会增强敏捷能力。 保持软件尽可能的清洁是快速开发软件的保证，因而敏捷团队的所有成员都 致力于只编写他们能够编写的最高质量的代码。 1 0 简单是最根本的。 敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标 一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今 天就对那些问题进行预防。相反，他们在今天以最高质量完成最简单的工作，深 信如果在明天发生了问题，也会很容易进行处理。 1 1 最后的架构、需求和设计出自于有组织的团队。 敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目 中所有方面的参与权力，不存在单一的团队成员对系统架构、需求或者测试负责 的情况，整个团队共同承担这些职责，每一个团队成员都能够影响它们。 1 2 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相 应地对自己的行为进行调整。 敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷 团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必 须随环境一起变化。 以上1 2 条原则是敏捷软件开发方法的一些常识性的基础原则，可以把成功的 软件开发建立在这个基础之上。 2 1 3 典型的敏捷开发方法 近年来发展起来的典型的敏捷方法有很多，例如x p ( e x t r e m ep r o g r a m m i n g ) ， 功能驱动程序设计( f d d ) ，s e r u m ，c r y s t a l ，a s d ( a d a p t i v es o f t w a r ed e v e l o p m e n t ) 等啪1 。这些方法在各自一定的领域内发挥重要作用，但是并非对所有项目都适用。 6 敏捷开发包括一系列的方法，主流的有如下七种阻1 ： 一、极限编程( ) 极限编程( x p ) 的思想源自k e n tb e c k 和w a r dc u n n i n g h a m 在软件项目中的 合作经历。x p 注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上 变化，x p 无需开发人员在软件开始初期做出很多的文档。x p 提倡测试先行，是为 了将以后出现b u g 的几率降到最低。 二、s c r u m s c r a m 是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集 合各种开发实践的经验化过程框架。s c r a m 中发布产品的重要性高于一切。该方法 由k e ns c h w a b e r 和j e f fs u t h e r l a n d 提出，旨在寻求充分发挥面向对象和构件技术 的开发方法，是对迭代式面向对象方法的改进。 三、c r y s t a lm e t h o d s c r y s t a lm e t h o d s ( 水晶方法族) 由a l i s t a i rc o c k b u m 在2 0 实际9 0 年代末提出。 之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列 不如x p 那样的产出效率，但会有更多的人能够接受并遵循它。 四、f d d f d d ( f e a t u r e d r i v e nd e v e l o p m e n t ，特性驱动开发) 由p e t e rc o a d 、j e f fd e l u c a 、e r i cl e f e b v r e 共同开发，是一套针对中小型软件开发项目的开发模式。此 外，f d d 是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被 开发团队接受，适用于需求经常变动的项目。 五、a s d a s d ( a d a p t i v es o f t w a r ed e v e l o p m e n t ，自适应软件开发) 由j i mh i g h s m i t h 在 1 9 9 9 年正式提出。a s d 强调开发方法的适应性( a d a p t i v e ) ，这一思想来源于复 杂系统的混沌理论。a s d 不象其他方法那样有很多具体的实践做法，它更侧重为 a s d 的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为 什么要具备适应性。 六、d s d m d s d m ( 动态系统开发方法) 是众多敏捷开发方法中的一种，它倡导以业务为 核心，快速而有效地进行系统开发。实践证明d s d m 是成功的敏捷开发方法之一。 在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速 应用开发方法。d s d m 不但遵循了敏捷方法的原理，而且也适合那些成熟的传统 开发方法有坚实基础的软件组织。 七、轻量型r u p r u p 其实是个过程的框架，它可以包容许多不同类型的过程，c r a i g l a r m a n 极 7 力主张以敏捷型方式来使用r u p 。他的观点是：目前如此众多的努力以推进敏捷型 方法，只不过是在接受能被视为r u p 的主流o o 开发方法而已。 2 2极限编程 极限编程最早由s m a l l t a l k 社群中的大师级人物k e n tb e c k 于1 9 9 8 年倡导，它 是一种轻量级的软件开发方法论，x p 从实践中来，是对实践的总结，也是经过实 践检验的，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动 精神。适用于1 0 人以下的项目组、开发地点集中的场合，现已成为小组开发方法 的一个典范，被业界广泛应用。 极限编程方法中包含4 个指导软件开发的价值观n ： 1 改善沟通 项目相关人员之间进行充分、多渠道的沟通。 2 寻求简单 在系统可运转的前提下，做最简洁的工作；在开发中不断优化设计，时刻保 持代码简洁、无冗余。 3 获得反馈 强调各种形式的反馈，如小交付、短迭代、先考虑测试再编码等。 4 富有勇气 面对压力做正确的判断并敢于付诸行动，如敢于丢弃不良的代码，疲惫时立 即休息等等。 建立在x p 核心价值观之上的是五项指导软件开发的主要原n - 1 快速反馈：开发人员通过简短的反馈循环迅速了解其当前产品是否满足了 客户的需求。 2 简单性假设：简单性假设指的是每个问题都视为很容易解决。这意味着只 需为当前迭代打算，而无需洞察未来可能需要什么。 3 逐步修改：通过一系列细微的修改来解决问题。这适用于规划、开发和设 计。一个这样的例子是，客户有一个静态的网站，希望支持j s p 。为此，x p 小组 将根据业务要求，进行大量的小型发布，而不是在一次发布中重新开发整个网站。 4 拥抱变化：采用保留选项，同时解决紧迫问题的策略。 5 高质量的工作：工作质量决不可打折扣。x p 采用测试先行的编程方式， 强调编码和测试的重要性。 在x p 的生命周期中，贯穿了一系列的行为： 1 倾听：x p 以交流为基础，其一些实践要求积极的倾听。它对正式的书面 8 文档的依赖性更低，因此要求高质量的口头交流。开发人员不仅需要倾听客户， x p 的一些实践指导如何更好地进行交流。x p 人员不依赖于文档，因此必须学习 并掌握其它形式的口头交流。 2 测试：在x p 中，测试并非在将产品交付给客户之前进行的马后炮，而是 整个开发过程中不可或缺的一步。它到了这样一种程度，即开发人员在开发代码 之前编写测试。x p 测试不限于准确性和缺陷测量方面，还将检查性能和一致性。 编写代码之前编写测试，要求开发人员转变思维方式。这样做的结果是，代码的 质量是有保证的，而不是等待开发周期的后期去捕获b u g ( 这样做的成本通常更 高) 。 3 编码：x p 毕竟是关于编程的，编写代码是一种工艺，通过重构、结对编 程和代码复核等实践得以改进。几乎没有书面设计，x p 开发人员书写表达其意图 的代码。只需通过阅读源代码，其它小组成员便能理解其中的逻辑、算法和流程。 这里必须指出的一点是，我们这里谈论的不是代码中的注释，仅仅代码本身便是 一种交流形式。请记住，就我们的接触范围而言，软件的源代码是离实际的最终 产品最近的。完成源代码后，我们将把它提供给编译器、链接程序和其它联编工 具。 4 设计：x p 的核心思想之一是，在整个项目的进展过程中，设计应是不断演 化的。设计并非固定的，不能赋予它单个职责，而是基于小组的，动态的。从某 种角度上讲，软件总是在一种状态下被设计。x p 接受系统的自然演进，而不是通 过限制设计行为，对前面所述的事实视而不见。不承认软件设计是动态和不断变 化的，将为其食古不化付出代价一系统将是复杂、停滞不前、充斥b u g 的。x p 同 其它方法之间的区别在于其流动性，对设计特性的响应。 针对以上这些行为，x p 表示成1 2 种核心实践： 1 规划游戏：规划游戏的职责是快速制定下一次发布或迭代的高级规划。 2 小型发布：x p 项目每两周交付一次可以工作的软件。平均两周的迭代实 现了一些需求，在每次迭代结束时，给客户演示迭代生成的系统，以得到反馈。 3 比喻：比喻是用于描述项目的通用观点、术语和语言。 4 简单设计：设计必须简单。从x p 的角度说，简单意味着代码完成的是最 简单、管用的工作。 5 测试：x p 开发的核心是使用自动化测试。测试首先被开发，然后在测试 装置中实现。x p 强调“测试先行 。在编码开始之前首先将测试写好，而后在进 行编码，直至所有的测试都得以通过。 6 重构：重构指的是在不改变系统中可见行为的前提下，对已有的代码设计 进行改进。 9 7 结对编程：结对编程是由两个开发人员在同一台电脑上共同编写解决同一 问题的代码，通常一个人负责编码，而另一个人负责保证代码的正确性和可读性。 结对编程是一种非正式的同级评审，它要求两个开发人员在技能上应该相互匹配。 8 集体拥有：开发小组的每个成员都有更改代码的权利，所有的人对于全部 代码负责。代码全体拥有并不意味者开发人员可以互相推委责任，而是强调所有 的人都要负责。如果一个开发人员的代码有错误，另外一个开发人员也可以进行 b u g 的修复。 9 持续集成：x p 倡导在一天中多次集成系统，而且随着需求的改变，要不 断的进行回归测试，这样可以使得团队保持一个较高的开发速度，同时避免了一 次系统集成出现的风险。 1 0 每周工作4 0 小时：当小组加班加点时，无法确保高质量和性能。正常的 工作时间，以确保质量。 1 1 现场客户：客户代表现场办公，是小组的一员。要求至少有一名客户代 表在整个项目开发周期中和团队开发人员在一起工作，负责确定需求、回答团队 问题以及编写功能验收测试。 1 2 编码标准：编码标准是一系列的约定，所有人在开发时必须遵守。 极限编程的生命周期由五个部分组成：探索阶段、计划阶段、迭代到发布阶段、 产品化阶段以及维护阶段和结束。如图2 1 显示了x p 项目的生命周期，结束阶段 没有标出，一般在维护阶段的后面。 ： 维护阶段： ，- - - - - - - - i - - 一 图2 1 x p 生命周期 f i g u r e2 1x p “f ec y c l e 探索阶段是极限编程的起点，目的是充分评估首次迭代所要实现的用户故事。 l o 用户故事是指特征需求、配置或者用户提出的非功能性的需求。用来记录用户故 事的纸质卡片被称作故事卡片( s t o r yc a r d ) 。故事卡片并非记录用户故事的每个细 节，极限编程方法强调面对面的沟通和交流，故事卡片只作简略记录，可以用来 建立文档。探索阶段内，用户的任务是把希望包含在首次发布版本中的用户故事 填写到故事卡片上来，团队成员的任务有两个：熟悉项目中将用到的工具、技术 和开发方法，以及成员间彼此熟悉。 计划阶段的主要任务是设置用户故事的优先级和对发布的用户故事和发布日 期达成共识。软件开发程序员对每个用户故事所需的劳动量进行初步估计，整个 软件开发团队根据劳动强度的估计对发布的用户故事和最终日期达成共识。首次 发布的日期一般不超过两个月。 迭代发布阶段的目标是实现一个已充分测试过的系统，为发布作好准备。一 次发布需要经历多次迭代，图2 2 是一个x p 的迭代周期，根据交付计划和项目速 率( 实际开发时间和估计时间的比率) ，选择要优先完成的用户故事或待消除的 b u g ，将其分解为可在卜2 天内完成的任务，制定本次迭代计划，然后通过每天 的站立会议，解决碰到的问题，调整迭代计划，会后是共享式的开发工作。开发 人员要确保新功能1 0 0 9 6 通过单元测试，并立即组装，形成新的可运行版本，由用 户代表进行验收和测试。一个迭代周期较短，约几周时间。通过划分计划时间表， 来形成多个迭代期。在迭代开始前，用户为迭代选择用户故事，在迭代快结束时， 对系统进行功能测试。随着最后一轮的迭代结束，产品的发布也即将进行。 ? 芯敲搴厂= j 逯倪登! 兰! ：制定绣r 代计划二二二二 b 唱。二 学习与定漉+ 新耀户故事 卜龇 始，象 会议_ 下一侄务 豢鬈篷二当壤新版本 寥躺援j 再，一。 图2 2 一个x p 迭代的周期 f i g u r e2 2o n ex pi t e r a t i o nc y c l e 通过系统部署来实现系统的产品化，在此之前，还需要对系统性能进行额外 的测试和检查。在产品化阶段，仍然可能会发现新的变化，是否将这些变化加进 当前版本，需要仔细斟酌。为了给维护和编写文档留下足够多的时间，产品化的 迭代周期可能会缩短，从原来的几周可能缩短到一周左右时间。 维护阶段的主要目的是增强系统性能、修正版本中的缺陷，构建重要的发布 版本。自首次版本发布后到项目结束前，开发团队都既需要维护现有运行的系统， 又需要执行下一轮新的迭代。因此，系统的开发速度可能会受到影响。 当所有需要实现的用户故事都开发完成时，项目也就进入了结束阶段。当然， 失败的项目也可能提前进入结束阶段。在结束阶段，可能需要编写必要的文档。 2 3s c r u m 方法 s c r u m 方法【1 2 】【1 3 】【1 4 】是由k e ns c h w a b e r 和j e f fs u t h e r l a n d 提出，旨在寻求充分 发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来 自英式橄榄球( 在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集 体行动，奋力实现同一目标胜利) 。s c r u m 方法最初实践于e a s e l 公司( 1 9 9 3 年) ，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务 应用产品的开发。s c r a m 提出的s c r a mm e e t i n g 、s p r i n t 、b a c k l o g 、s c r u mm a s t e r 、 s c r u mt e a m 、d e m o 等模式已被p l o p 作为组织和过程模式( o r g a n i z a t i o n a la n d p r o c e s sp a t t e r n ) 的标准。 s e r u m 的基本假设是：开发软件就像开发新产品，无法一开始就能定义f i n a l p r o d u c t 的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可 以保证项目成功。s e r u m 有明确的最高目标，熟悉开发流程中所需具备的最佳典范 与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每 天、每个阶段都朝向目标有明确的推进，因此，s c r u m 非常适用于产品开发项目。 s c r u m 开发流程通常以1 - 6 周为一个迭代周期，每个迭代周期叫做一个s p r i n t ， 由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该 完成的规格部份，开发团队必须尽力于每个周期后交付成果，团队每天用1 5 分钟 开会检视每个成员的进度与计划，了解所遭遇的困难并设法排除，决定第二天的 任务安排，这样的短会就叫做s e r u mm e e t i n g 。 s e r u m 较为有特色的，是它特别强调开发队伍和管理层的交流协作。每天，开 发队伍都会向管理层汇报进度，如果有问题，也会向管理层要求帮助解决。s e r u m 方法的开发过程包括三个过程：( 1 ) 计划和体系结构设计( 确定性过程) b a c k l o g ； ( 2 ) s p r i n t ( 经验性过程) ( 3 ) 交付和巩固( 确定性过程) s e r u m 过程认为一个产品 的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动 类似于传统方法中的维护和改善，目的在于整理s p r i n t 期压力下忽略的工作，为 下一阶段的开发做准备，以便轻装上阵。s c r u m 对过程的管理有很多独特的方法。 s c r u m 在实践中大大提高了生产率( 据软件生产率组织的c a p e r sj o n e s 称可提高6 倍) 。 s e r u m 中只有三个角色：s e r u mm a s t e r ，s e r u mt e a m 和p r o d u c to w n e r 1 2 1 s c r u mm a s t e r s c r u mm a s t e r 有别于项目经理一职，他的职责是帮助s e r u mt e a m 来处理除开 发之外的其他事务，例如安排和主持与客户、管理层人员和股东开会。s c r u mm a s t e r 帮助开发团队进行一些重要的团队本身无法作出的决策，并且充当开发团队和外 部世界之间的防火墙。s c r u mm a s t e r 只是引导团队，而非控制他们。最终，s c r u m m a s t e r 必须处理和项目有关的所有问题，包括团队内部问题，与管理层的接触， 或者团队能力不足等。 2 s e r u mt e a m s c r u mt e a m 是可以进行自我组织的，即此团队内部自己决定哪个开发任务由 谁来完成，每个成员具有相同的责任和权威。同时，每个成员都有一定的应付开 发任务的知识和经验。团队内部具体是什么结构并没有被定义，而是有实际的项 目来决定团队的规模和结构的复杂程度。s e r u mt e a m 的规模介于5 - 9 人。对于超 过此规模的团队，可以将它划分为较小规模的拥有5 - 9 人的小组。这样，小组内 部构成一个s e r u mt