谈谈用户故事

谈谈用户故事
1.背景介绍
产品开发、测试的需求源头都是用户故事
PM必须好好掌握用户故事
2.知识剖析
一、用户故事的概念
用户故事，描述了对用户、系统或软件购买者有价值的功能。

二、用户故事的三要素
角色、功能、价值
三、用户故事的独特价值
独特价值之一在于它的出现使敏捷开发方法覆盖了软件研发中的“需求”环节
用户故事的诞生，就是为了实现需求的敏捷化，是需求敏捷化的基石之一
独特价值之二在于它不仅实现了需求敏捷化的表述，还有效的将软件研发过程中的需求环节、开发环节和测试环节有效的连接起来。

通过经典的“三段论“描述和渐进的细节探索，用户故事实现了需求描述的敏捷化
通过优先级排序和故事点的有效应用，用户故事实现了需求到开发的连接
通过验收标准的渐进明确，用户故事实现了需求与测试的连接
独特价值之三在于它的特有的度量概念：故事点
故事点巧妙地将需求与研发计划有效地融合起来，并且很好地支撑了团队的持续改进
补充：
故事点：在项目开始的阶段，试着找出所有的用户故事，然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短），不一定非常精准的判断哪个最简单。

只要挑出你觉得最简单的就行了。

然后我们判断说，这个用户故事算1个“故事点（story point）”。

关于独特价值的第三点：
计划会议里面一个很重要的环节，那就是故事点的估计
实际上就是对在sprint里面要开发的user story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量）
重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事
四、用户故事的原则
INVEST
用户故事应该具有六大特点：Idependent（独立的）；Negotiable（可协商的）；Valuable to users or customers（对用户或者客户是有价值的）；Estimatable（可估算的）；Small（小的）；Testable（可测试的）
Idependent（独立的）
是指用户故事和用户故事之间应该尽量避免相互依赖。

Negotiable（可协商的）
在进入开发前，需求、开发、测试大家对用户故事的描述和验收标准已经达成了一致。

但是不管在开发前达成怎样的一致，在开发过程中必然会发生需求细节的进一步细化，这是因为随着软件开发的进展，系统的未知性由模糊而渐进清晰必然导致的结果，这是自然规律，任何人都无法避免。

而我们能做的，就是运用敏捷方法适应各种变化。

用户故事的“可协商性”就是指大家对所有之前达成的一致在新的变化发生情况下，协商后达成新的一致，从而推动系统的研发进展。

Valuable to users or customers（对用户或者客户是有价值的）
用户故事的经典三段论描述把故事的价值可视化的描述出来，这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。

Estimatable（可估算的）
上文中描述的独特价值之三
Small（小的）
因为用户故事是敏捷实践，而敏捷方法追求的是快速交付，那么作为源头，我们输入的需求也应该是面向交付的，所以，好的用户故事必须足够小。

Testable（可测试的）
所有合格的需求必须是可测试的，用户故事也不例外。

用户故事的验收标准正是体现了这一点。

五、好的用户故事的准则
好的用户故事当然应该遵守上述几个原则
下面谈谈好的用户故事的几个标准
针对性、封闭性、独立性
针对性：只包含一个用户，因为多个用户常常有细微的差别
一般是典型的用户，常常有共同的某类需求。

封闭性：完整地交付一个客户价值
一个封闭式的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标
下面给一个不是封闭式的用户故事的示例：
以一个在线求职网站为例：“作为一个招聘人员，我可以管理我发布的工作。

这个故事太大了，以至于没有太多意义。

“管理”这个活动很难被完成。

比如，你们公司有一个经理，他肯定不会说，“OK，我的管理完成了，是时候干点儿实事儿了”。

“管理”这个词很明确的提示我们，这个故事不是一个封闭式的故事，类似的词比如“维护”、“优化”、“改进”等等。

那我们一起来看看，如何写封闭式的用户故事。

首先要考虑的是，“管理”在这个上下文里面具体意味着哪些事情要做。

在一个在线求职网站，管理发布的工作，意味着我浏览这些工作广告对应的求职申请，检查发布的工作是否过期了，删除不太适合的求职申请，更新或修正工作描述等。

所以，写用户故事就是要把这些想法具体化。

上面的最初的那个用户故事，我们可以写成下面这样:
作为招聘人员，我期望能够浏览所有我发布工作对应的求职申请，我需要将符合要求的找出来发给招聘经理。

作为招聘人员，我可以调整我发布的工作的截至日期，这样我可以延长时间获得更多申请，或者提前结束该职位的招聘。

作为招聘人员，我可以删除不太合适的求职申请，这样我可以避免浪费时间在这些没有价值的信息上。

作为招聘人员，我可以修改我发布的工作的描述，以便于吸引更好的求职者关注这个职位。

独立性：故事间没有依赖
三种依赖性的类型：重叠（Overlap）、顺序（Order）和包含（Containment）
1.重叠依赖
重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。

用户故事功能重叠是没有很好进行拆分的指示器，错误地使用端到端的概念，在非特性团队的情况下按照部件或架构层次拆分用户故事
解决方式：
将重叠部分单独剥离出来做为独立的用户故事
合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中
组建特性团队以及合理界定端到端
补充：
端到端的流程：
端到端流程的定义是从客户的需求开始到客户的需求满足为结束。

为满足并能解决客户同一个相对独立需求的一系列相关子流程的组合。

特性团队：
特性团队是一个跨职能、跨组件的团队，能够从产品待办列表中抽取并完成最终客户想要的特性。

首先，应该准确理解“特性”。

这个特性指从产品的最终用户的角度看，对最终用户有价值，最终用户能够感知到的东西。

第二、职能。

比如UI设计、编程、测试，就是三种不同的职能。

最终用户想要的某个特性往往需要多个职能协作，“跨职能”就是要求一个开发团队具备所有必备职能，而不需要依赖团队外部的职能部门。

第三、组件。

当软件系统庞大、复杂时，通常把一个系统分解为多个组件。

组件团队有如下一些限制：
第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。

第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。

第三：由于职责单一，限制了学习，使得专业更加单一化
第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付
特性团队的好处：
团队内可以做到端到端，所以减少了等待，周期加快
比较容易在一个Sprint中交付可用的产品增量
减少了团队之间依赖，计划会更容易
责任范围的扩大，各种不同领域的专家在一个团队，增加了个人学习和团队学习的机会
以特性团队为主的组织在实现“迭代开发、增量交付”方面有天然的优势，成功的Scrum组织应以特性团队为主。

2.顺序依赖
顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。

顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。

从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的
但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。

解决方式：
要求一个迭代内的用户故事尽量做到没有内在依赖，保持每一个用户故事的独立性。

在同一迭代内，同一团队之内以及多团队之间的故事最佳情况都是做到无依赖。

保持迭代之间只有单向依赖。

如果一个迭代内用户故事有依赖，而用户故事的拆分满足其他良好的用户故事拆分规则，说明用户故事可能拆分的太细，或者迭代期太长，首先保持单向依赖，可以尝试缩短迭代期
任何情况下，不要有循环依赖。

剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。

3.包含依赖
包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。

解决方式：
特性一级用来做发布计划
用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划
特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去
遵从最小可行产品的理念，组合多个最小市场化特性而构成最小可发布的产品，并逐个迭代增强系统，一个最小市场特性可以多个迭代实现，每个迭代实现一些用户故事。

一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。

极端情况下一个市场化特性可以是一个用户故事，消除了包含依赖。