12个核心实践翻译自论文
——Extreme-Programming-A-Case-Study-in-Software-Engineering-Courses
一、在正式翻译论文之前，本人就个人查阅资料的相关情况，先对Extreme-Programming做一个简要概述：
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。
XP在制定需求方面，提倡客户是项目开发的队伍中的一员；在设计阶段提倡测试先行；在编码阶段提倡结对编程。
基于敏捷的核心思想和价值目标，XP要求项目团队遵循13个核心实践
团队协作(Whole Team)、规划策略(The Planning Game)、
结对编程(Pair programming)、测试驱动开发(Testing-Driven Development)
重构(Refactoring)、简单设计(Simple Design)
代码集体所有权(Collective Code Ownership)、持续集成(Continuous Integration)
客户测试(Customer Tests)、小型发布（Small Release）
每周40小时工作制（40-hour Week）、编码规范（Code Standards）
系统隐喻（System Metaphor）
——以上内容引自百度文库
二、12个核心实践论文翻译
1、规划策略(The Planning Game)：将业务与开发团队聚集到一起，共同决定需求的特征将会最大化业务价值。在XP中收集需求的相关技术与传统软件方法有着根本的不同。首先，客户需求使用自然语言写成的，非正式的“用户故事”卡片，与用例相似。这些卡片没有形式化，彼此之间没有关系和依赖，不容易被识别。软件开发人员将时间估算和客户分配到每张卡片的优先级。开发人员和客户一起玩“规划游戏”，在这个游戏中，用户选择那些包含一个月左右的短期增量交付的最重要内容的用户故事。客户接受并尝试每个短的执行增量。然后，重新检查其余的用户故事以查找可能的需求和/或优先级变化，并且为下一个执行增量重新开始计划游戏。
2、小型发布（Small Release）：一个包含了一系列有用特征的简单系统可以尽早的投入生产并且可以在较短周期期内频繁更新。XP通过3-4周的短期发布提高了螺旋式发展的速度。每次发布结束时，客户都会审阅中间产品，识别缺陷并调整未来的需求。
3、隐喻（Metaphor）：每个项目都有一个“名称系统”和描述，有助于指导各方之间的发展过程和交流。XP相信每个应用程序都应该具有基于简单隐喻的概念完整性，这就解释了系统工作的本质。例如，一个大的XP项目是克莱斯勒的工资系统。 这个项目的隐喻是，工资系统就像一条装配线，其中小时零件被转换成美元零件，所有零件都被组装并产生薪水。
4、简单设计(Simple Design)：只要满足当前业务需求，最简单的设计总是用于构建应用程序。无论如何，随着时间需求的变化，不要担心未来的需求。重构实践（见下文）将确保设计的高标准。XP致力于超级简单的设计。他们强调程序员不应该试图预测未来的需求，并相应地产生更复杂的设计。开发人员应该遵循简单的设计实践和“做可以工作的最简单的事情”。
5、测试（Testing）：XP遵循“测试优先”的方法，即在添加新功能之前，编写测试来验证软件。然后开发该软件以通过这些测试。使用XP开发的软件始终得到验证。进行两种类型的测试，单元和功能测试
5.1、单元测试：广泛的自动化白盒测试用例是在生产代码之前编写的。这些自动化测试被添加到代码库中。在程序员可以将他们的代码集成到代码库之前，他们必须通过他们自己的测试用例的100％，以及在代码库中写过的每个测试的100％。这可确保新代码在不破坏其他人的代码的情况下实现新功能。
5.2、功能测试：传统上，项目管理技术是基于开发人员自己评估他们的任务已完成的。或者，XP推广使用功能测试用例跟踪来计算项目完整性。XP将此评估称为“项目速度”。功能测试用例基于客户场景。当功能测试用例成功通过时，可以认为指定功能已正确实施。项目的完整性基于已通过的功能测试用例的百分比。团队成员可以明确地计算这个度量。
5.3、自动化测试：编写测试是不够的，你必须运行它们。单元测试全部收集在一起，每当程序员向代码库发布任何代码时（代码对通常每天发布两次或更多），每一次程序员测试都必须正确运行。百分之百，所有的时间！开发者有兴趣使用适当的自动化测试框架，例如 JUnit和NUnit，来控制和简化重复测试和持续集成的任务。这意味着程序员可以立即获得关于他们如何做的反馈。另外，随着软件设计的改进，这些测试提供了非常宝贵的支持。
6、重构：重构是在保留（而不是改进）其功能的同时改进代码结构的过程。XP主张持续而明确地重构代码。这是一种改进现有代码库设计的技术。其本质是应用一系列小的行为保留转换，以改善代码的结构。通过小步骤完成它们，可以降低引入错误的风险。
7、结对编程：使用XP的编程人员进行配对，并使用每对配对的单个机器编写所有生产代码。这有助于代码在写入时不断进行审阅。结对编程证明可以生成高质量的代码，但生产力几乎没有下降。
8、代码集体所有：所有代码都属于团队的每个成员，团队中没有一个成员拥有一段代码，任何人都可以随时对代码库进行更改。这鼓励每个人为项目的所有部分贡献新的想法。
9、持续集成：软件系统一天建成并集成数次;至少所有变更都集成到主集成平台的主代码库中，至少每天一次。因此，每天都有很多产品构建。每个构建都使用相关的测试用例进行测试。
10、40小时制：XP项目中的程序员通常坚持每周工作40小时，以保持生产力并避免加班。人们发现，在加班工作的紧急时期，产品的质量很差。
11、现场客户：将使用正在构建的系统的一个或多个客户分配给开发团队。客户有助于指导开发，并有权优先考虑，还可以说明需求并回答开发人员可能遇到的任何问题。这确保了与客户进行有效的沟通，这样需要的文件就更少了。
12、编码标准：XP项目中的每个人都使用相同的编码标准，从而可以轻松地成对工作并共享所有代码的所有权。开发成员不应该能够分辨出谁在XP项目中使用了哪些代码。应该定义并遵循商定的编码标准。
转载请注明出处！