PF-AGUI-60-G01 用户故事指南

YY/PF/AGUI/60/G01PAGEPAGE12024用户故事指南文档编号：YY/PF/AGUI/60/G01文档信息：组织级过程文件文档名称：用户故事指南文档类别：过程改进类密级：内部版本信息：1.0建立日期：2015/12/30创建人：韩亚平审核者：谢东、罗涛批准人：谢志华批准日期：2016/01/26文档修订记录版本编号或者更改记录编号*变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V0.2A新建2015/12/30韩亚平V0.3M修改2016/01/20陈姝、孔令宇V1.0M修改2016/01/21韩亚平*变化状态：A——增加，M——修改，D——删除文档评审记录序号评审人角色评审日期签字备注1谢东2016/012罗涛2016/013文档审批信息序号审批人角色审批日期签字备注目录1. 简介 41.1 指南目的 41.2 适用范围 41.3 术语与缩略语 41.4 参考资料 42. 概述 53. 实施步骤 63.1用户故事 63.1.1用户故事模板： 63.1.2用户故事三个属性： 63.1.3优秀用户故事特征（INVEST原则）： 73.2用户角色模型 83.2.1建立用户角色模型 83.3用户故事场景 93.3.1用户故事场景介绍： 93.3.2场景的类型： 93.3.3场景描述方法： 103.4用户故事验收标准 103.5用户故事分级&拆分 103.5.1拆分原则： 103.5.2用户故事的大小 103.5.3用户故事的分级 103.5.4用户故事拆分 113.6用户故事优先级 113.6.1用户故事优先级排序介绍 113.6.2用户故事优先级排序放法 113.7用户故事估算 133.7.1用户故事估算介绍 133.7.2估算方法 143.7.3开发速率 154. 常见问答 154.1当发现用户故事之间互相依赖怎么解决? 154.2用户故事拆分任务时遇到的常见问题有哪些？ 154.3用户故事的几种类型？ 164.4用户故事的几个衡量标准是什么？ 164.5用户故事与用例的区别有哪些？ 164.6将大的用户故事分割成小的用户故事有哪些好处？ 16

简介

指南目的本指南主要描述编制用户故事需要关注的一些关键活动和方法。通过本指南能够引导相关角色识别用户故事、编制用户故事。适用范围

本指南适用于所有团队，指南的主要阅读者包括执行敏捷过程的团队、敏捷教练、产品负责、需求人员、研发团队成员等。术语与缩略语用户故事：用于描述对用户有价值的功能。用户故事展现形式主要包含三方面内容：用户故事主题（用于计划和备忘）、交谈（故事细化描述）、验收标准（验证故事实现）；用户角色（UserRole）：是一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互。是使用软件的用户的分类。参考资料

《敏捷开发与用户故事》《集团敏捷研发管理体系V2.5》概述用户故事相关主要过程如下图所示：说明：序号活动描述角色1提出原始需求客户向PO提出原始需求客户/PO/需求人员2进行需求规划和分解PO采用自顶向下的方式进行需求分解，根据主题级、史诗级、用户故事三层进行逐步分解，形成树形结构的故事。PO/需求人员2.1应用场景分析PO根据客户的描述进行应用场景分析，形成场景分析图，结合场景分解出不同层级的用户故事PO/需求人员/开发人员/测试人员2.2业务流程图结合场景，针对复杂业务形成业务流程图，从业务流程途中分解出不同层级的用户故事PO/需求人员/开发人员/测试人员2.3角色建模进行用户角色的建模活动，形成产品的角色特征表，作为用户故事描述的角色基础PO/需求人员/开发人员/测试人员3用户故事活动根据用户故事树中的用户故事，进行相关活动，完善用户故事描述和验收标准等相关内容，为后续开发做好准备PO/需求人员/开发人员/测试人员3.1业务活动/操作分析根据用户故事主题进行用户故事的细化描述，针对细节操作和活动进行阐述，常采用讨论方式PO/需求人员/开发人员/测试人员3.2优先级排序已形成的用户故事进行优先级排序，形成MVP，为后续开发顺序做好准备，优先级为单一数据PO/需求人员3.3用户故事估算根据故事点评估在此用户故事规模PO/需求人员/开发人员/3.4用户故事验收标准用户故事通过的标准。PO/需求人员/测试人员实施步骤3.1用户故事3.1.1用户故事模板：作为一个用户故事，必须包含如下的内容：主题：采用三段论的方式进行用户故事描述。描述：对故事的详细描述，：故事场景业务流程验收标准：优先级：估算值：用户故事的估算针对每一部分在后续章节中有详细的描述3.1.2用户故事三个属性：用户故事描述了对用户、系统或软件购买者有价值的功能。其包括：描述：总体描述，用来做计划和行为提示，用户故事描述包含三个要素：角色、活动以及商业价值。描述方式为：作为XXX（用户角色）能够XXX（动作），以便于XXX（目的）其中：用户角色：谁要使用这个功能，在本指南中可以采用用户建模中的角色；活动：需要完成什么样的功能；商业价值：为什么需要这个功能，这个功能带来什么样的价值。有关故事的具体化细节:故事相关活动的细化说明，主要包含的内容：在这个故事中，每个角色需要参与的工作（活动）及实现的结果；在这个故事中，每个角色的工作流程；每个工作流节点的具体工作内容及具体业务控制逻辑要求和逻辑条件。包括在故事在团队讨论中内容形成的注释。验收标准：用于表达和明确故事细节且可用于确定故事何时完成，用于明确团队完成故事的标准。提示:用户故事要使用用户可以接受的业务语言来描述故事，不能够使用技术语言来描述。用户故事的质量是后续工作顺利完成的基础，因此尽可能保证用户故事的质量，不要因为用户故事的不清晰使得在开发中过多的投入到故事论述中，导致开发结果没有完成。3.1.3优秀用户故事特征（INVEST原则）：I–Independent，独立性，可独立交付给客户：要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。N–Negotiable，可协商性，便于与客户交流：一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。V-Valuable，价值性，对客户有价值：每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。E-Estimable，估算性，能估计出工作量：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。S-Small，短小：分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成，一个好的故事在工作量上要尽量短小，最好不要超过一个迭代周期的工作量,要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。T-Testable，可测试性:一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。3.2用户角色模型3.2.1建立用户角色模型建立用户角色模型即梳理用户角色:把客户和开发人员聚集到一个房间中，通过头脑风暴，列出初始的用户角色集合，然后整理最初的角色集合，通过整合角色和提炼角色，最终确定出使用软件的角色。具体操作方法可以参考如下：所有相关人员包括开发人员、需求人员、客户等均聚集在一起，通过头脑风暴首先列出原始的用户角色：只需要在卡片中写出自己想到的角色，不需要讨论和评估；将卡片读出来，粘贴到展示板中；直到大家没有新的角色提出；要注意列出的角色是产品实际使用用户。初步分类：将第一步形成的用户角色进行初步分类，形成角色集合：将卡片进行初步分组，标明角色间的关系；相同的进行重叠；包含关系通过卡片的覆盖进行体现；系统角色尽量是一个具体的人。整合角色：去掉完全重合的卡片角色，讨论中可能会新增新的卡片；丢弃对系统不重要的角色。提炼角色，建立角色卡片：经过前期的讨论，已经对角色之间的关系有了基本的了解；通过提炼的角色，描述角色特征，角色特征可以从如下几个方面进行考虑：用户使用软件的频率；用户在相关领域的知识水平；用户使用软件和计算机的熟悉程度；用户使用该软件的目标和特点，如用户特别关注便捷性、关注用户体验；本软件对该用户有帮助的特征；将特征形成用户角色特征卡片。为了让角色更加完整，在用户故事后续重更加生动准确。可以进行如下两个角色的补充，根据产品实际情况进行，非必需。虚拟角色：虚构出一个实际用户，阐述他的特点和可能使用的场景，该角色需要真正代表产品的目标客户，作为软件虚拟使用人员，可以配以名字、照片、相关信息描述，在项目中可以理解为是真实存在的。极端角色：可以找到一些遗漏的故事，根据产品需要决定是否有必要；3.3用户故事场景3.3.1用户故事场景介绍：定义：从用户的角度出发，描述了一组典型用户在典型工作环境下的典型需要、想法、工作习惯等，是指一个应用(通常就是你的那个产品)被使用的时候，用户“最可能的”所处场景。用户故事场景的设计，主要从以下几个方面考虑：对每一个场景，设计一个场景入口，就是描述场景如何开始用户故事主要是描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）需要给场景划分优先级，并按优先级排序用户场景有大有小，适度、平衡即可用户和系统有成百上千种可能的交互情况，在写场景的时候要有针对性用户故事场景的特征：

1．场景的背景：典型用户用户的需求、迫切需要解决的问题假设行业背景等2．场景：关于这个场景的文字描述：要列出这故事中出彩的地方,例如：软件的哪些功能让用户特别满意?逻辑和界面设计要注意哪些因素?第一次使用的用户和多次使用的用户在体验上有何区别对待?3．其他参考资料（工作规程、组织机构图、工作职责清单等）场景通常在限定的条件内而存在，场景包括时间、空间、设备支持、社交及用户情绪等多个方面，进行应用场景的判断和描述的时候，尽量把这些都考虑完整。3.3.2场景的类型：基于故事目标或者任务的场景：主要描述用户想做什么，不包含用户如何完成任务的任何信息。精细化的场景:提供了更多的用户使用细节。这些细节能帮助团队更深入的理解用户特点。全面的场景描述:场景和人物角色还可以结合起来，分类呈现不同类型的用户使用产品的原因，有什么样的需求，揭示出“什么样的人”在“什么样的场景”下会有“什么样的行为”。测试场景:说明预期的用户是如何完成这个任务的所有路径和步骤，包括用户可能使用的主要的入口或者其他的入口，供观察人员和记录人员在测试中使用。而在测试后，可对比下你的预期过程和用户完成任务的真实过程。3.3.3场景描述方法：场景描述中需要明确：环境-人员-事情-产生的价值；用户故事可以采用卡片、故事访谈链接、用户场景截图、故事板等方式表达故事的场景。3.4用户故事验收标准验收标准：定义故事是否完成的标准，让团队和产品负责人对此达成一致面向用户的价值设定验收标准，业务验收标准主要包含：PO或需求从业务的角度描述此功能的验收标准，在故事进入迭代计划之前该验收标准明确清晰；按照用户的需要，产品Backlog条目完成；PO或需求在Sprint结束时接受或拒绝接受开发团队的工作成果，对每个演示的故事和主要缺陷，PO表示接受（符合预期和验收标准）或拒绝（不符合预期或不满足验收标准），并给予团队反馈或意见；PO或需求根据用户的价值确定功能优先级，并确认功能已经开发完成；PO确认已经达成产品的投资回报率(ROI)。3.5用户故事分级&拆分3.5.1拆分原则：缩短完成用户故事的时间；减少用户故事大小的差异性；采用逐级分解细化方式，最终拆解为用户故事。3.5.2用户故事的大小用户故事的大小与完成时间不是成正比的，故事增加两倍，投入时间可能增加5倍；当前我们通过时间盒的方法控制用户故事的大小。目前我们的要求是：用户故事大小不能超过迭代周期。史诗：通常为大一点的用户故事，通常分为两种：复合故事（compoundstory）：由多个小的故事组成；复杂故事（complexstory）：本身就很大且不容易分解的故事。通常通过分层的方式体现，有些需要采用探针实验进行验证3.5.3用户故事的分级用户故事可以两个维度进行划分：一个是产品展现形式，一个是产品颗粒度。产品展现形式分为以下三部分：客户可见:产品史诗、产品功能、产品增强，描述产品的卖点(展现给客户)产品经理可见:产品优化、产品约束、产品条件、产品性能等开发团队可见三部分进行区分：产品缺陷，产品重构产品颗粒度采用树形结构的形式进行细分，上级故事也可称为史诗级别的故事。3.5.4用户故事拆分主要是要从客户角度对用户故事进行划分，具体可以：按照不同操作—即根据动作对故事进行分解，添加、删除、修改、浏览等按照数据—即根据数据边界进行分解，可以浏览产品名和介绍、可以浏览产品价格按照特性—易用性、性能、兼容性、并发性等等按照角色—从不同用户角度按照投入的人力-比如要完成信用卡支付(Visa,Master,AmericanExperess)，可以分成三个故事来实现按照实现复杂程度、步骤—解为探针实验调研以及实现两部分进行分解；按照流程:即根据业务流程进行分段，明确输入输出产品缺陷：分为两类，一类是客户发现的，需要展现给用户，一类是我们自己发现。3.6用户故事优先级3.6.1用户故事优先级排序介绍PO负责排序Story，产品总监负责排序Eipc和拍板有争议的story，排列优先级时需要考虑下面几点：1) 大部分用户和客户对特定特性的渴望程度；2) 小部分重要用户和客户对特定特性的渴望程度；3) 故事之间的互补或依赖关系。3.6.2用户故事优先级排序放法Kano模型我们根据用户需求重要性将需求分为三种类型：基本型需求>期望性需求>兴奋型需求，这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。需求类型定义不满足时满足时基本型需求顾客认为产品“必须有”的属性或功能当其特性不充足（不满足顾客需求）时，顾客很不满意当其特性充足（满足顾客需求）时，无所谓满意不满意，顾客充其量是满意期望型需求要求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为有些期望型需求连顾客都不太清楚，但是是他们希望得到的当没有满意这些需求时，顾客就不满意在市场调查中，顾客谈论的通常是期望型需求，期望型需求在产品中实现的越多，顾客就越满意兴奋型需求要求提供给顾客一些完全出乎意料的产品属性或服务行为，使顾客产生惊喜当其特性不充足时，并且是无关紧要的特性，则顾客无所谓当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高顾客的忠诚度通过两个问题确定功能的分类：关于产品中具有这项功能，用户会觉得怎样——功能存在形式关于产品中没有这项功能，用户又会觉得怎样——功能缺失形式对每个问题采用五点度量方式进行问答我希望这样我预期就是这样我没有意见我可以忍受这样我不希望这样答案分类，得到每条需求的分类维护在维度内进行数字优先级排序多人问卷调查，提高准确性实施：通过excel进行。相对权重法考虑一项功能所带来的正面益处，和缺乏他所产生的负面影响。评估如果实现它所带来的收益、如果不实现它所会招致的惩罚。同故事点估算一样，对收益和惩罚也是采用1-9的尺度进行相对度量。提示：优先级=价值百分比/成本百分比价值百分比=功能价值/价值总和3.7用户故事估算3.7.1用户故事估算介绍故事估算的目的主要是如下几点：获取更多的知识，基于更多的知识进行决策；让团队成员更加了解需求，保证需求验证的合理性；营造团队内良好的沟通氛围；估算不是为了更加的准确，单纯的为了能够制定合适的迭代计划。估算并不是唯一的解决途径，根据迭代开发结果对下一次的估算进行调整，从而让项目的估算更加接近项目的实际开发效率，当项目团队全力以赴的时候，估算就可以越来越弱化。估算的方法有很多，最常用的是故事点估算方法。故事点团队达成共识的一个代表标准规模的衡量单位。一个故事点可以是一个理想工作日（没有任何干扰的一个8小时工作日）、一个熟知的功能点（团队内某开发能力的人完成此的功能点需要的实际规模被团队共同认可）。故事点估算就是评估我们要实现的用户故事，相对于这个标准故事点的相对值；通过衡量故事点的评估，使我们更容易对团队有效的工作效率进行把握；在这里我们推荐使用理想工作日的方法进行估算。故事的估算通常由整个团队来进行，在这里需要强调一下与任务估算的差异，任务估算通常由承担任务的人直接进行。而用户故事由于是团队共同的责任，因此团队共同对结果进行负责，所以估算由团队来进行，故事的实现后期由团队通过站立会议进行集体跟踪，对问题集体进行处理，属于团队共同完成的用户故事。估算前需要明确估算的范围，即估算的内容包含完成此用户故事所有的规模投入时间，而不是单纯的开发或者测试等单方面的工作投入。3.7.2估算方法Delphi估算方法推荐使用最多并被业界推崇的Delphi方法（也称估算扑克），详细过程如下：所有团队成员聚集在一起，包括需求人员和开发人员以及与故事相关的所有人；准备好空白卡片和笔；用户故事讲解人员，选取一个故事，进行阐述，开发等相关人员尽可能的发出疑问，达成一致；没有疑问后，每个开发人员在卡片上写出一个估算值；以一个标准故事点（理想工作日）为参照，评估需要多少故事点；写过后不要给其他人看；所有人同时翻开卡片，通常差异较大；估算值最高和最低的人，对估算依据进行解释。在这个环节不能存在攻击现象；针对疑问达成公示后，再重新进行估算；通常2-3轮候，数据基本达成一致，这里并不需要所有卡片都统一成一个数字，估算结果合理即可，不需要绝对的精确。在讨论过程中可以将一些解释或者注意点、关键活动标注在卡片上，形成注释，也可能产生新的故事；提示：估算时候需要充分考虑，可能遇到的问题和需要执行的活动；估算时候需要明确对一个故事完成的标准，完成故事需要的活动内容，如单元测试、自我验证等。三角测量法估算完毕后，将故事点采用三角测量的方法，总体浏览一下估算是否存在偏差，是否对标准故事点理解一直没有偏差。即以故事点为维度，对已经评估的故事点根据估算大小进行一下排序，比较一下估算的大小是否与预期的故事大小顺序一致，相同的估算点故事是否大致相同，这样做是避免在评估过程中大家对标准故事点产生偏移。3.7.3开发速率速率：一个团队在于给迭代中完成的故事点数。根据速率评估下一个迭代的工作内容，进行计划安排，这个速率一定是常态的速率。每个迭代完成后得到这个迭代的速率后，对团队速率的评估需要考虑如下因素，从而得到一个团队常态的速率：需要评估本轮迭代工作是否存在异常。例如是否加班，是否本迭代中有其他工作的引入，是否人员变化等。每个迭代的速率是否平稳一致，参照历史迭代速率。常见问答4.1当发现用户故事之间互相依赖怎么解决?对于相互依赖的故事，可以采用以下处理方式：1）将相互依赖的故事合并为一个故事；2）考虑其它的划分方法，如根据动作对故事进行分解（增加、删除、修改）、根据数据边界进行分解；3）在故事卡上标明依赖关系；原则上，用户故事需要具有独立性，我们在编制用户故事的时候，要尽可能避免故事之间存在依赖关系。故事间的依赖关系会产生优先级和规划问题，即依赖关系越复杂，故事的不确定性就会越强。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。如果无法避免依赖，则必须在用户故事中标明此用户故事对其他故事的依赖，标明依赖的顺序。被依赖的故事，优先级必定提高，只有被依赖的用户故事完成才能继续开发依赖的用户故事。4.2用户故事拆分任务时遇到的常见问题有哪些？如果故事中某个任务特别难估算，则最好将这个任务从故事的其它任务中分离出来；如果一个故事的任务可以很容易的分给多个开发人员，则分割他们；如果有必要让客户了解故事中某一部分的完成情况，则可以把这部分拿出来作为一个任务。4.3用户故事的几种类型？各种“用户故事”中，大致可以分为史诗Epic、故事Story、增强Enhancement、缺陷Def