“除了编码和其他活动，我们在工作场所的人际关系也会影响到生产率和自信心。成功既需要技术又需要好的合作关系，极限编程致力于同时解决这两个问题。”
极限编程具体分成了哪些类型的内容呢？有价值观、原则和实践三部分。
=================================================
关于“管理”：
“XP是我在自己的软件开发实践中协调人性和生产率并共享这一协调的一种尝试。我已经开始注意到，我越是有人情味地对待我自己和别人，我们大家的生产率就越高。成功的关键不在于自我禁欲，而在于承认我们是人，我们生活在人与人之间交往的环境中。”
XP特别强调人性，大多数方法论往往忽略了“人”本身，而XP非常强调人性化。
=================================================
关于“时间不够”：
“你可能有足够的时间、资金和团队技能，也可能没有。如果你有6周时间去完成一个项目，你惟一能够控制的是你自己的行为。你不能控制别人的期望，但你可以告诉他们你所知道的关于项目的所有事情，这样他们的期望才有跟现实匹配的可能性。当我知道了这一点，我对最后期限的恐惧就消失了。'管理'其他人的期望不是我的工作，而是他们自己需要操心的，我要做的就是尽可能地沟通清楚。”
很多人应该都遇到过相同的问题吧，产品经理或者其他leader跟你说“我想xxxx功能，什么什么时候你要把这个完成。”这种最后期限会给工程师很大的压力，很多时候，这种要求是几乎不可能的。
“当我还是个年轻的软件工程师时，学会了根据三个变量来管理项目：即速度、质量和价格。项目发起人会设定其中的两个变量，而团队则评估第三个。如果计划不被接受，那么谈判也将随之开始了。
这个模型在实践中运行得并不好。时间和成本通常在项目范围之外确定，这使得质量成为你惟一能够操作的变量。降低你工作的质量并非明显是你的责任。你以这种方式制造工作进展的假象，但这是以减少成就感和损害团队关系为代价的。我们所说的成就感应来自于完成高品质的工作。
这个模型遗漏的变量是范围。如果我们让“范围”显式化，那么：
<1> 我们就拥有了一种安全可靠的应变方式。
<2> 我们就拥有了一条谈判的途径。
<3> 我们就拥有了对荒谬的、不必要的需求的一种限制。
”
如果产品经理提出的需求很不合理，我们需要做的并不是迎合他的需求，降低产品质量，而是向他说明我们真实需要的时间。无独有偶，鲍勃大叔在《clean code》中说了同样的话，就像医生不可能因为“病人很急，说你别洗手了，快给我动手术吧”，就真的听病人的话不去洗手一样，病人不了解不洗手的后果，而医生知道。同样的，产品经理不知道降低产品质量带来的后患——无穷无尽的bug，后期维护甚至开发后期的代码沼泽！我们必须严守这一关，不提供低质量的产品。如果产品经理说时间紧，如何做出调整是产品经理的事，并不是工程师的事。这里另外需要提到的一点是，增加人手并不是最好的解决方法，就像《人月神话》中提到的，以人数乘以时间来计量生产力，对于软件开发来说，只是个神话。根据《销烟中的scrum和xp》一书的研究来看，最佳人数是7人，从5~9人都是比较好的，小于5人，大于9人都不能给生产力带来明显帮助。
所以，最好的办法是限制范围。按照scrum中的方法，每次团队评估本轮sprint中所能完成的用户故事，完成不了的故事就放到下个sprint中。产品经理不能强制说我要这功能我要那功能，只能排优先级，跟团队说哪个重要，优先做哪个。生产力是固定的，工程师不能为了提高生产力而降低质量，这是一切罪恶的源头。