敏捷了还要文档吗？

　　连一个良好的设计都没有就写代码，这样的产品没有问题倒也是奇迹了。
　　流程设计，现在有了工作流相对要更简单一点。详细的功能设计。数据库设计。这三大设计，就算工期再紧，个人认为也不能太马虎，不然对后期会产生极大的不良影响。
　　而且本人不反对“造假”。就是用最短的时间，最方便的方法（有时甚不用数据库），或者仅用尚未完善的数据库。把大致的软件演示给客户看，让他们看得见摸得着，再看现在的做法是否满足，等基本定下了，那么再定一下交货期，在此之前，除非特殊情况，则不再做相应更改。这样工期反而可以缩短。
　　现在往往会看到一个基本不太懂软件工程和项目管理的领导，来一句：啊。。。这个项目客户说了，一个月必需交出来啊。然后下面同样不懂的，也不知道用基本迭代（“造假”其实也是迭代的一种）。而且尽可能完善得去做程序。这下完了，一个月不可能完成先不说，N个月都完不成也有可能。而这些还仅仅是项管的一些皮毛，稍微看一点点书都应该知道。

这都是被逼的。刚毕业的新人总是问：我先把东西写完再写设计文档可以吗？

文档仅为沟通所用，尤其是当the world is flat以后。

没文档 != 没良好的设计
有文档 != 有良好的设计

文档是产品或者项目一部分，要向客户交付的。跟敏捷没有任何关系。是不是敏捷都要写。
  所以要讨论的如何写出有用的文档。何为有用的文档，一句话两句话就说不清楚咯。

那什么样的文档才是好的呢？为什么在软件工程中要用到文档，为什么要那么多的文档在开发的不同阶段（对不起，忘了说这是指‘瀑布模型’中）。可见，文档还是必须的，其实我想说的或者期望大家讨论的是我到底需要什么样的文档，敏捷中又需要什么样的文档？！

為什麼要大家去討論你所需要的文檔呢?

所需要的文檔, 其實都要視乎項目情況, 團隊能力而決定.

例如我公司團隊所有文檔都是用英文寫的, 這不代表也可以應用在你的團隊上.

開發需要的文檔, 還是最好由開發隊伍去討論.

不喜欢设计文档，本人思维方式不适合做设计，更喜欢一步一步一实现功能，功能实现后再写设计文档（如果还能叫设计文档的话），对我而言文档更主要的功能是便于系统维护，当然代码也少不了要写尽量多的注释。

写文档有利于理清思路，如果是一个新的项目的话。前期的分析文档还是需要的吧。否则写story的时候，感觉无从入手。

换种说法，写文档前可以先写一个demo,也算是另一种心中有数吧。