（计算机应用技术专业论文）透明水晶开发方法在定制软件开发中的应用研究.pdf

摘要 从2 0 0 1 年敏捷联盟宣言( t h em a n i f e s t o o f t h e a g i l e a l l i a n c e ) 提出以来，宣言 受到广泛的响应，并展开了进一步的研究，随后产生了一系列的敏捷方法，如： 极限编程x p ( e x t r e m ep r o g r a m m i n g ) 、水晶系列方法( c r y s t a lm e t h o 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 ) 、s c r u m 等。这些方法给传统的软件开 发带来了巨大的影响，并且得到了广泛的应用。它们虽然在做法上各有各的不 同，但是本质上都是敏捷的。 定制软件开发是指根据客户的具体情况，具体要求，设计软件系统，提供 相应的服务。定制软件开发有其自身的特点，传统瀑布模型在定制软件的开发 中遇到了很大的挑战，出现了许多问题，如需求得不到满足、进度延期等问题。 而敏捷方法正是针对这些问题提出的，很适合定制软件开发。我国软件行业有 其自身的特点，如规模小、制度不健全等。本文通过分析我国定制软件开发的 特点认为，在众多的敏捷方法中水晶系列方法比较适合我国软件行业目前的现 状。本文结合中国网络通信集团公司网上营业厅项目，阐述了透明水晶方法在 定制软件开发中的应用研究。主要对以下几个方面的问题进行了探讨： ( 1 ) 介绍敏捷开发的内涵，原则，阐述了目前主要的敏捷开发方法的特点， 结合我国软件行业的现状，对各种敏捷方法的优缺点作简要分析。在众多的软 件开发方法中找出能很好的适用于我国软件行业的方法水晶系列方法。 ( 2 ) 分析我国定制软件开发的特点，论述了定制软件开发使用敏捷开发的必 要性和优势。结合定制软件开发的特点和水晶系列方法，提出定制软件开发应 该根据项目自身的情况采用与之相适应的水晶方法。 ( 3 ) 以网通集团网上营业厅项目为例，说明在定制软件的开发中如何采用 c r y s t a l 方法。包括人员组织，项目开发两个方面。针对目前在定制软件开发中 的问题，重点阐述了在项目开发中的增景开发、需求控制和进度控制。 ( 4 ) 在文章结尾，根据c r y s t a l 方法的特点，对定制软件如何采用c r y s t a l 方 法做了总结，并总结了c r y s t a l 方法的优点与其局限性。并对在本文研究中还存 在需要改进的地方进行了探讨。这样的工作，对于想要继续尝试研究和c r y s t a l 方法的人，或许有一些参考意义。 关键字：敏捷开发，透明水晶，定制软件 a b s t r a c t s i n c et h em a n i f e s t oo ft h ea g i l ea l l i a n c ep r o p o s e da t2 0 0 1 t h em a n i f e s t o r e c e i v e st h ew i d e s p r e a dr e s p o n s e ，a n dh a sl a u n c h e dt h ef a r t h e rr e s e a r c h , a n dh a sh a d as e r i e so fa g i l em e t h o d ss u c ha s ：x p ( e x t r e m ep r o g r a m m i n g ) ，( c r y s t a lm e t h o 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 ) ，s c m m t h e s em e t h o d sh a v eb r o u g h tt h eh u g c i n f l u e n c ef o rt h et 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 t , a n do b t a i n e dt h ew i d e s p r e a d a p p l i c a t i o n a l t h o u g ht h e yr e s p e c t i v e l yh a v ee a c hd i f f e r e n c ei nt h ep r o c e d u r e ，b u t e s s e n t i a l l ya l la r ca g i l e o r d e r e ds o f t w a r ed e v e l o p m e n tr e f e r st ot h ed e s i g n sf o rt h es o f t w a r es y s t e m w h i c hp r o v i d e st h ec o r r e s p o n d i n gs e r v i c ef o rc u s t o m e r s t h es p e c i a ld e t a i l s ，t h e s p e c i f i cr e q u e s t o r d e r e ds o f t w a r ed e v e l o p m e n th a si t so w nc h a r a c t e r i s t i c s ，t h e t r a d i t i o n a lw a t e r f a l lm o d e ld e v e l o p m e n tf a c ev e r yb i gc h a l l e n g ei nt h ed e v e l o p m e n t f o ro r d e r e ds o f t w a r ed e v e l o p m e n ta n d h a dm a n yp r o b l e m s ，f o re x a m p l e ：t h ed e m a n d c o u l dn o to b t a i ns a t i s f i e s , t h ep r o g r e s sp o s t p o n e sa n ds oo n t h ea g i l em e t h o di s p r e c i s e l yp r o p o s e di nt h ev i e wo ft h e s eq u e s t i o n s , s oi t i ss u i t a b l ef o rt h eo r d e r e d s o f t w a r ed e v e l o p m e n t o u rc o u n t r ys o f t w a r ep r o f e s s i o nh a si t so w nc h a r a c t e r i s t i c s ， f o re x a m p l e ：t h es c a l eo ft h ec o m p a n yi ss m a l lt h es y s t e mi sn o tp e r f e c ta n ds oo n t h i sa r t i c l e t h r o u g ha n a l y z e s o u rc o u n t r y so r d e r e ds o f t w a r ed e v e l o p m e n t s c h a r a c t e r i s t i ct ob e l i e v et h a tc r y s t a ls e r i e sm e t h o dq u i t es u i t a b l eo u rc o u n t r ys o f t w a r e p r o f e s s i o na tp r e s e n ts i t u a t i o ni nm u l t i t u d i n o u sa g i l em e t h o d s t h i sa r t i c l eu n i f i e s o n - l i n eb u s i n e s sh a l lp r o j e c to ft h ec h i n an e t w o r kc o r r e s p o n d e n c ec o m p a n y , r e s e a r c ht h e a p p l i c a t i o n f o rc r y s t a lc l e a rm e t h o di nt h eo r d e r e ds o f t w a r e d e v e l o p m e n t t h ea r t i c l em a i n l yc a r r i e d0 nt h e d i s c u s s i o nt of o l l o w i n gq u e s t i o n s ： ( 1 ) i n t r o d u c et h ec o n n o t a t i o na n dt h ep r i n c i p l eo ft h ea g i l ed e v e l o p m e n t , e l a b o r a t e d t h em a i na g i l em e t h o d s c h a r a c t e r i s t i c , u n i f i e st h ep r e s e n ts i t u a t i o no fo u rc o u n t r y s s o f t w a r ep r o f e s s i o n , m a k eb r i e fa n a l y s i st oe a c ha g i l em e t h o d sg o o da n db a dp o i n t s f i n do u tt h em o s ts u i t a b l em e t h o df o ro u rc o u n t r y ss o f t w a r ep r o f e s s i o ni sc r y s t a l s e r i e sm e t h o d ( 2 ) a n a l y z e st h ec h a r a c t e r i s t i co fo u rc o u n t r y so r d e r e ds o f t w a r ed e v e l o p m e n t ， e l a b o r a t e dt h en e c e s s i t ya n dt h es u p e r i o r i t yo fa g i l em e t h o df o ro r d e r e ds o f t w a r e d e v e l o p m e n t t h eu n i o nt h ec h a r a c t e r i s t i c so f0 r d e r e ds o f t w a r ed e v e l o p m e n t a n dm e c r y s t a ls e r i e sm e t h o d s , p r o p o s e dt h a to r d e r e ds o f t w a r ed e v e l o p m e n tt ob es u p p o s e d t ou s es u i t a b l ec r y s t a lm e t h o da c c o r d i n gt ot h ep r o j e c to w ns i t u a t i o nw h i c ha d a p t s w i t h i t ( 3 ) t a k et h eo n l i n eb u s i n e s sh a l lp r o j e c to ft h ec h i n an e t w o r kc o r r e s p o n d e n c e c o m p a n ya se x a m p l e ，e x p l a i n e dh o w t ou s et h ec r y s t a lm e t h o di no r d e r e ds o f t w a r e d e v e l o p m e n t i n c l u d i n gt h ep e r s o n n e l ，t h ep r o j e c td e v e l o p st w oa s p e c t s i nv i e wo f t h ep r o b l e m so ft h ep r e s e n to r d e r e ds o f t w a r ed e v e l o p m e n t ，e l a b o r a t e dw i t he m p h a s i s i ni n c r e a s ed e v e l o p m e n t ，t h ed e m a n dc o n t r o la n dt h ep r o g r e s sc o n t r 0 1 ( 4 ) a tt h ee n do ft h ea r t i c l e , a c c o r d i n gt ot h ec h a r a c t e r i s t i c so fc r y s t a lm e t h o d , m a k et h es u m m a r yt oh o wt ou s et h ec r y s t a lm e t h o di nt h eo r d e r e ds o f t w a r e d e v e l o p m e n t ，a n ds u m m a r i z e dt h ec r y s t a lm e t h o d sm e r i ta n dt h el i m i t a t i o n a n d s o m es t u d yi n t h i sa r t i c l ew h i c ha l s oe x i s t e dn e e d st o i m p r o v et oc a r r yo nt h e d i s c u s s i o n s u c hw o r kp e r h a p sh a ss o r e r e f e r e n c es i g n i f i c a n c e sf o rt h e s ep e o p l ew h o w a n tt oc o n t i n u et oa t t e m p tt h er e s e a r c hf o rt h ec r y s t a lm e t h o d k e yw o r d s ：a g i l es o f td e v e l o p m e n t , c r y s t a lc l e a r , o r d e r e ds o f t w a r e 武汉理工大学硕士学位论文 缩略词 ) 口：e x t r e m ep r o g r a m m i n g f d d ：f e a t t i r e d r i v e nd e v e l o p m e n t a d o ：a c t i v e xd a t a0 b j e c t a s p ：a c t i v es e r v e rp a g e b s ：b r o w s e r s e r v e r c o m ：c o m p o n e n to b j e c tm o d e l h i i 甲：h y p e r t e x tt r a n s f e rp r o t o c o l s ：i n t e r n e ti n f o r m a t i o ns e r v i c e s o d b c ：o p e nd a t a b a s ec o n n e c t i v i t y x m ke x t e n s i b l em a r k u pl a n g u a g e u m lu n i f i c dm o d e ll a n g u a g e 独创性声明 本人声明，所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人 已经发表或撰写过的研究成果，也不包含为获得武汉理工大学或其它教育机构的 学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已 在论文中作了明确的说明并表示了谢意。 矾以毋 关于论文使用授权的说明 本人完全了解武汉理工大学有关保留、使用学位论文的规定，即学校有权保 留、送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文 i 保密的论文在解密后应遵守此规定l 钴岛 武汉理工大学硕士学位论文 1 1 课题研究背景 第1 章引言 定制软件开发就是根据客户的具体情况，具体要求，设计软件系统，提供 相应的服务。大多数客户由于自身的历史和业务状况，对于软件系统会有自身 特殊的要求，而市场上的通用软件，一方面价格对一些客户来说难以承受，另 一方面功能难以兼顾到客户的个性化需求。因此不少企业转向定制开发。相对 于通用软件，定制软件有针对性强，使用方便，费用低廉，服务周到的优点。 随着我国信息化水平的提高，已经有很多企事业单位意识到了使用专用软 件可以大大提高资金使用率、提高员工的工作效率、降低成本、同现有业务接 轨等。定制软件开发在我国的需求也越来越大。然而，由于自身及客户的原因， 我国的软件企业在定制软件的开发中还存在一些的问题。 ( 1 ) 项目延期：项目延期会影响客户的业务，同时也会给软件企业带来损失。 然而在我国的定制软件开发中，由于受到开发人员的水平，软件企业的项目管理 水平及客户的需求变化等因素的影响，项目延期是一种普遍现象。 ( 2 ) 客户的需求得不到满足：在定制软件的开发中，由于需求调研的不充分 及客户需求的变动等原因，最终交付的软件产品往往不能满足客户的实际需要。 ( 3 ) 文档混乱：很多软件企业按照传统的软件工程的方法进行定制软件的开 发，这样在开发过程中就产生了大量的文档，然而项目开发与项目管理的原因， 很多文档与最终的软件产品有很大的差距， 艮混乱。 ( 4 ) 维护不能保证：据调查我国软件行业的人员流动率高达5 0 ，因此往往 出现项目做完了，项目组的人就走了不少的情况。这就给软件的维护带来了很 大的困难。因为开发人员走后，维护人员仅凭文档是很难进行维护的。 此外，在定制软件开发中还存在着开发成本过高，开发人员工作压力大，实 施难度大等问题。因此，采用一种与定制软件开发相适应的开发方法，提高定 制软件开发的效率，对促进我国软件行业的发展，促进国民经济的发展都具有 重要的意义。 武汉理工大学硕士学位论文 1 2 课题来源 由北京银通先达科技有限责任公司开发的中国网通集团公司网上营业厅项 目，在项目开始的时候，是按照传统的基于过程的开发方式进行开发的，要求 每个人必须严格按照要求写设计文档，程序要与文档严格保持一致等。但是随 着项目的进展，我们发现，如果再严格的按照那种要求来要求程序员，项目将 无法继续下去，更不可能按期完工了。于是我们对对开发方法进行了调整，在 众多的方法中我们选用了透明水晶开发方法。本文作者认为，类似这样的中小 型定制软件的开发有其自身的特点，水晶方法系列中的透明水晶方法很适合这 样的特点。 1 3 课题研究内容 ( 1 ) 课题研究目标： 研究透明水晶方法在中小型定制软件开发中的应用，并将研究成果应用 于网通集团网上营业厅项目的开发中，使项目能够按时高效的完成。 ( 2 ) 课题研究内容： 敏捷开发及透明水晶方法的内涵研究； 我国定制软件开发的特点研究； 以网通集团网上营业厅项目为例研究c r y s t a l 方法在定制软件开发中 的应用。 ( 3 ) 课题拟解决的关键问题： 在程序员水平参差不齐的情况下，如何使沟通更有效率。 定制软件开发中如何控制进度。 定制软件开发中如何控制客户的需求。 2 武汉理工大学硕士学位论文 第2 章敏捷软件开发的内涵及原则 2 1 敏捷软件开发的内涵 敏捷软件开发不是一个具体的过程，而是一个涵盖性术语( u m b r e l l at e r m ) ， 用于概括具有类似基础的方式和方法。这些方法，其中包括极限编程( e x t r e m e p r o g r a m m i n g ) 、动态系统开发方法( d y a d i cs y s t md e v e l o p m e n tm e t h o d ) 、 s c r u m 、c r y s t a l 和l e a n 等，都着眼于快速交付高质量的工作软件，并做到客 户满意。敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方 法。敏捷式开发是以人为主的，而传统的工程学是以过程为主的。1 1 】 适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传 统的工程学里，核心的概念就是把设计和构建这两个过程分开进行，构建是基 于设计的。而软件本身的需求是在变化的。一个项目在开发过程中需求会出现 变化，需求的变化从根本上推翻了工程学方法所建立的一个基础。工程学尽量 减少或者控制系统将来发生变化的可能，越这样做问题就越容易出现。既然我 们没办法避免变化的发生，那么我们就想找到一种新的方法能够更有效地适应 这种变化现象。这也就是敏捷式开发方法所要达到的效果1 2 1 。 工程学所采用的过程是尽量减少人在这个过程中所扮演的角色。在敏捷开 发中，提出的观点就是人在整个软件开发当中是最重要的因素，至于在这个开 发过程中使用什么样的方法是次要的因素。 把握住了这两点，就把握住了敏捷软件开发的核心。敏捷宣言及敏捷原则 都体现了这两点。 2 2 敏捷宣言 ( 1 ) 个体和交互胜过过程和工具 人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是 使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的 团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀 武汉理工大学硕士学位论文 的成员也一样会惨败。 一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可 能是一个平均水平的程序员，但是却能够很好地和他人合作。合作、沟通以及 交互能力要比单纯的编程能力更为重要。一个由平均水平程序员组成的团队， 如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员，但是成员 之间却不能进行交流的团队更有可能获得成功。 合适的工具对于成功来说是非常重要的。像编译器、i d e 、源代码控制系统 等，对于团队的开发者正确地完成他们的工作是很重要的。然而，工具的作用 可能会被过分地夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是 不好的。 较好的做法是从使用小工具开始，尝试一个工具，直到它无法适用时才去 更换它。不要急着去购买那些先进的、价格昂贵的源代码控制系统，相反先使 用一个免费的系统直到该系统已经不再适用。在决定为团队购买最好的c a s e 工具许可证( 1 i c c 船c ) 前，先使用白板和方格纸，直到有足够的理由表明需要更多 的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件( f l a tf l l e ) 。 更大的、更好的工具不能自动地帮你做得更好。通常，它们造成的障碍要大于 带来的帮助。 团队的构建要比环境的构建熏要得多。很多团队和管理者就犯了先构建环 境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队， 然后再让团队基于需要来配置环境。 ( 2 ) 可以工作的软件胜过面面俱到的文档 软件不能没有文档。虽然代码足以传达系统原理和结构，但是代码很难描述 系统结构等高层设计。因此，团队需要编制易于阅读的文档，来描述系统及其 设计决策的依据。 但是过多的文档比没有文档更糟。编制大量的文档需要花费大量的时间， 并且要使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间 失去同步，那么文档不仅不会起到阐述系统的作用，还会给读者造成重大的误 导。 因此，团队需要编写并维护一份短小的( s h o n ) 并且主题突出的( s a l i e n t ) 系统原 理和结构方面的文档，“短小的”意思是说，最多有一二十页。“主题突出的”意思 是说，应该仅论述系统的高层结构和概括的设计原理。 4 武汉理工大学硕士学位论文 由于只有一份简短的系统原理和结构方面的文档，因此，在培训新成员时 就不能用文档来培训了。最好的培训方法是密切地和他们在一起工作。紧挨着 他们坐下来帮助他们，把系统的知识传授给他们。通过近距离的培训和交互使 他们成为团队的部分。 在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真 实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困 难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时 常变化的系统的脉络图a dm a p ) 。人和人之间的交互是把这份脉络图传授给他 人的最快、最有效的方式。 很多团队因为注重文档而非软件，导致进度拖延。这是一个致命的问题。 “m a r t i n 文档第一定律( m a r t i n sf i r s tl a wo fd o c u m e n t ) ”的简单规则可以预防这个 问题的发生： 直到迫切需要并且意义重大时，才来编制文档。 ( 3 ) 客户合作胜过合同谈判 订购软件不像订购日用品。不能够仅仅写下一份关于你想要的软件的描述， 然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软 件项目的尝试都必将以失败而告终。 很多公司的管理者都希望开发团队能凭一个软件的描述就能在规定的时间 里开发出符合要求软件来。而这种做法是不可取的。 成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的 陈述，而是让软件的客户和开发团队密切地在一起工作，并尽薰经常地提供反 馈。 一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数 的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发 团队和客户的协同工作方式提供指导的合同才是最好的合同。 ( 4 ) 响应变化胜过遵循计划 响应变化的能力常常决定着一个软件项目的成败。当构建计划时，应该确 保计划是灵活的并且易于适应商务和技术方面的变化。 计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变 动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使 熟悉需求，并且确信它们不会改变，仍然不能很好地估算出开发它们需要的时 武汉理工大学硕士学位论文 间。 很多管理者都喜欢用p e r t 或者g a n t t 图来管理项目。通过这些图，他们能 够跟踪每个人的任务状态，他们可以对任务实际完成的日期和计划完成的日期 进行比较，并对出现的任何偏差做出反应。 实际上，随着项目的进行，这张图的组织结构以经不再适用。当团队增加了对 于系统的认识，当客户增加了对于需求的认识，图中的某些任务会变得可有可 无，另外一些任务会被发现并增加到图中。简而言之，计划将会遭受形态( s h a p e ) 上的改变，而不仅仅是日期上的改变。 较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计 划，再以后就做极为粗糙的计划。应该清楚地知道下两周要完成的任务，粗略 地了解一下以后三个月要实现的需求。至于系统一年后将要做什么，有一个模 糊的想法就行了。 计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时 间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队 会根据这个计划启动工作并有了相应的投入。然而，由于计划仅仅支配了几周 的时间，计划的其余部分仍然保持着灵活性。 2 3 敏捷开发原则 从上述的价值观中引出了下面的1 2 条原则，它们是敏捷方法区别于重型过 程的特征所在。 ( 1 ) 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满 意 m l ts l o a n 管理评论杂志刊登过一篇论文，分析了对于公司构建高质量产品 方面有帮助的软件开发实践。该论文发现了很多对于最终系统质量有重要影响 的实践。其中一个实践表明，尽早地交付具有部分功能的系统和系统质薰之间 具有很强的相关性。该论文指出，初期交付的系统中所包含的功能越少，最终 交付的系统的质量就越高。 该论文的另一项发现是，以逐渐增加功能的方式经常性地交付系统和最终 质薰之间有非常强的相关性。交付得越频繁，最终产品的质量就越高。 敏捷方法会尽早地、经常地进行交付。努力在项目刚开始的几周内就交付 6 武汉理工大学硕士学位论文 一个具有基本功能的系统。然后，努力坚持每两周就交付一个功能渐增的系统。 如果客户认为目前的功能已经足够了，客户可以选择把这些系统加入到产 品中。或者，他们可以简单地选择再检查一遍已有的功能，并指出他们想要做 的改变。 ( 2 ) 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创 造竞争优势 这是一个关于态度的声明。敏捷过程的参与者不惧怕变化。他们认为改变 需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要 的知识。 敏捷团队会非常努力地保持软件结构的灵活性，这样当需求变化时，对于 系统造成的影响是最小的。 ( 3 ) 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付 的时间间隔越短越好 交付可以工作的软件( w o r k i n gs o f t w a r e ) ，并且尽早地( 项目刚开始很少的几 周后) 、经常性地( 此后每隔很少的几周) 交付它。不赞成交付大量的文档或者计 划。那些不是真正要交付的东西。敏捷开发关注的目标是交付满足客户需要的 软件。 ( 4 ) 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作 为了能够以敏捷的方式进行项目的开发，客户、开发人员以及涉众之间就 必须要进行有意义的、频繁的交互。软件项目不像发射出去就能自动导航的武 器，必须要对软件项目进行持续不断地引导 ( 5 ) 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持， 并且信任他们能够完成工作 在敏捷项目中，人被认为是项目取得成功的最重要的因素。所有其他的因 素过程、环境、管理等等一都被认为是次要的，并且当它们对于人有负面的 影响时，就要对它们进行改变。 例如，如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。 如果某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行改变。 ( 6 ) 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面 的交谈 在敏捷项目中，开发人员之间相互进行交谈。首要的沟通方式就是交谈。 武汉理工大学硕士学位论文 也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需 要书面的规范、书面的计划或者书面的设计。团队成员可以去编写文档，如果 对于这些文档的需求是迫切并且意义重大的，但是文档不是默认的沟通方式。 默认的沟通方式是交谈。 工作的软件是首要的进度度量标准 敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。它们不 是根据所处的开发阶段，已经编写的文档的多少或者已经创建的基础结构 ( i n f r a s u u c t u r c ) 代码的数量来度量开发进度的。只有当4 0 的必须功能可以工作 时，才可以确定进度完成了加。 ( 8 ) 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持 一个长期的、恒定的开发速度 敏捷项目不是5 0 米短跑；而是马拽松长跑。团队不是以全速启动并试图在 项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。 跑得过快会导致团队精力耗尽、出现短期行为甚至于崩溃。敏捷团队会测 量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在 今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质 量标准的速度上。 ( 9 ) 不断地关注优秀的技能和好的设计会增强敏捷能力 高的产品质量是获取高的开发速度的关键。保持软件尽可能的简洁、健壮 是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够 编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再 来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。 ( 1 0 ) 简单使未完成的工作最大化的艺术一是根本的 敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目 标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会 在今天就对那些问题进行防卫。相反，他们在今天以最高的质量完成最简单的 工作，深信如果在明天发生了问题，也会很容易进行处理。 ( 1 1 ) 最好的构架、需求和设计出自于自组织的团队 敏捷团队是自组织的团队。任务不是从外部分配给单个团队成员，而是分 配给整个团队，然后再由团队来确定完成任务的最好方法。 敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项 8 武汉理工大学硕士学位论文 目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试 负责的情况。整个团队共同承担那些责任，每一个团队成员都能够影响它们。 ( 1 2 ) 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后 相应地对自己的行为进行调整 敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏 捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性， 就必须要随环境一起变化。 2 4 现在流行的敏捷方法分析 2 4 1 极限编程 在所有的敏捷型方法中，极限编程( e x t r e m ep r o 伊猢i i l g ，x p ) 是最为引人瞩 目的。以至于很多人都误解为敏捷就是极限编程。极限编程实际上是一种经历 过很多实践考验的一种软件开发的方法，它诞生了有几年的时间了，它已经成 功的应用在许多大型的公司，如 b a y e r i s c h ei a n d 船b a n k , c r e d i ts w i s s l i f e ，d a i m l e r c h r y s l e r , f i r s tu n i o nn a t i o n a lb a n k , f o r dm o t o rc o m p a n ya n d u b s 3 。 x p 的成功得益于它对客户满意度的特别强调，x p 是以开发符合客户需要 的软件为目标而产生的一种方法论，x p 使开发者能够更有效的响应客户的需求 变化，哪怕在软件生命周期的后期【4 j 。 同时，x p 也很强调团队合作。团队包括：项目经理，客户，开发者。他们 团结在一起来保证高质量的软件。x p 其实是一种保证成功的团队开发的简单而 有效的方法n x p 强调四种价值：交流，简易，回馈，勇气。x p 程序员之间紧密的相互 交流，x p 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项 目一开始，x p 就强调通过对软件的不断钡0 试来获得反馈，程序员尽可能早的把 软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，x p 程序员 就可以自信的面对需求和软件技术的变化【6 l 。 用1 2 条手段来保证达到目标： 1 、通过客户、开发人员、经理三方共同参加的计划游戏( p l a n i n gg a m e ) 来 确定开发计划 9 武汉理工大学硕士学位论文 2 、小版本发布一尽快发布，尽早发布 3 、通过系统隐喻( m e t a p h o r ) 来让每个人了解整个系统 4 、简单设计一为明确的功能进行最优的设计，不考虑未来可能需要的功能。 5 、重构( r e f a c t o r i n 酚不断优化系统设计，使之保持简单 6 、单元测试一先写测试，后写代码 7 、双人编程( p a i rp r o g r a m m i n g ) 一系统的每一行代码都是2 个人用一个键盘 完成的。 8 、代码集体拥有一开发队伍中任何人可以修改任何其他人的代码，代码不 属于某个个人。 9 、持续集成一至少每天将整个系统集成一次，保持一个能运转的系统。 1 0 、4 0 小时工作制保证休息，保持体力 1 1 、现场客户一客户自己也是软件开发队伍的重要一份子 1 2 、编码标准一必须有统一的编码规范，确保代码的可读性 但是x p 的实施起来很有难度。特别是在我国。因为x p 对程序员水平的要 求很高。而且它的一些做法很极端，在我国很难被接受。如结对编程等。如果 团队成员的经验比较丰富，水平比较高，而且项目不大，并且客户很配合，x p 是个不错的选择。 2 4 2s c r u m s c r u m 由k e n s c h w a b c r 和j e f f s u t h e r l a n d 提出，旨在寻求充分发挥面向对 象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄 榄球f 在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动， 奋力实现同一目标胜利) 。s c r u m 方法最初实践于e a s e l 公司( 1 9 9 3 年) ，现 已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用 产品的开发。s c r u m 提出的s c r u 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 ) 的标准i ，j 。 s c r u m 把一个项目分成若干个为期3 0 天的迭代阶段，称之为一“冲” ( s p r i n t ) 。开“冲”之前，你得明确这一“冲”要实现的功能，然后交给开发组去完 成。但是，在“冲”期间，需求必须是固定的。 管理人员并非在“冲”的时候就撒手不管了。每天，他需召集一个短会( 1 5 1 0 武汉理工大学硕士学位论文 分钟左右) ，称之为一个s c t u h l ，会上大家讨论决定第二天干什么。特别是大家 会对管理层提出那些阻碍项目进行的因素，并希望管理层能予以解决。当然， 他们也需要报告目前完成了什么，这样管理层每天都能了解项目的进展情况。 s c r u m 在实践中大大提高了生产率( 据软件生产率组织的c a p e r sj o n e s 称可 提高6 倍) ，在实施中有一个”间断平衡”( p u n c t u a t e de q u i l i b r i u m ) 现象( 类似于自然 界中物种的进化，在经过一段相对平衡的各自独立、并行的发展期后，在交汇 处发生变异1 ，即在经过紧张、并行的s p r i n t 开发后，在s p r i n t 评审时，软件产 品产生较剧烈的变化。 2 4 3 功能驱动开发 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 o 是由p e t e rc 0 a d 、j e f fd el u c a 、e r i c l e f e b v r e 共同开发的一套针对中小型软件开发项目的开发模式。 f d d 是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于 被开发团队接受，适用于需求经常变动的项目。简单地说，f d d 是一个以 a r c h i t e c t u r e 为中心的，采用短迭代期，日期驱动的开发过程。它首先对整个项 目建立起一个整体的模型，然后通过两周一次设计功能实现功能的迭代完成 项目开发”。此处的“功能”是指“用户眼中最小的有用的功能”，它是可理解的、 可度量的，并且可以在有限的时间内( 两周) 实现。在开发过程中，开发计划的制 定、报告的生成、开发进度的跟踪均是以上述“功能”为单位进行的。在f d d 中， 它认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在f d d 中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进程进 行精确及时地监控【研。 f d d 有以下五项任务： 建立整体模型 根据优先级列出功能的详细列表 针对功用逐项制订计划 针对功用逐项进行设计 针对功用逐项开发实现 头三项在项目开始时完成，后两项在每一次迭代周期时都要做。每一项任 务又可进一步分解并制订出相应的检验准则。 在f d d 中，编程开发人员分成两类：首席程序员和“类”程序员( c l a s so w n e r ) 。 武汉理工大学硕士学位论文 首席程序员是最富有经验的开发人员，他们负责开发实现系统的各项功能。对 每一项功能，首席程序员要定出需要哪些类( c l a s s ) 来实现这项功能，并召集“类” 程序员们组成一个针对这项功能的开发组。首席程序员作为协调者，设计者和 指导者，而“类”程序员则主要作源码编写。 2 4 4 水晶系列方法 c r y s t a l ( 水晶系列方法1 是a l i s t a i rc o c k b u m 提出的一组开发方法，分为 c r y s t a lc l e a r ) c r y s t a ly e l l o w , c r y s t a lo r a n g e 和c r y s t a lr e d 分别适用于不同的项 目。项目可以按照参加的人员和重要性划分【9 】，如下图所示： 图2 - 1 水晶方法系列图 重要性根据项目中的错误引发的后果分为： c d e l l o s so f c o m f o r t ( 某些不舒适) l o s so f d i s c r e t i o n a r ym o n e y ( 经济损失) l o s