文档介绍：--------------------------校验:_____________-----------------------日期:_____________XP的12个最佳实践现场客户(On-siteCustomer)XP:要求至少有一名实际的客户代表在整个项目开发周期在现场负责确定需求、回答团队问题以及编写功能验收测试。评述:现场用户可以从一定程度上解决项目团队与客户沟通不畅的问题,但是对于国内用户来讲,目前阶段还不能保证有一定技术层次的客户常驻开发现场。解决问题的方法有两种:一是可以采用在客户那里现场开发的方式;二是采用有效的沟通方式。项目:首先,我们在项目合同签署前,向客户进行项目开发方法论的介绍,使得客户清楚项目开发的阶段、各个阶段要发布的成果以及需要客户提供的支持等;其次,由项目经理每周向客户汇报项目的进展情况,提供目前发布版本的位置,并提示客户系统相应的反馈与支持。代码规范(CodeStandards)XP:强调通过指定严格的代码规范来进行沟通,尽可能减少不必要的文档。评述:XP对于代码规范的实践,具有双重含义:一是希望通过建立统一的代码规范,来加强开发人员之间的沟通,同时为代码走查提供了一定的标准;二是希望减少项目开发过程中的文档,XP认为代码是最好的文档。对于目前国内的大多数项目团队来说,建立有效的代码规范,加强团队内代码的统一性,是理所当然的;但是,认为代码可以代替文档却是不可取的,因为代码的可读性与规范的文档相比合适由一定的差距。同时,如果没有统一的代码规范,代码全体拥有就无从谈起。项目:在项目实施初期,就由项目的技术经理建立代码规范,并将其作为代码审查的标准。每周40小时工作制(40-hourWeek)XP:要求项目团队人员每周工作时间不能超过40小时,加班不得连续超过两周,否则反而会影响生产率。评述:该实践充分体现了XP的"以人为本"的原则。但是,如果要真正的实施下去,对于项目进度和工作量合理安排的要求就比较高。项目:由于项目的工期比较充裕,因此,很幸运的是我们并没有违反该实践。计划博弈(PlanningGame)XP:要求结合项目进展和技术情况,确定下一阶段要开发与发布的系统范围。评述:项目的计划在建立起来以后,需要根据项目的进展来进行调整,一成不变的计划是不存在。因此,项目团队需要控制风险、预见变化,从而制定有效、可行的项目计划。项目:在系统实现前,我们首先按照需求的优先级做了迭代周期的划分,将高风险的需求优先实现;同时,项目团队每天早晨参加一个15分钟的项目会议,确定当天以及目前迭代周期中每个成员要完成的任务。系统隐喻(SystemMetaphor)XP:通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。XP不需要事先进行详细的架构设计。评述:XP在系统实现初期不需要进行详细的架构设计,而是在迭代周期中不断的细化架构。对于小型的系统或者架构设计的分析会推迟整个项目的计划的情况下,逐步细化系统架构倒是可以的;但是,对于大型系统或者是希望采用新架构的系统,就需要在项目初期进行相信的系统架构设计,并在第一个迭代周期中进行验证,同时在后续迭代周期中逐步进行细化。项目:开发团队在设计初期,决定参照STRUTS框架,结合项目的情况,构建了针对工作流程处理的项目框架。首先,团