大师打个喷嚏，我们都要重感冒

charon
即使需求不变化,传统的软件开发方式一样是不行的.迭代的方法之所以成为主流,最根本的原因是迭代对风险的控制更加容易.
不知道你是不是认为需求必然发生变化,我是认为需求是必然会变的.那么既然会变化,是不是可以作出一个预测,从而对未来的变化做出应对呢?从工程学上考虑这个情况是不可能的,因为你需要花费太多的筹备成本.这就好像风险分析一样,你是可以对计划中所有的风险都在早期进行针对性的处理,但是这样显然是不经济的,因为你不能肯定那个风险会不会发生,即使会发生又会在什么时候发生.这一点KENT和MARTIN说的很清楚,你是上车之后就把车头对准你的目标,然后就松开方向盘一直向前,还是先找个大概方向,并从此不断地调整你的方向(或者用反对XP的人的说法:开枪/瞄准/瞄准).
从整体上把握走向,这个走向是谁制定的?是不是这个走向就不会发生变化了呢?需求工程现在之所以不在把形式化研究作为重点,是因为对需求的单纯理解,已经不是问题的关键.需求在绝大多数的情况下是不稳定的,并且不能被客户明确的理解的,即使在个别的时间被客户所部分的理解,但是由于新的变化又会走向不理解.从而对于整体的走向的把握不可能在最初就可能明确.
预先的设计会不会使对于整体的把握就十分有效呢?这首先要证明预先的设计可以做到可以证明其自身的合理性.你说对于一个有经验的团队不是难事,但是我认为这对于任何一个组织都是一个困难无比的工作(当然你可以继续坚持你认为不难,或者干脆就说对于你来说不难).设计合理性不仅仅是需要验证其功能是不是符合需求,还要验证其效能是不是合乎需求,还要验证其可维护性和建造性合乎需求.就只功能上来说,一个设计是不是可以实现一个功能,在实际实现以前是没有半点办法得到验证的.设计中有很多看起来很合理,但是具体实现的时候却漏洞百出的问题.同时设计中所有被我们无意忽略的某些因素,会在实现的时候造成许多莫名其妙的问题,寻找这些问题是一种非常复杂的工作,也是非常需要资源的工作.一个设计思路在一个项目中可能是合理的,但是把这个思路换到另外一个地方是不是合理就不好说了.而如果是合理的,那么你的设计还是存在问题,因为你已经有了足够的线索可以看出其相似性,那么这个时候你还是以一种作项目的方式而不是做产品的方式进行你的开发,说明你的大的方向就是最大问题.
同时XP并不是说要你不去做预先的设计工作,不然你怎么会得到你的SYSTEM METAPHOR.xp所要求的是,你不要做一个过于细化的预先设计,而只是找到一个总体的大的方向.
需求的调查深入是不是就可以理解需求呢?即使理解是不是这样的做法成本就更低呢?客户很多时候是不知道自己到底要什么的,所以才需要原形.但是原形不可能覆盖所有的方面,也不可能被用户长时间使用,这个时候你等待所得到的需求一样是失真的,不充分的.AGILE的关键在于其实小迭代,这样可以充当长期的原形的作用,同时小迭代更加使开发者可以控制设计的迷失.
同时我注意到你多次提到了构架这个词,不知你是不是在说ARCHITECTURE,我觉得我对于你的这个概念不理解.比如什么叫构架的转身,什么是构架的关键?请进一步解释.

不知道多久以前的开发方式叫传统，至少RUP里是有迭代的

至于需求的变化问题，这和做什么类型的软件有密切的关系，不能一概而论。而XP的优势和劣势都在现场客户这个环节上了。现场客户不能保证，依据需求变化就成了空话。
软件公司利用这点把需求捕获不准的风险转移给现场客户身上，恩，你签字吧，签字了如果有什么问题就是你们的问题了。
我们在做项目时，和我们对接的客户员工很不愿意在任何纸上签名字。

这是最大的分歧点，做多少的开始设计算够，没有一个很好的标准，
而所谓的框架错误，我的理解是：拿xp的比喻就是根本方向就是反的，等你开了一大半才发现。
这种错误对于任何项目都是灾难，XP和RUP谁更能避免这类错误？

至于小蚂蚁的成长问题和TDD根本无关，一个项目里面都是小蚂蚁，采用什么方法都是很大的风险，即使TDD也救不了。

RUP的迭代支持可以说是最让人诟病的一个特征（其次还有构架的混乱，计划的无序），但是迭代一样在这个环境中起到了非常好的效果。可见迭代的方式比较传统的瀑布方式是有无比的优越性。
而迭代的方式并不能让你不遇到风险，更加不会让你去犯错误。问题的核心在于迭代可以让你尽可能在早期发现这些问题，而给你采取补救措施带来更多的机会，同时即使项目失败也会把损失控制在最小。
在XP中你可能会在项目的后期才发现你的根本方向是反的，这样的情况是可能会发生的。但是你在其他的方式下，这样的情况一样会发生。
对于XP和RUP来说，XP的可控制性大大强于RUP。虽然他们一样被称为强约束方法，但是XP的约束性无疑更加明显和明确。同时XP对于迭代的强烈的要求，特别是对于短迭代的苛求，无疑使其更加容易避免犯错误。但是由于XP的控制和约束大大强于RUP，那么其使用的范围必然会被界定在一个更小的区间内。
项目的失败也必须失败的代价尽量的小，TDD不会一圈蚂蚁把不可能完成的项目完成，这一点毫无疑问。别的方法一样也不可能。但是由于TDD的强制性的小步策略，可以让你在早期就发现难点，发现问题，降低失败带来的损失。同时TDD对于学习和掌握新的能力无疑是一种良好的方式。

我把中重量级迭代开发也放入到传统开发过程中去了。hehe.
对于需求，从我的角度来看，或者说根据我们信息部门成功或者失败的经验(当然，面上都是成功了)，我们现在选择合作伙伴，最重视的是行业经验，或者，如果有类似项目的范本。作为行业企业，本质的业务流程是一样的，旁支的流程可能各有不同，但是这个不会影响到技术决策。但是，企业里面做项目，最重要的不是有没有一个产品(当然有产品更好)，可能建立一个能够使系统正常运转起来的机制更加重要。或者，这不仅仅是一个开发过程，更是一个实施的过程。本身一个系统的应用对于企业的管理水平是一个提升，但是，如果要一个技术项目团队去深入沟通提升的方向或者方式，那是超过能力范围了，这块东西有点归属与BPR的范畴，或者是一个咨询团队该做的事情。这也是为什么在BPR之后实施ERP，成功率要高得多的原因之一。
所以，对我们来说，最合适的方式是项目团队本身有自己的关于管理、关于系统的理念，并且这个理念和我们需要达到的目标相似(对于有经验的团队而言，一般都会相似)。在实施这个项目的过程中把用这个理念来剖析企业的某个层面的业务实际，来提升这一部分的管理和运作水平。而我前面说的充分沟通，更加强调的实际上是和高层的沟通。倒是没有把最终用户的沟通在初期放在一个很重要的位置上。决定项目走向的是高层对于项目的期望和认识。如果自己没有一把尺子，最终被各个应用部门牵着走，不论是什么团队，都会死得很惨.或者说，存在那么一种场景，实际用户要求这么这么做，我们对他说这样做可以实现，但是我们不建议那样，而是怎么怎么....
还有一点需要强调，对于风险和影响架构的因素，我这里强调的是关键因素，不是所有风险和因素。而且，我觉得kent在这里有点像不可知论者，对于风险控制，我前面有一个比喻：不能够因为会发生毁灭性的车祸而连系安全带的兴趣都没有了。或者说，是不是因为车祸在大部分情况下都不会发生，那么我们就不用安全带了？从kent的观点来看，我想就是不用了。风险控制的最终目的正是用各种手段避免它发生，或者万一发生之后按照预定方法控制它的影响面。我们这里下一步有时间的时候会对所有重要系统分别做应急预案，目的也在于控制万一发生紧急情况的影响面，有没有这样一个预案，当事情真正发生的时候，结果会有本质不同(因为我们的一个被认为稳如磐石的系统，在运行将近5年之后终于宕了一次机，虽然时间只有2个半小时，并且不在关键时刻，只影响到一个部门，但给我们的教训深刻，而且这个故障，即便是双机热备，也照死不误)。不能因为风险可能不会发生就不做提前预防。
还有一点就是经验。不过经验上的分歧不重要。而且那些莫名其妙而出来的问题，最终很少是因为总体设计的原因。很多时候是在细节设计和编码阶段的忽视导致的。如果在总体设计中出现这种带有颠覆性的问题，我会怀疑这个团队的前一个成功的类似项目是不是另一班人马做的。
至于架构，我的可能和时髦的用法不一样(因为我一直没有理解那个含义)。比如，要做一个OA，那么重要的是一个非结构化信息的管理机制和一个工作流引擎。当然，如果由浅入深的做的话，一般实施方都会先自己搞一个数据库来处理信息，并且粗略的实现一个工作流引擎来处理系统内流程相关的业务，但是到最终，可能会走向专业的内容管理系统和工作流引擎，自己开发的OA核心功能上可能会满足要求，但是成熟度、扩展性、可维护性上远不如产品，从甲方的观点来看，综合成本上成熟产品要比特地开发的东西要低，这一点我是深有体会。但是，从XP的方式来看，除非我甲方坚持，会一上来就这么考虑吗？一般我们也不会在招标前提出这种需求，但是会在收标后直接淘汰有那种自力更生想法的公司。还有一个例子是OLAP，如果不用OLAP服务器，根据需求直接设计，或者用类似于DB2 II的工具来做数据集成后再设计，都能够做到，连一个多维模型都不需要，软件成本低很多。但是，这种方案的灵活性呢，移交后的可维护性呢？如果这个系统我只想用1-2年，那倒无所谓。但是要用3年以上呢？

前面那个"....自己开发的OA核心功能上可能会满足要求..."这句话有点歧义。本意是：
....自己开发的oa的这一部分(指非结构化信息管理和工作流引擎)核心在功能上可能会满足要求...

charon
首先你混淆了一个概念,风险的概念.你说的那个死机的问题不是风险,而是一个设计缺陷.其次你对于构架的解释依然让我迷惑,我完全不知道你在说什么.特别是最后一段,你说如果是使用XP如何如何,我想问你如果使用别的方法又如何?你甲方不明确说明,我乙方就要给你强加一个东西在项目里面,你认为这个办法好还是不好?还有你对于OLAP的解释更加让我不能明白你到底是在什么地方得到的信息.在这样的一种绝对CLDS的开发方式下,你除了AGILE你还能有别的什么更好的选择吗?
对于企业应用项目来说,核心当然是对业务的理解.但是对于业务的理解绝对不是坐在那里看看资料,听听讲座就可以的.需要做大量的细致的调查研究,需要大量的沟通工作.谁也不是天生就带着那把尺的,而且那把尺子你不去经常性的使用,也会过时的.对于XP中各个角色的职责你还是去看看XP explained,对于你说的那个场景xp的解决方式我觉得绝对是最合理的，业务人员去作出业务决策，技术人员作出技术决策。
XP对于风险的控制是他的强项，而不是你说的弱项，安全带就是其强制性的短迭代。至于为什么短迭代是一种风险控制的最优策略，请参看上面提到的那本书或者参看RUP的解释。

ozzzzzz，
1 那个宕机问题如果是缺陷，也是os400作业调度的一个缺陷。但是，人家5年才出了一个这样的问题已经不错了。至今我们还是没有找到另一个能够以类似成本处理类似业务，并且稳定性、可靠性上能够超过这个的系统。
2 olap系统。现在的olap的系统大概有三个部分组成，一个是后端数据库，一个是olap服务器，一个是前端展现工具（不过现在的bi工具基本上都有）。实施过程中大量的工作在建模和etl设计上。但是，从技术上来说，不用这路做法也能够实现需求，直接通过数据集成的方式(就是类似于DB2 II的方式)从各业务系统中抽取数据来实现。
除了后面那个XP可以有点成效以外，前面那个建模和ETL设计，和XP一点关系没有。最后的分析界面，则取决于工具。最终甚至会交由业务人员去定制，和XP更加没有关系。
3 XP的所谓风险控制，是细粒度上的。从底向上控制风险是一种策略，希望以这种方式来达到全局的控制，是不是优于从顶向下，我认为这是一个看法问题，或者说是一个立场问题。
4  至于业务的理解。当然不是看资料听讲座（而且象我们这类企业也没人有工夫来做讲座，现场客户那就更不可能了，我上个星期约一个业务部门约了三次才有时间确认需求）。我们为了相对节省时间，通常会找那类实施过兄弟企业类似项目的团队。即便这样，关键还在于和实际客户的沟通确认(主要是了解现状)，以及与高层和部门主管的充分交流(明确目标系统中贯彻的管理理念)。这里面有一系列的技术方法，并不是说必须通过XP来沟通。而且对于规模大一点的项目，XP方式的沟通也存在着致命的缺陷。甲方为了控制风险，通常会将一个大合同拆分为几个来签，前期需求合同单独只是一个低价值合同(有可能会同时签两家，当然如果某家的需求或者做法被确认，会在后续合同中追认其应有的价值)，而软硬件平台必须等正式实施合同签订后(实施也有可能分期)才启动购买。这个时候怎么个XP法？或者说怎么能够让甲方在不启动软硬件采购的前提下确认你这个团队能够干好这件事情？
5 XP还有一个比较狠的地方就是认为XP到一定程度发现项目进行不下去了，就可以cancel掉，也算XP成功了，因为一般会在比较前面的阶段发生，所以为客户节省了投资。!!! 客户投资不仅仅是实施上的，我们现在的项目，软硬件投资也占了很大的比例，这些东西一旦用不上，折旧期也就是五年。就像那个olap项目一样，如果边建模边设计边沟通，最终发现搞不下去，几百万的投资就在那儿呆滞了。
这里的问题就是，XP成功不了的，是不是任何其他开发方式也就成功不了。

我觉得如果站在甲方的角度，问题会容易思考很多。
1 从企业的现状来说，越是对项目有影响力的人越处于管理序列的高端，沟通的机会和时间也越少。如何有效把握这些沟通机会，也是需求分析的一个重要动因，只有在实施团队对底下的业务现状有了一个了解，才有一个就管理提升进行沟通交流的基础，或者说沟通把理念落实到系统的可能(这里我对软件工艺中提到的传统软件工程的动因投反对票)。
2
系统业务功能的实现，以及易用性只是一个方面。实施过程中更加重要的是管理制度的配套。或者说这是一个系统的工程。怎样让系统的有效运作起来远比系统的实现要困难(这也不是培训的问题)。现有的企业项目开发团队或多或少已经认识到了这一点，所以也越来越加强相关力量的配备.或者换一句话说,企业项目不是在做开发,而是在做实施. XP团队,至少是我在这个论坛上看到的XPer们,我觉得还没有把认识提高到这个层次上来.
XP在过程上先进与否我没有那么热衷,毕竟,XP之前也有那么多系统开发是成功实施的.但是,管理理念上的一些东西,我的直觉,XP的哲学是排斥这些东西的.或者说,就像现场客户一样,XP对管理的要求太高了,以至于只需要解决技术问题,项目就可最大可能的成功实施.或者说,国内的大多数企业,包括国外的多数企业,都不具备实施XP项目的管理基础.反过来说,也是XP在企业级项目的应用,只能够在一个虚拟理想的环境中.

系统开发出来，最终却无法顺利实施，究其原因，主要还是因为客户企业决策者的景愿与现实有不小的差距。一般来说，客户企业的决策者总是希望建立一个大而全的理想系统，但是要实施这样一个理想系统，一般来说都会对现有企业制度体系造成相当程度的冲击，并且通常都会在实施阶段激起层层反对阻力。在这种情况下，客户企业决策者只能进行妥协，根据现实情况对系统功能进行相应调整，此时无论开发或实施都会受到牵连。那么RUP、XP或其他理论方法是如何分别应对这种挑战的呢，请各位fans各抒己见吧，具体案例具体分析最有说服力。