《用户故事与敏捷方法》读书笔记

第一章：概览

用户故事是对话，需求文档是描述，用户故事可以确保人人都阅读到。

用户故事面向客户，可以减少理解偏差，有助于跨职能团队互相理解和内外部的沟通。

用户故事由研发团队确定故事点大小和优先级，但是排序的时候由客户方确定，因为sprint优先级是以价值为主而不是以任务为主。

暂不开发的部分可以先以史诗占位，等到了这一步骤再开始分解成具体的用户故事，因为故事也可以迭代。

测试应尽快在迭代中编写。

 

完整的用户故事包括（硬指标）：

3C:卡片（Card）、会话（Conversation）和确认（Confirmation）

Card：用户（角色）+故事（目标）+价值（可选）

Conversation：详情描述，包括相应的图形、表格附件等，并需要口头澄清

Confirmation：约等于满意条件+数据指标（例如：满意条件为可以流畅跑通游戏，流畅数据指标为平均帧数60fps)

优秀的由用户故事为（软指标）：

准确的用户建模+INVEST标准的故事

第二章：编写

故事6特征：INVEST (Independent，Negotiable，Valuable, Estimable, Small, Testable)。

独立的：故事要避免相互依赖。

可讨论的：故事是功能简短的描述，细节将在后续客户与开发团队讨论中产生。

有价值的：故事需要对客户或者用户有价值，需要避免只对开发者有用的故事。

可估计的：故事需要量化，如故事点估算量化，如果太大无法量化应该作为史诗故事可以继续拆分。

小的：太大太小都不利于工作展开，大的史诗故事一般分为复合故事和复杂故事，复合故事可以按步骤分解，复杂故事可以按类型分解。太小的故事可以合并成一个故事在分子任务。

可测试的：故事满意条件应该是功能型和明确定义的，需要可以被自动化测试的。

编写故事中开发团队和客户团队的职责：

开发团队：开发团队帮助客户团队编写而不是只记录，需要解释相应的技术是否可实现。

客户团队：负责编写而不是只定义需求，需要确保故事是对自己有价值的。

 

第三章：用户角色建模

用户角色，是一整类用户的集合。

建模步骤：

1、头脑风暴列举所有可以想到的用户类型（最好列举的用户可以是个体）；

2、整理相似类型的用户成一个集合（尽量将用户定义为人）；

3、整合同一个集合内的多个用户类型，用一个新的用户类型代表这个集合或者留下一个最有代表性的用户类型抛弃其他用户类型。

4、提炼用户角色，为整合好的用户角色定义相应的特征。

根据产品需求可以考虑虚构人物和极端人物两个角色的建模。

注：即便有真实用户在现场，为了避免遗漏等问题还是需要做一些简单的角色建模。

 

第四章：搜索故事

1、用户访谈；2、问卷调查；3、观察；4、故事编写workshop。

用户访谈：问题需要开放，不能封闭的让受访者只能回答是否，问题也需要与背景无关，避免遗漏故事。

问卷调查：适合在迭代中搜集故事，不适合在最初作为主要搜集方法。

观察：观察demo使用者的反馈记录下改进项。

Workshop：结合头难风暴，原型等方法快速编写大量故事，故事讨论应该在较高层面，而不是讨论细节。

 

第五章：和用户代理合作

用户代理指可能是直接用户或者和直接用户有所属关系到人，比如客户经理之类。

用户代理给出的反馈很多时间可能不是直接用户的真正的关注点，有几种方式可以促进成功：

1、可有限的接触到直接用户

成立一个由直接用户组成的一个客户顾问团队，该团队可以对产品的实际使用提出建议反馈到用户代理那，这样可以减少用户代理下错误的决定。

2、无法接触到直接客户

可以建议用户代理寻找多个不同背景的非正式用户代理组成一个用户代理组，这样可以降低错误的风险。

3、如果自己是直接用户之一或者知道直接用户的需求

如果有把握自己清楚用户需求，就不必以用户代理反馈来制定故事优先级。

设计客户团队：

1、邀请直接客户加入；2、确定一个负责任；3、确定成功的关键结果。

 

第六章：用户故事验收测试

在写代码前写测试可以提醒开发哪些需要注意。

满意条件应该有客户定义。

测试要站在用户的角度。

测试要一直持续到无法为故事增加价值为止。

自动化测试是必要的，客户设计测试条目，程序执行单元测试代码。

测试主要是功能型的，有时候也包含可用性，性能，压力测试等。

 

第七章：优秀故事准则

切蛋糕：较大的故事拆分时应该都具备完整性，可以是需求为单位拆分而不是以技术功能为单位拆分，可以在拆分后的故事里再以技术功能为单位拆分子任务。

封闭性：一个故事里的需求功能应该是可以被完成的，而不是一个持续的过程，例如‘管理’，可以改为‘审核’，‘编辑’和‘删除’等。

卡片约束：类似一个满意条件。

更具时间确定故事的规模。

有些需求不一定要是故事，也可以就是一个任务。

故事里需要包括用户；每个故事都只为一个用户编写；主动语态编写；由客户编写。

要记住编写故事的目的。

 

第八章：估算用户故事

故事点：团队先定义一个故事点的工作量。

团队估算：所有人（客户和开发）都可以估算，但是只有切实执行的人可以发表意见。

估算：当出现不同时间的时候，需要双方或多方都发表意见，然后重新故事，直到大多数人达成共识，故事点不可以平均。

三角测量：当一个故事不好估算时，可以用两个类似的工作来做参照估算。

作用：更具故事点可以计算下速率，以便下一个迭代的时间和故事的安排。

注：因为不同团队对一个故事点的定义不同，所以同一件事不同团队做起来表现的故事点可能不一样。

 

第九章：发布计划

发布周期：2到6个月最好，敏捷里通常给一个理想发布日期和一个可接受的发布日期。

优先级：可以有多种方式，包括普通方式（高中低），DSDM（必须有，应该有，可以有和这次不会有），风险优先级，结构优先级等。

选择迭代长度：通常为1到4周，如果不确定，尽量短。

故事点预计工期：故事点和速率计算工期。初始速率可以由历史记录推算，猜测速率可以讨论。

创建发布计划：按故事点分配好故事到每个迭代（sprint）。

 

第十章：迭代计划

在一个发布里划分完迭代和故事点后，要对每一个迭代进行规划（sprint计划会）。

故事研讨：将本迭代（sprint）的故事合集在计划会上一一解释讨论清、楚。

分解任务：分解成面向开发的工作单位。（注：1、如果某个任务难以估算，就将其分离出来，单独放在sprint里；2、如果某个任务可以同时被多人开发，则分解成多个任务；3、必要的情况可以设置为一个任务，如‘客户对故事满意’。）

认领任务：写情况经办人，估算工作量并确认。

 

第十一章：测速和监控

不用实际工作量计算，估算多少就按多少。

计划速率和实际速率可做图参照，一般两三个迭代后开始稳定。

燃尽图：可以爆露问题，是团队自管理的工具。根据燃尽图的走势，可以为下一轮冲刺的故事任务估算做参考。

 

第十二章：故事对比其他需求方法

三种需求方法：用例use case，需求规格IEEE 830，交互设计场景interaction design scenario

用户故事比用例范围更小，(use case——user case diagram)。

IEEE 830关心特征，用户故事关心目标

interaction design scenario比用户故事更具体。

 

第十三章：用户故事的优势

注重口头沟通：面对面沟通会比文档记录更清晰。

用户故事容易理解。

用户故事大小适合做计划。

用户故事适合做迭代开发：写故事的时候不是一次就把所有细节写清楚，而是按照合适颗粒度去写，先写一部分，然后按照节奏去补全故事地图。

用户故事不要求细节一步到位。

用户故事支持’随机应变‘的开发：理想的按自上而下的计划开发在中大型项目中很难办到，开发人员会在不同层的设计来回切换，用户故事更适合这种模式。

用户故事鼓励参与，增加透明度。

不足：

在大型项目中数量多而复杂，需求的可追溯性不高，难以归档团队的交流沟通。

 

第十四章：用户故事的问题

1、故事太小（在sprint优先级会议中需要合并PBI，如果故事太大则需要拆分PBI）

2、互相依赖

3、伪需求（存在，暂不好鉴别）

4、细节太多

5、想的太远（偏离用户故事的思想）

6、频繁划分用户故事（需要扫描剩余故事，只划分真正有这个需要的故事）

7、客户难以划分优先级（难以体现商业价值，可以尝试划分更小的故事去衡量）

8、客户不愿意写用户故事也不愿意划分优先级。

 

第十五章：Scrum和用户故事

Scrum是迭代和增量的开发

Scrum master少管理多领导

一个PB应该包含一个版本目标所有的PBI。

Sprint计划会：前半部分梳理需求即’故事研讨‘（PB到SB）后半部分’冲刺规划‘（任务拆分、估时）。

站会越早越好，必须短，主要三个问题，昨天做了什么，今天要做什么，遇到了什么困难，SM要保持站会快的节奏。

PB的用户故事需要对客户或者用户具有价值

 

第十六章：其他问题

非功能性需求：用卡片约束条件限制，如性能需求，可以是要求多少fps。

物理工具还是电子工具：鼓励物理工具，原因是简单，方便。

是否保留故事：物理卡片可以在完成后丢弃，电子卡片可以保存记录追踪。