（通信与信息系统专业论文）基于agile的项目管理软件的研究与实现.pdf

一 。肇 ijj_r 一嚣然怒一 本人声明所呈交的论文是本人在导师指导下进行的研究工作及戢待i 沆，丫 本人签名： 型l 乌j 刍 日期：趔：圣：! ! 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在一年解密后适用本授权书。非保密论 文注释：本学位 本人签名： 导师签名： 适用本授权书。 日期： 日期： 弘，；p jji1 北京邮电大学硕士研究生论文 摘要 基于a g i l e 的项目管理软件的研究与实现 摘要 在当前的市场条件下，为应对商业环境的不断变化，软件 开发的方式须由预见性( 以计划为推动力) 向适应性( x , j - 不确 定性的探索) 转变，以满足客户对创新的不断需求。本文就是 在此背景下，介绍了敏捷开发的方法论并基于敏捷模型开发了 一套项目管理软件，将敏捷过程中可以被流程化和模式化的东 西转化为可表示的软件形式。由于不像传统的开发模式，敏捷 开发还没有一套成熟的项目评估机制，因此探索如何设计和实 现敏捷项目管理系统，并建立一套切实可行的管理机制是本文 的主要工作。 文中首选对敏捷开发模式进行了研究，并与传统的开发模 式进行了对比。然后提出了一套实现敏捷管理的j 2 e e 系统， 并详尽分析了系统架构和涉及到的技术。最后就实现进行了详 尽的阐述，包括模块设计、数据库设计、报表设计等等。 敏捷项目管理软件在开发完毕后，现已运用到了实际的软 件开发团队之中，并一直处于持续改进之中，整套系统对于敏 捷团队和项目管理者都具有一定的参考和借鉴意义。 关键词：敏捷开发s c r u mj 2 e e 项目管理 北京邮电大学硕士研究生论文 摘要 r e s e a r c ha n di m p l e m e n t f 叮1 0 n o fp r o j e c tm a n a g e m e n t s o f t 、 ，a r eb a s e d0 na g i l e a b s t r a ( 了r i nt h ec u r r e n tm a r k e tc o n d i t i o n s ，i no r d e rt oa d a p tc h a n g i n g b u s i n e s se n v i r o n m e n ta n dm e e tc u s t o m e rd e m a n d s ，s o f t w a r e d e v e l o p m e n t m e t h o dh a st ot r a n s f e rf r o m p r e d i c t a b i l i t y ( p l a n d r i v e n ) t oa d a p t i v e ( e x p l o r a t i o n o fu n c e r t a i n t y ) i nt h i s b a c k g r o u n d ，t h i sp a p e r i n t r o d u c e st h e a g i l ed e v e l o p m e n t m e t h o d o l o g ya n dd e v e l o p sas e to fm a n a g e m e n ts o f t w a r ew h i c h c a n p u tp r o c e s s - o r i e n t e d a n dp a t t e r n - o r i e n t e d t h i n g s i n a g i l e d e v e l o p m e n tp r o c e s si n t os o f t w a r ef o r m u n l i k et h et r a d i t i o n a l p a t t e r no fs o f t w a r ed e v e l o p m e n t ，a g i l ed e v e l o p m e n t d o e sn o th a v e as o p h i s t i c a t e dp r o j e c te v a l u a t i o nm e c h a n i s m s ，s oh o wt od e s i g n a n dr e a l i z a t i o no fa g i l ep r o j e c tm a n a g e m e n ts y s t e ma n de s t a b l i s ha v i a b l em a n a g e m e n tm e c h a n i s m si sm a j o rw o r ko ft h i sa r t i c l e f i r s to fa l l ，t h ea g i l ed e v e l o p m e n tm o d e lh a sb e e ns t u d i e di n t h i sp a p e r ，a n dw i t ht h et r a d i t i o n a ld e v e l o p m e n tm o d e lh a sb e e n c o m p a r e d t h e nas e to fa g i l em a n a g e m e n to fj 2 e es y s t e m sh a s v 北京邮电大学硕士论文 摘要 b e e nr a i s e d ，i n c l u d i n gad e t a i l e da n a l y s i so fs y s t e ma r c h i t e c t u r e a n dr e l a t e d t e c h n o l o g y f i n a l l y t h ed e t a i l e dr e a l i z a t i o no f e x p o s i t i o nh a sb e e nc a r r i e do u ti nt h ep a p e r , i n c l u d i n gm o d u l e d e s i g n ，d a t a b a s ed e s i g n ，r e p o r td e s i g na n ds oo n a f t e ra g i l ep r o j e c tm a n a g e m e n ts o f t w a r ef i n i s h e d ，i th a sb e e n a p p l i e dt ot h ea c t u a ls o f t w a r ed e v e l o p m e n tt e a ma n dh a sb e e ni n c o n t i n u o u si m p r o v e m e n t t h ee n t i r es y s t e mf o ra g i l et e a m sa n d p r o j e c tm a n a g e r sh a sac e r t a i nd e g r e ev a l u eo fr e f e r e n c ea n d l e a r n i n g k e y w o r d s ：a g i l ed e v e l o p m e n t 、s c r u m 、j 2 e e ，p r o j e c tm a n a g e m e n t 北京邮电大学硕士研究生论文目录 第一章绪论 目录 1 1 研究背景1 1 2 项目管理软件现状。2 1 3 本论文的主要工作和创新2 1 4 论文结构3 1 5 本章小结3 第二章敏捷开发研究 2 1 敏捷开发5 2 2 敏捷开发过程。7 2 3 敏捷模式9 2 3 。ls c r u m 较传统开发模型盼优点1 0 2 3 2s c r u m 于珙窖坷名眵秀e 1 2 2 i 3s c r u m 疡翰璺工2 2 4 本章小结1 3 第三章敏捷项目管理软件解决方案 3 1 软件体系分析1 5 3 1 j 掌售g 碧勺咿1 5 丈j 2 用落善勃绕1 6 3 1 3 三层g 劳前工6 3 2 开发工具1 7 i2 jj 2 洒】7 i2 2 月冒z 工8 i 2 3p h p 工8 3 3 敏捷项目管理系统解决方案1 9 王王j 苏易储择2 9 3 3 2 舆懈次方案】9 3 4j 2 e e 2 1 3 4 1j 2 e e 塞刁幻孵岔2 工 3 4 2 ，2 e e 基吞劈有。2 2 3 4 3j 2 e e 锲钇a p i 与绍斧2 3 3 5 三大流行框架介绍2 s 3 5 1s t r u t s 2 6 3 工2 月函e r n a t e 2 8 j ，：，：j 7s p r i n g 2 9 l 北京邮电大学硕士论文目录 3 6m a s h u p 技术3 1 3 6 1 4 9 ：，争3 1 3 6 2m a s h u p 多尝：型3 2 3 6 3 相关兹刁e 3 3 3 7 本章小结3 s 第四章敏捷项目管理软件的分析与设计 4 1 概述3 7 4 2 商业价值分析3 8 4 3 需求分析3 9 4 4 系统角色分析4 0 4 5 功能设计一4 1 4 6 数据库表设计4 3 4 6 1 兹锚律衷发劳屠乏删4 3 4 6 2 澎务裁据r 庠袤兹i p 4 5 4 6 3 系纷管髫麦掰矛4 6 4 7 本章小结4 7 第五章敏捷项目管理软件的实现 5 1 系鳎i 概述4 9 5 2 软件主要模块的实现5 0 工2 j 菝澎吼叠元旋5 0 5 2 2 南产趔，蹋为毛质量5 工 王2 了办r 袤5 2 5 3 报表设计5 3 5 3 1 版本燃烧曲线( r e l e a s eb u r n d o w nc h a r t ) 5 3 5 3 2 缺陷状态趋势图( d e f e c ts t a t ec h a r t ) 5 5 5 3 3 威贸迸溲乙枣( r a t eo f p r o g r e s sc h a r t ) 5 6 5 4 整体页面展示s 6 5 5 总结5 7 第六章总结与展望 6 1 本文的总结s 9 6 2 进一步的工作6 0 参考文献 附录一 致谢 2 北京邮电大学硕士研究生论文 绪论 1 1 研究背景 第一章绪论 瀑布模型是传统的被广泛采用的软件开发模型，它的核心思想是按工 序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化 的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制 定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基 本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水， 逐级下落。 瀑布模型的线性过程太理想化，受到了广泛的批评，最突出的一点是 围绕需求分析的，通常客户一开始并不知道他们需要的是什么，而是在整 个项目进程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设 计的，但在这种情况下，现实世界的反复无常就显得瀑布模型有些不切实 际了。 同时，即使给定了客户需求，根据这些需求在一定的精确性范围内( 瀑 布模型所建议的) 估算时间和成本是非常困难的。因此，建议只有在客户 需求可以在最初阶段明确并且相对稳定的项目中才使用瀑布模型。 另外瀑布模型还假定设计可以被转换为真实的产品，这往往导致开发 者在工作时陷入困境，通常，看上去合理可行的设计方案在现实中往往代 价昂贵或者异常艰难，从而需要重新设计，这样就破坏了传统瀑布模型中 清晰的阶段界限。 除此以外，瀑布模型必须通过许多的强制完成日期和里程碑来跟踪各 个项目阶段；各个阶段的划分又完全固定，阶段之间也极少反馈，而且在 阶段开发过程中将产生大量文档，极大地增加了工作量；用户只有在项目 生命周期的后期才能看到结果，从而增加了开发的风险；早期的错误可能 要等到开发后期的测试阶段才能发现，进而带来严重的后果。 为了解决问题，敏捷开发模型孕育而生。现在i b m 、t h o g u t w o r k s 、 阿里巴巴等许多公司和团队为了适应新的形势，逐渐向这一开发模式转型， 它是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件 项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集 成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也 北京邮电大学硕士论文绪论 可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 在推广敏捷开发的过程中，一款良好的敏捷项目管理软件变得至关重 要，它的目的在于管理整个敏捷团队和项目，提高整个团队的生产力，保 证敏捷开发思想更好地布置到团队中去，减少人与人之间的交流成本并加 强合作；提高整个团队的效率，提供可定制化的报表跟踪项目状态和风险， 并对现有a g i l ei 具进行集成；同时允许将敏捷流程注入到q a 组中，为 q a 提供最佳实践。 1 2 项目管理软件现状 对于软件项目管理存在多款产品，大致可分为以下几类： 1 传统工具：代表软件为m i c r o s o f tp r o j e c t ，它可以帮助用户编制任 务进度计划、管理各种资源和费用；可以绘制g a n t t 图、各种统计图形、 生成图文并茂的报表。但它的适应的范围太广了，涵盖各行各业的项目， 导致没有什么针对性。 2 表格工具：代表软件为e x c e l ，它到现在为止也是应用最为广泛的 工具之一，它可以方便地记录项目开发过程中的各个条目。但由于它的本 地性，在执行流程化的过程中，每个团队成员必须拥有一份e x c e l 表格， 并且当团队成员的记录有所改变时，得不到及时更新。 3 b u g 跟踪工具：代表软件为b u g z i u a 、j i r a ，它们作为一个产品缺 陷的记录及跟踪软件，能够建立一个完善的b u g 跟踪体系，包括报告b u g 、 查询b u g 记录并产生报表、处理解决、管理员系统初始化和设置。由于 它们的立足点在项目的缺陷上，对于管理整个项目具有一定的局限性。 4 w i k i ：作为一种新型的管理方式，w i k i 具有自由编辑的特性，适 合于小型团队的开发。但由于其记录不具有结构特性，无法进行大型的增 删查改和跟踪。 5 a g i l e 工具：这样工具还比较少，代表软件有m i n g l e 、r a l l y ，这 些软件大多是一些知名的r r 公司开发的，但使用费用十分昂贵。 1 3 本论文的主要工作和创新 2 北京邮电大学硕士论文 绪论 本文主要从a g i l e 模型入手，分析a g i l e 开发的流程，精简冗余过程， 突出重要环节，并设计一套基于w e b 的项目管理软件，评估项目进度， 跟踪软件缺陷，监控开发效率。 传统的软件项目管理软件，基本上是基于瀑布开发模型，对于项目进 度和风险的评估都有一套成熟的系统。而敏捷模型作为一种适应需求变化 的新型的开发模型，在项目评估方面并没有一个既定的标准。它的每一个 迭代开发( i t e r a t i o n ) 都是正常结束的，因此如何设计项目进度报表、缺 陷跟踪报告、团队开发效率报告变得至关重要。 同时，以往的项目管理软件多站在开发者的角度，使用者也大部分是 开发人员。而本软件主要站在管理者和q a ( 质量保证) 的角度，并兼顾 客户的反馈，帮助管理者跟踪项目进展情况，为其做出正确的决策提供足 够的信息。 1 4 论文结构 论文第二章主要对敏捷开发模式进行了研究，包括敏捷开发的各个环 节、敏捷的原则并着重介绍了s c r u m 开发模型以及与传统瀑布模型的对 比：第三章前半部分提出了基于j 2 e e 的三层架构系统，从宏观上介绍了 敏捷项目管理将采用的软硬件技术，后半部分则详细介绍了相关的j 2 e e 技术细节；第四章分模块和分角色对敏捷项目管理软件进行了分析，阐述 了各个部分要实现的功能，并设计了一套数据库表结构；第五章就各个模 块的实现进行了阐述，包括具体的流程和实现方法；最后一章对全文进行 了总结，并提出了进一步的研究工作。 1 5 本章小结 本章主要描述了本研究课题的来源、背景以及研究意义，同时分 析了现在普遍管理项目的工具，并由此提出了本论文的研究方向和主 要工作内容。 北京邮电大学硕士研究生论文 敏捷开发研究 2 1 敏捷开发 第二章敏捷开发研究 敏捷开发( a g i l ed e v e l o p m e n t ) 是一种以人为核心、迭代、循序渐进 的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个 子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一 个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在 此过程中软件一直处于可使用状态。 敏捷开发并不是全新的开发方式，它借鉴了大量软件工程中的方法。 迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法， 在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们也可见到瀑布 式与快速原型法的影子。 敏捷开发可理解为在原有软件开发方法基础上的整合一取其精华， 去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发 的过程中，我们每两周都会得到一个可以工作的软件。这种非常短的循环， 使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结 果。”【1 1 这只是敏捷开发优势中的一部分。敏捷允许开发过程中的需 求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项 目返工借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开 发已经成为解决软件危机的标准答案。 然而，我们不得不面对的现实却是，模式与方法的优化并不意味着 问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。大项 目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目， 合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增 容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高 度，而如果缺乏有效协调手段，新方在法带来众多便利的同时，也会引发 了几乎同样多的问题。 敏捷丌发是由一些业界专家针对一些企业现状提出了一些让软件开 s 北京邮电大学硕士论文敏捷开发研究 发团队具有快速工作、响应变化能力的价值观和原则，并于2 0 0 1 初成立 了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件 开发方法。通过这项工作，他们认为f 1 1 ： 个体和交互胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作胜过合同谈判 响应变化胜过遵循计划 虽然右边也具有价值，但左边的价值远远大于右边。同时，他们还提 出了以下遵循的原则【2 】【3 】： 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使 客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为 客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几 个月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工 作。围绕被激励起来的个体来构建项目。给他们提供所需的环 境和支持，并且信任他们能够完成工作。 在团队内部，最具有效果并富有效率的传递信息的方法，就是面 对面的交谈。工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能 够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。简单是最根 本的。最好的构架、需求和设计出于自组织团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省， 然后相应地对自己的行为进行调整。 为避免软件设计中的腐化，具体到实践，敏捷开发采用了以下面向对 象的设计原则：1 ) 单一职责原则( s r p ) ，就一个类而言，应该仅有一个 引起它变化的原因；2 ) 开放封闭原贝j j ( o c p ) ，软件实体应该是可以扩展 的，但是不可修改；3 ) l i s k o v 替换原贝j j ( l s p ) ，子类型必须能够替换掉它 们的基类型；4 ) 依赖倒置原则( d i p ) ，抽象不应该依赖于细节，细节应该 依赖于抽象；5 ) 接口隔离原贝j j ( i s p ) ，不应该强迫客户依赖于它们不用的 方法。接口属于客户，不属于它所在的类层次结构；6 ) 重用发布等价原 贝, i j ( r e p ) ，重用的粒度就是发布的粒度；7 ) 共同封闭原贝j j ( c c p ) ，包中的 6 北京邮电大学硕士论文 敏捷开发研究 所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产 生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影 响；8 ) 共同重用原贝i j ( c r p ) ，一个包中的所有类应该是共同重用的。如 果重用了包中的一个类，那么就要重用包中的所有类；9 ) 无环依赖原则 ( a d p ) ，在包的依赖关系图中不允许存在环。1 0 ) 稳定依赖原贝j j ( s d p ) ， 朝着稳定的方向进行依赖。1 1 ) 稳定抽象原n ( s a p ) ，包的抽象程度应该 和其稳定程度一致。 敏捷设计就是一个过程，不是一个事件。它是一个持续的应用原则、 模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计 在任何时间都尽可能得简单、干净及富有表现力【4 】。敏捷开发人员不会 对一个庞大的预先设计应用那些原则和模式。相反，这些原则和模式被应 用在一次次的迭代中，力图使代码以及代码所表达的设计保持干净。 2 2 敏捷开发过程 敏捷开发过程可描述如下( 图2 - 1 ) ：两个圆圈表示不同的视角上的 敏捷实践，包括开发者视角和项目管理的视角： 图2 1 敏捷开发过程 7 北京邮电大学硕士论文敏捷开发研究 t e s t d r i v e nd e v e l o p m e n t ( 测试驱动开发) ：它是敏捷开发的最重要的 部分。实现任何一个功能都是从测试开始，首先对业务需求进行分析，分 解为一个一个的用户素材( s t o r y ) ，记录在用户素材卡( s t o r yc a r d ) 上。 然后进行结对编程，一个人依照用户素材，从业务需求的角度来编写测试 代码，另一个人对其进行审查，如有不同意见则进行讨论，直到达成共识。 接着角色对调，由另一个人编写该测试代码的实现。 c o n t i n u o u si n t e g r a t i o n ( 持续集成) ：在以往的软件开发过程中，集成 是一件很复杂的事情，通常很长时间才会做一次集成，这样的话，会引发 很多问题，比如创建未通过或者单元测试失败。敏捷开发中提倡持续集成， 一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于 集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。 一次集成要做哪些事情呢? 它至少包括：获得所有源代码；编译源代码； 运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过， 最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖 率分析等等。 r e f a c t o r i n g ( 重构) ：重构是在不改变系统外部行为下，对内部结构 进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常 是在有新需求过来，现在的系统架构不容易实现，从而对原有系统进行重 构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在 敏捷开发中，重构贯穿于整个开发流程，每一次开发者上传代码之前，都 要对所写代码进行重构，让代码达到简洁可用。值得注意的是，在重构时， 每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只 是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。 p a i r - p r o g r a m m i n g ( 结对编程) ：在敏捷开发中，做任何事情都是结对 的，包括分析、写测试、写实现代码或者重构。结对做事有很多好处，两 个人在一起探讨很容易产生思想的火花，也不容易走上偏路。 s t a n du p ( 站立会议) ：每天早上，项目组的所有成员都会站立进行 一次会议，由于是站立的，所以时间不会很长，一般来说是1 5 2 0 分钟。 会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题： 1 你昨天做了什么? 2 你今天要做什么? 3 你遇到了哪些困难? 站立 会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你 类似的问题，那么在站立会议后，他就会和你进行讨论。 f r e q u e n tr e l e a s e s ( 小版本发布) ：在敏捷开发中，不会出现这种情况， 拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的 8 北京邮电大学硕士论文敏捷开发研究 产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布 的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因 为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档 和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以 客户有新的需求或者需求进行变动，也能很快的适应。 m i n i m a ld o c u m e n t a t i o ( 较少的文档) ：其实敏捷开发中并不是没有文 档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求 以及系统a p i 的用法，如果有新人加入团队，最快的熟悉项目的方法就 是让他看测试代码，而比一边看着文档一边进行调试要高效。 c o l l a b o r a t i v ef o c u s ( 以合作为中心) ：表现为代码共享。在敏捷开发 中，代码是归团队所有而不是那些模块的代码属于者，每个人都有权利获 得系统任何一部分的代码然后修改它，如果有人觉得某些代码有问题，那 他能够对这部分代码重构而不需要征求代码作者的同意。这样每个人都能 熟悉系统的代码，即使团队的人员变动，也没有风险。 c u s t o m e re n g a g e m e n t ( 现场客户) ：敏捷开发中，客户是与开发团队 一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开 发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速 度得到客户的反馈。 a u t o m a t e dt e s t i n g ( 自动化测试) ：为了减小人力或者重复劳动，所 有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对质量 保证人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能 够编写自动化测试脚本或者用工具录制。 a d a p t i v ep l a n n i n g ( 可调整计划) ：敏捷开发中计划是可调整的，并不 是像以往的开发过程中，需求分析 概要设计 详细设计 开发 测试 交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。 而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作 出相应的调整和变化。 敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有 激情有活力的，能够适应更大的变化，做出更高质量的软件。 2 3 敏捷模式 敏捷开发的模式有许多种，常见的有以下几种： 9 北京邮电大学硕士论文敏捷开发研究 极限编程( x p ) ：这种方法强调的是适应性，而不是可预测性。 适合场合：公司并不确切知道自己需要什么样的最终产品。 s c r u m 5 ：这种方法强调的是重新开始迭代过程，而不是企图补 救问题。 适合场合：公司在使用新工具，以及应用软件在开发过程中几乎 肯定会变化。 自适应软件开发沁d ) ：这种方法强调的是速度和灵活性。 适合场合：公司需要应用软件能够迅速见效，还能随客户使用需 求的增长而灵活变化。 动态系统开发方法( o s o m ) ：这种方法最初来源于强调用户参与 的快速应用软件开发( r a d ) 技术。 适合场合：开发人员不是非常了解环境的情况。 功能驱动开发( f d d ) ：这种方法强调的是可预测性以及遵守开发 最佳实践。 适合场合：开发团队必须开发具有特定功能及可读性高于正常水 平的应用软件。 其中s c r u m ( 英式橄榄球争球队) 开发模式是敏捷开发中最重要的一 种，在最近的一两年内逐渐流行起来。其基本假设是： 开发软件就像开发新产品，无法一开始就能定义软件产品最终的规 程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保 证专案成功。s c r u m 将软件开发团队比拟成橄榄球队，有明确的最高目 标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密 地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目 标有明确的推进。 s c r u m 开发流程通常以3 0 天( 或者更短的一段时间) 为一个阶段，由 客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑 选该完成的规格部分，开发团队必须尽力于3 0 天后交付成果，团队每天 用1 5 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排 除。 ” 2 3 1s c r u m 较传统开发模型的优点 s c r u m 模型的一个显著特点就是响应变化，它能够尽快地响应变化。 下面的图片使用传统的软件开发模型( 瀑布模型、螺旋模型或迭代模型) 。 1 0 北京邮电大学硕士论文 敏捷开发研究 随着系统因素( 内部和外部因素) 的复杂度增加，项目成功的可能性就迅 速降低。 图2 - 2 复杂度成功曲线( 瀑布模式) 下图是s c r u m 模式和传统模式的对比( 图2 3 ) ，阴影部分表示s c r u m 模式在相同复杂度下增加的成功率。 c o m pl e x i t y s u c c e s s m e d i u m h i g h c o m p 呐 图2 - 3 复杂度成功曲线( s c r u m 模式) 北京邮电大学硕士论文敏捷开发研究 2 3 2s e r u m 有关名词解释 1 ) b a c k l o g ：可以预知的所有任务，包括功能性的和非功能性的所有 任务。 2 ) s p r i n t ：一次迭代开发的时间周期，一般最多以3 0 天为一个周期。 在这段时间内，开发团队需要完成一个制定的b a c k l o g ，并且最终成果是 一个增量的，可以交付的产品。 3 ) s p r i n tb a c k l o g ：一个s p r i n t 周期内所需要完成的任务。 4 ) s e r u mm a s t e r ：负责监督整个s c r u m 进程，修订计划的一个团队 成员。 5 ) t i m e b o x ：一个用于开会时间段。比如每个d a i l ys c r u mm e e t i n g 的 t i m e b o x 为1 5 分钟。 6 ) s p r i n tp l a n n i n gm e e t i n g ：在启动每个s p n n t 前召开。一般为一天 时间( 8 小时) 。该会议需要制定的任务是：产品管理者和团队成员将 b a c k l o g 分解成小的功能模块，决定在即将进行的s p d n t 里需要完成多少 小功能模块，确定好这个p r o d u c tb a c k l o g 的任务优先级。另外，该会议 还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块 的工作量以小时计算。 7 ) d a i l ys c r u mm e e t i n g ：开发团队成员召开，一般为1 5 分钟。每个 开发成员需要向s e r u mm a s t e r 汇报三个项目：今天完成了什么? 是否遇 到了障碍? 即将要做什么? 通过该会议，团队成员可以相互了解项目进 度。 8 ) s p d n t r e v i e wm e e t i n g ：在每个s p r i n t 结束后，这个t e a m 将这个 s p f i m 的工作成果演示给产品管理者和其他相关的人员。一般该会议为4 小时。 9 ) s p d n tr e t r o s p e c t i v em e e t i n g ：对刚结束的s p r i n t 进行总结。会议 的参与人员为团队开发的内部人员。一般该会议为3 小时。 2 3 3s c r u m 流程 1 ) 将整个产品的b a c k l o g 分解成s p r i n tb a c k l o g ，这个s p d n tb a c k l o g 是按照目前的人力物力条件可以完成的。 2 ) 召开s p r i n tp l a n n i n gm e e t i n g ，划分，确定这个s p d n t 内需要完成的 任务，标注任务的优先级并分配给每个成员。注意这旱的任务是以小时计 1 2 北京邮电大学硕士论文敏捷开发研究 算的，并不是按人天计算。 3 ) 进入s p d n t 开发周期， m e e t i n g 。 4 ) 整个s p r i n t 周期结束， p r o d u c to w n e r 。 在这个周期内，每天需要召开d a i l ys c r u m 召开s p r i n tr e v i e wm e e t i n g ，将成果演示给 5 ) n 队成员最后召开s p r i n tr e t r o s p e c t i v em e e t i n g ，总结问题和经验。 6 ) 这样周而复始，按照同样的步骤进行下一次s p r i n t 。整个过程如下 图所示( 图2 4 ) - 2 4 本章小结 图2 - 4 s e r u m 流程 本章主要从敏捷开发入手，介绍了敏捷过程中一些重要的原则和经 验，然后从开发和管理的角度详尽解释了敏捷过程中的重要环节。最后， 着重介绍了s c r u m 开发模式。 北京邮电大学硕士研究生论文敏捷项目管理软件解决方案 第三章敏捷项目管理软件解决方案 3 1 软件体系分析 随着软件开发技术和网络技术的飞速发展，w e b 应用的复杂程度不 断增加，软件的体系结构的重要性越来越突出。它不但影响系统的设计和 开发进度，还直接影响到系统的后续发展潜力，甚至关系到系统的成败。 根据用户界面与后台数据库之间的层数，可把应用软件分成单层结构，二 层结构，三层结构等几种。 3 1 1 单层结构 单层应用软件由于包含了所有的应用逻辑，从后台最基本的数据处理 到前台对用户的响应以及处理结果的显示，所以应用软件往往比较庞大。 单层软件的优点在于运行效率高，响应快。由于所有的处理在一个程 序中全部完成了，实现功能时没有经过中间层次，所以程序的运行效率往 往比较高，对用户的响应也比较快。 ， 单层软件的缺点在于设计难，开发难，一处修改可能会影响到整体。 由于单层应用软件比较庞大，所以相应的带来一些不利因素：在设计阶段 要求设计人员必须面面俱到，从复杂的逻辑结构中整理出程序设计文档； 在开发阶段，软件开发人员之间的协作也比较困难；在测试和维护阶段， 对软件的局部改动可能会影响到整体；软件发布之后，为适应新的需求， 在开发新版本的软件时，往往要全面调整程序结构，甚至废弃原来大量的 代码。所以单层软件的版本更新往往比较难。更重要的是，单层软件无法 满足网络应用或者分布式应用。所以单层软件结构早已不能满足目前软件 行业发展的需要。在这种情况下，应用程序分成了客户端部分和服务器端 部分两部分，从而形成了两层结构，也称为客户一服务器结构。 北京邮电大学硕士论文敏捷项目管理软件解决方案 3 1 2 两层结构 在两层结构中，用户界面和业务规则在客户端，数据维护在服务器端 实现，这通常由另一个独立的应用程序操作数据库来完成，例如 s q l s e r v e r 或者o r a c l e 等数据库系统。传统意义上的客户一服务器模型就 是指这种应用结构。 应用程序包括用户界面、业务逻辑和数据维护三个部分。把应用程序 分为客户端实现和服务器端实现，在两层结构中，如果把业务逻辑放在客 户端，则往往使得客户端非常笨重；如果把业务逻辑放在服务器层，则往 往难以在数据库系统中实现复杂的应用逻辑。为此，业务逻辑层被单独提 取出来构成中间的一层或多层，形成分布式系统。 3 1 3 三层结构 三层结构把信息系统划分为表示层、业务逻辑层、数据访问层。 ( 1 ) 表示层，是整个系统的用户界面，根据用户操作调用相应的业务逻 辑。它用于检查用户输入的数据，向业务逻辑层进行提交，并接收经过业 务逻辑层处理后返回的客户需要的数据，展示给用户。一般来说，客户层 不存放或存放很少量的业务逻辑。 ( 2 ) 业务逻辑层，是应用系统的关键所在，通常由应用程序或w e b 服 务器实现。它负责根据客户层提交的用户需求从数据库提取相关的数据进 行处理，并把处理的结果返回给客户层以展示给用户。 ( 3 ) 数据访问层，提供数据库支持，即d b m s ，负责管理对数据库数据 的读写，能迅速执行大量的数据更新和检索。现在的主流通常是像 s q l s e r v e r ，o r a c l e ，d b 2 ：等这样的关系数据型数据库( r d b m s ) 。 三层结构中的三层，只是逻辑上的概念。具体实现时，物理结构上的 差异可能会很大。三层可以在一台计算机上，也可以在两台，三台，甚至 更多的计算机上，只要它们在体系上遵循三层结构即可。只不过在一台或 两台计算机上实现三层结构，它的优势时很难体现的。 在三层结构中，每一层支持应用程序的一个独立部分。在事务处理过 程中，每个客户机只向应用服务器发出一个请求，这就减少了网络通信和 竞争。 三层体系结构的优点： ( 1 ) 减轻了客户端的负担。客户端应用程序和应用服务器