敏捷公开课：Scrum项目中要写什么文档？产品Backlog、原型、规则...

企业架构  |  业务分析   |   敏捷研发  |  自我成长

---

敏捷宣言中有一条：可以工作的软件 胜过 面面俱到的文档，于是很多团队成员开始“勇敢”的站出来说“我们不需要写文档了”。这是在偷懒，还是真的可以不要任何文档？本文就Scrum项目中的文档主题与大家进行深入交流。

如果你关心Sprint回顾会议这个话题，可以听熊小龙老师讲的敏捷公开课【Scrum项目中的文档】

我的观点

我成立IT帮，主要是想帮助更多人成为复合型人才的学习者，成为一个有思想、有目标、有行动的完整个体。我会开展一系列的学习和分享，这次敏捷课堂就是其中一期书虫会内容。作为分享者或老师，我希望能带给大家不一样的内容：

• 它不一定面面俱到，但应该视角独特

• 它未必百分之百正确，但或许能给你启迪

• 它也许给不出答案，但能拓展你的思考空间

如果你希望知道Scrum项目中文档的更多内容，那么请继续往下看。

在采用Scrum方法之前，团队有两种模式：

• 一种是正规瀑布式的，前期有详尽的各类文档，例如厚厚的需求规格说明书，以及各种模型的设计文档。当有变更发生时，还有非常正式的变更管理流程来帮你决定如何处理这个变更。这类文档看似会让人觉得对内容、进度有把控感，特别是对项目经理来说，这些文档会让自己有种安全感。然而，事实上，就算前期投入再多时间和精力，需求变化是肯定会发生的。

• 另一种就是野战队，没有可遵循的重复开发方法，一拨人来了一个项目聚在一起，来了需求就做，主要靠个人能力。这类团队做些小项目还行，项目稍微大一点就会出现各种管理问题和技术问题。

这两类模式都面临一个问题，文档该怎么写？而到了Scrum，竟然又多了一个问题，“文档要不要写？”对于这个问题，我先肯定的回答：“在Scrum中肯定是需要写文档的。”

接着我来说说“写什么样的文档”，以及“什么时候写”这两个更为重要的问题。

写什么样的文档

1.原型

        开发一个产品，必须先能描述它，否则就无法构建它，所以产品必须通过文档来描述，而这个文档我认为最好的就是原型，更多内容参考我内训的一张讲义：

我补充一下原型的意义和误区，希望让大家对原型有个正确的认知：

• 原型意义

• 功能需求依赖与用户需求，是用户需求在系统上的一个映射，通过原型可以更真实的体现开发者的思考，帮助开发者的思考

• 传统的产品说明文档起不到应有的作用（不完整、含糊不清、特别是未经测试），所以高保真产品原型可以大大缩短产品上市时间

• 有利于将复杂的问题简单化，提升用户对软件的认知，降低对软件的期望。

• 原型的误区

• 替代开发文档：原型是文档的一部分，但是它不是全部，它不能表现规则、算法等隐含的逻辑

• 过于精细化：原型不是产品最终实现，过去精细化会导致维护成本的提升，同时又不能给产品质量提升带来太高的价值

2. 产品Backlog

        在原型的误区中我说到原型只是文档的一部分，那文档还有什么呢？

        在Scrum的3355框架中有一个重要的工件，就是产品Backlog，这是作为Scrum实施必备的一个文档，它实际上就是产品的需求文档，只是它与传统的需求文档的差别在于产品Backlog是分层次的，这个符合DEEP规则，以前文中也说过，更多内容大家可以自己上网搜索了解一下，我就不再重复说了

3. 规则文档

        对于一个产品来说，规则和算法是原型和Backlog无法体现出来而又非常重要的部分，所以在我所带的每个团队，我都会要求他们除了原型和产品Backlog之外，还要写的一个文档就是规则文档。

        

规则可以单独一个文档，如果规则不是特别复杂，写在Backlog文档中也是可以的，例如我带过的一个团队是这么写的