聊聊什么是敏捷又不被技术嫌弃的需求文档.pdfVIP

聊聊什么是敏捷又不被技术嫌弃的需求文档 先问几个问题，大家觉得写文档是一件必要的事吗？你喜欢写文档吗？？你写的文档程序猿和测试 会看吗？？ 假如你自己能独立设计和开发一个产品，你甚至根本就不需要写文档。文档的存在很大程度是因为 团队协作需要进行信息传递。但负责传递信息的文档会存在几个问题， 而在一个变化万千的互联网行业里，大家应该知道有一种绝望叫做，当你还在写文档的时候，别人 已经在收集用户反馈了。 关于信息传递在知乎我找到一个图表，大概表达的是 沟通成效和沟通渠道的关系“ ”， 我们可以发现右上角面对面交流的效率是最高的，左下角用纸来交流效率最低。 当今的世界是敏捷开发的天下。传统开发过程中，人们通过交付文档来获得价值。但这样做的结果 仅仅是撰写了产品的附加件而已，对于产品本身的交付没有太大的帮助。在经典的敏捷软件开发宣 言中， 我们会发现很有名的一句话， 工作的软件高于详尽的文档， 你写再多的文档也不如用一个哪怕简陋却可运行的软件来阐述明白你 的问题。 当然文档也有它存在的必要，比如说它的 记录“ ”功能，若干个月后，项目换了负责人，他就可以通 过这份文档了解项目的来龙去脉，从而更好的传承设计思路。文档也有益于解决纷争，当传递过程 中信息流失太多，事后追究过错，看一看文档就能找到问题所在。 因此在互联网行业，无论是大企业还是创业公司，文档有其存在的必要，但这个文档应该是一份轻 量且高质量的文档。那么一份敏捷有效的文档应该遵循怎样的原则呢？？ 最最基本的有两条： 1. 敏捷性 2. 可读性 什么叫敏捷的文档，我的理解就是 精简易迭代“ ”。 所谓精简，就是指你的文档只讲重点，什么标题目录复杂的专业术语统统都先抛掉，只写当前任务 的核心要点。 有些需求文档会先讲行业和业务背景，还会有名词解释的类别，专门有一块来解释后 文难懂的专业术语， 而对于一份敏捷的文档来说，这些细节应该在 MRD 或者 BRD 里说明，不应该在 PRD 里废话。如果 程序猿需要了解业务背景知识，当面讲给他听。 所谓易迭代，就是这份文档要有一个易于迭代的形式。 一是编写人员不应该花费过多的时间去注意排版和规范，思考的重心在需求内容。 二是要有迭代记录的区域，需求变更频繁，变动的原因、时间、提出人、处理情况还是有必 要记录下来的。 当然大家可以将这部分统一进 PRD 的文章开头，也可以另外用专门的软件或文档来管理。 关于 敏捷性“ ”还有一个要点要提一提，就是编写文档的时机。我们要知道，不是先写文档，才做产品 。合理的顺序应该是先有产品，需要的时候才写文档，当然这一点比较难把握，实际操作中大家需 要综合考虑。 接着说可读性，我的理解也是两个要点： 1. 形式易读 2. 考虑阅读对象 关于形式易读，其实它会增加编写人员的写作成本，但还是有一些很基本的技巧和方法可以快速的 达到目标。最起码，我们要用上设计四原则的前两个，亲密性和对齐， 再用简单的色块区分开文档的不同要点，就能很大的提高阅读人员的理解速度，同时不会增加太多 的编写成本。 接着就到了本文浮夸标题的内容了 T.T ，也就是写一份考虑阅读对象尤其是程序猿的文档。写文档 的人其实最怕写完文档却没人看，所有的努力仿佛都被浪费了，而产品需求文档最主要的阅读人员 就是开发工程师和测试工程师。那究竟怎样的文档才是他们喜闻乐见的呢？？ 我的想法是写一份符合程序猿思维模式和工作方法的文档。 比如说测试最常见的工作方式是什么，就是撰写测试用例。测试用例如果简化一点，我们可以 用写 用户故事“ ”（user story ）的方法来写 用用户故事的方法来编写需求文档，可以让我们将注意力放在需求上，而不是解决方法和实施技 术上。过早的提及技术实施方案，会降低对需求的注意力。 这里我上网搜了一下资料，规划业务 需求，可以采用 “3W模板 ”，也就是： –谁（ Who ） –是什么（ What ） –为什么（ Why ） 上面的 3W 实际上就是描述了相关利益者是谁，他们想要什么，他们为什么有这种需求。下面举一 例子进行说明： –谁（ Who ）：用户 –是什么（ What ）： 希望借助一个应用程序在不同服务器