缘起
“我们产品已经做完了，客户说要补上需求文档，可我们只有用户故事，这个文档应不应该写呢？”
“没有这个文档，客户能验收吗？”
“不能，客户要开课题评审会，这个是评审会材料之一。”
这个文档要不要写呢？写，为什么？不写，为什么？写怎么写？不写，怎么不写？
为什么敏捷不写文档？
先把话说绝点，敏捷就是不写文档。那为什么不写文档？
为了减少浪费。
敏捷认为所有中间产品，需求，计划，设计，测试用例……都缺少客户价值，客户最想要的价值，无疑是最后的可运行的软件。因此所有中间文档都应该省略省略再省略，直到不写。
不在对客户没有价值的东西上面浪费时间，这是敏捷不写文档的真实含义。
只是从实践上看，最浪费时间的无疑是那些无用的文档。但倘若文档是有用的，而且甚至是客户价值的重要部分，一切就变了。
怎样写这个需求文档？
就这个文档而言，它是为了验收所用，和开发没有关系（已经开发完了），和日后维护没有关系。
那怎么写？这个问题就不回答了，当然是按验收的写法写。
所以，所有文档的所有写法，在每个企业都不相同，不应该问“敏捷开发应该怎样写XX文档？”，而是应该问“应该怎样写上面那个文档？”，而若能这样发问，答案已经明确了。
“写不写文档”的常见做法
常见的文档虽然很多，但下面几个维度几乎永远存在，具体某个文档通过几个维度的分析，处理方法各不相同：
信息长期/短期有效的文档
长期有效比如竞争对手分析文档，架构设计文档，需求管理文档（用户故事），产品路线图……
长期文档适合详细描述，用语应完整（就是写Word那种写法），甚至可以动用图形和建模工具。
短期有效比如评审发现的问题，PO在计划会上讲解的内容等。
短期文档适合粗略描述，典型的就是用纸或Word凌乱地写一些关键内容，无需长期保存，月末一般就无用了。
不可/可被”可运行软件“替代的文档
上面举例的文档中，竞争对手、架构设计、用户故事、路线图都无法从代码中看出来，适合文档化。此外，一些科学计算的公式、复杂的设计也属于此列。
而界面设计、数据库表结构设计、流程图、伪码等，一旦软件做好了，更容易在可运行软件中看出，就不要着大量笔墨于此。
若感觉后者处于”没有就做不出软件，但做出软件又没用了“的尴尬境地时，应采用轻量级设计。
上一篇：浅析敏捷开发及其可用性
下一篇：敏捷过程成熟度的真正价值 |
[复制链接]
service@step365.com
0571-87357690
狗仔卡
发表于 2013-4-3 08:47:10
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡