敏捷软件开发和极限编程介绍

敏捷软件开发和极限编程介绍0. 软件开发的本质 先让我们看看一般的产品生产： 例一，汽车生产。原材料、配件等采购完毕（我这里说到了采购配件，这相当于把部分功能的生产转交给其他职能公司。对应到软件生产的(子)项目外包。这个话题在本文就不扩展了），进入生产、组装、测试车间，进行一系列规定的工作流程。正常情况下，如果不发生不可抗拒的事件，那么可以按时完成合同规定的交付。这中间不会有什么变动性和不可预测性。 例二，再来看一个例子，比如某人想盖一栋房子，他想使用环保材料，当开发商给出房子的草图、价格预算，交给他时，他可能会改变主意。在建造房子的过程中，他的一些想法会逐渐明朗化。当房子盖好之后，实物呈现在他眼前时，原先他的那套装修想法也可能根据房子的实际样子来做调整，比如厨房的布局、主卧的装潢等。总的来说，事先的计划遇上了变化，站在“客户至上”的位置上，开发商业就要改变计划，满足客户的新需要。至于如何操作，那是合同谈判的事。客户改变想法是有理由的，因为原先那一套东西都是构筑在设计中的（纸质设计图，有的开发上会提供3D图形或动画），客户直到见到实物，才会有他进一步的，更明确的想法。 软件开发是也生产性的行业，他的产品是交付给客户的软件。类比上面的例子，软件开发更接近于建筑行业，需求会变动，每次生产的东西都不太一样，甚至大不一样。更例外的一点，软件开发的工作量和时间估计比建筑生产更具备不确定性。这种不确定性来自于需求变动、资金支持、技术风险、人员流动、质量控制、功能范围的确定等。 （另外，一般来说通常客户只能规定四个变量 “代价、时间、质量、范围”中的三个，另外一个就是开发团队来选择了，比如客户准备花$XXX在这个月底实现所有功能点；那么在压力下，质量的选择就是开发团队来确定了；否则就得调整客户选择的其他三个变量。这四个变量之说来自拥抱变化，极限编程的开山之作。） 总的来说，软件生产的本质是具备创新性的新产品开发。 新产品开发有那些特征呢？ 不可能在前期创建一成不变的、详细的规格说明。 在开始阶段，很难进行预期分析。随着经验数据的出现，计划与估算的可能性才会相应增加。 在开始阶段，识别、定义、调度、和安排所有的细节活动都是不太可能的。通过构建反馈周期，可以推动自适应步骤。 一般情况是主动适应没有定义的变动，并且改动率比较高。 与创新性新产品开发对应的就是具备可预见性的制造。它可以有笨重的前期规格说明、估算、推测计划等。而新产品开发拒绝这些“可靠的”前期规格说明，理由是： 客户或者用户不可能明确知道他们到底要什么。（需要通过逐步的交流和引导让其明确起来） 他们很难陈述所有的需求和知识。 他们想要的许多细节只能在开发过程中逐步展现出来。 细节对于他们可能过于复杂。 当他们看到了产品的开发，他们将可能会改变初衷。 外部压力（比如竞争者的产品或者服务）导致需求的变更或者增加。 1. 近年来软件项目的一些统计数据以及一般性结论 正是因为软件开发不是循规蹈矩的可预见性的生产活动，而是具创新性的新产品开发活动，所以很多采用遵循可预见性产品生产方式的软件项目最终都以失败收场，不管是小企业还是知名企业。这是新产品开发肯定会有的情况，当然也有方法论的问题。 让我们来看一组软件开发领域的研究和统计数据，这些数据显示了近年来软件项目开发的基本情况： 图1.显示了一个对23,000个项目“成功实施持续时间”的关系，这里的“成功”定义为“项目在资金预算和项目工期内完成，并具备所有预先指定的特征和功能”。（Standish98 Jim Johnson, et al. 1998. ChAOS: A Recipe for Success, 1998. Published Report. The Standish Group）（大家可以用这个定义来衡量一下自己公司的项目成功率如何。）图1. 项目成功率和项目持续时间的关系图 （横坐标为项目持续时间(多少个月)；纵坐标是项目成功的比率） 从这个图中，我们可以看出项目持续时间短的成功率比较高。可见小型项目易于成功。另外也有研究表明小团队的项目更易于获得成功。 图2. 显示了软件项目开展过程中增加进来的变动性因素的情况。项目大小以功能点来衡量，在图中对应横坐标；纵坐标表示需求的变动，仍以功能点为单位。(Jones97 Jones, C. 1997. Applied Software Measurement. McGraw Hill)图2. 需求变更和项目大小之间的关系图 从这个图中我们可以看出需求变动无法规避，典型地，一个项目肯定要面对需求变更的情况，犹如前面的盖房例子。需求变更也影响到项目的成功率。（这里的成功依旧遵从前面的定义。） 图3. 是需求管理中的要求实现的功能点在软件产品交付之后实际被使用情况的比率，这个比率非常惊人地表明几乎一半的功能甚至从为被使用过，相当多一部分功能也很少被使用。在竞争性产品市场上，这些功能点可能是卖点，从而也增加了项目的体积、复杂性，影响到项目的成功率，交付日期。非竞争性领域，对这些需求应该再考虑考虑:-）按20-80原则，20%的功能具备了产品的80%的重要内容)（Johnson02 Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.）。另外，基于风险和客户驱动，可以最大化最常使用的功能。从而一个项目甚至在完成了其20%功能时，就可以成为一个较为有用的阶段性发布。图3. 产品中要求的功能点在实际中的使用情况 另外，有证据显示，随着功能点的增多，每个开发人员的生产效率下降，每个开发人员的错误率上升。（Jones00 Jones, C. 2000. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley）。此外有证据显示失败项目中很大一部分是采用瀑布模型的。 2. 瀑布模型 vs. 迭代模型 有什么样的世界观，就会有什么样的方法论。宇宙万物变动不居。没有绝对的静止。软件项目的实施过程同样如此。需求的变动，资金投入的变化、团队人员进出、质量范围改变、时间期限变更等之间都有一系列联动关系。 应对变动性产生了截然相反的两种态度。 通过分阶段的确定输入、输出来规避变动性，先确认输入是固定不变的（经评审的），这样就可以设计产生想要的下一个输出。这就是所谓“推(Push)”方式，这种方式似乎规避了变动性，注意，我们先前的图2. 说过即便是需求功能点变更也是常有的情况，所以对这种变动性的认识和响应实际上是被推迟到了项目的后期客户验收阶段。 另外一种态度就是积极响应这种变动性，项目开展的整个过程中都鼓励加入新的需求这种方式。 如果忽略许多争论不休的地方，大体上，试图规避或者说想一步到位获取需求的线性开发方式就是对应到“瀑布模型（Waterfall Model）”，而积极响应变化的通过多次反复的增量式过程就是“迭代模型（Interative Model）”。有必要说明一点，瀑布模型的发明者本人说他是迭代模型的拥护着，它只是认为瀑布模型是软件开发中的最简单的一种模型。 我们来看一些图，直观地看一下这两种模型。 图4. 是瀑布模型及其高风险示图，从这个图中我们可以看到随着时间的延续，风险增大。恐或正是因为早期的低风险，才使得人们在很长一段时间内喜欢采用这种模型。害怕风险是人类的通病。并且这种模型很简单，一个单调的过程，容易记忆，操作起来也很简单。需求-设计-实现-测试。图4. 瀑布模型及其高风险示图随着越来越多的证据证明了瀑布模型的高风险和高失败率之后，瀑布模型自身也发生了一些变化，以致继续有人采用这种模型的变体来进行项目开发。正如我以前写过的一个文档，这个模型一般来说不适合于是软件开发上。 图5. 是瀑布模型随着时间的推移，新加入变动性因素（比如需求变更等）的总体代价关系。图5. 瀑布模型的变动性的总体代价 这种模型的一个重要问题就是缺乏反馈。他是一种通过单向的控制来完成的，并且相信这种控制都正确的，比如从ANALYSIS -DESIGN这个过程，根据分析的决议来做设计，并且相信这个ANALYSIS是正确的。这类似于行军打仗，每个上级都认为他的指令被正确的执行，这种指令的正确性暂且不谈(这涉及到每层的控制人员的专业素养)，显然会出现将在外军令有所不受的情况，或者失之毫厘，谬以千里。它的控制流程是Push式的，一层层往下推，如图6.这里只截取了其中一个部分。图6. Push 模式中的一个片段 学过控制理论的人都知道一个最简单的道理，“没有反馈(feedback)，就没有控制”。反馈的基本原理就是把输出反馈给输入，如果偏差很大，就得调整控制过程，最终使得输出满足输入的需求。总体上看，软件开发的输入是客户，输出是软件产品，控制过程是软件项目的开发过程。如果只是一次性地把软件产品交付给客户，显然就是没有反馈。其过程是线形的： “客户 - 项目实施- 客户”这样一个过程，风险很大，所以应该与客户协作，多进行几此这样的过程，让整个开发过程自适应化，最终交付成功得产品。如图7.所示： 图7. 有反馈的，自适应过程 图7.的过程，在项目开发过程中，就是多次的迭代。每个迭代过程都是具体而微的 “需求-设计-实现-测试”单调过程。正是这样的多次迭代，降低了最终交付产品时的风险。 让我们看看迭代过程，下图：图8. 迭代过程示意图每个迭代过程都是具体而微的“需求-设计-实现-测试”，通过这样多次的小步迭代，逐渐构筑成一个完整的系统。如图9.多次的迭代，系统增量式地完善起来。 图9. 多次迭代，系统增量式完善起来 随着时间的推移，每次迭代的重点又有所不同，图8.中我们可以看出，早期迭代过程中，需求的比重大，中期则是设计和实现的比重增大。测试是始终比较重要的环节:-)。测试从始至终地控制着质量，降低风险。下图显示了瀑布型测试和迭代型测试的对比。 每次迭代，完成客户要求的优先级别高的风险大的功能点（对应到user-stories）。每次确定user-stories的时候都允许加入新的需求，一旦确定了下一个迭代过程要实现的user-stories列表之后，直到这个迭代过程结束，都不允许变动这个列表。顺便说一下，所有user-stories的列表就是最终功能测试和验收测试的依据。User-sotiry不同于user-case，简单说，可以将user-story看成是user-case的描述部分，便于编写。而细节则在每次迭代的迭代设计阶段细化规格，再简单地设计，刚够满足应用就行。复杂的设计会有很多问题哦，做集体项目，并不是让你表现代码技巧的时候。图10. 迭代过程中引入变化的总体成本走势每次迭代开始都欢迎加入新的需求变化，这样，就逐步的减小了产品完成时候的风险，迭代模型对于变化的总体成本示意图如图10.所示。 多次迭代的一个好处就是能更准确的估算时间。不建立原型，光是纸上谈兵，很难准确的确定项目的工期/工时和工作量(人月)。所谓原型，可以是抛弃式或非抛弃式的，这种原型的目的除了是验证架构性信息获取正确之外，也可以用来争取客户，获得中标的机会。更重要的是，可以用于估算项目工作量和时间，因为就你的团队，对这个塑造原型的前几次迭代所完成的功能点数量，就可以大致地推断你的团队的生产效率和持续前进的速度。从而把握好如何确定项目的时间。这里有一个图显示了估算项目时间的不确定性：图11.初期迭代之后才能大致估算时间进度表 另外：可以研究一下敏捷迭代开发-管理者指南上提到的如何签定两阶段合同的问题：如果我是甲方，我就会在第一阶段让准备竞标的各公司给出我的需求的一个原型（可以是草图的），最终中标的，对这部分工作也买单。至于合同方面的事，具体的操作由市场部方面研究研究如何操作 :p） 总之，Waterfall-like Model的实施，需要经验丰富的把关者，无论哪个阶段都是如此。（经验和不确定性的关系我们可以看图12。）比如需求分析阶段，获取需求的能力，分析需求的能力；设计阶段更是如此，甚至在整个项目成型之前，在这个设计师脑中就已经存在了一棵枝繁叶茂的项目树，无所不包，甚至包括了哪个枝干的哪个枝丫上果子的大小，颜色，成熟度以及一阵x方向的风吹来如何做运动等等细节。如果不是做过相同的项目，有具备这样精确设计的设计师，你告诉我，我立马去拜访求教。更何况技术普通的一个项目团对呢？！。导师斯大林说：制定了正确的政策，就要靠党的干部执行下去。且不说有个无所不能的领袖人物，还要有忠贞不二的业务水准高的众多干部。每下一个过程都不得有异议（异议是某种反馈）地执行。类瀑布模型就是这套体制，似乎落伍了。（团队成员都知道我有几个精辟的软件工程和软件开发的比喻，不知道大家认为这个比喻怎么样 (o)/，比如说为什么多重继承麻烦且对象模型难于实作等。）图12. 经验和（估算、推测性设计的）不确定性之间的关系图 迭代模型适合于应对变动性的，技术水平一般的，但有进取心的积极求胜的中小项目团队。在复杂性面前强调简单性，在质量保证方面强调反馈的重要性，在决策方面强调群策群力和交流，在技术难点和技术风险上强调的是勇气。没有价值信念，很难让团队成员行动起来驱除惰性。Push模式下的成员，习惯性的成了等待工作任务的“代码员（coder）”（尤其是项目处在审核、需求分析、概要设计、详细设计、文档评审阶段，coder在干吗？），而不是“软件工程师”。在这个满街都是“客户经理”、“销售工程师”的时代，叫一个专业学历的人做个普通的“代码员”，即使薪金有吸引力，职业前景也不见得明朗。有进取心的人会有动动的想法。这是合情合理的。 3. 迭代模式的几种重要方法(以XP为例子)走马观花一把 敏捷方法在坐标图的位置如图13。纵坐标是瀑布模型的严格程度；横坐标是文档的正规程度。图中可见UP(统一过程)是迭代模型，它有比较正式的文档，如果你使用过UP过程，就会发现它会形成大量的文档，图表，UML use-case等，迭代周期可伸缩范围较大。其实作以RUP最为著名。图13.XP与其他几种敏捷方法的示意图 让我们重点看一下XP (Extreme Programming)，是Kent Beck创建的一种增量式迭代(IID)开发方法。这种方法通过快速创建高价值的软件、技能化和平稳的软件开发技术以及灵活响应变化等方面来提高用户满意度。它主要适用于中小团队，交付日期为一年左右的项目。极限的意思就是把各种好的实践发挥到极至，我在单元测试讲座中提过。 文档方面只有一些非正式的工件，例如归总的特征需求索引卡片，称为story-cards。 Xp的重要实践(围绕这些实践，应该进行培训哦:-*)：图14. XP的重要实践 每个实践都值得去研究。对于有争议的地方，寻求个妥协方案出来，总比没有方案好。我就不细说了。可以对比图15.看一下这些实践的实施： 图15. Xp的反馈 这么多的实践，要由人督促指导实行这种方式。所以刚开始实行XP的团队都配备一名教练。更重要的使让大家认同这种方式。孟夫子说“无恒产者无恒心！”。斗胆小辈我加一句“人无价值信念无恒心”。一个开发团队，一种开发模式要建立起一个信念，一种价值观，下面是XP的价值观，也是XP最看重的： 交流 交流的重要性不言而喻，但仍然要鼓励再鼓励。项目组成员的每天10分钟站立式会议，了解当天的任务和项目的状况。开发人员之间的即刻交流做设计和编码等。客户的参与与促进同客户的沟通，其方式为编写验收测试和计划游戏。总之，没有交流就没有软件开发。意义够大了吧。 简单性 简单性是指“做刚好够用的事”。简单性不仅指设计的简单，也指需求、项目管理工具等。比如说项目文档，你三五个人的团队，有时间维护质量上层的文档吗？尤其我要说是设计文档，重中之中是详细设计文档。认为XP不用详细设计是误解，它在领到user-stories之后，编码之前的时间来简单设计。XP不排斥文档，只不过认为它是一种开销，XP坚信（文档化的）代码是最好的文档。并不是懒不想写文档，是维护这个文档要花费三倍甚至以上的时间：我在白板上画好了商量后的草图，要先抄下来，再写成标准的word或openoffice文档，碰到图还得画图，UML还得再画。所以把它简单化：草稿，行，存档！白板，行，拍照存档。充足的人员和时间偷偷会给你吗？在项目产品化阶段的知识共享和培训时再完善文档！把存档的草稿正式化。另外设计师总倾向于采用精巧的，复杂的设计，好象不这么做就不是好的设计师似的；这种复杂性还给交流和理解带来问题，更可能影响到其他简单设计就可以足够应付的地方配合你“精巧设计”要做复杂更改的问题。 反馈 反馈保证了质量和自适应。客户编写user-story-card时，程序员立刻就可以进行评估，这样客户就知道工作量。测试先行有反馈，小步迭代有反馈，持续集成有反馈。项目跟踪人员每日得到user-sotries-list上完成情况的跟踪记录反馈，客户每个迭代结束得到重要反馈等。 勇气 面对一堆代码，即使你是你写的，你敢做变动吗，你做了变动之后有信心说不会有问题吗？再进一步，你敢做重大的变动吗？没有前面的价值信念和实践，你肯定不敢说有信心。我们的信念和实践现在已经做了很多事：单元测试，验收测试，持续集成，经常性的重构代码，一致的编码规范。有了这些保证，你跟以前相比勇气大多了：）。勇气除了面对激进的代码变动，还包括探求新知。面对新技术，要保持一颗年轻的心哦！ XP的生命周期： 试探阶段目的：- 充分评估第一次迭代的story-cards - 可行性保证活动：- 建立原型（20%的需求就是最重要的基础架构性的，前面论述过了） - 技术等方面的试探性论证 - sotry-cards的编写和评估 发布计划游戏（Release Planning Game）目的：- 对第一次迭代的日期和story-cards达成共识 活动：- 发布计划活动 - 故事卡片（story-cards）的编写和评估 迭代计划游戏（Interation Planning Game）目的：- 明确本次的迭代任务活动：- 用户从user stories中确定最有价值的特征作为本次迭代的目标 - 加入上次迭代未通过验收测试的user-stories 迭代开发目的：- 在一个迭代周期内实现user-stories活动：- 简单设计、测试、结对编程、重构、迭代期验收以及在需求细节上与客户不断沟通协作 发布 （如果没有完成发布前的工作，返回到迭代计划游戏阶段）目的：- 产品化，发布产品活动：- 产品文档、技能培训和团队知识共享，排除项目中的“知识孤岛”现象（其实轮换配对减少了知识孤岛的存在，知识孤岛让开发人员都不知道软件其他部分，这对维护期是个灾难） - 发布产品 维护期（略） XP的工件、角色和实践： 工件（没有文档，除了软件，项目产生了其他什么吗？）1）story-cards - 记录简明特征需求（非use-case和场景）的纸质卡片，预示着需要进一步与客户讨论具体细节，粒度2-10天。XP是特征驱动不是用例驱动。2）任务列表 每次迭代中针对story编写的任务列表卡片或白板上的表格，任务粒度1-2天。3）可视化图表 - 用于便于沟通。 角色客户 - 编写故事(stories)和验收测试 - 挑选用于发布和迭代的故事开发-程序员 - 编写测试、设计、和代码 - 重构 - 确定、领取任务和估算开发-测试员 - 帮助客户编写和开发测试管理-教练（有经验的XP团队可不设置） - 过程辅导 - 过程定制 - 干预和培训管理-项目跟踪者 - 收集度量情况 - 报告进度 - 根据简单的估算进行反馈 其他-顾问等 - 技术咨询和指导 实践对应到需求：（谁说XP不做需求，而且是持续获取需求！） - 计划游戏 - 现场客户 - 验收测试 设计： - 系统隐喻 - 频繁重构 - 简单设计 实现： - 频繁重构 - 编码标准（一致的风格、文档化(如doxygen）注释，这可以是最好的设计和实现文档） - 结对编程 - 代码的所有权归团队 测试和验证： - 验收测试，客户测试 - 测试先行的开发单元测试 - 现场客户 项目管理： - 计划游戏 - 小版本发布 - 平稳的工作进度 - 站立短时间会议 配置并改变管理环境： - 持续继承 - 公用房间 - 计划游戏 核心实践和描述：（摘自Craig Larman Agile and Iterative Development: A Managers Guide）不翻译，看点原味的吧。 实践 描述 整个团队协同工作，或者现场客户参与 The whole teamprogrammers and customerswork together in a common project room. One or more customers sit more-or-less full time with the team; they are expected to be subject matter experts and empowered to make decisions regarding requirements and their priority.The customer contribution includes detailed explanationto the programmersof the features briefly summarized on story cards, Planning Game participation, clarification, and writing acceptance tests in collaboration with a programmer.The purpose is in response to the consistent project failure research indicating that more customer involvement is paramount to successful projects.The first release of XP spoke of only one onsite customer; this has been recently revised to emphasize a group of customers. 小型而频繁地发布 Evolutionary delivery. Not applicable to all projects. Not to be confused with organizing one release cycle into many short iterations. 测试: 验收测试和客户测试 Testing practices in XP are very important. All features must have automated acceptance (functional) tests. All tests (acceptance and unit) must run with a binary pass/fail result, so that no human inspection of individual test results is required. The acceptance tests are written with collaboration of the customerthey define a testable statement of what acceptance means. This is called Customer Tests in XP. 测试: 测试驱动开发和客户测试 Unit tests are written for most code, and the practice of test-driven development (and test-first development) is followed. This includes the practice that the unit test is written by the programmer before the code to be tested. It is a cycle of test code, rather than code test. Usually, the open-source XUnit testing framework family (such as JUnit) is applied (see www.junit.org). All acceptance and unit tests are automatically run repeatedly in a 24/7 continuous integration build and test cycle.See p. 292 for a detailed example. 发布计划游戏 The Release Planning Game goal is to define the scope of the next operational release, with maximum value (to the customer) software. Typically a half-day one-day session, customer(s) write story cards to describe features, and developers estimate them. There may also exist story cards from prior exploration phase work. The customer then chooses whats in the next release by either 1) setting a date and adding cards until the estimate total matches the time available, or 2) choosing the cards and calculating the release date based on their estimates. 迭代计划游戏 The Iteration Planning Game goal is to choose the stories to implement, and plan and allocate tasks for the iteration. It happens shortly before each new iteration (13 weeks in length). Customer(s) choose the story cards for the iteration. For each, programmers create a task list (on cards or whiteboard) that fulfill the stories. This is followed by a volunteering step in which the programmers choose a set of tasks. They then estimate their task lengths. If tasks are not estimated in the half-day to two-day range, they are refactored. 简单设计 Avoid speculative design for possible future changes. Avoid creating generalized components that are not immediately required. The design should avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible. 结对编程 All production code is created by two programmers at one computer; they rotate using the input devices periodically. Pairs may change frequently, for different tasks. The observer is doing a real-time code review, and perhaps thinking more broadly than the typist, considering tests and so forth.Certainly, team productivity is not simply a function of the number of hands typingit is more nuanced. The XP claim is that the combination of cross learning, the peer pressure of more disciplined practice observance and more hours actually programming than procrastinating, defect reduction due to real-time code review, and the stamina and insight to carry on when one programmer is stuck, all add up to an overall team improvement. 频繁重构 Refactoring in the XP context is the continual effort to simplify the fine-grained code and larger design elements, while still ensuring all tests pass. That is, cleaning the code and design, without changing functionality. There is supposed to be lots of refactoring in XP. This practice is also known as continuous design improvement.The goal is minimal, simple, comprehensible code. It is achieved by small change steps, verifying tests after each, and ideally the use of refactoring tools, now available in some IDEs. 代码归集体所有 Any pair of programmers can improve any code, and the XP value system is that the entire team is collectively responsible for all the code. The value of its her code, and her problem is not endorsed; rather, if a problem or chance to improve is spotted, its the spotters responsibility. A related goal is faster development by removing the bottleneck associated with change requests in an individual code ownership model.The obvious danger of modifying code one did not originally write is ameliorated in XP by some of the other practices: The guaranteed-present unit and acceptance tests running within an automated continuous integration build process inform you if you broke the code, your pairing partner brings another set of eyes to the change, and common adherence to coding standards ensures all the code looks the same. 持续集成 All checked-in code is continuously re-integrated and tested on a separate build machine, in an automated 24/7 process loop of compiling, running all unit tests and all or most acceptance tests. There are several open-source tools for this, built on the ubiquitous Ant technology, including CruiseControl and Anthill. 平稳的工作节奏 Frequent overtime is rightly considered a symptom of deeper problems, and doesnt lead to happy, creative developers, healthy families, or quality, maintainable code. XP doesnt support itrather, it promotes no overtime. 站立会议 With collective code ownership, frequent refactoring, and regular swapping of pair programming partners, everyone needs to follow the same coding style. 系统隐喻 To aid design communication, capture the overall system or each subsystem with memorable metaphors to describe the key architectural themes. For example, the C3 payroll system was described in terms of an assembly line of checks with posting rule machines operating on them, extracting money from different bins.Many have reported this the least necessary practice. 其他实践和价值观： 现场客户代理 Many groups wishing to apply XP cannot find full-time ultimate customers to work in the project room. For example, consider a new internal system for (very busy) commodity traders. And this problem is common for commercial products for an external market. The common solution is to designate customer proxies that do join the team in the project room, have good (though not as ideal as true customer) knowledge of the domain and requirements, and that represent the ultimate customers. If proxies are used, it is important that the true customers at least participate in end-of-iteration demos, and preferably, in the Planning Games. 随时联络客户 When the onsite customer is not present, arrange matters so that the customer representative is committed to fast access, such as via a mobile phone. 拥抱变化 The overarching attitude that XP promotes is to embrace rather than fight change, in the requirements, design, and code, and be able to move quickly in response to change. 完全自愿地 (接受任务) Tasks are not assigned to people. Rather, during the Iteration Planning Game, people choose or volunteer for tasks. This leads to a higher degree of commitment and satisfaction in the self-accepted responsibility, as has been explored in DL99. 非常轻量级地建模 XP encourages programming very early and does take to extreme the avoidance of up-front design work. Any more than 10 or 20 minutes of design thinking (e.g., at the whiteboard with sketches or notes) before programming is considered excessive. Contrast this with Scrum or the UP, for example, where a half-day of design thought near the start of an iteration is acceptable. 最少或“刚刚够的文档” With the goal of getting to code fast, XP discourages writing unnecessary requirements, design, or management documents. The use of small paper index cards is preferred for jotting brief descriptions, as are verbal communication and elaboration. Note that the practice of avoiding documentation is compensated by the presence of an onsite customer. XP is not anti-documentation, but notes it has a cost, perhaps better spent on programming. 度量 XP recommends daily measurement of progress and quality. It doesnt mandate the exact metrics, but to use the simplest ones that could work. Examples include numbers of completed tasks and stories, and number and success rate of running tests. 墙壁图表 The collected metrics are daily updated on wall graphs for all to easily see. 跟踪和每日跟踪者 The regular collection of task and story progress metrics is the responsibility of a tracker. This is done with a walk-about to all the programmers, rather than email; commenting on thisand very telling of the XP attitudeRon Jeffries (one of the XP founders) said, XP is about people, not computers. Test metrics can be automatically collected by software. 递增的基础结构 XP recommends (as do the other iterative processes) that the back-end infrastructure (for example, a persistence layer) not be the main focus of implementation in the early iterations, but rather, only enough is implemented to satisfy the user-functional requirements of each iteration. 公用项目工作室 XP projects are run in a common project room rather than separate offices. Pair programming tables are in the center of the room, and the walls are clear for whiteboard and poster work. Of course, people may have a private space for private time, but production software development is a team sport in XP. 每日站立会议 As in Scrum, there is a dail