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