不光是做软件，凡是做产品，最后关注的总是产品的质量。
举个例子，比如你做一锅汤：
今天你状态很好，做完后尝了尝，感觉很美味，你的家人尝了以后也有同感，喝完后感觉心情舒畅、意犹未尽。
隔了一个礼拜，你做同样的汤给家里人喝。做完后你尝了尝，感觉依然美味，盼望着得到家人的赏识，然而他们却说味道咸了点。你很奇怪，为什么同样自己尝过了，家里人却感觉不一样呢？是不是最近加班多了，休息不好，味觉不准了？
一个月过后，你要去国外出差，给家里请了个临时保姆。一天，他也做了这么个汤，做完后，他也尝了尝，感觉口味很不错，可是端上桌，家里人说这汤太辣了。原来这保姆才从湖南老家出来不久……
因此，只把焦点放在最后的产品上往往是不够的。需要对“做汤的过程”加以控制。所以工程界会比较关注过程的管理，在软件领域也称作“软件生命周期管理”。
再来看看UP和XP。它们都属于软件过程，只不过各有特色。
再拿刚才那个做汤的例子：
大家都听说过德国人的厨房像化学实验室，天平、计时器、量杯……装备齐全，再配上精确的菜谱，严谨的德国人能够确保不用尝那最后一口都做出口味基本一致的汤。
换了中国人，大部分人都不会模仿德国人做菜的方式。解决方案很简单，让你的太太和孩子都尝那最后一口，再根据反馈调整几次，同样能做出全家人满意的汤。
这个例子也许不太贴切，但是可以联想一下:德国人做汤倾向于UP;中国人做汤倾向于XP。
UP和XP最终目的都是为了保证产品的质量，不同的是，两个过程所强调的方法不同。我想，没有人会说“UP的目的在于变态地追求文档的完美”、“UP是为了要程序员学会写各种各样文档”……之类的话。同时，也没人会说“XP就是不要文档只要代码”、“XP就是要变态地追求完美的代码”……这样的话。
这些不正确的看法，只是人们对于这两种过程的误解。或许是来自于开发人员和项目经理的那些“不堪回首的经历”。
“UP害惨了整个软件行业，让开发人员没完没了地写文档而忽略了代码，XP才是王道”这样的话，我不敢苟同，仍然有很多企业使用着UP这样的重型软件工程，就好比德国人依然喜欢把厨房弄得像个实验室。
XP固然是个好东西。但是，不知道大多数人对于XP的热衷是出于对XP文化的理解，还是国人惯有的“一窝蜂”似的行为。不晓得一个“能够熟练阅读代码的Leader”是不是能够真正运用好XP，确保他的团队能够尽可能少地出现"Over engineering"这种违背Agile精神的东西，或是能够让他的团队保证“每周只工作40小时”这样的基本实践？
对于不同的技术和过程，应该给予冷静的分析和慎重的选择。每个过程和技术都不能以“正确”或“不正确”来定性，只能以“合适”和“不合适”来定性。因为正确或不正确是要严格证明的，而合适不合适是来源于工程实践的结果。所以，COBOL依然在金融领域起着举足轻重的作用，科学家们仍不忘Fortran，汇编和C仍然健在……
另外不得不提的是文化上的差异。为什么很多时候，我们学习国外的先进技术，购买了整套生产线，引进了全套图纸，请国外专家做了详细的全程化培训，国人生产出的产品品质依然不如国外原产的？这是每个中国人都应该思考的问题……