前言
Preface
敏捷宣言里面有一句话，叫“可工作的软件 高于 详尽的文档”，这句话高屋建瓴，指明了敏捷项目对文档的看法，但并没有给出具体的，可操作的指导。于是我们常常听到人们讨论这样两个问题：
 


 
敏捷项目文档要不要写？
敏捷项目文档怎么写？
 
网上能找到的资料，往往局限在文档的某个领域，例如用户故事。或者是一些指导性的原则，比如寻求平衡，涌现式等等，原则都对，但是到具体的操作上，又似乎没有意义，有点像“正确的废话”。
 
由于IT项目复杂多变，这两个问题的答案也并不简单，我在构思了很长时间后，打算用一个系列的文章，来解构敏捷文档的设计原理，并与普通项目文档进行对照，同时分享错误的书写案例及敏捷教练的建议。希望能从务实的角度对这两个问题进行解答。在解释要不要写，怎么写的同时还会兼顾一下 “为什么这样写？”
 
这个系列的文章将包括：
 
普通项目文档和敏捷项目文档的逻辑和结构差异。（为什么，怎么写）
只花三分之一的精力，就能维护更有效的项目文档。（怎么写，哪些不要写）
需求变了，文档竟然无需做太大改变？（怎么写，哪些不要写）
 
正确维护敏捷文档，让优秀的业务（需求）分析人员失业。（怎么写）
不写文档？找到比文档更有效的替代品。（要不要写）
 
今天是这个系列文章的首篇--
 
普通项目文档和敏捷项目文档的逻辑和结构差异
一
个IT项目文档，主要包括 需求描述 和 技术实现 两部分。我们都知道敏捷项目中，需求是采用“用户故事”的格式来描述的。


 
 
用户故事如果写的好，不但能节省至少50%的项目资源，还能帮客户扩大至少50%的收益，而且能够训练工程师的思维，从以交付为中心，向以客户为中心作出实质性的转变。
 
但是很多人实际使用过用户故事之后，感觉只是换了一个格式描述需求而已，并没有体验到上面所说的好处。这因为用户故事虽然看起来简单，但是大道至简,衍化至繁，想写对，写好，并不是一件容易的事。这一章里面，我打算先说说下面两个方面：
 
以用户故事为中心的敏捷文档和普通项目文档有何本质区别？
 
敏捷项目不但记录需求，还能引发颠覆性创新，普通项目文档为何做不到？
 
从书写的逻辑上来讲，普通项目文档的书写逻辑是描述“为什么”，“做什么”和“怎么做”。
举个例子：
项目伊始，需求分析人员通过访谈和调研，了解客户希望解决的痛点，或是希望获取的价值，这里我们统称为“Why”---即客户为什么要启动这个项目。
 
假如我们的客户是一位传统行业制造商， 经过调研我们得到了“Why”：
 
“已有的分销商推广的模式无法在新产品发布后立刻通知所有潜在买家，影响销售量的提升”。
 
基于“Why”，我们跟客户探讨一些选项，最后客户选择了一个听上去合理，并且成本可接受的方案，即：
 
“建立一个网站，定期发布新产品，吸引对产品感兴趣的人，并且通过开放注册，留下这些访客的信息以便将来主动的及时的推送新产品信息。”
 
到这里，客户的“Why”就转变成了具体的需求“What”。
 
接下来，需求分析人员会顺着“网站需要哪些功能”这个逻辑进行思考，进而衍生出类似于
 
“用户注册需要填写哪些信息“
“网站展示的产品信息包含哪些部分”
“网站如何进行产品分类“
“网站后台如何推送产品信息”
 
等等详细的需求分解。然后交由设计人员，设计出具的页面，表单， 用户的交互过程等等，此时形成了解决方案文档（Solution Document）。得到客户确认后，交给交付团队，交付团队在技术实施的过程中，补充相应的架构设计，编码规范，参数配置，测试 等等文档。
 
普通项目的文档，和普通项目本身一样，基本上是根据下面这个流程来进行逐步构建的。

 
这个过程，就是一个从 Why 到 What 到 How 的过程。 这个过程中的步骤是有先后顺序的，我们假设只要把每一个环节都做正确，那么最终得到的结果也是正确的。
 

 
敏捷敏捷项目文档的书写也是从“Why”开始，但与普通项目不同之处在于：
 
普通项目在需求分解的过程中，也会回头参考Why，但是需求文档本身是不包含Why的部分，基本上只包含What -- 提供什么样的功能。
 
敏捷项目需求分解时，由于采用了用户故事的格式，What和Why总是成对出现的。
 
我们还是用前面的例子来解释一下。
 
通过调研得出的最原始的 “Why” -- “已有的分销商推广的模式无法在新产品发布后立刻通知所有潜在买家，影响销售量的提升”。
 
在敏捷项目中，接下来我们会构建一些这样的用户故事（Epic和Feature不再此文范围）：
 
“作为制造商，我需要一个带有注册功能的网站来吸引用户注册，这样我可以获得潜在买家的信息，从而为未来新产品的推广积累用户数据。”
 
“作为制造商，我需要我的网站上具有推送功能，每当新产品上线的时候立刻推送给注册用户，从而提升销售量。”
 
每一个小的用户故事都包含了Who，What 和Why三部分。所以，在敏捷项目中，需求，和需求背后的原因，总是成对出现。
 
而且在普通项目中，设计和交付环节的文档，只能基于需求文档进行讨论，最初的Why，只有少数几个人知道，远不如What和Why成对出现这样的方式容易追溯。随着项目复杂度的升高，以及项目进程的展开，人们更加容易落入细节工作的黑洞，忘记出发点。
 
另外，脱离了Why，设计交付团队很容易聚焦在 “什么是好” 的用户注册方式，而不是 “什么是给当前客户带来最大价值的” 用户注册方式。于是产生了IT项目中一个非常常见的情况--团队认为好的设计方案，客户并不买账。
 
用户故事这种Why和What始终结对出现的设计方式，在需求分析阶段，能帮助我们即使在讨论很细节的地方，也仍能检视是否符合客户的价值诉求。
 
清晰稳定的用户需求
VS
涌现式用户需求
 
另一个现实问题是， 现在的软件行业，供给端极其丰富，能满足Why的What，远不止一种。项目团队常常遇到的一个困扰就是客户的需求总是在变化---今天想要搭建网站，方案都做出来了，又觉得手机App好。但如果你仔细观察，客户要解决的根本问题，其实基本是稳定的。

 
如上图所示，用户故事在分解的过程中，如果我们把Why的部分用蓝色标出来，我们可以看到他们变化的可能性不大，相反灰色的What部分，就有可能有很多种实现方式。
 
普通项目中，我们希望What，也就是需求，是尽可能的清晰，稳定，一旦制定后改动较少。因为前面提到的普通项目的文档流程中，后面的步骤依赖于前面步骤的正确性。于是普通项目中，我们常常希望需求分析人员能力足够强，客户脑子足够清晰，知道自己想要什么并且坚定不移，然而这样的人都是可遇不可求的。
 
敏捷项目中，需求分散在每个User Story的What部分里，但它并不是越细，越清晰，越确定，就越好。相反，它是一个简短的描述，并不包含太多的细节，参考3C原则。
 

用户故事中的“What”只是一个简短的说明，并非像普通项目的需求描述那样越细越好。细节则是通过“对话”（Conversation）来浮现出来，并落实到纸面上（Acceptance Criteria）。
 
有项目经验的人们一定知道，如果设计团队和研发团队拥有足够的原始背景信息，商业上下文信息，他们往往能够发现一些不合理的需求和设计，并有可能给出更出色的方案。Coversation环节就提供了一个这样的场域。
 
以上面的需求为例，如果每个人都知道了用户注册功能是“为未来新产品的推广积累用户数据”，那么在在“Conversation”中产生这样的思考：
 
-- 什么样的用户注册信息对产品推广最有价值？除了联系方式之外，还可以收集哪些有价值的信息？（是否应该关联社交媒体账号？）。
 
【让好的设计浮现出来】
 
--既然是收集用户数据为了将来推广用，那么肯定是收集的越多越好，哪些功能可以降低用户的注册成本，增加注册意愿？
【对原有需求进行好的补充】
 
--通过用户主动注册来收集用户信息，已被验证是一个低效的方式，这或许不是个好的What，结合互联网思维和行业潜在用户的特征，xxx方式能更好的引流来用户数据。
【颠覆原有需求】
 
符合客户利益的需求，以及好的设计，在这样的细节的讨论过程中就诞生了(涌现式)。

 
普通项目这种情况发生的机会比较少。在需求分解阶段可能引入个别有经验的技术人员参与讨论和制定，但无法像用户故事一样，每个用户故事都可以引入设计人员，开发人员和测试人员参与讨论，最大限度的群策群力，发挥群体的智慧。
 
敏捷宣言中，有一句话叫做“个体和互动高于流程和工具”，用户故事的3C原则就是宣言的一个实践。
 
说了这么多，最后总结一下，敏捷项目的需求文档和普通项目的需求文档的区别主要体现在两方面：
 
1: 普通项目的文档撰写采用由 Why 到 What 到 How 的流程。并假设只要把每一个环节都做正确，那么最终得到的结果也是正确的。
 
敏捷的文档撰写，Why和What始终结对出现。Why是贯穿始终的参考线。
 
2: 普通项目在需求分析时要做到细节清晰，明确，确定。交付团队的主要职责是将需求转化为技术实现。
 
敏捷项目的需求描述分散在用户故事中，是一个框架性的描述，需求的细节遵守3C原则，在讨论中涌现。交付团队参与需求细节的共创。
 
作者：佚名