也曾尝试过，不带文档的“裸体”前进，可想而知，最后经常造成项目的返工，新来的人员要拼命读以前的人留下的几乎没有注释的源码。
后来尝试过，制订完善的规范，用了大量的软件开发文档模板，可惜仍然无法减轻开发者的负担，另一方面令人尴尬的是，情况并没有比不带文档好多少，因为在项目的实施中，很少有文档与软件能够完全同步的。一份简单的需求文档从项目开始到项目结束，往往会改动得面目全非，在此同时，要花费专门的软件开发人员去整理文档，不得不说是一种资源浪费。
与其做着虚假的文档，穿着皇帝的新衣，不如就干脆裸体，这是我的想法，但一直没这个胆子去实施。
不知是谁说过：软件=程序+文档，我持一半的赞同一半的不赞同，软件最终就是要给用户用的东西，用户只要用了满意，就是一个好软件，不满意就不是好软件。对于用户来说，他需要付出的是软件的费用，另一部分软件开发过程中的文档等，是公司为了产品以后的升级、维护、扩展而准备，用户没有义务为此付费。
一直以来，我们都采用Case工具，采用UML图进行交流，有时候尽是这些工具很难满足我们的需要，我们也会想尽一切办法去表达自己的意思。使用了这些工具后，我的感觉是，大家都已经由原来的正常人变成了哑巴。有时候，明明一句话可以解决问题的，却要比上半天的手势。
新技术与新工具的采用，带来的应该是人与人之间更通畅的信息交流，如果效果正好相反，那么我们不得不考虑一下，为什么会这样。
直到接触敏捷开发，才觉得开朗了一些，软件开发尽管没有银弹，但在不同的形势下，总有合适的方法来让开发人员爬出焦油坑外。
在<<敏捷建模、极限编程和统一过程的有效实践>>这一本书上，开头作者就指出了，他们在快速交流中，并不使用Case工具，他们使用的不过是几张纸片，而且抓了支笔就开始画草图，甚至，在书中的后半部分，在设计用户界面时，也居然是用草图画出来的。
也许我看起来很可笑，但是说实话，我真的没有这样去做。向来我都认为，严格地管理，严格地遵循规范才能够出高质量的产品，现在看来，好像是我误解了些什么东西。软件设计的目标是成功开发出一个成品，让用户可以使用它。
在做项目的过程中，我们往往过份关注了软件的扩展性与易用性，以致于过度的分析需求，不但提供了一些用户用不着的功能，也让用户投入了不需要花费的资金，同时，我们还浪费了大量的时间。
在XP实践中，有许多实践是令人兴奋的，不说其它的，虽然XP中不反对文档，但根据它的思想，给了开发人员一个尽量少写或不写文档的借口。 我一直没有机会去实践结对编程，但直觉上认为它是一个好东西，虽然并不相信，可以提高百分之几十的效率，但软件的开发毕竟是一个脑力活动，做个小功能，转换一下思路，是一个好办法。
但结对编程中，有一个让我迷惑不已的地方：一般而言，人要进行做某事，要进入状态，大约要15分钟左右的启动时间，然后，无论是任何打扰（包括电话，有人问话），都会造成思路的中断，从而使得人要重新调整状态，这又有几分钟的时间耗费。我不认为这样会使得人更专注（有人在旁边监视也一样）。
因为没有结对编程的经验，所以也不过妄言几句。
文章来源于领测软件测试网 https://www.ltesting.net/
