“UP是正楷，XP是草书。先学好了UP，才能学好XP；先学XP再学UP就会乱套。 ”
老师曾这么说。最近，对这句话有了深刻的体会。
软件过程是一个以人为中心的活动。人是项目中最难确定和控制的因素。休息的质量、情绪的起伏都会影响整个活动。为了尽可能地约束这种个体的不确定行为和减少开发过程中不必要的误会。"UP"采用了大量的文档来对整个开发过程进行控制。这些文档主要分为以下几类：
- 计划文档——项目的开发计划、迭代计划、测试计划等。
- 技术文档——项目的设计文档、某个操作的说明文档等。
- 记录文档——日常的会议纪要、每日进度反馈、评估报告等。
文档成了UP活动的主要部分。在UP中，往往大量的资源用于文档的制作。这些文档的目的是为了尽可能减少不必要的沟通成本和误会，也为了在发生问题的时候能够尽快确定原因找到解决方法。
而正是因为如此繁重的资源消耗，导致真正的设计和代码只占到了总开销的很少部分。这对很多人来说不可理解，甚至觉得本末倒置。于是很多敏捷方法诞生了，最具代表性也是对UP思想最具颠覆性的就属XP了。
对外，XP以快速的反应速度来响应客户的需求；对内，XP以高质量的代码和设计来确保尽可能不产生不必要的文档和资源开销。
从表面上看，在当今，XP确实是一种非常理想的开发过程。
但是，从没有过程到XP往往会非常失败。这是为什么？问题的关键还在于人。
UP利用文档来约束和规范人们的开发活动。当一个没有经验的团队经历UP后，就等于把性格各异、习惯差别不同的人统一成了“相对较一致的开发人员”。
他们有一致的编码习惯，有共同的用语，有严格的规则。随着经验的积累，这个团队间的默契越来越高。此时，如果过程由UP向XP切换，付出的代价就会相对较低。
XP主张快速反应。如果一个没有经验的团队在一开始就尝试XP，那么后果可能是惨痛的。因为一个没有经验的团队其成员间的相互了解颇少，对于一件事，往往十个人有十种想法。当缺少文档约束时，在以代码和设计为中心的活动中，成员之间往往因为水平的参差不齐导致无休止的讨论甚至争论，代码被不必要地频繁改动。这是因为，在团队建设早期，成员之间往往连最基本的尊重和信任都不存在。 这种无意义的活动往往会严重影响项目的正常进行。
所以，学习和应用过程不仅仅是个体的事，而是整个团队的事。只有当团队采用严格文档化的过程并且经过磨合后，才能渐渐向轻量级的过程迁移，逐渐将不必要的文档删减掉，采用更灵活的过程。但是，此时并不是“没有文档”而是“心中有文档”。