XP12个最佳实践.docVIP

现场客户 ( On-site Customer ) XP： 要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试。 评述：现场用户可以从一定程度上解决项目团队与客户沟通不畅的问题，但是对于国内用户来讲，目前阶段还不能保证有一定技术层次的客户常驻开发现场。解决问题的方法有两种：一是可以采用在客户那里现场开发的方式；二是采用有效的沟通方式。 项目：首先，我们在项目合同签署前，向客户进行项目开发方法论的介绍，使得客户清楚项目开发的阶段、各个阶段要发布的成果以及需要客户提供的支持等；其次，由项目经理每周向客户汇报项目的进展情况，提供目前发布版本的位置，并提示客户系统相应的反馈与支持。 代码规范 ( Code Standards ) XP： 强调通过指定严格的代码规范来进行沟通，尽可能减少不必要的文档。 评述： XP对于代???规范的实践，具有双重含义：一是希望通过建立统一的代码规范，来加强开发人员之间的沟通，同时为代码走查提供了一定的标准；二是希望减少项目开发过程中的文档，XP认为代码是最好的文档。对于目前国内的大多数项目团队来说，建立有效的代码规范，加强团队内代码的统一性，是理所当然的；但是，认为代码可以代替文档却是不可取的，因为代码的可读性与规范的文档相比合适由一定的差距。同时，如果没有统一的代码规范，代码全体拥有就无从谈起。 项目： 在项目实施初期，就由项目的技术经理建立代码规范，并将其作为代码审查的标准。 每周40小时工作制 ( 40-hour Week ) XP： 要求项目团队人员每周工作时间不能超过40小时，加班不得连续超过两周，否则反而会影响生产率。 评述： 该实践充分体现了XP的以人为本的原则。但是，如果要真正的实施下去，对于项目进度和工作量合理安排的要求就比较高。 项目： 由于项目的工期比较充裕，因此，很幸运的是我们并没有违反该实践。 计划博弈 ( Planning Game ) XP： 要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围。 评述： 项目的计划在建立起来以后，需要根据项目的进展来进行调整，一成不变的计划是不存在。因此，项目团队需要控制风险、预见变化，从而制定有效、可行的项目计划。 项目： 在系统实现前，我们首先按照需求的优先级做了迭代周期的划分，将高风险的需求优先实现；同时，项目团队每天早晨参加一个15分钟的项目会议，确定当天以及目前迭代周期中每个成员要完成的任务。 系统隐喻 ( System Metaphor ) XP： 通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。 评述： XP在系统实现初期不需要进行详细的架构设计，而是在迭代周期中不断的细化架构。对于小型的系统或者架构设计的分析会推迟整个项目的计划的情况下，逐步细化系统架构倒是可以的；但是，对于大型系统或者是希望采用新架构的系统，就需要在项目初期进行相信的系统架构设计，并在第一个迭代周期中进行验证，同时在后续迭代周期中逐步进行细化。 项目： 开发团队在设计初期，决定参照STRUTS框架，结合项目的情况，构建了针对工作流程处理的项目框架。首先，团队决定在第一个迭代周期实现配件申请的工作流程，在实际项目开发中验证了基本的程序框架；而后，又在其它迭代周期中，对框架逐渐精化。 简单设计 ( Simple Design ) XP： 认为代码的设计应该尽可能的简单，只要满足当前功能的要求，不多也不少。 评述： 传统的软件开发过程，对于设计是自顶而下的，强调设计先行，在代码开始编写之前，要有一个完美的设计模型。它的前提是需求不变化，或者很少变化；而XP认为需求是会经常变化的，因此设计不能一蹴而就，而应该是一项持续进行的过程。Kent Beck认为对于XP来说，简单设计应该满足以下几个原则： 成功执行所有的测试； 不包含重复的代码； 向所有的开发人员清晰地描述编码以及其内在关系； 尽可能包含最少的类与方法。对于国内大部分的软件开发组织来说，应该首先确定一个灵活的系统架构，而后在每个迭代周期的设计阶段可以采用XP的简单设计原则，将设计进行到底。 项目： 在项目的系统架构经过验证后的迭代周期内，我们始终坚持简单设计的原则，并按照Kent Beck的四项原则来进行有效的验证。对于新的迭代周期中出现需要修改既有设计与代码的情况，首先对原有系统进行代码重构，而后再增加新的功能。 测试驱动 ( Test-driven ) XP： 强调测试先行。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。 评述： RUP与XP对测试都是非常的重视