关于设计的可扩展性。

兄弟，Uncle Bob在XP界算不上少林武当，连青城派也算不上. 如果他写的那本敏捷软件开发中的代码水平代表他自己的代码水平，并且他自己的水平代表了XP leaders们的水平，那大家赶紧扔了XP吧，太没前途了。
是不是正宗的XP，去验验12条军规先。如果有一条不对，就连XP也算不上，就别提正宗了。

关于现场客户，偶最有发言权了。
hehe,因为我就是手头这个项目的现场客户，但是我自己知道，我不是一个合格的现场客户。所有业务上的问题不论大小我都负不了责，最多对界面有点决定权。真正对业务有决定权的人，不论领导还是具体的员工，说句实话，在一个星期内分七次去问同一个问题，估计至少能够收到5个不同的回答，而且，大伙都忙着真实的业务呢，沟通了几次，就没空陪我们玩喽。
而且，我们这里信息化搞了7-8年之后，各个部门都学乖了，在看到真实可运行的东西之前，免谈太具体的细节问题，不过，这里的关键是一点，根据客户看似复杂并且有些矛盾的陈述，建立起一个蓝图，并且以客户能够理解的较为直观的方式表述出来，这个能力绝大部分团队都不具备。所以才需要拿真东西说话。

同意，所以重点是“确定条件和变量范围”，否则要不就是写的太死，要不就是过度设计。

大有同感。
所以我说项目开发有两个原型阶段，开发阶段用快速原型，上线意味着真正的原型完成，在后面的几个月里，用户开始提出修改意见，这种模式我称为慢速原型法，上线后才是真正的开发重点，除非是很成熟的业务系统，否则上线后的一段时间内业务用户还是在做相当于业务测试的工作。
如何缩短上线时间拿出实际运行的“原型”，上线后如何进行bug修改、业务变更和设计变更，需要重新来定义项目的生命周期，并采用一系列的过程、技术和管理手段支撑。

现场客户我也有发言权，因为我第一次有意识地实践xp中的某些东西就有现场客户。
这个项目是真正要用的，和现场客户利益直接相关，所以比较充分获得现场客户在xp中的地位这方面的经验。
第一个版本的确定非常快，动手做出来也很快，但还没完成就获得现场客户的强烈反馈，真是体现了开发过程中的现场客户的直接参与（嘿嘿，我觉得我很幸运，能第一次实践就在这么一种很刺激的环境中），搞的我很厌倦，心里一直在骂，不过这是我自己选择的：）
之后才感觉到这种厌倦的好处太大了，以后的版本一马平川。
并且确实一开始说一定要实现的东西到最后也没实现，因为是客户的选择。

说点别的吧：大陆大多数的项目恐怕都是求来的项目，客户自然没有那么多责任心在里面，这种情况我想xp的那些名将都想不到的。

但是做企业项目的团队，很多时候对于上线后怎么调集足够的资源保持快速相应能力通常缺乏足够的认识，或者说缺乏什么才是企业项目最重要实施阶段的认识。特别是那类分期上线的情形。上半年我这个项目的第一阶段上线，而整个团队的重心都在后续的开发任务上，当时记得提交了n多问题，而且多次口头强调了紧迫性，结果过了1周发现项目组把这些问题的解决的优先级放在在相当靠后的位置（而且当时正好是春节前后，结果搞得相当被动）。当时就差点晕死，发现两边对有些问题还是缺乏共识。
不过深究起来，这个也怪不了项目组，应该说是开发方和甲方的利益不一致导致的，其实是乙方更高层的领导应该尽到自己的责任。
业务部门对项目组和企业而言都是最宝贵的资源，对于同一件事情，大规模调集这类资源通常都只有1-2次机会。如果不能够在上线过程中保持一个迅速的良性互动，对双方都是浪费和很难挽回的损失。

对于企业项目而言，在一个正规的企业里面，客户的责任心应该说不会比项目组差，但是客户的耐心是有限度的，或者说客户（不论是现场客户还是业务客户）是一个有限资源，虽然通常这个限度要超过项目组以负责、有计划的态势开展项目所需的上限。
大多数时候，项目是会被甲乙双方利益立场不同而出现很多问题。乙方总想尽快用更少的资源（意味着更少的成本和更多的利润）完成开发计划，通常存在很多短期行为(包括在设计、代码开发阶段和实施阶段)，而甲方可能会考虑的更加务实、长远一点（从某种意义上说，乙方昨晚项目验收之后是拍拍屁股走人的，而甲方的相关人员却是长期的利益相关者）。当然，这个是在甲方存在信息部门的前提下，很多中小型企业可能本身没有信息化相关的专职部门，所以事情会不一样。

现在的软件开发如同装修市场 有的自己找人干 有的找装修公司 有的直接买装修好的房子.

嗯 严重跑题 .

设计的可扩展性和以下几个方面有关
按重要成度排序

1 对业务的理解

2 组件的划分

3 采用的技术规范 比如开发框架 数据库

1 2 先不谈 说说第3条 就现在的情况看xml开发框架的灵活性和扩展性是最好的. 比如cocoon  

在数据库方面 RDB是大家常用的但是 但经常修改RDB的表结构 键 字段 索引 依然是要伤筋动骨的. xml    native db+xquery能很好的解决这个问题.虽然没有多少人用 但用过的人都知道. 哈哈又是废话

我最熟悉的企业的信息部门是某个三甲医院的信息部门了. 医院的信息部门有个一个开发组,负责医院内部的大部分的软件的开发. 如果需要外来公司做项目,外来公司在最后会留几个人到医院来做现场改. 而那个聪明的公司就是外派的人员都是当地的开发人员,水平一般那种,比如家在这边,或者有男(女)朋友在这边.当最后项目完结的时候,外派人员就会不想在那个公司干了.因为现场开发实在是累. 又加上是项目的开发人员之一,同时有个社会关系在当地.于是最后外派人员就变成了医院信息部门的研发人员了. 于是医院的项目维护和后续开发有了部分保证,公司也不会和医院关系搞的太坏. 
这种情况下,甲方和乙方的利益冲突因为某个开发人员的隶属关系的转变而得到了缓和.  项目做的烂点也好说了.  当然这是在外包项目少的情况下.要是全部外包大概医院也不能招太多的人进来.毕竟医院信息部人员编制不是无限的.

没错，企业项目的开发过程比较复杂，特别是在后续版本的开发阶段，后续版本开发、bug修改、紧急问题处理、功能升级等等混杂在一起，如何协调客户资源，在解决前面版本上线后的问题同时，进行后续版本的开发，这里面的名堂还是挺多的，要不也不会有实施方法论了。

好了，我看我们都严重跑题，如果有兴趣可以另开一贴讨论。