敏捷开发方法在ERP系统中研究与实现论文.pdf

大连理工大学硕士学位论文 摘要 敏捷开发方法是一类软件开发方法的统称 其中包括极限编程 s e r u m 方法等 这 类方法重视软件开发过程中人的重要性 强调个体的竞争力 强调人与人之间的交流与 合作 强调可以工作的软件 极限编程方法作为一种敏捷开发方法以其高度可操作性获 得了广泛的研究与关注 目前 企业e r p 系统开发大量采用了传统的软件开发方法 但其成功率并不高 为了探索如何将敏捷开发方法应用到e r p 系统中 论文从敏捷的性质出发 在前人工 作的基础上对敏捷开发方法进行了研究 并在实际项目中加以了实践 通过价值观 原则和实践三个方面对敏捷开发方法进行分析 从关注点 特色和缺 陷三个方面比较了几种特定的敏捷开发方法 然后 把敏捷开发方法的基本实践同传统 的c m m 关键过程域和目标进行了对比 分析了敏捷开发方法运用重构技术 设计模式 和u m l 图的特点 接下来 结合实际e r p 系统 分析了需求变化的特点和使用敏捷开 发方法的优势 将部分极限编程方法的基本实践和部分s e r u m 管理方法 u m l 图 单 体和m v c 设计模式 重构技术和测试先行应用到实践中 并在此基础上 给出了敏捷 开发方法的五个应用规则 在传统方法和敏捷开发方法的比较 以及项目实践的基础上 可以得出这样的结论 在规模不大 业务灵活 管理基础相对较弱的中小型企业e r p 系统开发中 重视敏捷 开发方法的应用 并结合u m l 设计模式以及面向对象思想 可以充分改善开发人员 与客户之间的不良关系 增进有效代码的产出率 提高项目团队的开发质量与速度 降 低开发费用 更易达到项目的最终成功 关键词 敏捷开发 e r p 重构 大连理工大学硕士学位论文 r e s e a r c ha n di m p l e m e n t a t i o no f a g i l es o f t w a r ed e v e l o p m e n ta p p r o a c hi n a ne r p s y s t e m a b s t r a c t a 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 o l o g yi sas e r i e so fs o f t w a r ed e v e l o p m e n tm e t h o d s s u c h 豁e x t r e m ep r o g r a m m i n g s e r u ma n d8 0o i li tf o c u s e so ni n d i v i d u a l sa n di n t e r a c t i o n s c u s t o l n e rc o l l a b o r a t i o na n dw o r k i n gs o f t w a r e s i n c ee x t r e m ep r o 掣锄m i n gi sp e r f o r m e d c o m p a r a t i v e l ye a s i l yi np r a c t i c e i ti ss t u d i e de x t e n s i v e l ya n du s e dw i d e l y c u r r e n t l y t h e t r a d i t i o n a ls o f c w a r ed e v e l o p m e n tm e t h o d sa r em o s t l yu s e di nt h e d e v e l o p m e n to f e r ps y s t e m s h o w e v e r t h es u e e c r a t eo f i m p l e m e n t i n gt h e s es y s t e m si sn o t h i 曲 h e n c e t h i st h e s i sn l a k e sf u r t h e rr e s e a r c ho nt h eb a s i so f t h ep i o n e e r i n gw o r kb ys t a r t i n g f r o mt h ei n t r i n s i cp r o p e r t i e so fa g i l i t y a n dt h em o t t l e da g i l ep r a c t i c e sa l ew e l la p p l i e dt ot h e p r a c t i c a ls y s t e m b ya n a l y z i n gv a l u e s p r i n c i p l e sa n dp r a c t i c e s s e v e r a la g i l em e t h o d sa r ec o m p a r e di n t e r m so fk e yp o i n t s s p e c i a lf e a t u r e sa n di d e n t i f i e ds h o r t c o m i n g s n 忙d i f f e r e n c e sb e t w e e n p r i m a r yp r a c t i c e so fa g i l ea p p r o a c ha n dt h ec m mk e yp r o c e s sa r 髓a n dg o a l sa r ef o c u s e do i l t h ea g i l em e t h o d su s i n gt h eu m l g r a p h t h ed e s i g np a t t e r n a n dt h er e f a c t o r i n gt e c h n o l o g y a r es t u d i e d a c c o r d i n gt oa ne r pp r o j e c t i ta n a l y z c st h ec h a r a c t e r so fc h a n g i n gr e q u i r e m e n t s a n dt h ea d v a n t a g e so f a g i l ea p p r o a c h p u t sp a r t so f x pa n ds e r u mp r a c t i c e s u m lg r a p h s t h e s i n g l e t o na n dm o d e l v i e w c o n t r o l l e r m v c d e s i g np a t t e r n s t h er e f a c t o r i n gl e e h n o l o g y a n d t h et e s t f i r s tp r o g r a m m i n gi n t oa p p l i c a t i o n a n dt h e np r e s e n t sf i v ea p p l i c a t i o nr u l e so fa g i l e m e t h o d s t h e r e f o r e i td r a w sac o n c l u s i o nt h a ta g i l em e t h o d s v i t ht h ea i d so fu m l o b j e c t o r i e n t e di d e a sa n d s i g np a t t e m ss h o l l l db ee m p h a s i z e di nt h ed e v e l o p m e n tp r o c e s so f e r p s y s t e mc h a r a c t e r i z e db yc h a n g e s p e e d a n dt u r b u l e n c e n l ea g i l em e t h o d sc 趾h e l pt h e t e a ms u c c e e di n p r o j e c t s a l t e r t h ed y s f u n c t i o n a lr e l a t i o n s h i p sb e t w e e nc u s t o m e r sa n d d e v e l o p e r s e n h a n c et h eq u a l i t ya n ds p e e do fs o f t w a r ed e v e l o p m e n t a n dc u td o w nt h er e l a t e d c o s t k e yw 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 r p r e f a c t o h n g i i i 独创性说明 作者郑重声明 本硕士学位论文是我个人在导师指导下进行的研究工 作及取得研究成果 尽我所知 除了文中特别加以标注和致谢的地方外 论文中不包含其他人已经发表或撰写的研究成果 也不包含为获得大连理 工大学或者其他单位的学位或证书所使用过的材料 与我一同工作的同志 对本研究所做的贡献均己在论文中做了明确的说明并表示了谢意 作者签名 生垄翌1日期 丝丝 盔丝旦 大连理工大学硕士研究生学位论文 大连理工大学学位论文版权使用授权书 本学位论文作者及指导教师完全了解 大连理工大学硕士 博士学位论文版权使用 规定 同意大连理工大学保留并向国家有关部门或机构送交学位论文的复印件和电子 版 允许论文被查阅和借阅 本人授权大连理工大学可以将本学位论文的全部或部分内 容编入有关数据库进行检索 也可采用影印 缩印或扫描等复制手段保存和汇编学位论 文 作者签名 导师签名 科i 利 都杠 2 生年j 三月 盟曰 大连理工大学硕士学位论文 1 绪论 1 1 研究背景 软件危机 s o r w a r ec r i s i s 爆发于2 0 世纪6 0 年代中期 为了应对 软件危机 专家和学者们开始了软件工程方面的研究 自1 9 9 1 年卡内基梅隆大学软件工程研究所 r c m us e i 推出了软件开发能力成熟度模型 c a p a b i l i t ym a t u r i t ym o d e lf o r s o f t w a r e c m m l 0 版以来 业界就对c m m 给予了高度重视 软件开发者开始遵循c m m 和i s o 体系 既追求软件构造方式的完美性 又注重总体的可预测性 早期的c m m 倾 向于文档和计划驱动 面向阶段以及预测性计划 然而 过于严格的过程并不总给我们 带来美好的结果 传统软件开发方法试图在长时间跨度内对一个软件开发项目制定出详 尽的计划 然后严格按照计划进行软件开发 这类方法在计划制定结束后拒绝变化 因 此它不太适应于需求快速变化的情形 并且大量的早期文档在开发过程结束后变得毫无 价值 有些甚至在开发过程中就己毫无意义 这些文档就像枷锁一样注定了该方法 滞 重 m o n u m e n t a l 的特性 敏捷开发方法是适配性而非预测性 是面向人的而非面向过程 具有短周期小增量 发布的特性 采用敏捷开发方法的开发团队能从客户那里迅速得到反馈信息 可以及时 修正自己的开发路线 朝着胜利的终点一步步逼近 敏捷开发方法的成功项目案例越来 越多 有应用于中小型项目的 如c 3 薪金系纠 o r c a 安全事件响应系统 2 等 也有应 用于大型项目的 如a t l a s 租赁系统 s l i d x 的福利系统 4 等 有些院校甚至将敏捷开发 方法纳入到了软件工程的授课内容 如卡尔加里大学 u n i v e r s i t yo fc a l g a r y 和南艾尔伯 塔理工学院 s o u t h c ma 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 p j 1 2 研究的目的和意义 信息化是企业自身发展的迫切需要 也是当今社会企业提高国际竞争力的必由之 路 e r p e n t e r p r i s er e s o u r c ep l a n n i n g 即企业资源计划系统 是企业信息化的重要组成 部分 是信息化管理的基础和核心 企业上线e r p 是要能把计划 采购 库存 生产 销售 财务等各个环节的真实状况及时 准确地反馈给企业管理层 以便管理层能够迅 速地做出正确的决策 然而 在国内e r p 的成功率并不高 有些企业实施e r p 未满一 年就夭折了 有些企业使用过好几个不同的e r p 系统 换了好几个软件供应商 最终 效果还是不理想 不成功的原因是多方面的 提高e r p 的成功率 除了企业要形成合 适的企业文化外 软件开发团队采用合适的开发方法也是至关重要的 人件 的作者t o md e m a r e o 早在2 0 0 0 年c u t t e rt r e n d sr e p o r t 上就预测 敏捷开 敏捷开发方法在e r p 系统中的研究与实现 发方法 原话说的是x p 对当今时代的作用可与c m m 在上世纪八 九十年代初相媲美 敏捷开发方法最适合解决那些具有快速变化 动荡无序性质的问题 6 信息时代的企业 要勇于创新 并且企业的创新既要好又要快 只有这样才能让企业在竞争中立于不败之 地 在这样一个不断变革的世界里 传统的严格软件开发方法往往难以凑效 敏捷开发 方法却是适宜的 我国9 9 以上的企业是中小型企业 大部分中小企业规模不大 财力有限 经营上 随机应变 比较灵活 业务稳定性差 管理基础薄弱 敏捷开发方法在此大有用武之地 因此研究和实践敏捷开发方法对加快我国企业的信息化进程具有十分重要的意义 敏捷开发方法可以有两个研究方向 一是 对敏捷开发方法自身的研究 不断完善 其理论体系 二是 在实践中应用敏捷开发方法 不断积累实践经验 该文主要是研究 如何将极限编程和s e r u m 方法运用到实践中 并在实践中摸索出适合自己团队的方法 1 3 主要工作 论文的主要工作体现在以下几个方面 1 分析了敏捷开发方法与面向对象 设计模式 重构及u m l 之间关系 2 作者及其他团队成员在某中小型企业e r p 项目的实施过程中 对敏捷开发方法 基本实践做了有意义的改造 以适应整个团队的开发需要 3 在e r p 系统的开发中应用了敏捷开发方法 包括面向对象思想 设计模式 u m l 图 重构技术和测试先行 并作为系统的反馈 修改了原有的辅助工具 4 在总结前人理论和项目实践的基础上 给出了敏捷开发方法的五个应用规则 1 4 组织结构 该文余下部分组织如下 第二部分介绍敏捷开发方法 主要介绍敏捷宣言 敏捷原则以及敏捷开发方法 第三部分主要介绍敏捷开发方法与c m m 面向对象 设计模式 重构和u m l 之 间的关系 第四部分介绍项目背景 项目早期开发方法 需求快速变化的事实以及敏捷开发方 法的优势 第五部分介绍实际项目中敏捷开发方法的应用 在软件开发的艰难时期引进了敏捷 开发方法 并在开发中得到了实践 以及作为反馈对辅助工具进行的改造 第六部分主要介绍通过实践和在总结前人理论的基础上得出敏捷开发方法的应用 规则 最后对论文的工作做出了总结 并对下一步的研究工作进行了展望 大连理工大学硕士学位论文 2 敏捷开发方法 2 1 敏捷 同其他任何复杂的概念一样 敏捷也有许多定义 在此引用j i mh i g h s m i t h 对敏捷 下的定义 敏捷是为了在动荡的业务环境中获益而创造变革和响应变革的能力 该定 义说明了应用环境和敏捷所应具备的能力 敏捷具有四个方面的性质 创造和回应变革 灵活性和即兴创作 与现实的一致性 以及灵活性和结构性的平衡 敏捷所设定的问题涉及变革的创造和回应 敏捷既意味着回应变革的能力 也意味 着创造变革的能力 也就是说敏捷不仅仅是一种反应 更是一种行动 它包含两个方面 一方面 敏捷的组织创造变革 给竞争对手施加压力 另一方面 敏捷的组织接受变革 迅速而又有效地回应商业环境的快速变化 相比而言 前者最重要 创造变革需要创新 固步自封不行 只有创新才能带来新的商业价值 才能引领时代 相反 没有创新的组 织迟早会被时代所遗弃 从而走向失败 回应变革 首先需要承认并意识到变革 墨守 成规和近视观察都不行 只有重视变革的组织才能在变革面前积极应对 并采取适当的 措施予以回应 反之 忽视变革 否定变革和拒绝变革的组织只能在变革的现实面前一 蹶不振 品尝失败的苦果 敏捷组织中的成员既要懂得如何把握机会 又要懂得如何即兴创作 敏捷就是快速 轻松和灵活 并迅速行动的能力 以最少开销完成任务的能力 适应不断变革环境的能 力 不断创新的能力 创新是敏捷成员必不可少的一种能力 缺乏创新能力的个人或组 织很难称得上是敏捷的 敏捷是灵巧的 灵活的 这并不等于说敏捷是不讲究纪律和技巧的 相反 敏捷也 需要纪律和技巧 一个有技巧的敏捷成员比初学者会更敏捷 因为他或者她对质量有更 好的感觉 初学者对质量是好是坏缺少足够的感性认识 只能原地转圈 虽然随时改变 但并没有什么质的进步 在懂得技巧的过程中 必须遵循一定的纪律 脱离纪律谈技巧 可能导致在不适当的时候做出不适当的改变 而这并不是敏捷的本质 敏捷的个人具有 即兴创作的能力 他们对规则和分界线十分清楚 他们也知道手中的问题何时超出可描 述的范围 进入不可描述的领域 他们知道如何将自己的知识扩展到未知领域去实践和 学习 即兴创作能力会在处理严重情况时大放异彩 计划需要现实来检验 它带来的主要问题是计划本身是错误的 如果始终与原有计 划保持高度一致 那么正确的行为往往被拒之门外 其结局通常是失败的 敏捷项目的 敏捷开发方法在e r p 系统中的研究与实现 控制不会这样做 它是使其与商业价值保持一致 敏捷的组织并不拒绝计划 它把计划 当作一种指导 而不是一种控制机制 敏捷的组织会通过短期迭代或类似方法不断检验 计划 并为以后的计划制定指明方向 在一个时间段只做短期计划 只对那些重要的或 者优先级高的特性做计划 这是敏捷的计划制定方法 一旦这些特性完成 就交给用户 只有在得到用户认可后才继续下一轮迭代 一般来说 重要的特性或者优先级高的特性 短期改变不会太大 采用这些特性制定计划并在短期内完成 会提高项目的成功率 保 持与现实一致 有两种非敏捷的极端行为 一种是计划一切内容 另一种是不做任何计划 两者都 容易做到的 也容易失去对方的优势 没有计划 容易失去方向 敏捷无从谈起 只能 是盲目的反应 计划一切又容易失去灵活性 失去敏捷的空间 导致与现实的脱节 只 有调整好两者的关系 才能做到真正意义上的敏捷 敏捷的组织既将有关内容限定得足 够窄 以便于做得出色 而又不至于太窄而限定研究和调整 成为敏捷意味着既要相信 自己制定计划的能力 又要相信自己响应变革的能力 敏捷需要计划 但不拘泥于计划 重要的是需要做好灵活性和结构的平衡 2 2 敏捷宣言与原则 2 0 0 1 年初 一些软件开发方法专家聚集在美国犹他州的滑雪胜地s n o w b i r d 的一幢 大楼中 一起交谈 讨论 寻找共同话题 通过交谈 1 7 名与会代表发现了他们所使用 的方法确实存在着许多共同点 希望能将这些共同点记录下来 也希望记录下来的文档 能拉响软件工业的战斗号角 为此 他们分了三步来进行 第一步 为这类软件开发方法找个正式的名字 虽然这些方法过去常被人称之为 轻 载方法 l i g h t w e i g h tm e t h o d s 但该名字并不足以代表这些方法的共性 会议的结果 是将这些软件方法正式命名为敏捷开发方法 同时组建了敏捷联盟 a 百l ea l l i a n c e 第二步 他们签署了一份价值观声明 即 敏捷开发宣言 t h em a n i f e s t of o r a g i l e s o f t w a r ed e v e l o p m e n t 1 7 1 内容如下 1 个体和交互胜过过程和工具 2 可以工作的软件胜过面面俱到的文档 3 客户合作胜过合同谈判 4 响应变化胜过遵循计划 第三步 敏捷联盟的成员从上述价值观中引出了下面的1 2 条原则 7 i 1 我们最先要做的是通过尽早地 持续地交付有价值的软件来使客户满意 大连理工大学硕士学位论文 2 即使到了开发的后期 也欢迎改变需求 敏捷过程利用变化来为客户创造竞争 优势 3 经常性地交付可以工作的软件 交付的间隔可以从几个星期到几个月 交付的 时间间隔越短越好 4 在整个项目开发期间 业务人员和开发人员必须天天都在一起工作 5 围绕被激励起来的个体来构建项目 给他们提供所需的环境和支持 并且信任 他们能够完成工作 6 在团队内部以及团队之间 最有效果并且最富有效率的传递信息的方式 就是 面对面的交谈 7 可以工作的软件是首要的进度度量标准 8 敏捷过程提倡可持续的开发速度 责任人 开发者和用户应该能够保持一个长 期的 恒定的开发速度 9 不断地关注优秀的技能和好的设计会增强敏捷的能力 1 0 简单是根本的 它是使未完成的工作最大化的艺术 1 1 最好的架构 需求和设计出自于自我组织的团队 1 2 1 每隔一定的时间 团队会在如何才能更有效地工作方面进行反省 然后相应地 调整自己的行为 2 3 敏捷开发方法 确切地定义敏捷开发方法几乎是不可能的 原因是特定的实践总是在变化嘲 然而 敏捷开发方法具有一些共有的特性 渐增式 短周期 小版本渐进交付 协作 业务人员 和开发人员长期紧密地在一起工作和交流 简单易懂 方法本身易学 易修改和易存档 和适配性 即使在最后时刻也能够处理需求变化 9 等 第一 敏捷开发方法把重点放在解决那些具有不确定性又在不断变化的问题上 随 着不确定性程度的增加 严格的传统开发方法取得成功的可能性会迅速下降 而敏捷开 发方法取得成功的可能性会迟缓下降 但当不确定性增加到一定程度时 不管采用哪种 方法 项目的成功率都不会怎么高 也就是说 在一定环境下 敏捷开发方法确实提高 了项目的成功率 但它并不能保证成功 第二 敏捷开发方法强化用户驱动 敏捷开发方法要求客户参与 没有客户参与就 没有敏捷开发方法 只有客户才能知道他真正想要的是什么 但单凭合同或者计划往往 无法满足客户的实际需求 要想少做无用功 就必须让客户参与其中 问题发现得越早 纠正得越及时 就越能为开发团队节约出开发时间 从而提高了软件开发效率 有了客 敏捷开发方法在e r p 系统中的研究与实现 户的参与 需求会朝着最终目的不断变化 开发团队也必须采用敏捷开发方法对此给予 回应 第三 敏捷开发方法强调以人为本 敏捷开发方法是 面向人 p e o p l e o r i e n t e d 的 而非 面向过程 p r o c e s s o f i e n t e d 的 传统的工程方法试图确定一个普遍适用的 过程 使得该过程无论谁使用都会起作用 但是敏捷开发方法告诉我们 没有任何过程 能增加开发团队的技能 所以过程只在开发团队的实际工作中起到支持作用 1 0 1 人是获 得项目成功的最为重要的因素 如果团队中没有优秀的团队成员 使用再好的过程也难 以逃脱失败的结局 同时 不好的过程也可能使最优秀的团队成员失去效用 面向人 并非意味着以某个人为中心 而是要使个体目标与团队共同目标保持一致 第四 敏捷开发方法是 适配性 的而非 预设性 的 传统软件开发方法试图对 一个软件开发项目在很长的时间跨度内制定详细的计划 然后依照计划进行软件开发 只要需求不变 这类方法就一直起作用 但一旦需求改变 该方法就有些失灵了 敏捷 开发方法则不同 它不仅适应变革 而且拥抱变革 同时留意保持代码的质量 l l 其实 敏捷开发方法的目的就是成为适应变化和推动变化的过程 甚至允许改变自身来适应变 化 l o l 总的说来 敏捷开发方法强调开发人员和客户代表之间的密切合作 人与人之间面 对面的交谈 经常性交付有价值的已更新的商业软件 紧凑的 自组织的团队 以及回 应需求不断变化的开发方式和团队组织方式 具体的敏捷开发方法有很多 包括 极限编程 e x t r e m ep r o g r a m m i n g x p s c r u m 动态系统开发方法 d y n a m i cs y s t e m sd e v e l o p m e n tm e t h o d d s d m 自适应软件开发 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 a s d c r y s t a l 方法 特性驱动开发 f e a t u r e d d v e n d e v e l o p m e n t f d d 实用程序设计 p r a g m a t i cp r o g r a m m i n g p p 等 2 3 1 极限编程 极限编程最早由s m a l l t a l k 社群中的大师级人物k e n tb e c k 于1 9 9 8 年倡导 当时实 践的项目背景就是第一章提到的c 3 薪金系统 c h r y s l e r sc o m p r e h e n s i v ec o m p e n s a t i o n p r o j e c t o r a c l e 公司的j i mh a u n g s 曾这么描述极限编程 极限编程是一种成功实践的 有力描述体 1 2 1 极限编程中的 极限 一词来自b e c k 的认识 他认为要将软件开发中 好的原则和实践演绎到极致 1 3 1 或者可以说 为成功做好准备 尽其所能 然后处理结 果 这就是极限的含义 极限编程要求实践者们坦承自己有能力做什么 然后去做力所 能及的事情 同时 欢迎和希望其他人也加入进来 壮大编程队伍 良好的合作关系是 做好事情的保证 除了编码和其他活动以外 工作场所的人际关系也会影响到软件开发 大连理工大学硕士学位论文 团队的生产率和自信心 项目的成功既需要技术又需要良好的合作关系 极限编程致力 于同时解决上述两个问题 极限编程是放弃旧的 低效的技术和习惯而采用新的 有效 的技术和习惯 极限编程是因为你今天的竭尽全力而充分欣赏你自己 极限编程是努力 在明天做得更好 极限编程是要开发人员按照其对团队共同目标所做出的贡献来评价自 己 极限编程是让开发者的一些人性需求在软件开发中得到满足 1 4 包括基本的安全感 归属感 成就感 成长以及亲切感等 接下来从生命周期 角色责任 价值观 原则 实践五个方面来解析极限编程 极限编程的生命周期由五个部分组成 试探 计划 迭代发布 产品化以及维护期 和结束 如图2 1 所示 图2 1 极限编程过程的生命周期 f i g 2 1l i f ec y c l eo f h ex pp r o c e s s 试探是极限编程的起点 目的是充分评估首次迭代所要实现的用户故事 用户故事 是指特征需求 配置或者用户提出的非功能性的需求 用来记录用户故事的纸质卡片被 称作故事卡片 s t o r yc a r d 故事卡片并非记录用户故事的每个细节 极限编程方法强调 面对面的沟通和交流 故事卡片只作简略记录 可以用来建立文档 试探期内 用户的 任务是把希望包含在首次发布版本中的用户故事填写到故事卡片上来 团队成员的任务 有两个 熟悉项目中将用到的工具 技术和开发方法 以及成员间彼此熟悉 敏捷开发方法在e r p 系统中的研究与实现 计划期的主要任务是设置用户故事的优先级和对发布的用户故事和发布日期达成 共识 软件开发程序员对每个用户故事所需的劳动量进行初步估计 整个软件开发团队 根据劳动强度的估计对发布的用户故事和最终日期达成共识 首次发布的日期一般不超 过两个月 迭代发布期的目标是实现一个已充分测试过的系统 为发布作好准备 一次发布需 要经历多次迭代 一个迭代周期较短 约几周时间 通过划分计划时间表 来形成多个 迭代期 在迭代开始前 用户为迭代选择用户故事 在迭代快结束时 对系统进行功能 测试 随着最后一轮的迭代结束 产品的发布也即将进行 通过系统部署来实现系统的产品化 在此之前 还需要对系统性能进行额外的测试 和检查 在产品化期 仍然可能会发现新的变化 是否将这些变化加进当前版本 需要 仔细斟酌 为了给维护和编写文档留下足够多的时间 产品化的迭代周期可能会缩短 从原来的几周可能缩短到一周左右时间 维护期的主要目的是增强系统性能 修正版本中的缺陷 构建重要的发布版本 自 首次版本发布后到项目结束前 开发团队都既需要维护现有运行的系统 又需要执行下 一轮新的迭代 因此 系统的开发速度可能会受到影响 当所有需要实现的用户故事都开发完成时 项目也就进入了结束期 当然 失败的 项目也可能提前进入结束期 在结束期 可能需要编写必要的文档 极限编程方法定义了七种不同角色 分别负责不同任务 这些角色包括负责编写代 码和测试的软件开发人员 负责填写用户故事和功能测试的客户 帮助客户完成和维护 功能测试的测试人员 负责收集反馈信息的信息收集人员 负责整个开发过程和帮助其 他人遵守纪律的教练 负责解决专业问题的顾问 作决策的经理 价值观是知识和理解的另一个层次 极限编程方法中包含5 个指导软件开发的价值 观 沟通 简单 反馈 勇气和尊重 沟通不一定代表行为 所以沟通必须和实际行为 结合起来 另一方面 没有沟通的行为是危险的 是不会进步的 对于创造团队意识和 高效合作意识来说 沟通是十分必要的 k e n t 曾给简单系统制定了四个评价标准 通过 所有测试 体现所有意图 避免重复以及类或者方法数量最少 简单不是一成不变的 昨天简单的解决方案可能在今天仍然能达到预期的效果 但它并不一定还是简单的 无 论是软件开发的细节 系统需求 还是系统架构等方面都不是长久固定不变的 而是动 态变化的 变化不可避免 产生了对反馈的需要 反馈有助于系统及时改进 勇气是指 选择正确的事情 勇敢的完成它 尊重是指团队成员为同一个项目的成功 彼此之间互 相关心 一8 大连理工大学硕士学位论文 价值观并非单独存在 它们彼此平衡和相互支持 系统越简单 沟通的内容就越少 就越有利于沟通的进行 越有利于反馈的获取 反馈是沟通的关键部分 没有反馈 沟 通则无从谈起 加强沟通能够去除那些不需要或者可暂缓的需求 有利于系统简单化 如果缺乏其他价值观的平衡 勇气将会蜕变成低效的 危险的 不顾后果的盲目 表达 真实感受的勇气有助于沟通的顺利进行 放弃错误的解决方案和寻求薪方案的勇气有助 于简单化 寻求真实的勇气有助于增加反馈 团队中的个体都是重要的 每个人对团队 的贡献都应该得到尊重 每个人也应该尊重别人对团队的贡献 如果缺乏尊重 其它价 值观也不复存在 抽象的价值观并不能直接用来指导实践 在价值观和实践之间需要有个中间层 那 就是起着桥梁作用的原则 极限编程方法中 存在1 4 个指导实践的原则 人性化 经 济学 互惠互利 自相似性 改进 多样性 反省 流 机遇 冗余 失败 质量 婴 儿步 接受责任 人是软件开发中最为重要的因素 人性化的原则就是确保软件开发的 这一源动力 优秀的开发者在工作中需要有安全感 成就感 归属感 成长和亲切感 软件开发过程中 除了个人需求 还有团队需求 当两者发生冲突时 既不能总是牺牲 个人需求以满足团队需求 也不能总是不顾团队需求追求个人需求 两者之间必须做个 平衡 两个影响软件开发的经济学方面价值是金钱的时间价值以及系统和团队的可选择 价值 明确的增量设计是金钱价值的体现 所有的实践都应该是增加软件和团队对未来 可选择的价值 互惠互利是极限编程方法中最为重要的原则 也是最难坚持的原则 互 惠互利原则是要寻找一种能够通过解决更多问题 而不是创造更多问题来让人们接受意 见的实践 在软件开发中的自相似性原则是指在一个新环境中应用经验的解决方案 该 原则不一定总能起作用 所以需要不断积累经验 在变化的环境中达到完美的境界是不 可能的 唯一能做的是马上行动 不断完善和改进 这就是改进原则 为了团队共同目 标的多样性原则确保了软件开发中的高效性 反省原则要求开发团队学会分析成功的原 因 或者获取失败的教训 不断学习是反省的行为 软件开发的流是指通过同时参与所 有的开发活动来交付有价值软件的稳定流 该原则表明 平稳的软件流比偶尔的大规模 部署创造的价值更多 极限编程的实践倾向于活动的连续流 而不是离散的阶剧1 4 1 在 软件开发中 软件开发者要学会把问题转化为学习和改进的机遇 这便是机遇原则 为 了确保解决问题 适当的时候采用适当的冗余是不可避免的 有时测试可能是一种冗余 但它是必需的 实在无法继续下去的时候 需要有勇气选择失败 失败原则并不是让我 们在知道怎么做时选择失败 而且在不知道怎么做时 冒点风险可能是通向成功的最佳 捷径 质量原则要求开发者不要通过牺牲质量来获取快速交付的假象 而且事实上 降 低质量常常只能导致更晚的不可预见的交付 而高质量要求通常会导致更快的交付 婴 敏捷开发方法在e r p 系统中的研究与实现 儿步顾名思义 就是每次前进一点 适当的时候前进一大步 实践中表现为每次执行一 个测试 每次集成和测试几小时内有价值的改变 这就是测试先行和持续集成 接受责 任的原则要求团队坚持接受责任原则 而不是指派责任 原则是为了更好地理解实践 极限编程方法包含1 4 个基本实践 坐到一起 完整 团队 富含信息的工作空间 充满活力的工作 结对编程 结对与个人空间 故事 周 循环 季度循环 松弛 1 0 分钟构建 持续集成 测试先行编程 增量设计 坐到一起指的是项目团队应该经常在一起讨论 交流 客户的问题终究是人的问题 单凭技术往往无法彻底解决 坐在一起用感官直觉来交流是十分重要的 一支完整团队应该包括那些可得到的 拥有项耳成功所必需的各种技能和视角的 人 完整团队不是静态不变的 而应该是动态变化的 当某个人或某个组的技能或意见 变得很重要时 就应该将相关人员吸收进团队来 反之 当某个人不再需要时 他或者 她可以离开这支团队 必要的时候可以进入另一支团队 工作空间理应富含有关用户故事 进度 缺陷等信息 许多团队通过分类存放故事 卡片来实现这项实践 另外 工作空间还需要提供其他的人性需求 以确保工作人员在 舒适的环境中高效的工作 充满活力的工作意味着在有效率的时间段内高效地工作是足够 没有必要用今天无 效率的透支来影响接下来好几天的工作效率 否则对个人和团队都是不利的 结对编程是指产品代码的编写工作由坐在同一台机器前的两个人共同完成 结对编 程是辛苦的 但结对并不意味着没有了个人空间 尊重个体的差异很重要 故事实践强调尽早估算 e a r l ye s t i m a t i o n 为业务和技术观点的交流提供了更早的 机会 周循环或者季度循环都是针对迭代周期而言的 其实践就是一次做一周或一个季度 的工作 在每周或季度的开始时候举行会议 会议的内容包括回顾以前的工作 确定这 周或季度所要实现的故事 寻找瓶颈 以及团队成员接受任务等 松弛可以使团队成员交付比承诺更多的故事 对建立和重建信任关系很有裨益 1 0 分钟构建指的是在1 0 分钟以内自动构建整个系统和运行所有的测试 它是一种 理想状态 该实践给出了三条线索来达到这一理想状态 1 0 分钟自动构建 如果不能自 动构建 首先实现自动化 然后构建系统的改变部分 可以只测试那些因为改变而存在 风险的系统 持续集成要求及时对改变的地方进行集成和测试 这对于保持开发团队的同步来说 是非常必要的 并且持续集成应该是足够全面的 以保证部署系统的简洁性 大连理工大学硕士学位论文 测试先行编程实践给编码带来了诸多益处 使编码有针对性 反馈设计质量 为软 件开发提供了安全性保障 建立信任以及高效的节奏感等 增量设计是指系统设计应力求简单化 每天检查设计能否适应当天的系统需求 在 适当的时候适当的地方及早进行设计改进 重构在此大有用武之地 上述基本实践并非极限编程的全部 但它们提供了一个尊重 沟通和反馈的基础 孕育着简单和勇气 1 4 充分体现了极限编程的价值观和原则 团队成员可以通过这些实 践不断增长信心和能力 但是 并不是每个项目的开发都适合直接采用或者需要采用上 述所有的基本实践 项目团队必须根据项目的不同而采取不同的实践 在开发中 可能 需要增加一些实践 也可能需要修改一些实践 极限编程对敏捷运动的贡献有很多 其中关键的一项是改变了开发人员与客户的不 良关系 这对软件开发来说是十分重要的 极限编程是业界众多实践的总结 再加上它 的高度可操作性 所以它在敏捷开发方法中一马当先 获得了广泛的研究与关注 有关 文献也有很多 它们极其广泛地传播了敏捷开发方法的思想 但极限编程方法也不是放 之四海而皆准的 项目成功率还会受到影响软件开发团队之间相互交流的诸多因素 特一 有的商业文化以及无法克服的技术障碍等等的影响 关于极限编程的主要争议有两点 缺乏文档和适用于小团队的局限性 因此 当把它应用到最适合的领域之外时 可能需 要进行适当的调整 2 3 2s c r u r a s e r u m 名称来自英式橄榄球 有并列争球的意思 最初由k e ns c h w a b e r 和j e f f s u t h e r l a n d 提出 后来m i k e b e e d l e 也参与协作 s e r u m 方法的提出 旨在寻求充分发挥 面向对象和构件技术的软件开发方法 是对迭代式面向对象方法的改进 s e r u m 方法把 工业过程控制理论应用到了系统开发中来 是一种注重灵活性 适配性和生产率等思想 的经验性方法 s e r u m 方法认为软件开发所处的环境和开发技术不会也不应该是一成不 变的 而是经常会发生变化的 软件开发团队成员必须学会如何在这样一个不断变更的 环境中有效工作 必须学会如何才能开发出适应性强的软件系统 软件开发过程更是一 种经验过程 而不是确定性过程 确定性过程是可描述的 可预测的 确定的可重现行 为结果的过程 并且可以通过科学方法对其优化 经验过程与之不同 它通过观察输入 和输出不断进行度量 采用的是一种黑箱 b l a c kb o x 方法 并结合经验判断对黑箱进行 调控 从而产生满意的输出 s e r u m 方法极力倡导自我组织的团队 自我管理的团队 团队的日常考核以及避免预测性过程 s e r u m 项目管理的重点是最大程度地改善 环境 监控支付特性 并不断加以调整 以响应变化的需求 在s e r u m 项目中 环境为开发团 敏捷开发方法在e r p 系统中的研究与实现 队成员的交互提供便利 团队成员相信交流 彼此协作 学会调整和知识共享对于产品 交付来说是至关重要的 s e r u m 过程大致可分为三个阶段 开发前 开发期和开发后 如图2 2 所示 开发期开发后 图2 2s e r u m 过程 f i g 2 2s e r u mp r o c e s s 从图2 2 中可以看出 开发前期包含两部分 即计划和体系结构设计或者高水平设 计 计划包括待开发系统的确定 设定预期目标 s e r u m 方法把急待完成的一系列任务 称为待办事宜 b a d d o g 包括未细化的产品功能要求 缺陷 客户提出的改进 具有竞 争力的功能和技术升级等等 将待办事宜按优先级和估算代价排序 构成待办事宜列表 待办事宜列表应该包括当前己知的全部需求 待办事宜列表会受待办事宜的新增 待办 事宜的更新和细化 待办事宜优先级变化和估算更加准确的影响 因此 待办事宜列表 是可变的 在体系结构设计段 软件开发团队需要充分考虑实现新增待办事宜项对既有 系统会产生什么样的影响 同时确定系统所需的变化 从而改善系统的性能 期间的活 动包括针对产品待办事宜项的体系结构设计以及准备系统发布内容的初步计划 即试探 性的设计和原型活动 开发期是s c r u m 方法的敏捷部分 s e r u m 方法重视可能引起变化的环境或技术 例 如时间框 质量 需求 资源 开发技术和工具 甚至开发方法等 与传统方法不同 大连理工大学硕士学位论文 s e r u m 方法并非仅在软件开发初期考虑这些问题 而是在整个开发过程中时刻关注它们 的变化 并设法加以控制 以便灵活地适应变革 9 1 在s e r u m 方法中 开发周期是一个 为期3 0 天的 被称为s p r i n t 冲刺 的迭代 用于迭代任务的待办事宜称作s p r i n t 待办事 宜 其粒度一般为几小时到十几小时不等 s p r i n t 待办事宜会随着迭代的进行而不断更 新 新的任务经常是出现在每天迭代开始前 随着s p r i n t 待办事宜的增多 软件开发团 队会设法改进他们创造新待办事宜的能力 在开发后期 问题基本上都得到了解决 几乎不可能再有什么新问题或者尚未处理 的问题 本阶段的主要任务是系统集成 系统测试 发布最终版本 编写文档以及指导 培训等 在s e r u m 方法中 完成全部需求的时刻 也就是欢迎开发后期到来的时刻 s e r u m 方法定义六种角色 s e r u m 主管 产品所有人 s e r u m 团队 客户和经理 他们有着各自不同的任务和职责 s e r u m 主管是s e r u m 方法引进的一个新角色 对s e r u m 的成功与否负总责 其职责范围包括确保项目按计划进行 贯彻s e r u m 规则 价值观和 实践 监听过程 并扫除开发过程中的障碍 以保证团队高效工作 他们既要与项目团 队 也要与客户和经理打交道 产品所有人由s e r u m 主管 客户和经理三方选举产生 对整个项目负官方责任 产品所有人管理 控制和创建产品待办事宣列表 并对其编排 优先级 为待办事宜项估算任务量 将待办事宜问题转化为待开发特性 对有关任务具 有最终决定权 s e r u m 团队是项目团队 基于s p r i n t 待办事宜工作 为了保证s p r i n t 成 功 他们有权决定必需的行为和自我组织 举例来说 他们参与强度估算 制作s p r i n t 待办事宜项 回顾产品待办事宜项 建议从项目中需移除的障碍 客户参与产品待办事 宜项有关的任务 经理决定项目中必须遵守的规范 会议制度等 经理也参与目标和需 求的设定 可以选择产品所有人 规范开发过程 同s e r u m 主管一起削减待办事宜 谈到s e r u m 方法 就不得不谈到它的价值观和实践 s e r u m 价值观包括五个方面 承诺 c o m m i t m e n t 关注 f o c u s 公开 o p e n n e s s 尊重 r