Main在他的一篇博客中写道：
重温下敏捷宣言：人和交互重于过程和工具可以工作的软件重于求全责备的文档！-----我们公司似乎走了完全不同的路！与客户合作重于合同谈判随时应对变化重于循规蹈矩！
关于文档正好有些话要说就回复了一个，自己也做个记录（超级自恋，哈哈）
其实大多数的公司可能都对文档要求比较强（这是好一点的，那些连文档都不要求的恐怕还不如这些公司）。我觉得文档这个东西不能少，我们经常说文档具有二义性，没人看等等。但是要知道一个公司里面不是都是程序员，还有产品经理，项目经理，配置管理人员，测试人员，维护团队，部门经理，solution经理，marketing，sales.....你能让他们去看代码还是UML图？文档是一个很好的折中，是大家共享的对问题的理解。不同的文档代表的是不同的角色对其他角色的承诺，当我们把文档作为一种承诺的时候，也许就不会觉得文档多余了。而且文档中的二义性也会降低。因为二义性只会让你吃亏。
在我们公司是这样的，A角色写文档与B角色review，这个文档是A对B的承诺。文档中任何的二义性，允许B向着自己有利的方面理解。当然这是一种理想情况，往往review的结果也是一个文档，在这个文档中描述B对A的文档的认可。中间会有反复和妥协，总得来说我觉得文档是很重要的。
举例来说，产品经理写需求文档，会跟项目组进行review，当文档定稿了接下来会有很多角色根据这个文档开展自己的工作。这就是产品经理对项目组的承诺：我承诺你们在给定的资源条件下完成的产品达到文档的要求，我就认可你们的工作。好了，下面研发team写自己的需求分析；测试组开始写自己的测试用例；技术文档组可能会写一些相关文档和用户手册等。需求分析又是一个文档，但是是反过来的，研发组对产品经理的承诺：我们承诺在给定的资源条件下实现如文档中描述的功能。这个时候谁的文档也不敢乱写了，当然也不会出现产品都出来了再补文档的情况。
我不知道main()指的是不是只有设计文档（相当于研发组对自己的承诺，这个意义要小一些）。胡乱侃两句，哈哈。