敏捷开发大家都不陌生，他对文档的态度是偏向于反对，但是也不是说一点文档都没有。他的说法是 代替文档。
那么敏捷开发为什么会这么认为呢？其实大家在做项目开发的时候都会有这样的体会：
- 时间紧任务重，哪有时间写文档呀？代码都写不过来。
- 辛辛苦苦把文档写好了，但是但是项目才进行一小半好不好，需求怎么就变了呀！需求变了，代码都改不过来，那还有时间去修改文档呀？于是乎一开始写好的文档就变成了一个个的坑。默默的坑着后来的人。
于是就有了这样的现象：
- 当接手一个遗留项目的时候最希望的就是有文档，但是没有文档——郁闷；
- 啥？！找到文档了，太好了……但是当看完了文档再去看代码的时候就会——更郁闷。
（各位前辈呀，为后来人着想着想呀！）
- 等自己完全接手项目，流程都弄明白了之后呢？忙改代码做新功能，至于文档？哪有时间去想文档呀。
于是乎文档就成了一个包袱一个累赘，有还不如没有。
为啥会这样呢？因为文档和代码没有直接关系，没有“联动”关系！
那么啥是联动关系呢？我们举个例子，PowerDeszner做数据库设置的时候，我们不仅可以用这个工具做数据库文档，而且设计好了之后，还可以直接创建数据库。当文档有变化的时候，也可以自动修改数据库。还可以反向工程，就是指定一个数据库，然后根据数据库里的表和自动，自动生成文档。这就是联动。
如果您对powerdes不熟悉的话，我在举一个CodeFirst的例子。CodeFirst就是先写代码设计类，然后用vs里面的来自动创建数据库，类结构发生变化了，可以自动的去修改数据库的表结构。这样就可以达到代码和数据库的一致性，而且有变化只需要修改一个地方（代码）就可以了，另一个地方可以自动变更。
这就是我所说的“联动”。如果所有的文档都可以和代码进行这样的联动，需求有变化了，先去修改文档，然后代码会自动随之变更，那么文档就不会成为负担了！
这就是我所说的“文档式驱动”！
当然在实际中，并不是所有的功能都是先文档在代码。而是根据具体的情况来灵活控制的。
这里在举一个WebAPI的例子。我们打开VS201*，新建一个webapi的默认项目，我们会发现有一个help的目录。进去一看，哇，api的使用文档！有接口名称、参数名称和他们的注解，还有调用实例。这还不是最神奇的，更神奇的是，当代码修改了之后，help里面的内容也会随之更新。这样写接口再也不用担心更新文档的问题了。
这是有代码“生成”文档。这个仅仅是对程序员来说的，写代码用的文档。除此之外还有给客户看的文档，等等。如果这些都可以“联动”起来，做到有需求的时候，只需要改动一个地方，其他的地方都会随之更新。这是不是很爽！
可能有人说，我这是痴人说梦，该醒醒了，别浪费大家宝贵的时间。这个当然不是无稽之谈，今天也不是愚人节。下面还是用例子说话。
公司以前用asp.net mvc做项目。后来发现开发速度跟不上，于是找了一个国外的无后端的东东 ，叫做backendless。他的思路就是，凡是服务器做的事情（UI除外），都可以不用写代码了，都由他来包办。Backendless提供了一个平台，在这个平台上面配置各种服务，配置完了前台就可以直接调用。这个前台包括：web、手机web、安卓、苹果、flash（Flex）、等，并且可以生成对应的调用代码。我们写点前台代码就OK了。
每一个环节都有人在做“联动”的事情。只是从整个项目的角度来看，把各个环节用一条线，从始至终的串联起来，让各个环节可以“联动”。目前还没有发现做这种事情的人（自己除外）。
这么做的难度很大，推广也很难。其实大多数的情况都是只做一块，比如选择日期的my97，分页的Aspnetpager，在线编辑器，各种ORM，各种UI，单点登录，用户中心等。他们都只做一块，其他的不管。这样才能够让大家灵活的选择和使用。
再举一个盖大楼的例子。要盖楼首先要一个图纸，然后请建筑公司来按照图纸把大楼盖出来。盖楼之前图纸可以修改，盖楼的时候会按照最后修改后的图纸来施工。但是楼盖好了，再去改动图纸，大楼就不会受到影响了。大楼改好之后，图纸和楼失去了联动，图纸不会去影响大楼了，因为楼已经盖好了。
再来看看导航软件，我们输入出发地和目的地，然后导航就会规划一条路线出来，我们按照这个路线开车，开着开着发现前方路口堵车，怎么办？重新规划路线绕过堵车点。然后我们按照重新规划好的路线继续行驶。路线实时指导我们的行车方向，路线变了，我们的车就跟着变。这样就是实时联动。
说了这么多，大家可能都蒙登了，我到底要说啥？还是来张图吧。
总之呢，就是不能让文档孤单单的存在，要让文档和代码和页面互动起来。需求有变化了，首先想到的是改文档，然后对应的地方会随之自动更新，不需要修改代码！
最后说一下啥是“超敏捷”，前面说了敏捷开发，那么超敏捷开发呢，顾名思义说的就是开发速度会更快。
