产品：详解史诗、用户故事、拆分、验收标准、待办事项、用时预测、故事卡
目录
- 一、史诗（Epics）
- 二、拆分 (break down )：史诗-用户故事
- 三、验收标准（Acceptance Criteria）
- 四、待办事项列表（Backlog）
- 1. 优先级（Prioritisation）：
- 2. MosCow Rules
- 五、用时预测（Estimating）
- 六、故事卡(Story Cards)
一、史诗（Epics）
一般来说，大型的用户故事（user stories）叫做史诗（Epics）。
一般格式：
As a(作为 )…
I want(我希望)…
So that(这样以便)…
（用户故事-史诗）
分解开来，描述一个产品预期的功能需要从很多方面来展开，因而用户故事需要在不同的细节层次上编写，而史诗就类似这些细节层次的用户故事体现出来的集合。
（史诗-用户故事）
史诗级项目通常太大，敏捷团队无法在一次迭代中完成，所以在开发之前会被分解成多个更小的用户故事。
二、拆分 (break down )：史诗-用户故事
将史诗根据实际和想象进行细化的一个过程，分解成多个用户故事(一般不超过5行)。
拆分原则：提取出来的故事比原始史诗小。
材料上给的例子如下：
Epic：
作为一个用户,
我想备份我的整个硬盘
这样我就不会失去任何工作。
break down story 1:
作为一个超级用户，
我要根据文件大小、创建日期和修改日期指定要备份的文件或文件夹
以便我能更好地管理这些文件。
break down story 2:
作为一个用户,
我想指出文件夹不备份
这样我的备用硬盘就不会装满我不需要的东西。
break down story 3:
作为一个忙碌的管理者，
我希望我保存的搜索名默认为城市名，除非我选择手动覆盖它
这样我就可以简化我的搜索。
break down story 4:
作为一个忙碌的管理者，
我希望用户界面上的“保存收藏”选项显示在“搜索位置”附近的移动设备上
这样我就可以选择开始一个新的搜索或者使用一个保存的搜索，并且可以在天气应用程序中减少我的按键。
—> 说实话，我觉得扯挺远的，例子中但凡跟“管理文件”沾边都算是一个合理的分解。所以个人的感觉就是，先把the key word关键词找出来，保证比史诗更小更详细地围绕关键词拓展即可。
第一句：是对角色的拓展和遐想，原理就是“通过关注一个特定的用户角色或画像来提取一个更小的故事。例如：“第一次用户”、“社交网络工作者”、“我妈妈”等等。”
第二句：首先让他工作起来，然后细化到某个功能，以此满足第一句中指定用户的需求。
第三句：结果
拆分方法有一篇文章写的挺好的，可以看看，粘贴如下：
把史诗（Epic）拆分成用户故事（UserStory）的15种方法 -简书
1、通过关注一个特定的用户角色或画像来提取一个更小的故事。(“优先考虑你的用户，然后才是你的用户故事。——杰夫巴顿）例如：“第一次用户”、“社交网络工作者”、“我妈妈”等等。
2、通过替换可用性基本效用来提取更小的故事。(首先让它工作，然后让它变得漂亮。)
3、通过分解CRUD（创建、读取、更新、删除）边界来提取一个更小的故事。
4、通过关注不同的场景来提取一个更小的故事，例如“快乐路径”(主要成功场景)和替代(异常)流。
5、通过聚焦于一个简化的数据集来提取一个更小的故事。
6、通过关注一个简化的算法来提取一个更小的故事。
7、通过购买一些组件而不是自己构建所有组件来提取一个更小的故事。
8、通过丢弃那些增加麻烦、依赖和供应商锁的技术来提取一个更小的故事。
9、通过用一些手工过程代替完全自动化来提取一个更小的故事。
10、通过将批处理替换为在线处理，提取一个更小的故事。
11、通过用通用名替换custom来提取一个更小的故事。
12、通过减少支持的硬件/操作系统/客户端平台来提取更小的故事。
13、从另一个故事的接受标准中提取一个较小的故事。
14、用“1”代替“all”，提炼出一个更小的故事。(注意:寻找“all”的隐含实例，因为这个词通常不会被明确地写出来。)
15、通过扫描关键字(如“和”、“或”、“句点”和其他类型的分隔符)来提取一个较小的故事。
作者：RichardCook
三、验收标准（Acceptance Criteria）
- 在用户故事完成之后，验收标准是一个更高层次的测试；同时，也可以帮助开发团队理解用户的需求，进一步协商确定业务价值。
- 一般写在故事卡的背面。
怎样算一个好的验收标准：
1.说明一个意图（而不是一个解决方案）
2.与具体实现方案无关（不论故事是基于安卓、iOS、还是网页、basic GUI，在陈述上都是一致的）
3.都是从较高层次出发，即“相对宏观的”（而不是过于强调细节）
举例一：
User Story：
作为营销副总裁，
我想选择一个 假期 来回顾过去广告活动的表现
这样我就可以确定哪些是有利可图的。
Acceptance Criteria：
•确保它适用于主要零售节日:圣诞节、复活节、母亲节、父亲节、元旦。【解释“假期”】
•假日季节可以设置为假期前的几天。【解释“假期”2】
•假日季节可以从一个节日设置到下一个节日(如圣诞节到元旦)。 【时间】
举例二：
User Story：
作为网上银行客户
我想看到我的日常账户的滚动余额
这样我就知道每笔交易后我的账户余额是多少了
Acceptance Criteria：
•滚动平衡显示 【“余额”展现设想】
•如果应用了筛选器，则不显示余额 【“余额”展现设想2】
•滚动余额是为每笔交易计算的 【“余额”解释】
•在可用事务的整个时间段内，将显示每个事务的余额 【时间】
—> 可以看到，如果用户故事的关键词明显，提取出关键词，然后围绕它的解释、展示设想、目的都是可行的验收标准；除此之外，时间也可以作为一个通用的度量标准。
在评价标准方面，也有写的比较好的文章，可以看看：
ACCEPTANCE CRITERIA FOR USER STORIES - cnblogs
四、待办事项列表（Backlog）
是产品或服务中要开发的功能的优先级列表。
1. 优先级（Prioritisation）：
-基于业务价值
-价值还必须得到投资回报(ROI)的支持
-考虑风险
资料中给了一个很好的表示优先级的动态过程：
2. MosCow Rules
1⃣️本质
DSDM(动态系统开发方法)支持的一种优先级划分方法。
2⃣️四大要素：
1）必须有: 功能必须实现，如果没有，系统将无法工作。
2）应该有: 功能是重要的，但可以省略，如果时间或资源限制出现。
3）可能有: 功能增强系统与更大的功能，但其交付的时间表不是关键。
4）想要: 功能只服务于有限的用户群体，不像前面的项目一样驱动相同的业务价值。
3⃣️举例：
在针对支付方式的story中：
-must have: 能够接受Visa和MasterCard。
-should have: 添加加American Express。
-could have: 添加PayPal
-want to have: 添加Gift Card
五、用时预测（Estimating）
在产品开发的需求明确以后，团队需要给出一个初步的预计完成时间，以此确定交付期限。
确定用时需要考虑的因素包括：
1）工作量的大小
2）理想时间
3）实际时间
4）根据其他度量标准判断出来的工作量大小
六、故事卡(Story Cards)
一般用于记录用户需求。课件材料上给的一般格式模板，截图放上来，对理解有些帮助。
#正面：
#反面：
