传统方法的缺点--难以维持设计/文档/程序的一致性。这么久以来都没能解决这个问题（相信很多人有这个感受）。所以不得不怀疑传统开发方法的适用性。看看国标的文档模板，真TMD恶心，在实际应用过程中效果如何？我是没有遇到用的很好的。
所以现在想换一种开发方法，使用XP方法尝试一下。
但我对xp方法了解甚少，现有一问题请教:(问题较弱，莫笑话我)
xp过程，会有哪些文档，其中哪些是过程性文档，哪些是最终留下来的文档？在做的过程中不断涌现出来的一些想法，算法，结构，需要记录成文档吗？如果是，记录到最终留下来的文档中吗？
__________________
多多交流--zhaochaohua@sina.com
我的认识，不一定对
1.对敏捷方法/重量级方法之间的差异认识：
差别在于中间文档（包括项目经理所需要的进度文档，以及软件本身所需要 的设计文档等）多少。中间环节减少导致团队高效。
2.敏捷方法需要什么文档？
--架构设计文档
没有了
XP开发方法比传统的开发方法问题更多，不要以为XP就是银弹。你可以去我那里问问dlee，他以前做过将近一年的XP方法下项目开发，可谓一肚子苦水，呵呵，XP对人的要求太高了，XP会累死人的。
好呀，我当向dlee请教些经验。
我为什么这么抓狂地要尝试新方法，是因为中间环节太多了，同步工作量太大，疲惫不堪。而我们现在就几个人，沟通起来比较容易，所以想使用XP。我估计也不会失败到哪里去。
请问一下robbin,到底为什么用xp会累死?
xp减少了所写的文档,又使用pair programming,为什么反而会更累?
愿闻其详.
我正在看一些敏捷建模，但没有足够的实践，仅作参考。
XP，FDD等都是敏捷联盟的成员，都是非常好的方法。
楼主所述的文档－代码同步问题，确实是体现敏捷优点的地方。
1. 敏捷的一个核心原则就是“轻装前进”！
只保留有价值的制品，抛弃临时制品。
2. 在有危害时才更新模型
我对XP也不是很懂，你可以向dlee请教。
XP强调尽量多的创建，要求至少日创建1次，甚至一日创建n次，试问一个软件项目，你每天都要把项目反复创建n次，你受的了吗？当然反复迭代创建次数越频繁，集成测试越频繁，软件的潜在问题就越容易得到及时的解决，但是太过频繁的迭代次数会破坏正常的开发进度，和拖累程序员的身心。
XP要求文档在代码中，没有单独的文档，一个大型项目，试问如果你对代码不是很熟悉，你会不会抓狂？
结对编程更加不切实际，如果两个人默契程度不够，你就等着互相埋怨吧。
所以XP适合那种小型的，规模不大的，开发人员水平非常高的项目，例如现在网络上非常多的开源软件的开发，就适合用XP。