用户故事

一、定义

用户故事是描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。
用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。
2.功能：需要完成什么样的功能。
3.价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a , I want to , so that .
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
举例：“作为一位敏捷教练，我想要有敏捷看板，以便于早会时同步任务的状态信息给迭代成员。”

由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）：通过验收测试确认用户故事被正确完成。

二、用户故事的原则

• INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
• 独立性（Independent） - 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
• 可协商（Negotiable） - 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
• 有价值（Valuable） - 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
• 可估算（Estimable） - 开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
• 短小（Small） - 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
• 可测试（Testable） - 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

三、如何使用用户故事？

3.1 在什么时候使用用户故事？

用户故事是在敏捷开发中表达需求的主要方式，也是最小可产生价值的可执行的需求。
需求池管理在当前需求管理流程尚未成熟的基础上可以任何工作项类型存在（当前各团队中主要为史诗、特性、需求等工作项类型管理），但要求：
所有进入迭代的需求必须使用「用户故事」的工作项类型，同时满足INVEST原则，完成验收标准的定义等。

3.2 应该由谁书写用户故事？

需求澄清会前，由产品经理和PO根据产品场景等对用户故事进行拆分，并初步输出验收标准。
需求澄清会上，基于用户故事的原则，由全员对用户故事的拆分提出意见，完成分解的用户故事，优先级以及验收标准确认。
迭代过程中，由产品经理对用户故事负责，若出现需要变更，需获得PO授权或确认，并同步所有团队成员。

3.3 什么情况需要分解用户故事？

出现需要拆分的用户故事时，应「关闭」原用户故事，拆分成新的颗粒度大小合适，满足用户故事原则的故事。

• 当用户故事太大，单个迭代无法容纳时（比如双周迭代无法完成一个任务甘特功能）
• 当用户故事可能足够小，但当前迭代剩余时间不够（比如F1235 中途有新增文案修改需求）
• 当用户故事太大，难以估算/较难描述故事背后的商业愿景

• 当用户故事太大，对团队成员无法明确其阶段性价值时

  3.4 如何分解用户故事？

• 按照数据边界分解

  • 例子：作为一位研发，我想要有登记工时功能，以便于记录日常研发时间。 可以分解成
    • 作为一位研发，我想要有登记工时功能，以便于记录日常研发时间。注意，不可以提交负数
    • 作为一位研发，我想要有登记工时功能，以便于记录日常研发时间。如果输入工时超过9999，则限制最大值为9999
• 按照操作边界分解
  • 解释：通常为 CRUD操作（Create、Read、Update、Delete）
  • 例子：作为一位敏捷教练，我想要有敏捷看板，以便于早会时同步任务状态信息给迭代成员 可以分解成
    • 作为一位敏捷教练，我想要有敏捷看板，以便于展示任务状态信息
    • 作为一位敏捷教练，我想要有敏捷看板，以便于变更任务状态信息
    • 作为一位敏捷教练，我想要有敏捷看板，以便于在看板上直接新增任务
    • 作为一位敏捷教练，我想要有敏捷看板，以便于在看板上直接删除任务
• 去除横切考虑
  • 解释：一个系统中会存在很多正交或者横切的特性，比如安全处理、错误处理toast机制、日志记录等，应该为用户故事建立两个版本：一个具备对横切关注点的支持，一个不具备这种支持。
  • 例子：作为一个用户，在使用系统登陆之前，需要使用用户名和密码登陆。当澄清会中成员讨论出，完成此用户故事应该包含：包含了密码需要“至少8个字符、字母加数字组合、储存和传输是必须加密”等需求时，应该分别建立故事的安全和不安全版本，则：
    • 作为一个用户，在使用系统登陆之前，需要使用用户名和密码登陆，密码需要有至少8个字符、字母加数字组合
    • 作为一个用户，在使用系统登陆之前，储存和传输是必须加密
• 忽略满足性能限制
  • 解释：考虑把功能性与非功能性需求隔离到不同的用户故事，从而分解大型用户故事
  • 例子：作为一个管理人员，我希望可以批量导入任务，以便于 XXXX
    • 作为一个管理人员，我希望可以导入任务
    • 作为一个管理人员，我希望可以批量导入10w条任务
• 分解具有混合优先级的用户故事
  • 解释：如果大型用户故事中的小故事具有不同的优先级，则可以对他们进行分解
  • 例子：作为一个用户，我需要登陆到系统中 。这个用户故事对于用户的满意度包括下列几点内容：
    • 如果用户输入有效的邮箱和密码，则可以正常授权登陆
    • 如果用户连续5次输入密码错误，则拒绝访问，并10分钟后才能再次尝试登陆
    • 如果用户密码一直输入错误，给他提示：尝试通过“忘记密码”功能找回密码，或者给他发邮件，告诉他有人试图使用他的账号登陆。
  • 根据以上的内容，可以得出，正确的邮箱和密码登陆优先级为最高，密码连续输错5次拒绝访问次高，最低为第三点一直忘记密码的提示功能
• 不要把故事分解成任务
  • 原因：拆解出来的研发任务无法独立交付到测试手中独立测试，因为对测试/产品来说，验收时只要前端/后端都无法完成验证一个登陆流程。
  • 反面例子：作为一个用户，我需要登陆到系统中，将用户故事分解为：
    • 编写中间层
    • 对登陆界面进行研发
• 避免相关变化的诱惑
  • 解释：避免在具有适当大小的特性中增加相关变化而把事情弄糟，除非这些变化具有同样的优先级。
  • 例子：在完成一个用户故事时，发现部分代码修改的过程中，已有的代码中存在一个bug，此时应该考虑哪一个优先级更高？是花半天时间修复一个已经存在一年的bug，还是把同样的时间完成迭代目标任务以免阻塞进度？
• 组合用户故事
  • 用户故事并非越小越好，对于双周迭代来说，拆解至约2～5天内能完成的用户故事则会比较合适，对于更长时间周期的迭代（一般不建议迭代周期过长，因为随着范围的扩大，迭代的风险叶会随之越高），用户故事可以相对变大一些，重要的是要善于发现并组合相同特性的用户故事，明确迭代的目标和价值。

    3.5 用户故事的排序

    3.4.1 优先级

    根据MoSCoW原则，在系统中使用「优先级」属性来规范迭代内用户故事的优先顺序，该优先级一般由PO最终决策并与团队达成共识，团队需保证PO所需的Must、Should的完成，并力争Could能完成；在发生重要变更的时候，牺牲Could或Should保证变更的影响可控。

3.4.2 优先等级

当迭代中存在多个相同优先级的用户故事时，需通过「优先等级」属性来明确定义当前优先级下的完成/协同顺序，该顺序在遵循「优先级」定义的情况下一般由团队相互协作的成员确定即可，明确短期内协同的统一目标。

优先等级	说明	举例
自然数	- 数字越大，表明优先等级越高 - 该数字只具有相对大小的意义（“100”与“20”只能说明100比20的优先程度更高，无任何其它含义） - 初步定义时，可将各故事之间间隔拉大，以防中途有新的需求插入	当列表中出现3个P2时，由100，99，60确定「优先等级」为100的用户故事在当前优先级中应最优先完成

3.5 用户故事的工作流

用户故事工作流

3.6 属性