关于设计的可扩展性。

如何使设计适应业务的变化？其实是个业务逻辑层设计的问题。需求的变化总是预计不了的，只能使设计更易于变化。

在需求方面 变化是肯定要发生的 所以尽可能将需求分解成 小的任务 将它们之间的联系暂时切断.

在开发阶段 保证小任务组的独立性 灵活性 自主性. 如果在工作中发现这个小组总要 和其他组讨价还价 被迫做频繁的修改 就说明任务的划分有问题.

但是不论用如何先进的管理方法 项目经理的设计能力 对业务的理解能力 还是相当最重要的. 一个错误的划分和业务理解 就能叫项目延期 甚至失败.

您强调业务方面的知识，这个可以说比较重要，但并不是必须的，可能这个也是xp最与众不同的地方了。
具有业务方面的了解自然是好事，减少交流的代价，但如果没有业务的知识，就要了解业务，是不是有点浪费精力了呢？因为了解业务恐怕是个很复杂的事情，所以我觉得在没有业务知识，并且还没有必要了解业务的时候，适合上xp。

btw：800年前的帖子，我都快忘了当时说的都是些什么东东了：）

"您强调业务方面的知识，这个可以说比较重要，但并不是必须的，可能这个也是xp最与众不同的地方了。
具有业务方面的了解自然是好事，减少交流的代价，但如果没有业务的知识，就要了解业务，是不是有点浪费精力了呢？因为了解业务恐怕是个很复杂的事情，所以我觉得在没有业务知识，并且还没有必要了解业务的时候，适合上xp。"


俺对xp不感兴趣.

嘿嘿 学经济学和发财没什么关系

xp算我举的一个例子吧，你说
但是不论用如何先进的管理方法 项目经理的设计能力 对业务的理解能力 还是相当最重要的. 一个错误的划分和业务理解 就能叫项目延期 甚至失败.

我说的就是在xp中 项目经理的设计能力 对业务的理解能力并不重要。
在xp中，也谈不上你说的编程前对模块的划分。
我的意思就是你说的这些技能和手段并不是放在哪里都好使的。

同志哥，谁说xp不需要理解业务了？不说erp这样的大系统，就是营销管理里面的一个订单业务处理过程，你不理解业务，你怎么保证你做的就是对的？怎么去把握业务的变化？怎么进行业务的分析和改善？你不会说xp是不用做业务分析吧。
不理解业务去做项目，项目到头来就是一个死。

如果存在不需要理解的业务的系统，那么我看也就是Hello world这样的东西了。软件的价值是什么？对于企业而言是管理的改善和便利，核心是业务，没有业务的软件也就意味着没有任何价值，没有价值的软件开发它做什么？

业务方面自有人来处理，不是开发方的事情。

能介绍一下吗？不是很明白，开发方是怎么一回事？具体做什么？业务方怎么和开发衔接？

难道我理解错“业务”的概念了？我没什么底气了：）
开发队伍中的用户代表管业务方面的事情，队伍中的开发方做软件。

举个简单的例子：
从某个数据库里面提出数据，计算后成报表或图形。
我根本不管这些数据代表什么意思，只要知道字段就行了，计算公式从哪里来为什么是这么计算的我也不管，用户提供，报表或图形为什么要这样我也不理会。
最后做的也蛮好的嘛，基本可以用快又好来形容。

那么谁来做业务到技术实现的转换？

经常会碰到过这种情况：

客户代表：我要做A；
开发：没问题，实现A；

客户代表：不对呀，应该是这样的，我要的是B；
开发：OK，立马实现；

客户代表：还是不对，你看这个地方应该是这样的，我要的是C；
开发：到底怎么回事，你到底要怎样，能不能一次说完？
客户代表：哎呀，我也说不清楚，反正我们就是这么做的，大的流程你们实现的没有问题，就是有些细节问题，我们尽量想清楚，不好意思；
开发：好的，考虑仔细我们再做，最好这些内容经过业务领导的确认签字，我们就照着开发；
客户代表：没有问题；

开发：看看我们这次提交的怎么样？
客户代表：这次看起来好多了，不对呀，这个地方好像我们实际上不是这么做的，我看看，不好意思，我要的是......

最后的结果
项目组的业务顾问经过分析后，发现客户要的不是A、B、C、D，而是E。


好了，这个话题扯远了，我不再对业务问题发表意见，呵呵。