在很多年以前，有一种测试类型叫文档测试（暴露年龄了，不知道有多少读者记得这项测试活动），主要测试的对象就是需求文档。在版本初期，测试人员需要阅读一份很长的需求文档，这份文档会包含这个版本的所有功能点、交互方式及页面字段信息。研发团队通过这份文档来对齐需求。
在当下的敏捷环境中，我们显然不会这么玩。所有的需求都会被拆解成用户故事（User Story），从用户角度对系统的某个功能模块所做的简短描述（需求文档刚好相反，关注的是系统功能，很少会提及用户场景）。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
基于用户故事，我们如何获取我们所需要的信息呢？需要经过反复的沟通和确认，通过用户场景提问，把需求逐步澄清，并形成验收条件（Acceptance Criteria），产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。
注意下 AC 与 TC（Test Cases）的区别，AC 是针对需求内容的说明和解释，根据需求制定验收标准，每一条 AC 应该体现业务价值，是需求交付时必须满足的一组条件。而 TC 主要是由测试来编写，而且 TC 会比 AC 更详细，必须包含 AC 所有的内容。TC 通常还应该包含很多异常用例，以确保系统对异常功能的处理。关于 TC，后续会专门来聊聊。
在对齐用户故事的过程中，我们可以通过上图的方向进行思考和提问，以达到澄清需求的目标。至于用户故事的最终呈现形式，并不是那么的重要。
如上图，用户故事地图，就是一堵用户故事墙，大级别的用户故事排在第一列，根据优先级，描述用户需求。对第一排故事成纵向分解。通过地图方式，可以让团队能够有一个空间充分思考各类可行方案，从而找到一条可以最大化投入产出的路子。可以让各种干系人对功能需求有相对一致的理解和整体认识。同时，根据这些故事排列出每个迭代的用户故事优先级。
用户故事地图还可以传送出很多的信息，比如它的橫纵坐标，其实是非常有意义的，横轴代表了用户的使用路线图，纵轴代表了需求的优先级。那几条红色的虚线，就代表了每个迭代需要做的基本内容了，相当于一个粗粒度的迭代待办列表（Sprint Back log）。
注意：这个地图是动态变化的。每经过一段时间，团队都应该重新审视这张用户故事地图，看看我们的规划是否发生了偏差？还有哪些需要补充的？有没有更好的意见或者建议？是否有些功能是不必要的？
分享一份我司内部关于需求的管理方式，基于 Confluence 工具，模板如下图（实际使用由于保密问题就不放出来了）。好像要填很多的内容，很多人可能会有疑问，敏捷不是不提倡写文档么，怎么你们还要写这么多内容？澄清下，敏捷从来都没有提不写文档，而是提倡写有价值的文档。通过下面这个文档，我们可以很清晰的知道用户故事的信息：在哪个迭代被研发，需求内容是什么，如何去做验收。不好么？
独立性（Independent）：要尽可能地让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）： 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）：每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。通常让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）：一个好的故事在工作量上要尽量短小，最好不要超过 3 天的工作量（我们的实践，具体可根据团队自行定义），用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）：一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。
在需求评审的阶段，从用户使用场景的角度出发，通过提问，把需求逐步澄清，并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性，做到业务可验收、研发可实现、测试可验证、部署可交付。
把 “确认正确的事” 说明白了，接下来，我们聊点什么呢？敬请期待。
[原文连接]（https://mp.weixin.qq.com/s/JhFvsmNB9bBCGCkrxYFoJw）
