上篇我跟大家详细介绍了产品 Backlog，它是敏捷团队管理开发过程的核心，所有的活动和交付物都围绕产品 Backlog来进行。一个完整的 产品 Backlog = 估点的用户故事（User Story, 之后统称为 Story ）+ 优先级 + 验收标准。
那为什么 Story 是作为描述产品 Backlog 最好的形式？我们又如何编写有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致，共同决策呢？本篇我就带着你从理解 Story 开始，经过建模、搜集、编写、估算，让“一张卡片”发挥出它的洪荒之力，快速挖掘需求，理解需求。
用户故事
为什么要用 User Story ？
软件需求是一个沟通问题。在现实开发的过程中，最常见的一个问题就是一旦有一方（业务或开发）占主导地位，沟通就会出现问题，项目不管是速度还是质量都会受损。这个时候我们就需要有一个协同工作的方式，让两方共同承担资源分配的责任。那这种协同工具必须具备的特点是团队任何角色都可以很好的理解，并且能清楚的站在用户的角度。
另一个方面是我们没有办法在最开始就完美的规划出项目中所有的需求，我们需要定期获得反馈信息在作出下一步的判断，没有包罗万象的决定，我们需要一边收集信息，一边不断频繁迭代一个个小的需求。而 User Story 完美的解决了这两个问题。它具有以下特点：
- 强调对话，而不是文档
- 可以同时被所有相关人员理解
- 大小适合做计划
- 鼓励推迟考虑细节（即 Story 也可以迭代）
User Story 是什么？
User Story 描述了对用户、系统或者软件购买者有价值的功能。一般由三部分组成：卡片（Card）、对话（Conversation）、测试（Confirmation）, 通常称 “3C”。而卡片最重要的要素体现在于它代表了客户需求，但是记住，卡片不是记录需求的。
使用 Story 的过程：
- Story 工作坊编写
- 团队选择迭代长度
- 估计每个迭代能做的事情
- 制定发布计划，Story 分布，优先级设定
了解了 Story 是什么，为什么要用 Story ，下面我们来看如何开始建模、收集、编写、估算一个 Story 。
简单的用户故事
Story 建模
用户角色是指一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互。
建模步骤：
-
通过头脑风暴，列出所有的用户角色集合
团队成员坐在一起，每人把所有想到的所有角色列举在卡片上（一个卡片一个角色，一个角色是一个用户） -
整理最初的角色集合
将所有卡片展示出来，重叠的角色放在一起，对剩下的角色进行分组 -
整合角色
即浓缩角色，大家分别描述自己写的角色代表的是什么，等同角色则进行浓缩成一个，丢弃对系统不重要的角色。在整合的动作结束后，展示出角色的关系，把通用角色放在最上面。 -
提炼角色
这一步需要通过给每个角色定义 一些特征来建立角色模型。角色特征是关于同属于一类用户的事实和有用信息，其实是作为角色间的区分，比如：
- 用户使用产品的频率
- 用户在相关领域的知识
- 用户使用计算机和产品的情况
- 用户对产品的熟悉程度
- 用户使用产品的目的和注重点
搜集 Story
区别于传统模式收集需求的方法，敏捷更强调 Story 的时间维度，即没有一种方法可以在一个单一阶段获得所有的 Story ，这就是之前所说的 Story 也可以迭代。有以下几种方式：
- 用户访谈
- 问卷调查
- 观察
- 故事编写工作坊
前面三种大家接触的比较多，我今天我想说下最后一种最有效的方式——故事编写工作坊。这个方法的重点在于数量，而不是质量，并且这个环节无关界面设计。
开端以一个用户角色开始，只需要简单的线指向这个用户角色要走的每一步，以生活服务平台其中一个用户角色（搜索餐厅类型），Story 有：
用户可以搜索附近的餐厅
用户可以搜索评价餐厅
用户可以查找餐厅位置
用户可以根据口味选择自己喜欢的类型
……
每一步都可以写出大量的故事，为了防止遗漏，可以在最后问自己以下问题来检查：用户接下来最可能干什么？到这里，用户有什么困惑？用户此刻需要什么额外信息？这一步会犯什么错误？
如何编写用户故事
编写 Story
建模完成，搜集好用户故事，接下来就是编写，好的 Story 要具备 INVEST原则
Idependent（独立的）
每个 Story 代表一个独立的功能，最好能覆盖到每一个细节，用户故事间保持独立性不仅便于排列和调整优先级，使得发布和迭代计划更容易制定，便于独立地理解、跟踪、实现、测试以及频繁交付。
这里我想说一个很多人常问的问题：Story 间相互依赖怎么办？如果你的 Story 相互之间有很强的依赖，相互优先级彼此影响，那有两种方法可以绕过，一是合并成一个大的、独立的故事；二是用一个不同的方式去分割故事。
Negotiable（可协商的）
一个 Story 的内容要是可以协商的， Story 不是合同。它只是一个简短的描述，不包括太多的细节；具体的细节在沟通阶段产出。一个 Story 带有了太多的细节，实际上限制了用户、团队的想法和沟通。具体的细节可以作为验收标准写在卡片之后。
Valuable（有价值的）
每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。Story 对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的 Feature，而非一个一个的 Task。
这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。
Estimatable（可评估）
计划会议里面一个很重要的环节，那就是故事点的估计。实际上就是对要开发的 Story 进行一个粗量级的估算，以便于团队能够知道这个 Story 的复杂度（工作量）。
重点放在当前迭代里能否按照该 Story 的接收条件和团队定义的DOD(完成标准,以后文章会详细介绍 ) 来完成这个 Story ，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计 Story。
让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。不可估算的故事可以变成两个故事，一个探针故事（获取足够信息的技术探索），一个真实功能。
Small（小的）
一个好的 Story 在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代中能够完成。Story 越大，在安排计划，工作量估算等方面的风险就会越大。
Testable（可测试的）
一个 Story 要是可以测试的，以便于确认它是可以完成的。如果一个 Story 不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的 Story 例子：软件应该是易于使用的。
INVEST 原则
估算
编写好 Story ，接下来要对 Story 进行估算，常用的方式是故事点，他是由团队定义的，这个故事点可以是理想日工作（即任天），也可以用复杂度来定义，不管什么方式，都需要团队所有成员共同定义，这里介绍计划扑克方估算方法。
团队成员每个人手里都有一副扑克，牌点数一般有0、1/2、1、2、3、5、8、13、20、40、100。首先由 PO 对 Story 进行讲解，然后由 Scrum Master 负责协调进行初始评估工作。敏捷估算中不是要估计绝对的时间，而是尽量确保故事之间的相对估计是准确的。由于估计是相对的，所以需要首先找打一个基准，我们可以先找一个不是最小的，也不是最大的来作为一个基准，可以先找出一个大家认为适合分配为2点的故事。在找2点的故事时，很可能会出现大家意见不一致的情况，这时就需要大家都分别说明自己的见解后再重新找。有了2点基准后，就可以对每个故事进行评估了，而后面的故事都可以基于以前的故事来进行相对估计了。大家统一估计，过程中有可能会出现大家对故事理解不一致，这时就需要返回去修改故事，确保大家理解一致。估算以有了统一的估算值为止。
在估算之后，为了验证与其他 Story 的大小是否保持一致，推荐使用三角测量法，即将所有估算好的 Story 贴在一起，上下左右验证是否粒度一致。
估算
今天我们从理解 Story 开始，经过建模、搜集、编写、估算四个步骤，让大家从一开始了解愿景到分解产品 Backlog ，再到今天一步步的产出 Story 这一过程的深入，让你的产品转型之路已走了过半。下篇我会从如何根据 Story 制定迭代的发布计划、迭代计划，以及如何测试和监控整个迭代过程。
image
网友评论