关于设计的可扩展性。

这个问题是可以回答的(也许你认为是无法回答的)：把做可扩展性代价告诉他，让他选择，而不是自己直接做成可扩展性的。
>>不能把所有的责任都交给现场客户的，毕竟他也只是客户的一个代表而已，
业务逻辑的整理是很困难的一件事情，所以需要有领域专家。
因为回答了业务方的话题，所以这两句已经不用回答了。

呵呵，你连具体的扩展方向都不知道，怎么定可扩展性代价？怎么让用户选择？

另外，我没有认为这个问题是无法回答的，只不过我回答的方式和你的不一样而已。

我的措辞也有些激烈(被你的居高临下语气所激)
问题的前提是可以做出可扩展设计，是做不做，而不是能不能。
我说的意思是告诉客户做出可扩展的代码需要的时间，如果可扩展代码根本不知道怎么写，那就不叫可扩展设计了，也就是说已经无法做可扩展设计了。

我同意“而对于替用户多想一些没有提到的功能，那么就要深入领域，深入行业，才能超前想出一些功能。”

我谈谈我的想法
在分析时，我们要尽可能的将功能罗列，在设计时，要尽可能的将功能减少，
要有一定的高度，不能没有高度，否则用户不认同。
但是又不能太高，因为费用太高，
这一切都是取决于对“风险”的把握。
如果“风险”太高，那只好去掉一些功能，
但是可以在设计中留有余地。
流多少的余地，那就靠项目经理的平衡能力了。
这也是一个“风险”

对上面的CMS，

如果要求对某些用户可以浏览，某些用户不能浏览，又或者某些用户只能浏览一部分。。。。。。。
。。。。（又产生了许多需求变化）
如何扩展？
如果要求可以对某些级别的用户可以浏览，另一些级别用户不能浏览。。
（又产生了许多需求变化）
如何扩展？
软件在修改啊，修改，有一天
啊，软件终于完成了它的生命了。
这本来就是如此。
唯一不变的是，你可以承担多少“风险”，你的软件就有多少扩展性

哦，不好意思。

前面有人讲过了，可扩展的设计有支持业务的和支持结构的两种，这个我是赞同的。

再进一步深入的话，支持业务的可扩展性的前提是业务逻辑本身是具有可扩展性的，然而这一信息往往是隐含在用户的要求里面的，很多时候用户不会主动的抽取这层业务逻辑。
而认为这完全是用户的责任，用户不提，我就不做，从而自己撒手不管，我认为最终会对双方造成损害。
因此我倾向于有业务人员去协助用户抽取这层业务逻辑，然后再进行可扩展的设计。

我前面说xp相对于传统软件过程把一部分责任移到别的什么地方去了，意思就在这里："业务人员去协助用户抽取这层业务逻辑"在我看来是传统软件过程的思路；在xp中似乎根本就没有"业务人员"这个角色，"现场客户不提，我就不做"这个应该是xp的思路。现场客户在xp中的作用我说不清，在我的判断中，现场客户在非常多的方面承担了传统软件过程中的您所说的"业务人员"的责任，几乎是必不可少，并且非常强调"现场"这两个字。
交流会使现场客户主动抽取这层业务逻辑的。

呵呵，现场客户是一个符号，谁说一定要是真正的客户了？
我的意思是在XP中，如果客户不愿意或者能力不足以担任现场客户，那么就配业务人员做现场客户。这个业务人员和传统方法中的业务人员有一些微妙的分别，就是他必须做出取舍，我认为这是非常关键的一点。

我先确定一下我对某些概念的确切含义，我这里说的客户和用户的意思是软件最终使用者，我说的业务人员是属于开发方公司的销售部门人员。
现场客户不一定要是真正的客户……这个我没想过，我觉得不是真正的客户不大可能给你提供正确的业务决策，您所说的业务人员无法承担完全的业务决策责任，业务方和开发方角色会再次混合。
我个人认为如果现场客户不是真正的客户，那么这个开发过程已经不能称之为xp，任何对xp的定制都有可能损害xp的核心价值观，当然不是一定损害xp的核心价值观，但xp的实践之间很多耦合的极其密切，我不知道在破坏这种紧耦合以后，它还还是不是一个整体。

哦，那么我对业务人员的定义和你不同，业务人员和销售人员完全是两个概念。

我认为xp主要解决的问题是“怎么样更快更好的做”，但是对于“怎么样保证做的方向是正确的”只是简单的用“现场客户”和“计划游戏”来搪塞了一下。
在大型项目中“现场客户”很有可能是虚化的，不是一个单独的个人所能承担的责任。

您的意思是"现场客户"是xp中难以说清的东西，一个为了理论上的完整性而凭空提出的一个概念，或者是不可靠的一个角色？
我确实不知道您的这个判断的原因，不过您这么说的话确实失去争论的基础了：在我看来争论的话题的前提是应用xp开发过程，而没有现场客户，就意味着不是应用xp的开发过程，那么争论的话题的前提也没有了。