关于设计的可扩展性。

可扩展性这个词很模糊，我们需要明确。
实际上有设计支持业务的可扩展性和设计支持结构的可扩展性两个方面的问题。比如对于顾客的折扣，会有新老客户的问题，还有促销的问题，还有其他很多业务领域几乎成为惯例的折扣变更的问题。这些东西如果你的程序不支持，只能说明你的需求理解存在问题，而不是你的设计是不是遵守了xp的简单设计问题。xp所反对的大多数情况下是结构的可扩展的问题，也就是代码的无谓的灵活性的问题。对于业务不管是采用什么方法论，都要遵守尽量重视客户的需要，客户的业务逻辑，客户的行业环境。这个方面没有什么价钱好讲，一切以客户的需要为我们的目标。而结构上来说就不是这个问题。比如客户没有要求或者目前这个迭代没有涉及到的模块，你偏偏要提前的考虑什么接口，考虑可移植等问题，这就是要反对的了。客户修改折扣，不是为了可能凡是的变化，而是现在和今后不断发生的变化，这并不因你使用什么方法论而受到影响。也不是你采用重构可以解决的问题（系统已经在运行，你还要经过重构才能支持修改折扣，修改客户的性别，修改客户的名称，这些都是不可能的）。xp虽然支持对客户的需求的深入理解，但是如果你不能把客户的需求真正的吃透，xp一样会失败。

我想xp中的很多方法还是可以用的而不只是集成测试和结队编程吧。

如果为了比如界面上的某些可能要提出的需求(比如想到可能客户将来会要求在任何地方停留都有帮助信息)，这种可扩展性属于什么呢？

呵呵，随便说说的，我想用户故事和计划游戏应该没了。

这个问题问得好！
实际上这些问题在项目的初期，以至于在公司开发项目之前就应该确定。帮助的易用性问题，是一个软件使用性的大问题。但是这个问题涉及到很多的成本因素，而且这些因素往往是在项目洽谈初期就可以估算出大概的成本范围的。当然我们要认识到这个问题不是技术问题，而是文档撰写的问题。不管你使用什么方法论，都会遇到这些问题。这不是一个扩展性的问题。

专门的业务人员确实有隔了一层的缺点，但是当他担负起以下职责的时候，就有好处了：
1、有更充分的时间和精力了解用户方的背景知识，从而理解用户功能需求的业务本质
2、在熟悉业务的基础上，可以较好的展望用户未来的变化，引导甚至达到规划用户业务的级别
3、协助用户确定业务需求的优先级别。（这一点其实非常关键，开发人员往往是从功能的难易程度来区分优先级别的，往往不能反映用户的真实需求）
4、协助用户找到可接受的变通处理办法。

一个业务人员在拿到用户需求的时候首先的反映应该是：
    “这个需求我理解了吗？它的优先级是多少？在现阶段是不是紧急的？”

而一个开发人员在拿到用户需求的时候首先想的是：
    “我怎么去实现它？”“用什么方法？需要多少时间？”

那这样的话我们是不是把宝都押在了需求人员身上了。还有一些问题是：
   1.需求人员可能不懂技术，对客户承若了不可能实现的功能。
   2.需求人员不知道实际开发中需要知道一些需求，而如果是开发人员来做需求就可以最大限度地避免。

不能因为"任何方法论都无法解决"就说"这不是扩展性的问题"。
我想只要是在原有基础上更改增加代码(也许不局限于代码)就叫扩展，为了将来可能出现的某些扩展做一些预先的设计就叫可扩展性的设计。
而帮助系统是一个"在原有基础上更改增加"的一个功能，您可以为了这个将来可能出现的东西做一些可扩展性的设计，当然也可以不做，但无论做不做应该都是可扩展的设计。

btw:我想"在公司开发项目之前就应该确定“这句恐怕已经不是xp的强项了，xp出现的理由就是变化的需求。

关于第一个问题
需求人员是不能向客户承诺进度的。
需求人员的职责是分析用户需求，标出优先级。
开发人员的职责是给每一个需求给出实现难度和估计时间。

如果一个高优先级的需求恰好是非常难实现的（甚至是不可能实现的），
那么就是项目经理需要和客户协调决定的。

关于第二个问题
开发人员可以直接向客户询问，但是应该由需求人员在场。
或者直接向需求人员询问。

我认为是传统开发方法把不是自己的责任都揽过来了，XP把它们又放到原来该去的什么地方了。而应该负的传统开发方法推卸掉的责任XP又重新担负起来

客户：提供用户故事->开发者:评估->客户：选择->开发者:实现
还有比这个更合理的责任分配吗？