极限编程 - 价值观与原则
XP 通过引入基本的价值观、原则和实践来降低变更成本。通过应用 XP，系统开发项目在变更方面应该更加灵活。
极限编程价值观
极限编程 (XP) 基于五个价值观 -
沟通
简单性
反馈
勇气
尊重
沟通
沟通在项目的成功中起着至关重要的作用。项目的很多问题往往源于沟通不足。许多情况可能导致沟通中断。一些常见的问题包括 -
开发人员可能没有告知其他人关于设计中关键变更的信息。
开发人员可能没有向客户提出正确的问题，从而导致关键的领域决策出现偏差。
管理人员可能没有向开发人员提出正确的问题，导致项目进度被错误地报告。
开发人员可能忽略了客户传达的一些重要信息。
极限编程强调团队成员、管理人员和客户之间持续不断的沟通。极限编程实践，如单元测试、结对编程、简单设计、通用隐喻、集体所有权和客户反馈都侧重于沟通的价值。
XP 采用教练，其工作是在人们没有进行沟通时注意到这一点并重新引导他们。更倾向于面对面沟通，并通过结对编程来实现，并且客户代表始终在场。
简单性
极限编程认为“今天做一件简单的事情，明天付出一点额外代价来修改它”比“今天做一件可能永远不会用到的更复杂的事情”更好。
做需要做的事情和被要求做的事情，但不要做更多。
“做最简单可能起作用的事情”即 DTSTTCPW 原则。
以最简单的方式实现新功能。也称为 KISS 原则“保持简单，愚蠢！”。
当教练看到极限编程开发人员做一些不必要复杂的事情时，可能会说 DTSTTCPW。
重构系统，使其成为具有当前功能集的最简单的代码。这将最大化迄今为止投资所创造的价值。
采取小的简单步骤来实现目标，并在问题发生时减轻故障。
创造一些你感到自豪的东西，并以合理的成本长期维护它。
永远不要实现你现在不需要的功能，即“你不需要它”（YAGNI）原则。
沟通和简单性相互支持。
沟通得越多，你就能越清楚地看到需要做什么，并且对真正不需要做什么更有信心。
你的系统越简单，你需要沟通的内容就越少，需要的开发人员也越少。这将带来更好的沟通。
反馈
每次迭代的承诺都会被认真对待，并交付一个可工作的软件。软件尽早交付给客户并获取反馈，以便在需要时进行必要的更改。关于系统当前状态的具体反馈是无价的。反馈的价值在于一个持续运行的系统，该系统以可靠的方式提供关于自身的信息。
在极限编程中，在不同的时间尺度上确保所有级别都有反馈 -
客户告诉开发人员他们感兴趣的功能，以便开发人员可以只专注于这些功能。
单元测试告诉开发人员系统的状态。
系统和代码向管理人员、利益相关者和客户提供有关开发状态的反馈。
频繁发布使客户能够执行验收测试并提供反馈，并使开发人员能够根据该反馈进行工作。
当客户编写新的功能/用户故事时，开发人员会估算交付更改所需的时间，以便与客户和管理人员设定期望。
因此，在极限编程中，反馈 -
充当变革的催化剂
指示进度
让开发人员相信他们走在正确的道路上
勇气
极限编程以以下方式为开发人员提供勇气 -
专注于所需内容
沟通并接受反馈
说出进度和估算的真相
重构代码
适应随时发生的更改
丢弃代码（原型）
这是可能的，因为没有人单独工作，并且教练会持续指导团队。
尊重
尊重是一个深刻的价值观，它位于其他四个价值观的表面之下。在极限编程中，
每个人都尊重彼此作为宝贵的团队成员。
每个人都贡献价值，例如热情。
开发人员尊重客户的专业知识，反之亦然。
管理层尊重开发人员接受责任和获得对其自身工作授权的权利。
与沟通、简单性和具体反馈相结合，勇气变得极其宝贵。
沟通支持勇气，因为它为更多高风险、高回报的实验打开了可能性。
简单性支持勇气，因为对于简单的系统，你可以负担得起更大的勇气。你不太可能在不知情的情况下破坏它。
勇气支持简单性，因为一旦你看到简化系统的可能性，你就会尝试它。
具体反馈支持勇气，因为如果你能看到测试最终变为绿色，那么在尝试对代码进行彻底修改时你会感到更安全。如果任何测试没有变为绿色，你就知道可以丢弃该代码。
极限编程原则
价值观很重要，但它们很模糊，从某种意义上说，可能无法确定某件事是否有价值。例如，从某人的角度来看简单的事情，从其他人的角度来看可能很复杂。
因此，在极限编程中，基本原则源于价值观，以便可以根据这些原则检查开发实践。每个原则都体现了价值观，并且更具体，例如快速反馈 - 你要么拥有它，要么没有。
极限编程的基本原则包括 -
快速反馈
假设简单性
增量变化
拥抱变化
高质量工作
快速反馈
快速反馈是为了获取反馈，理解它，并尽快将学习成果重新应用到系统中。
开发人员设计、实现和测试系统，并在几秒钟或几分钟内使用该反馈，而不是几天、几周或几个月。
客户审查系统以检查它如何才能最好地做出贡献，并在几天或几周内提供反馈，而不是几个月或几年。
假设简单性
假设简单性就是将每个问题都视为可以用简单的方式解决。
传统上，你会被告知要为未来计划，为重用而设计。这种方法的结果可能会变成“客户今天需要的东西没有得到满足，最终交付的东西可能已经过时且难以更改。”
“假设简单性”意味着“今天做好今天的工作，并相信你能够在未来需要时添加复杂性。”在极限编程中，你会被告知要做好工作（测试、重构和沟通），专注于今天重要的事情。
有了良好的单元测试，你可以轻松地重构代码以进行其他测试。
遵循 YAGNI（你不需要它）。
遵循 DRY（不要重复自己）原则。例如，
不要有多个相同（或非常相似）代码的副本。
不要有多个冗余的信息副本。
不要浪费时间和资源在可能不需要的事情上。
增量变化
在任何情况下，一次性进行的重大更改都不会奏效。任何问题都可以通过一系列最小的变化来解决。
在极限编程中，增量变化以多种方式应用。
设计一次更改一点。
计划一次更改一点。
团队一次更改一点。
即使是极限编程的采用也必须采取循序渐进的步骤。
拥抱变化
最佳策略是在实际解决最紧迫问题的同时保留最多的选择。
高质量工作
每个人都喜欢做好工作。他们试图创造他们感到自豪的质量。团队
工作良好
享受工作
在生产有价值的产品时感觉良好