敏捷开发之写不写文档

青衫不改

缘起

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

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

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

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

为什么敏捷不写文档？

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

为了减少浪费。

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

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

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

怎样写这个需求文档？

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

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

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

“写不写文档”的常见做法

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

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

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

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

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

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

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

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

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

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




上一篇：浅析敏捷开发及其可用性
下一篇：敏捷过程成熟度的真正价值

lanj

个人觉得敏捷写不写文档已经成为一个做不做敏捷必考虑的一个问题了。现在看到很多公司都在试行所谓的”敏捷“，且不论形式或者结果怎么样，但是绝大部分是没有文档输出的，没有文档成了敏捷的标志。个人觉得文档这回事有几种情况下还是需要的，一个就是对于一些例如政府部门的客户，在签订的合同里面可能已经规定了验收的时候必须提供哪些文档，这个时候，我觉得还是需要提供的，因为合同里面已经有规定了，你不能说自己是敏捷开发就不提供文档，毕竟客户不管你是CMMI还是敏捷的。还有个就是对于开发的人来说当然敏捷使他们更高兴了，觉得自己都在做自己关注的事情，没有花费时间写文档之类的，但是对于维护人员呢？这个维护人员不仅仅是客户方的，还是公司内部的，我们知道每个项目都有一定的保质期，1年到5年不等，如果没有文档，只是一个backlog和一套源码给维护人员，就足够了吗？肯定是有一定问题的吧。所以个人认为有些必要的文档或者记录还是需要的，这和是不是执行敏捷不是一回事，也不是执行敏捷的理由。

xinkeji

lanj 发表于 2013-4-8 15:42
个人觉得敏捷写不写文档已经成为一个做不做敏捷必考虑的一个问题了。现在看到很多公司都在试行所谓的”敏捷 ...

楼上说的很有理，这个行业目前就是这样的。。

maissepar

看起来好像不错的样子

舜风

有空一起交流一下。

车前草

很有借鉴意义，先收藏了，谢谢楼主。

い╃→苍凉ゝ

以我的经验来看，楼主的想法是可以执行的~

谜一般的女子~

其实，很多情况下都是这样的，习惯就好。

九箭

以我的经验来看，楼主的想法是可以执行的~

天气真好

这么强,支持楼主，佩服

用心生活i

很有借鉴意义，先收藏了，谢谢楼主。

我亦无泪纵横i

众里寻他千百度，蓦然回首在这里！

狮子座向日葵

好帖是需要鼓励的~

醉影笑惊鸿

确实不错，顶先

丁香姑娘@

非常好，顶一下占位编辑