《解析极限编程（第二版）（中英文对照）》的原文摘录
不是你未知的东西导致你陷入困境，而是你已知的东西并不正确。 (查看原文 )
在团队软件开发中最要紧的是沟通。每当开发中出现问题的时候，通常已经有人知道了解决方法，但有权做出改变的人却不知道。 (查看原文 )
如果你想要人们接受你的意见，那你就应该解决更多问题，而不是创造更多问题。 (查看原文 )
通过牺牲质量来控制的手段是没有效率的。质量不是一个控制变量。项目不会因为接受低质量而加快速度，也不会因为要求高质量而使进度减慢。要求高质量通常导致更快的交付，而降低质量标准通常会导致更晚的不可预见的交付。 (查看原文 )
实践本身是空洞的。除非以价值观作为目的，否则实践会变得生搬硬套。 (查看原文 )
实践是与环境相关的。如果环境变了，你需要选择不同的实践去适应不同的环境。但是你的价值观却不须要为了适应新的环境而改变。 (查看原文 )
像害怕、愤怒和焦虑之类的负面情绪始终暗示有糟糕的事情将要发生。 (查看原文 )
将价值观显式化很重要，因为没有价值观，实践很快会变成生搬硬套，为行动而行动，缺乏目的或方向。
价值观与实践的结合意味着程序员有充分的理由会选择高效率地执行一个实践。价值观让实践有的放矢。 (查看原文 )
只要你可以在有效率的时间段内高效地工作就足够了。今天没有效率地透支自己，从而毁掉接下来两天的工作，这对你和你的团队都不利。
软件开发是一个洞察力的游戏，而洞察力来自于准备好的、休息好的和放松的头脑。
只要有足够的咖啡因和雪茄，我就可以超越某个临界点从而长时间地敲击键盘，但从这个临界点开始，我实际上就已经开始在做不利于这个项目的事情了。这种情况（做不利于项目的事情）其实是很容易发生的，当你太疲倦的时候，你很难意识到你正在降低项目的价值。 (查看原文 )
在改变任何代码之前先编写一个自动化测试。测试先行编程能马上解决很多问题：
范围蔓延——这很容易就会使程序失去控制并引入一些“以防万一”的代码。通过明确客观地描述程序应该做什么，你可以让自己的编码有针对性。如果你真的想将其他代码加进来，就再写一个测试——等你手头的测试运行通过后。
耦合与内聚——如果测试编写起来很困难，这是个信号，说明是设计上有问题，而不是测试。低耦合、高内聚的代码是很容易测试的。
信任——如果一段代码不能运行，那么它的作者是很难得到别人信任的。通过编写干净的可运行代码，并运用自动化测试来证明你的意图，你给了你的队友一个信任你的理由。
节奏——编程的时候很容易就会几个小时都不知道自己在干什么。如果使用测试先行编程的方法，下一步要做的工作就会很清楚：要么编写另外一个测试，要么让没有通过的测试运行。 (查看原文 )
改变总是从自身开始。你惟一能改变的人是你自己。不论你的组织功能多么健全或者情况刚好相反，你都可以自己开始应用XP。 (查看原文 )
对一个团队强制实行实践会破坏信任并导致怨言。主管们可以激励团队的责任感，但团队是使用XP、改进的瀑布模型，还是完全混乱的开发过程，完全取决于他们自己。 (查看原文 )
一旦发现了对你的改进有意义的主意，就放手去做。如果你们能作为一个团队进行改变，那就太好了。如果不能，那就单独进行直到能同你信任的人分享你的收获。 (查看原文 )
我最近和一个技术组长谈话时，他告诉我他完全支持程序员写自动化测试用例。“好啊，”我说，“那么你试过JUnit吗？”
“噢，没有，我从没有写过测试。我只是认为这是一个好主意罢了。”
期望别人做你自己不想做的事情是无礼和低效的。让别人冒你不想冒的险，将破坏了队员间的关系和团队凝聚力。权力和责任的错位会导致不信任，你也将因此失去了学习、反馈和自我提高的机会。 (查看原文 )
在每种情形下，方法都类似的：首先改变自己，然后把改变的成果贡献给其他人。这两个步骤都能创造价值。我改变，是因为我发现了改进的方法。而当我向他人提供新技能时，我已经经历了它们带来的好处 。 (查看原文 )
我记得曾经参加一个全天会议，内容涉及计划一个组织如何开发软件。从一开始程序员和主管人员都在。另外还安排了相关的不同工作的代表参加会议，让他们就需要什么样的开发风格陈述自己的观点。
程序员从谈论XP开始：风险管理、即时回报、反馈以及为什么喜欢跨越阶段的活动。所有的人都点头赞成，这些都是有意义的事情。
然后是架构师。他们认为，虽然XP对于编程来说不错，但是如果他们在项目开始阶段就设计好架构，所有事情的进行都将平稳得多。他们遭到很多人的反对，反对意见认为：“流”以及“流”的含义意味着，在开始时仅需要设计足够启动开发的架构即可，然后应该随着开发的进行逐步将架构细化。架构师们不情愿地承认，虽然可以这么做，但最好还是在架构阶段做架构设计。
接着是交互设计师们。他们认为，虽然XP对于编程来说不错，但是如果他们在项目开始的阶段就设计好交互，所有的事情的进行都将平稳得多。程序员、主管人员和架构师们又回到了关于流的争论。交互界面设计师们认为，虽然可以在开始时仅设计足够启动开发的交互，接下来持续地精化交互，但是这样还不如在项目开始阶段就做好交互设计。
当底层设计者们建议让他们在项目开始阶段就做好所有的底层设计时，会议变成了一场闹剧。我们没花多少时间就让他们勉强同意增量工作。
故事的结局是不愉快的。你不能说服其他人违背自己的意愿。这些人都没有把自己看作是大整体的一部分。 在压力下，他们还是倒退回尽力预先进行他们所有的工作。
这就好像是持不同观点的人被捆绑在一起冰上行走，所有他们想做的是争论谁是第一个。其实谁是第一个并不要紧，整体团队并没有认识到他们被捆绑在一起。事实上，齐头并进，将会比任何一群试图迫使他人跟随其后，取得更多的进步。 (查看原文 )
权力与责任一致的原则表明，给一个人权力做决定而不必亲自承担后果，其他人还不得不服从他的决定，这样是不好的。 (查看原文 )
XP 是一条可以使得一起开发的人们共同进步直至卓越的途径。它和其他方法的区别是：
* 短开发周期，提供及早的、具体的、持续的反馈。
* 增量计划方式，迅速地提出一个总体计划，并在项目生命周期中不断演化。
* 能够灵活安排功能的实现，以应对变化的业务需求做出反应。
* 使用由程序员、客户和测试人员编写的自动测试来监控开发进度，支持系统的演化，并尽早发现缺陷。
* 通过口头沟通、测试和源代码交流系统结构和意图。
* 演化的设计过程贯穿整个系统生命周期。
* 依赖于能力普通但能积极参与的程序员之间的紧密协作。
* 各种实践兼顾项目成员的短期直觉以及项目的长期利益。 (查看原文 )
There is a human effect from quality. Everybody wants to do a good job, and they work much better if they feel they are doing good work. If you deliberately downgrade quality, your team might go faster at first, but soon the demoralization of producing crap will overwhelm any gains you temporarily made from not testing, or not reviewing, or not sticking to standards. (查看原文 )
我们将控制项目中的4个变量——成本、时间、质量和范围，其中，范围的控制最有价值。
对于软件开发来说，范围是最应该注意的变量。。。。在项目管理中，最有力的决定之一就是消除范围。如果积极主动地管理范围，你就可以向管理人员和客户提供对成本、质量和时间的控制。 (查看原文 )
