用户故事的诞生
“一般情况下，我们根据手头的信息来做决策。我们经常这么干。不要在项目开始时就做一套包罗万象的决策，我们要把各个决策分散在项目过程中。为此，我们要确保有一个获取信息的过程，越早越好，越频繁越好。用户故事由此应运而生。”
——《用户故事与敏捷方法》
用户故事是敏捷项目交付中必不可少的部分。客户通过用户故事理解并认可产品的设计思路和解决方案，研发团队依据用户故事完成具体的产品实现。
我们今天来聊一聊从用户故事的产生到完成这一系列动作中，BA所需要具备的技能包。
用户故事的来源
用户故事往往来源于一个新的想法，一个痛点或者一种需要。
在这里需要BA识别三点：
1. 是谁提出的？是否为项目干系人
2. 提出的原因是什么？
3. 识别这是一个解决方案？还是一个需求？
识别是谁提出的，目的是为了确认这是终端用户的需求还是客户自己的需求？如果是客户的需求，就要识别客户是否为项目干系人，在干系人中处于什么角色？是否会直接使用系统？
案例分享：
两个客户针对同一个业务点，提出了两个不同的想法。她们其中一位会直接使用系统做一些配置类的工作，她提出的想法都是跟自己的要做的操作相关的；而另一位客户则为项目负责人之一，她提出的想法是能够体现自己的业绩。不同角色的想法往往是出于不同的原因，我们搞清楚原因就能基本确定这个想法的业务价值。
于此同时，了解提出该想法的原因也能帮助我们判断这是一个痛点？一个需求，一种需要？或者是一种解决方案。
很多时候，用户或者客户并不能清楚的表达出自己想要什么，或者想解决什么问题。他们往往会给出一种自己认为最合理的解决方案。我们在澄清需求的时候，要多问为什么，多问这样做会带来什么？或者产生什么结果？通过一系列的问题，挖掘出最根本的痛点或需要。
案例分享：
背景是在做一个财务系统的时候，系统有一个统一的报表模版，每个月用户可以根据自己的需要生成当月的财务报表数据。
客户突然提出不想要这种统一的模版，希望每个月都可以创建新的模版，每个月的财务报表依据当月的模版去生成。
我们咨询了客户才知道，客户其实是希望每个月都能看到用户对模版的裁剪情况。根据客户的诉求，我们在生成当月报表的同时会保存一份当月裁剪的模版快照。
所以，在一开始澄清需求的时候，BA就要搞清楚是谁提出的想法？为什么？以及通过不断的提问确认这是一个需求还是一个解决方案。如果是需求，需要我们帮助客户/用户一起考虑可行的解决方案。如果是解决方案，那么需要评估这种方案是否真的能解决客户的问题，以及方案的可行性，是否有更高效的方案。
用户故事的前身
需求澄清之后，就到了设计解决方案的阶段。一个解决方案是多个角色配合设计得出的，并非BA一个人的成果。解决方案是否可行要考虑到以下几个方面：
- 是否解决了客户/用户的痛点？或者达到预期的目的？
- 技术上是否可行？
- 有没有过渡设计？
- 项目预算是否能承受？
- 交付时间是否能承受？
第一点是最重要的。我们设计的解决方案必须是有业务价值的。价值的体现就是能够满足客户/用户的某种需要或者解决他们的痛点。这一点也是需要及时向客户侧确认的。交付团队内部确定了方案的可行性之后，需要BA向客户侧阐述我们的方案设计，并最终得到客户侧的确认。
技术可行性是向客户侧确认方案之前就要明确的。我们提出的所有方案设计必须是现有技术可以完成的，这一点也是需要开发同事提前确认的。一般我们都会提前确定一位feature owner主要负责解决方案上的技术问题，也为之后IPM的问答环节提前做好准备。
另外，需要注意的是，在设计方案阶段，BA，Dev和UX往往都会有很多奇思妙想涌现出来，我们还是要根据解决客户痛点和技术可行来收敛解决方案。过渡的设计不能带来更大的业务价值，反而会增加我们的工作复杂度。
案例分析：
背景是系统要创建一份数据的配置表，根据这个配置表在一定时间周期内生成相应的数据文件。
在设计配置表的时候，大家提出了配置表的版本管理，理由是需要重新生成某个周期内的数据文件时，可以选择该周期的版本配置表，这样数据的准确性更高。
经过和客户的反复确认，这个配置表更换的可能性极低（除非换系统），偶尔有变动也只是个别的配置有增加，不会更改原有的配置。那么，在这种情况下，我们做版本管理就显得比较多余。最终，我们砍掉了版本管理的功能。
有时候对于一个需求或痛点，我们能设计出多种方案。在选择方案的时候，还要综合考虑项目预算和结点的客户因素。在预算和时间均允许的条件下，选择适当的解决方案。
综合以上几个因素，客户侧确认了解决方案之后，BA就可以对解决方案做拆解，书写出一个一个的用户故事。从这个角度而言，解决方案算是用户故事的前身了。
用户故事的拆解
解决方案确认后，BA要对方案做更细致，可以指导研发的拆解。这里介绍几种常用的拆解方法：
- 业务流程步骤——可以根据具体的业务流程做拆解。先完成一些特定的步骤，在通过增量实现整个业务流程。
- 业务规则拆解——如果某个业务有许多的规则，那么对这些规则分类，然后根据不同范围/类型的规则拆解用户故事。
- 工作内容的划分——把业务范畴内的工作按照主次划分，然后根据划分的结果拆解用户故事。
- 业务使用场景——如果业务使用的场景有不同的划分，则可根据具体的场景拆解用户故事。
- 操作——如果某个业务有不同的操作，则可根据不同类型的操作拆解用户故事。
以上都是比较常见的拆解方法。当然，还有一些业务可以衍生出更有效的拆解方式，可以适当做一些spike确定拆解的可行性。
着重强调一下，按照业务流程步骤做拆解的时候，可能会有一些故事卡之间依赖关系比较多；如果要降低故事卡之间的依赖，故事卡的点数又会增加。那么，需要依据团队的人员情况做一些取舍。或是合并依赖性较大的故事卡，牺牲故事卡必须足够小的原则；或是在有依赖的故事卡上给测试人员提供测试的入口，舍弃故事卡原有的点数；或是spike其他更有效的拆卡方式。
案例分享：
背景是我们要做一个新功能：在购物的时候，可以选择一些特定的商品使用优惠券，同时，优惠券的金额不能超过这些特定的商品。
由于优惠券的整个使用场景就在购物的流程中，拆解故事卡的时候，也是根据业务流程来拆的。虽然在写故事卡的时候也标示了每张卡的先后顺序，但是有一些前置故事卡还没有做完，后置故事卡已经完成了。QA要等前置故事卡完成后才能测试，这就造成了QA工作的堆积。
我们在retro的时候讨论了如何解决这个问题，但是如上文所述，皆有取舍。大家可以思考一下面对流程一环套一环的业务，怎样做拆分会比较好。
用户故事的书写规范和原则
书写规范
用户故事的书写一般需要包含这些内容：
- 陈述用户故事（作为xxx，我希望xxx，从而xxx）——陈述用户故事的业务价值
- 背景——关于用户故事的产生和业务上下文，帮助客户和团队理解。
- 依赖——该故事卡和其他故事卡之间的依赖关系
- 范围——该故事卡包括的业务或功能点
- 范围之外——不会包括在此故事卡中的业务或功能点
- 验收标准——具体的验收故事卡的标准梳理
- 实例化——有些故事卡逻辑比较复杂或者规则、流程较多，则需要列举一些例子帮助客户、团队理解。
不同的BA写出来的故事卡也是千差万别的。有的故事卡会写得非常细致，有的则写的相对粗一些。良好的用户故事满足INVEST原则。
INVEST原则
Independent（独立性）
Negotiable（可协商）
Valuable（有价值）
Estimable（可估算）
Small（小型）
Testable（可测试）
BA们对这个原则并不陌生，其实对于“独立性”，我的理解是尽可能的降低或避免故事卡之间的依赖性，在实际项目中，是很难做到故事卡之间完全独立的。另外，“可协商”是说这个故事卡是经过协商的。用户故事并不是传统的需求文档，留有协商的空间，当然，协商的目的是用最佳的方法达到用户故事的目标和验收标准。
其他的原则，相信大家都已经非常的熟悉，就不做赘述了。
用户故事的排序
针对某个解决方案梳理了所有用户故事之后，我们需要对用户故事做一个排序。这个排序可以把握两个原则：
- 彼此的依赖关系——前置故事卡的排序会靠前一些
- 优先级——按照业务价值对故事卡做优先级划分
根据这两个原则可以识别出来下一个迭代要做的故事卡有哪些。依赖关系弱且优先级比较低的故事卡，可以往后排。这样做的好处是在一个迭代结束后，我们可以识别出一些新的问题，那么在做下一次迭代的时候，可以做一轮更新。此外，还得考虑一个迭代的并行性，如果一个迭代全部都是有依赖关系的故事卡，那么很有可能需要一些Dev，QA等待前置卡的完成。
用户故事的确认
按照我司目前的工作模式，项目上的故事卡都需要客户签字确认后，才能进入研发。和客户签卡也是一件值得琢磨的事情。
- 提前准备 -
BA需要提前确认会议的时间安排，预测能签几张卡，提前准备好这些故事卡，而且要提前串好故事线。在开始确认每一张故事卡之前，需要给客户先大致介绍一下今天要签的故事卡是属于哪个业务范畴的，其背景是什么，让客户先有个心里准备。
- 准备故事卡 -
然后，准备的故事卡最好是有难有易，讲的时候可以根据客户的状态做调整。比如，客户已经处于比较疲劳的状态，那么可以挑一些简单的故事卡和客户确认，调节一下状态。如果客户的状态持续良好，那么可以挑优先级高且有一定难度的故事卡确认。
- 可视化故事卡 -
如果故事卡涉及到业务流程，则需要提前准备好业务流程图帮助客户理解内容。如果有新的交互，则要准备好原型图，向客户展示。如果是数据相关的故事卡，则需要提前准备一些数据举例说明数据的流转变化。
这些方式都可以帮助客户快速的理解故事卡的内容，让我们尽快的达成一致，完成签卡确认。也能获得客户侧更多的好感，有助于我们后续的良好合作。
IPM
故事卡签了之后，就可以组织交付团队一起IPM了。
- 介绍业务上下文 -
一般IPM开始时，我会用20分钟的时间向大家介绍本次IPM涉及的业务上下文，尤其是涉及到一些专业的领域知识时，会简单的解释一下专业知识。确保大家有一个共同的认知后，再开始介绍故事卡以及它们的依赖关系。
- 把控时间 -
在IPM的时候我们要注意时间的把控。有时候大家会就一个业务问题所需要的技术支撑展开讨论并陷入细节，需要及时提醒，只要不影响估点，可以暂时记录问题再私下讨论。
在后续的开卡，结卡过程中，仍然要以解决痛点为前提，实现故事卡所要达成的目标并按照验收标准进行测试工作。
在整个用户故事从无到有的生命周期中，每个环节都有一些技巧可以促使用户故事快速而准确的产生。作为BA，也需要更多的学习和探索，挖掘更深的需求，呈现更佳的解决方案，梳理更清晰的用户故事，这也是我们能交付的真正价值所在。