敏捷-用户故事

用户故事用户故事 一、用户故事的概念一、用户故事的概念 用户故事=用户+故事=人+故+事，那就是一个人因为什么原因要做什 么事，提炼出来三要素就是 who、why、what。从需求角度描述就是 一个用来确认用户和用户需求的简短描述。 二、用户故事的三要素二、用户故事的三要素 用户故事在软件开发过程中被作为描述需求的一种表达形式。 为了规范 用户故事的表达，便于沟通，用户故事通常的表达格式为：作为一个, 我想要, 以便于。 一个完整的用户故事包含三个要素： 1.角色（who）：谁要使用这个 2.活动（what）：要完成什么活动 3.价值（value）：为什么要这么做，这么做能带来什么价值 三、三、3C3C 原则原则 用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为 3C： 卡片(Card)、 对话(Conversation) 和确认(Confirmation)。 （1）卡片（Card）：用户故事一般在小卡片上写着故事的简短描述， 规则和完成标准。 卡片的正面书写故事的描述，格式为：作为一个 , 我想要, 以便于描述需求； 卡片背面书写完成用户故事的规 则和完成标准，格式为：Given…When…Then。 （2）交谈（Conversation）：用户故事背后的细节来源于和客户或者 产品负责人的交流沟通；确保各方对故事的理解正确。 （3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。 四、四、INVESTINVEST 原则原则 好的用户故事除了格式规范，要素完整外，还应该遵循INVEST 原则： Idependent（独立的）；Negotiable（可协商的）；Valuable（有价 值的）；Estimatable（可评估）；Small（小的）；Testable（可测试 的）。 1. Idependent1. Idependent（独立的）（独立的） 要尽可能的让一个用户故事独立于其他的用户故事。 用户故事间保持独 立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便 于独立地理解、跟踪、实现、测试以及频繁交付，也使得用户故事的大 小估算所涉及的范围更清晰，从而估算偏差更小。 2. Negotiable2. Negotiable（可协商的）（可协商的） 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故 事只是对用户故事的一个简短的描述，不包括太多的细节；具体的细节 在沟通阶段产出。 一个用户故事带有了太多的细节， 实际上限制了用户、 团队的想法和沟通。 3. Valuable3. Valuable（有价值的）（有价值的） 每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角 色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度 去编写，描述的是一个一个的 feature，而非一个一个的 task。 这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱 动的价值导向工作方式转变， 使团队中的每个人知道自己每天做的工作 价值。 4. Estimatable4. Estimatable（可评估）（可评估） 计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对 要开发的 User Story 进行一个粗量级的估算，以便于团队能够知道这 个 user story 的复杂度（工作量）。 重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的 DoD(完成标准)来完成这个用户故事， 如果不能完成， 给出理由， 由 PO 来决定是否拆分或者重新设计用户故事。 让开发者难以估计故事的问题来自：对于领域知识的缺乏 （这种情况下 需要更多的沟通） ，或者故事太大了 （这时需要把故事切分成小些的） 。 5. Small5. Small（小的）（小的） 一个好的故事在工作量上要尽量短小， 最好不要超过 10 个理想人/天的 工作量,至少要确保的是在一个迭代中能够完成。 用户故事越大， 在安排 计划，工作量估算等方面的风险就会越大。 6. Testable6. Testable（可测试的）（可测试的） 一个用户故事要是可以测试的，以便于确认它是可以完成的。 如果一个 用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不 可测试的用户故事例子：软件应该是易于使用的。 五、三个准则五、三个准则 用户故事在遵循了 INVEST 原则后，基本就是一个好的用户故事了。再 重点分析三个准则，帮助在产出用户故事时更好地符合原则。 三个准则是：一个用户、完整价值、不依赖。 1.1. 一个用户一个用户 只包含一个用户， 因为多个用户常常有细微的差别。 一般是典型的用户， 常常有共同的某类需求。 2.2. 完整价值完整价值 完整地交付一个客户价值。一个完整的用户故事意味着这个故事完成 后，用户可以达成一个明确的、有意义的目标。 3.3. 不依赖不依赖 依赖性的三种常见类型是：重叠、顺序和包含。 总体上来说，故事之间功能点相互重叠是需要避免的；顺序关系是现实 存在，在多数情况下可以通过一些手段解决； 包含关系对复杂系统是有 帮助的，对排定发布和迭代计划的影响需要注意。 （（1 1）重叠依赖）重叠依赖 重叠依赖是带来最多困扰的依赖形式， 特别是多个用户故事包含多个不 同的重叠部分时， 很难找到一组用户故事可以代表该最小可行产品的功 能集合，该集合应该包含且仅包含一次需要的功能。 解决方式： • • 将重叠部分单独剥离出来做为独立的用户故事； 合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的 用户故事中； • 使用 Scrum 开发模式。 （（2 2）顺序依赖）顺序依赖 顺序依赖是指要使某用户故事完成， 另外的一个或多个用户故事必须在 它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依 赖。 从敏捷开发的角度， 整个系统是从初始的最小可行产品逐步演化为强大 的产品，后面的每一步是建立在前面的基础之上的。 但从另外的角度， 不必要的顺序依赖使得排列和调整优先级变的比较困 难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以 把握。 解决方式： • • 一个迭代内的用户故事尽量做到没有内在依赖； 保持迭代之间只有单向依赖，在时间上只有后面迭代的故事对前 面迭代故事的单向依赖（前向依赖）； • 剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求 混在一个故事里。 （（3 3）包含依赖）包含依赖 包含依赖是指在组织用户故事时使用有层级的管理， 比如常见的特性－ 故事两级管理，一个特性包含多个用户故事， 这样就构成了特性对其属 下故事的包含依赖。 解决方式： • 用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计 划，特性一级可以用来做发布计划； • 特性一级同样可以进行拆分， 直至拆分到最小市场化特性的程度， 并将其包含的用户故事分别归到新拆分出的特性中去； • 遵从最小可行产品的理念，一个特性分多个用户故事多个迭代实 现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。