刚接触敏捷开发时候很是不适应，单单就没有文档这一项就感觉很别扭。什么都需要去问旁边的同事。开发团队的人也说这是敏捷开发没有文档。我也就信以为然了。现在重新审视一下文档这个东西不觉发现其实敏捷开发的出现是有其道理的。
软件开发虽说是开发，但是从整个软件的生命周期来看大部分的时间都是在维护，以前一直把软件开发当作修建建筑，现在想想这么比喻是有缺陷的。建筑一般盖好之后轻易不改变，要改变就是推倒重来。但是软件不是这样的，一旦产品上线这个产品会经历用户的检验然后产品升级通过一遍又一遍的迭代，逐渐的这个软件变得越来越好，就像windows系统似的。与其说软件开发是一个制作过程还不如说软件开发是一个从普通逐步逼近完美的修补过程。
再来看文档，早在软件工程的学习中就知道文档是为了方便开发人员沟通，提高开发的效率而存在的。但是实际情况真的是这样么？因为软件开发不是一次性的工作，是需要不断迭代不断完善的，所以到最后很有可能文档比代码还难以维护。试想一下把a=1修改为a=2本来一秒钟都用不到的事情，如果加入文档维护那么就是一个需要至少半天的工作量。
于是敏捷开发出现了，提倡没有文档或者提倡代码就是文档；提倡没有注释或者说代码就是注释。注释和文档一个道理从a=1到a=2代码改动已经很明显了。如果加上注释那么读注释的人就要知道这段代码为什么该在什么时候改的等等信息，但是这些信息也许不是读代码的人需要的。无用的信息占用了宝贵的时间造成了资源浪费。
敏捷开发没有注释没有文档那么靠什么管理？答案是靠工具，各种工具，各种人性化的工具。
版本控制工具:按照上面的例子把a=1改为a=2，如果用之前的SVN很难保证代码的可读性，本来改动一个数字可能在这段代码周围就会有杂七杂八的注释，上次的，上上次的，上上上次的……。如果使用git之类的版本控制软件，情况就会好很多。众所周知Git每次提交都需要写详细的提交注释，这就相当于我们之前修改代码要写的注释，与之前注释不一样的是这里的注释是对这次修改动作的一个整个描述，而且这个注释只有你在调用的时候他才会显示，不会平白无故的占用读代码人的时间。
Bug管理工具:无论什么事，归根结底人才是主体，软件开发更是这样。敏捷开发需要一个融洽的团队，需要一个和谐的氛围，否则开发就是踢皮球，利用Jira之类的“缺陷跟踪管理系统”每个人每个迭代干了多少工作量一目了然，想偷懒都不好意思。由于每个迭代通过之后都会有奖励，如果因为个人而影响到整个团队那个人脸上也挂不住，所以人的积极性也调动了起来。每个人每天早上来了之后会去此次迭代中寻找自己熟悉的bug，就相当于大家一致面对一个巨大的敌人然后各自利用自己擅长的部分去对付这个敌人。正应了那句话“好的团队会让每个人力量发挥到极致”。最后的结果就是大家抢着修Bug，恐怕给整个团队拖后腿。
以上两个工具仅仅是冰山一角，工具是无限的但是思想是不变的，以人为本不教条主义正是传统开发过程中最缺少的东西。纵观敏捷开发的过程，不是没有文档而是把文档交给了自动化工具完成，把人从文档中解放出来，将更多的精力投入到系统开发当中。自动化工具或者说开发管理工具的使用大大的节省了团队的时间，提高了效率。这些工具以及这些工具产生的数据严格的说不能算是文档，但是他们比文档更加高效，更加具有时效性。
敏捷开发也有其自身的“缺点”，比如新手上手比较慢，如果文档齐全（注意这是一个虚拟语气）的话新人可以更快的融入团队，但是从国内大部分开发团队的情况来看，一般遵循瀑布模型的软件开发所产生的开发文档要么和代码不对应，要么就是没有文档。所以照这样来看在没有文档的情况下，通过Jira等Bug管理系统学习已有的代码反而是促进新人更深入研究代码的一个主要动力。也许这个过程中虽然费了一些时间，但是得到的却是异常丰富的代码经验。经过前期新人对代码的熟悉，公司对新人的水平就会有一个大致的了解，这同时也是保证了新员工水平的一种方式。一个连别人代码都看不懂的人还搞什么开发！机器能看懂你就应该能看懂，不是别人写代码的水平差，是自己的水平不够而已。（最后一句是吐槽，请酌情忽略）