关于设计的可扩展性。

在我看来，xp的12条原理的性质是不一样的，类似于持续集成、双人编程等等都可以看成实施的手段，但是“现场客户”不一样。

xp说：“应用xp方法，最好有‘现场客户’”，但是xp没有回答“谁可以担任现场客户？”“现场客户是一个还是多个？”“现场客户改变了怎么办？”诸如此类的问题。所以我认为在xp中，现场客户更多的是一个概念而不是实施的手段。

另外，xp的原理是可以单独应用的，只不过xp认为一起运用效果更好而已。
我并不认为我们一定要全盘照抄xp才叫做应用xp的开发过程。
你可以说没有现场客户就不是完整的xp……

xp的大多数实践不是xp创始人创造出来的，xp是把这些实践集合在一起成为的开发过程。
因为xp的大多数零件都不是xp创造出来的，所以xp的意义就是一个整体。至于大多数零件不属于xp。
所以你说的大多数可以单独应用的原理或实践……在没有xp的时候，就有人在应用，所以和xp无关。

ft，变成形而上的讨论了，你说不是xp就不是xp吧，在我看来这无关紧要。

您的意思也许是想在一个更宽广的领域而不仅仅在xp的领域讨论一些问题，不过在更宽广的领域我都不知道我要说什么才能有点正确性，所以我也是一直让话题局限在这个小范围内。
sorry，在更宽广的领域非我力量所及。

刚才写了好多断线了：（
只好简单总结一下我的观点，顺带回归一下主题

设计的扩展性包括针对业务的和针对结构的
——》其中针对业务的设计扩展性应当依赖于业务逻辑本身的扩展性
——》业务逻辑本身的扩展性在xp中应当由“现场客户”决定

xp的“现场客户”是一个概念，而不是实用方法。
现场客户=负责执行计划游戏的人+负责编写验收测试的人
xp没有回答“现场客户从哪里来？”“现场客户变更了怎么办？”等问题
而这些问题和项目的成败是有密切关系的。

我的实践：
最好的现场客户：得到充分授权的精通业务的用户代表或者是用户团队（必须有一个负责人解决不同用户代表之间的需求冲突）
最差的现场客户（比没有要好）：由开发方派出的专门的业务人员，没有实际用户

很多实际情况下我们介于两者之间。

反对，在我个人看来这么简单分类基本就是形而上学，为分类而分类。

《解析极限编程》第10章 简短概述 开头:
现场客户---在团队中加入一位真正的、起作用的用户，他将全职负责回答问题。
所以现场客户=负责执行计划游戏的人+负责编写验收测试的人+很多其它事情(包括编写用户故事)

《解析极限编程》第10章 10.11现场客户大致的论述了这些问题，不能说没有回答，并且回答的基本够了。

xp的"现场客户"基本就是您说的最好的现场客户
最差的现场客户一出现，很多xp中形成的结论都要推翻或受到质疑，在这种情况下，可能已经不适合用xp了，仅仅用那些实践。
关于"现场客户"您的一些见解和《解析极限编程》对照一下，我个人感觉有点反差过大。

呵呵，你碰到过多少最好的现场客户？
在越是大型的项目中，最好的现场客户也越是稀少，甚至可能根本不存在。

我的见解和xp有反差是很正常的，我前面就说过了，xp对于现场客户的描述太过简单，要求过于理想，可行性很低。
但是我很喜欢xp的其他实践，因此我倾向于改造xp的“现场客户”，使之成为更具可行性的实践。

您一方面在说xp，另一方面又在说情况是现场客户不够合格，这两方面是矛盾的。
如果您要在xp的基础上讨论问题，我愿意。
如果您要在"现场客户不够合格"前提下讨论问题，我即使有心也无力。原因我早已说过：我个人认为的xp的整体性。
不过我终于弄明白一点：您一开始就要在一个宽广的领域讨论一些问题，而不是在弄过xp之后再谈论xp的。

“在xp的基础上”，不是“在xp的框架下”
我认同xp的理念和绝大部分实践，但是我认为“现场客户”这个实践不好，需要改进。
如果你认为“xp的整体性”是指xp的所有实践都是金科玉律，或者说都是互相牵制的，不能改进的，那我实在是太遗憾了……

是互相牵制的，但不是不能改进的，从道理上说肯定有替代品。但如何改进不是我的兴趣所在，我个人没那么多精力同时做这件事情。我们争论的基础失去了，同时我不反对改进。
虽然我不会去做改进这件事情，但我对您要做这件事情本身是没有反对意见的。