我对文档的要求：必要的、最小的冗余

这个东西不错啊。

非常同意！
而且你们的这个框架也很牛逼！

1.文档工作量尽量地少。
  数据库设计文档都不要了？
2.“需求背景”“略”字带过
  来新人维护怎么办？
3.改了代码后自己迅速修改文档
  有几个人愿意后补文档？
4.完全可以在开发完成后再补充文档。你完全可以在快速编码的过程中通过调试实现最优设计，这种设计往往比预先的设计要少很多漏洞。
  都没想好编什么码？
5.其版本通过版本工具来维护
  同意

文档的多与少，应该写到什么程度，和项目的性质紧密相关，另外和项目的重要性也有关系。

如果是公司自己的项目，视项目的重要性可相应地调整文档内容和厚度。
一般文档只要能描述清楚需求，写好详细设计,便于日后系统的升级和优化就可以了。

但如果是系统集成项目，文档没有厚度，中标可能性会大大降低。

做系统集成的公司大多有个可笑的场景，同事见面了寒暄几句都在做什么项目，接下来第一句就是，文档写了多少页啊，没个500页以上说的人都不好意思，因为在这个行业里，好像一般8，900页才刚及格，一个项目1000几百页文档很常见，但真正能起到指导实施的内容，也许只有几十页有点意思，大多是实施的时候前期的设计文档都被废弃了。

是可笑还是悲哀，但这就是现实。

敏捷开发模式不需要文档。
几个人聚在一起就研究需求，在白板上画出uml草图，继续研究，再修改，在画，打印下来或者数码相机拍照留档。
尤其强调，uml图是为了交换意见而用，不作为文档内容。