敏捷开发智慧一：写不写文档？

缘起
“我们产品已经做完了，客户说要补上需求文档，可我们只有用户故事，这个文档应不应该写呢？”

“没有这个文档，客户能验收吗？”

“不能，客户要开课题评审会，这个是评审会材料之一。”

这个文档要不要写呢？写，为什么？不写，为什么？写怎么写？不写，怎么不写？

为什么敏捷不写文档？
先把话说绝点，敏捷就是不写文档。那为什么不写文档？

为了减少浪费。

敏捷认为所有中间产品，需求，计划，设计，测试用例……都缺少客户价值，客户最想要的价值，无疑是最后的可运行的软件。因此所有中间文档都应该省略省略再省略，直到不写。

不在对客户没有价值的东西上面浪费时间，这是敏捷不写文档的真实含义。

只是从实践上看，最浪费时间的无疑是那些无用的文档。但倘若文档是有用的，而且甚至是客户价值的重要部分，一切就变了。

怎样写这个需求文档？
就这个文档而言，它是为了验收所用，和开发没有关系（已经开发完了），和日后维护没有关系。

那怎么写？这个问题就不回答了，当然是按验收的写法写。

所以，所有文档的所有写法，在每个企业都不相同，不应该问“敏捷开发应该怎样写XX文档？”，而是应该问“应该怎样写上面那个文档？”，而若能这样发问，答案已经明确了。

“写不写文档”的常见做法
常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：

信息长期/短期有效的文档

    长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图……

    长期文档适合详细描述，用语应完整（就是写Word那种写法），甚至可以动用图形和建模工具。

    短期有效比如评审发现的问题，PO在计划会上讲解的内容等。

    短期文档适合粗略描述，典型的就是用纸或Word凌乱地写一些关键内容，无需长期保存，月末一般就无用了。

不可/可被”可运行软件“替代的文档

    上面举例的文档中，竞争对手、架构设计、用户故事、路线图都无法从代码中看出来，适合文档化。此外，一些科学计算的公式、复杂的设计也属于此列。

    而界面设计、数据库表结构设计、流程图、伪码等，一旦软件做好了，更容易在可运行软件中看出，就不要着大量笔墨于此。

    若感觉后者处于”没有就做不出软件，但做出软件又没用了“的尴尬境地时，应采用轻量级设计。