重新划分
重新划分是在不更改功能性的前提下对代码加以改进。XP 小组在进行重新划分时毫不手软。
开发人员重新划分有两个重要时机：实现特性之前和之后。开发人员尝试确定更改现有代码是否可以让新特性的开发更容易。他们查看刚刚写好的代码，看是否有方法可以对它进行简化。例如，如果他们认为有抽象的机会，就会进行重新划分来从具体实现中除去重复的代码。
XP 建议您应该编写可能运行的最简单的代码，但同时也建议您应该不断学习。重新划分让您将学到的知识加入到代码中，同时又不会破坏测试。它使您的代码简练。这意味着它可以存在相当长的时间、为以后的开发人员引入更少问题，并为他们指引正确的方向。
简单的设计
XP 的诽谤者说该过程忽略了设计。事实不是这样。问题是重量型方法建议您做的不过是提前完成大部分琐碎的设计任务。这就象是拍一张静态的地平线的照片，静止不动，然后尝试画一张如何到达那里的完美的地图。XP 说设计不应该在事物将保持不变的前提下预先仓促进行。XP 认为设计非常重要，因此应该是一个持续的事务。我们总是先尝试使用能够工作的最简单的设计，然后随着现实的不断显现来更改它。
什么是可能工作的最简单的设计？它是符合以下条件的设计（感谢 Kent Beck 为我们一一列出）：
运行所有测试
不包含重复代码
明确陈述程序员对所有代码的意图
包含尽可能最少的类和方法
对简单设计的需求并不是说所有设计都很小，也不表示它们是无足轻重的。它们只不过需要尽可能简单，但是仍能工作。不要包括不使用的额外特性。我们称这样的事物为 YAGNI，表示“您将不需要它（You Aren't Going to Need It）。”不要让 YAGNI 破坏您成功的机会。
集合体代码所有权
小组中的任何人都应该有权对代码进行更改来改进它。每个人都拥有全部代码，这意味着每个人都对它负责。这种技术可以让人们对部分代码进行必要的更改而不用经过代码拥有者个人的瓶颈。每个人都负责这一事实消除了无代码所有权所带来的混乱。
“每人拥有所有代码”与“没人拥有代码”的说法并不一样。没人拥有代码时，人们可以随处进行破坏而不必负任何责任。而 XP 说，“如果是您破坏的，应该您来弥补。”我们有一些必须在每次集成之前和之后运行的单元测试。如果您破坏了某些事物，您要负责进行修补，无论它位于代码的哪一部分。这需要极端规则。可能这是名称中带有“极端”的另一个原因。
持续的集成
经常进行代码集成可以帮助您避免集成梦魇。XP 团队在一天中集成了代码几次，每次都在所有单元测试对系统运行后执行。
传统方法工作方式如下：编写大量代码后执行一次大爆炸式的集成，然后花费相当长的时间来改正问题。这种笨拙的形式的确使项目速度减缓。大爆炸式的集成给团队立即带来大量问题，并且这些问题通常都有几百种可能的原因。
如果经常进行集成，任何特定集成失败的原因都会非常明显（以前运行过测试，因此错误一定是新事物犯下的）。使用这种方法，当遇到问题时，可能的原因就相当有限。修改起来更容易，花的时间少得多，使团队保持最快速度前进。
现场客户
要使功能最理想，XP 小组需要在现场有一位客户来明确素材，并做出重要的企业决策。开发人员是不允许单独做这些事情的。让客户随时在场可以消除开发人员等待决策时出现的瓶颈。
XP 不会假装素材卡是开发人员交付必要代码所需的唯一指示。素材是对以后在客户和开发人员之间填写细节的对话的一项承诺。与将所有要求写在一个静态文档中不同，其思想是进行面对面的交流，减少产生误解的机会。
我们发现让客户在现场是可能最好的一种情形，但这不是解决问题的唯一方案。底线是客户必须随时在需要回答问题和根据企业价值为团队提供指示时有空。如果客户并非在现场专职陪伴团队的情况下就能做到这些，那很好。如果能和团队待在一起，这会更方便，但只是建议而已。
小发行版
发行版应该尽可能地小，同时仍然提供足够的企业价值以证明它们值得。
只要觉得有意义就可以发布系统。这样就尽可能早为用户提供了价值（请记住，今天的钱比明天的钱来得值钱）。小发行版将为开发人员提供具体的反馈意见，告诉他们哪些符合客户需要，哪些不符合客户需要。然后，小组可以将这些经验教训包括在其下一发行版的规划中。
一周 40 小时
Kent Beck 说他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲惫而满足。”一周 40 小时工作可以让您做到这一点。确切的小时数并不重要，重要的是原则。长时间地持续工作会扼杀工作绩效。疲劳的开发人员会犯更多错误，从长期来说，将比按“正常”时间表进行的开发慢得多。
即使开发人员可以在长时间很好工作，这也不意味着他们应该这样。最终他们会厌倦，会离开他们的工作，或者产生影响他们工作绩效的非工作问题。如果您打乱了人们的生活，将会尝到它所带来的恶果。加班并不是解决项目问题的答案。实际上，它是更大问题的症状。如果您要走向灭亡，就无药可救了。
