从一个项目谈xp在国内的应用

《从一个项目谈xp在国内的应用》由会员分享，可在线阅读，更多相关《从一个项目谈xp在国内的应用（8页珍藏版）》请在金锄头文库上搜索。

1、从一个项目谈从一个项目谈 XP 在国内的应用在国内的应用 目前国内对于 XP 方面的研究和应用此起彼伏，各种关于 XP 的书籍争相出版，对于以 XP 为代表的“敏捷软件工程“方法的争论也在网络上随处可见。 之所以出现这样的情况，是因为国内的用户在软件项目的实施过程中遇到了很多问题，例如项目的交付时间推迟、用户需求变更频繁等，我们的软件工程师迫切的希望能够找到解决问题的“银弹“。对于高度动态、通过非常短的迭代周期来应对需求变化的极限编程方法论来讲，确实能够从一定程度上解决问题。但是，对于国内的软件开发项目来说，XP 并非“银弹“，它的一些最佳实践不是都适合国内的情况。本文结合一个具体的软件开发项

2、目，讨论一下 XP 在国内的应用情况。 一一 XP 简介简介 1.1 传统软件开发方法 在最近的数十年中，很多企业的 CEO 们都面临着增加盈利的压力，因此，他们采用各种方法，例如裁员、业务外包、BPR、ERP、CRM 等等。以上种种，使得世界 500 强的大部分企业在 20 世纪 90 年代的后期一直保持者二位数的利润增长。但是很多迹象表明，在传统的企业业务模型中已经没有多少可供削减开支的地方，因此，需要进行彻底的改革。在软件开发领域，情况更是如此。 自上个世纪 60 年代以来，软件工程思想逐渐形成与发展，也出现了很多软件开发模型与方法，例如瀑布模型、快速原型、增量模型和螺旋模型等1。而在

3、90 年代以后，卡耐基梅隆软件学院推出的 CMM，更是对于软件开发的过程管理，提出了确切的衡量指标。但是，最近的研究表明，有 50的项目会拖延交付，有 30以上的项目会超出预算，软件开发领域的项目情况比软件工程刚刚提出的时候相比，只是有很小的提高。详细的数据（数据来自美国 GSM 研究机构, Michael Mah）如下表所示： 政府信息部门 ( 1979 ) 50% 超出预算 60 延期交付 45 不能使用 29 无法交付 2 交付后不能使用 来自各个行业的 210 个项目 ( 1997-1999) 40 项目延期交付，平均延期交付时间 67%30% 项目超出预算，平均超支 167 传统的软

4、件开发过程，以 RUP 为代表，强调项目的可控性，是一个用例驱动的基于 UML 和构件式架构的迭代增量式开发过程。RUP 定义了初始、细化、实现和部署 4 个阶段，分别对应着关键里程碑的划分。RUP 对于角色、流程、工件和活动的要求是灵活、可配置的，所以它广泛的适用于各种类型的项目。但是，在 RUP 的各个流程碑，都规定了要交付的成果，尤其是对于需求的变更以及文档，它强调及时的更新与同步。以上这些都决定了 RUP 是一种重量级的软件开发方法，比较适合大中型的项目和产品开发。 1.2 XP 以及其核心价值 最近，出现了很多轻量型的软件开发方法，例如水晶模型、适应模型以及极限编程等。它们都强调，软

5、件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势， 而弱化人的缺点， 突出了人在软件开发过程中的作用2。 Kent Beck在XP的开篇之作 Extreme Programming Explained - Embrace Change中提出了极限编程这一创新的软件过程方法论。极限编程是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化。在极限编程中，包括四个基本活动：编码、测试、聆听与反馈 Kent Beck 指出，XP 有四个核心价值是我们应该注意的： 沟通：项目中发现的问题往往是由于开发人员与设计人员、设计人员与客户之间的 沟通不畅造成的，因此，在 XP 项

6、目中没有沟通是不可能的。 简单：XP 认为应该尽量保持代码的简单，只要它能工作就可以。Kent Beck 指出与 其实现一个复杂的的系统，不如设计一个能够满足目前需要的、简单的系统，因为你 所考虑的情况可能永远都不会发生。 反馈：尽快获得用户的反馈，并且越详细越好，使得开发人员能够保证自己的成果 符合用户的需要。 勇气：这是最重要的核心价值。因为 XP 强调要“拥抱变化“，因此对于用户的反馈， 要勇于对自己的代码进行修改，丢掉坏的代码。 下面我们将要谈到的 XP 的最佳实践就体现了上述四个核心价值。实际上，XP中并没有多少新的观点，它的一些最佳实践也都是长久以来都在使用中的。 1.3 XP 的

7、适用环境 从 XP 的核心价值中我们可以看到，XP 弱化针对未来需求的设计，非常注重当前的简化。它的实践，有一个非常关键的假设就是开发人员只注重眼前需求而依赖重构来适应需求的变动所带来的风险与开销要小于需求变化使得事先充分设计失效的代价；反之，实施 XP 就是不明智的。 因此, XP 适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP 在平衡短期和长期利益之间做了巧妙的选择。 我们可以看到，XP 并不是解决问题的“银弹“，它也有不适合的情况。Beck 曾经建议在以下情况下不宜采用 XP： 中大型的

8、项目（项目团队超过 10 人）； 重构会导致大量开销的应用； 需要很长的编译或者测试周期的系统； 不容易进行测试的应用； 团队人员异地分布的项目； 不能接收 XP 文化的组织和团队； 二 项目概况及背景 二 项目概况及背景 我们公司是亚洲领先的电子商务解决方案供应商， 在 J2EE 架构的项目执行方面有丰富的经验，结合 RUP 形成了自己的一套电子商务项目实施方法论，并在多个项目中成功进行实施。同时，由于具体项目时间和成本的限制，也出现了许多问题，主要有以下两点： 项目交付后，用户提出很多的修改意见，有些甚至涉及系统架构的修改：出现这种 情况的主要原因是很多项目虽然是采用增量迭代式的开发周期，

9、 但是在部署前才发布 版本，用户只是在项目部署后才看到真正的系统，因此会发现很多界面、流程等方面 的问题； 对于用户提交 BUG 的修改周期过长：开发人员在作开发的时候，对于单元测试的重 视程度不够，模块开发结束后就提交给测试人员进行测试，而测试人员由于时间的关 系，并不能发现所有的问题；在用户提交 BUG 后，开发人员由于项目接近尾声，对 于代码的修改产生惰性，同时又没有形成有效的回归测试方法，因此，修改的周期比 较长。 针对 XP 的核心价值，可以看到，如果我们能够加强与用户的沟通、增加项目中测试实施的力度、提高开发人员的勇气，就可以从一定程度上解决上述问题。 从 2001 年开始，公司内

10、部展开对于 XP 等敏捷方法的研究，希望能够借鉴一些做法，来完善项目方法论。 2002 年 5 月，我们决定在公司的一个新的项目中启用 XP 的一些最佳实践，来检验其效果。 该项目是为一家国际知名手机生产厂商的合作伙伴提供手机配件定购、申请、回收等服务，项目的情况如下表所示： 条目 描述 = 项目名称 合作伙伴管理系统 处理工作流程 9 个 项目周期 43 个工作日 项目金额 25 万 项目小组人员 5 人，其中资深顾问 2 名 = 从上表中可以看出，该项目是一个小型项目，而且项目小组成员对于 XP 在项目开始之前都有一定的了解，另一方面，客户要求的项目周期比我们预期估计的时间有一定的余地，因

11、此我们决定利用这个项目进行 XP 的试验性实践。 三 XP 的最佳实践以及在项目中的应用 三 XP 的最佳实践以及在项目中的应用 在项目执行过程中，我们基本上还是采用 RUP 的软件过程，而没有死板的套用XP 的做法，例如：在需求分析阶段，我们还是采用 Use Case 来对需求进行描述，而不是 XP 规定的 CRC 卡片；在系统分析与设计阶段，首先进行系统的架构设计，而不是简单的套用 XP 的“简单设计“实践。 下面我们结合项目的具体情况，讨论一下 XP 的 12 个最佳实践。 1. 现场客户 ( On-site Customer ) o XP： 要求至少有一名实际的客户代表在整个项目开发周

12、期在 现场负责确定需求、回答团队问题以及编写功能验收测试。 o 评述：现场用户可以从一定程度上解决项目团队与客户沟通不 畅的问题，但是对于国内用户来讲，目前阶段还不能保证有一 定技术层次的客户常驻开发现场。解决问题的方法有两种：一 是可以采用在客户那里现场开发的方式；二是采用有效的沟通 方式。 o 项目：首先，我们在项目合同签署前，向客户进行项目开发方 法论的介绍，使得客户清楚项目开发的阶段、各个阶段要发布 的成果以及需要客户提供的支持等；其次，由项目经理每周向 客户汇报项目的进展情况，提供目前发布版本的位置，并提示 客户系统相应的反馈与支持。 2. 代码规范 ( Code Standards

13、 ) o XP： 强调通过指定严格的代码规范来进行沟通，尽可能减少 不必要的文档。 o 评述： XP 对于代码规范的实践，具有双重含义：一是希望通 过建立统一的代码规范，来加强开发人员之间的沟通，同时为 代码走查提供了一定的标准；二是希望减少项目开发过程中的 文档，XP 认为代码是最好的文档。 对于目前国内的大多数项目团队来说，建立有效的代码规范， 加强团队内代码的统一性，是理所当然的；但是，认为代码可 以代替文档却是不可取的，因为代码的可读性与规范的文档相 比合适由一定的差距。 同时，如果没有统一的代码规范，代码全体拥有就无从谈起。 o 项目： 在项目实施初期，就由项目的技术经理建立代码规范

14、， 并将其作为代码审查的标准。 3. 每周 40 小时工作制 ( 40-hour Week ) o XP： 要求项目团队人员每周工作时间不能超过 40 小时， 加班 不得连续超过两周，否则反而会影响生产率。 o 评述： 该实践充分体现了 XP 的“以人为本“的原则。但是，如 果要真正的实施下去，对于项目进度和工作量合理安排的要求 就比较高。 o 项目： 由于项目的工期比较充裕，因此，很幸运的是我们并 没有违反该实践。 4. 计划博弈 ( Planning Game ) o XP： 要求结合项目进展和技术情况，确定下一阶段要开发与 发布的系统范围。 o 评述： 项目的计划在建立起来以后，需要根据

15、项目的进展来 进行调整，一成不变的计划是不存在。因此，项目团队需要控 制风险、预见变化，从而制定有效、可行的项目计划。 o 项目： 在系统实现前，我们首先按照需求的优先级做了迭代 周期的划分，将高风险的需求优先实现；同时，项目团队每天 早晨参加一个 15 分钟的项目会议， 确定当天以及目前迭代周期 中每个成员要完成的任务。 5. 系统隐喻 ( System Metaphor ) o XP： 通过隐喻来描述系统如何运作、新的功能以何种方式加 入到系统。 它通常包含了一些可以参照和比较的类和设计模式。 XP 不需要事先进行详细的架构设计。 o 评述： XP 在系统实现初期不需要进行详细的架构设计，而是 在迭代周期中不断的细化架构。对于小型的系统或者架构设计 的分析会推迟整个项目的计划的情况下，逐步细化系统架构倒