我原来的项目程序方式看来就和XP差不多，当然pair programming做不到；但测试是完全做到了。至于说需求变动，我认为是最不可能的地方。事实上，最经常碰到的故事是user story说了千百遍，大家都没有异义，甚至快速原型也做出来了，然后按这个开始开发，各模块也测试得差不多了，甚至完成最后内部可 用性测试，但用户一看到出来的样子，马上出一大堆新的需求，这也罢了，故事和原来是完全不一样的。要适应意味着要推倒重来。

其实传统不传统，XP不XP，最大的问题都不是开发开者测试，而是客户的故事是未定型的。只要故事是确定的，WINDOWS我也可以把它build出来。另一方面，客户一边情况下缺乏对需求的把握，所以常常是拿几箩框的界面菜单当成是需求，至于每个菜单里说什么，他自已是稀里糊涂的。要替他想出来，细化出来。 所以问题就在这里，和编程无关的，就是用户的需求分析，这才是关键。

少了点什么，对不对？不错！少了建模(modeling)。程序架构的建模当然是一个技术问题，用户不需要懂，对用户也是透明的，但是业务逻辑的建模，就纯粹是信息化中的业务问题，而偏偏这个建模，用户不懂，不但不懂，而且最通常的情况是不愿意懂，不愿意承认它的存在（承认了就等于说自已业务能力不足了），结果，开发者实际上是拿到了一些无建模的“需求线索”，而常常在中国如此恶劣的软件环境下，建模这一笔成本和时间，大约占了项目的五分之一左右，完全没有机会打入预算，除非，你不打算干这行了。

在中国干软件干得特别累人，这就是最根本的原因。在中国项目预算和时间都没有办法准确预计，这也是根本的原因。.实际情况是时间都很紧，客户并不了解开发程序需要非常详细的故事定义，他认为这是技术的东西，他不需要懂；没有准确的定义，开发本身就存在着不到位的危险；时间就没有办法估计。没有建模过程，所谓一个项目要花多少时间完全就取决于经验，而且必须是完全同类同细节的经验。这还没有包括开发者必须探求符合技术趋势要求的开发和架构范式的所涉及到的不确定性。

上面两条影响项目估计的最重大因素，在XP编程中都完全没有涉及，相信在国外成熟的软件产业环境下开发者也极少会碰到。在这种条件下所谓推广XP编程，等同于让程序员背上不能背的责任，没有建模过程，没有成熟范式甚至甚同类的经验（不是缺乏开发经验），却要承担所有预测不准的后果。既要马儿跑，又要马儿不吃草，莫过于此了。

所以ＸＰ说是可以适应客户需求变化，我看只可能是专业性客户，象软件咨询公司那种本来就是牛人的需求变化。外国是这样的，但中国不是这样的。而且，在中国客户可以按ＸＰ要求开发团队适应客户的需求变化；但公司却不会适应因此产生的团队对工资和开发期限的变化。

缺乏了需求阶段性冻结这一条，ＸＰ是一堆让开发团队受难的屁话。ＸＰ最大的疑问是它的基础，它假定客户需求基本上是清晰的。而实际上传统的经验是无论你如何和客户一起商量故事，一直到你把东西做出来为止，客户才会说那是不对的。这就是传统软件管理的基础：客户不知道他想干什么，想要什么，直到他看到不想的，他知道那是他不想要的，但仍不知道他自已到底要什么。ＸＰ编程说了一大堆擦边球，都是废话，因为这个最根本的东西，他碰也没有碰。
我是这样看的。

XP编程有些理念值得参考，但所谓可以自由适应用户需求变化的，没有真正经受过地就不要站着说话不腰不疼——偏偏，无论是在美国的始倡者，还是在中国内地的附和者，仅仅从其缺乏细节描述的高调中，我就认为他们都没有经过那种地狱的磨练的。