关于设计的可扩展性。

    这种情况倒没什么问题，关键谁是决策者？业务决策和技术决策是否分离？
   我认为XP是很强调“做什么”和“怎么做”这两者的分离的。
   一人兼两职总会有点问题的。

可能必须出一个界限了。
当你用面向对象的设计的时候，几个面向对象的东东比如封装就可以利用了，这个算不算应付需求变化手段呢？把整个东西划分成几个对象，还有继承关系，应该也算应付需求变化了，还有您说的接口设计，明显也在隔离很多东西，这些都是已经很成熟的应付需求变化的某些技术。
当这些技术被开发方掌握以后，用这些技术已经几乎没什么副作用了，我想这些技术应该不能算我们所讨论的"应付需求变化的设计"。
措辞有问题，意会吧(不好意思)。
还有一个扩展性的概念问题，我觉得我们一直在讨论的是需求变化，而不是增加。

    所以有单元测试。 谁都是可以是决策者，只要他能拿出依据。如果实在分歧比较大的情况下，就要提交团队讨论。 如果没有结果，那么由项目经理去拍板。

   抱歉注明一下： 谁都是可以是决策者 是指 代码决策者。业务决策还是要靠客户的。前头例子如果是一个规则系统的话，决策权就在客户手里了。代价也是他付的

   项目经理一个人做业务决策和技术决策的最终拍板？
  我是非常反对这种做法的。兼一个决策还行，兼两个会出问题的，对于项目经理的依赖性太强了。

补充：看到你的修改了，那就没什么问题了。

是“XP是很强调“做什么”和“怎么做”这两者的分离的”，但关键的是xp中有提到的现场客户在现实开发中又是很难实现，如果让专门的人来做需求分析，在把分析完的结果给开发人员，那还不如开发人员直接来分析需求。我想通过中间的一层转换需求信息的可靠性就大大打折扣了。

对于可扩展性，开发人员的职责是提供多种选择方案，做或不做，或是在哪方面扩展，并提供对每种方案的估算。而用户的职责是决定选择哪种方案。
用户选择哪种就做哪种，当然国内的情况比较复杂，有时候用户还是需要开发人员来引导。

     呵呵，所以我强调需求/经验/refactoring

我们在做系统前完全可能想：这个系统将是全世界最完美的可扩展的系统。
实践证明，这样的结果往往是你把驴当作马交给客户。

  理解需求是一个持续交流的过程，XP中非常注重，我们随时可以和客户交流。

  经验，我们不再是流水线上的一个机器，而是人，可以互动交流，没有等级森严、交流渠道不是错综复杂。 我们抬头就看见我需要请教的专家或者讨论的家伙

  refactoring,虽然我有经验，但是并不能一眼看穿世界。或许我只看到了3-4步，而实际需求只要我做到5步即可。我们就稍微refactoring一下下吧。

没有现场客户的xp是什么样子的呢？不是xp了吧，至少不是极端的xp了，在这种情况下如果还用xp的其他实践，我想没准会成功，但我觉得现在这种没有现场客户的xp的开发经验还没被人大规模收集和总结过，不好说怎么回事了。

没有现场客户的情况更需要专门的需求人员作为“代客户”
当然前提是这个需求人员业务水平要比较熟悉。

对于业务比较复杂的项目而言专门的需求人员更是必须的，否则非常容易走错方向。

另外补充一点：
    需求人员不仅仅是理解分析引导规划用户的需求，很重要的一点是要协助用户根据实际的业务需要来判定各项需求的优先级，我认为这在XP里面是至关重要的，而通常情况下技术人员是根据实现的难易程度来判定优先级的。

   呵呵，通常业务比较复杂的系统，必然有个客户，否则真会是指驴为马了。
最底限度，有个稳定的联系通道，面向XP团队通道口必须有一个权威的声音。