优秀的用户故事准则
目标故事：了解使用软件的目的，通过目标衍生故事。例如找工作是一个目标，那么可以拆分为搜索工作，编写简历，投递简历，申请工作等……
切蛋糕方法：面临一个大的故事，采用纵向切蛋糕的方法拆分更小的故事，每个故事都提供某种完整的end to end（闭环） 的功能。例如“求职者可以发布简历”这个故事拆分“求职者可以提交简历，简历包括名字，地址和教育背景这样的基本信息；求职者可以提交简历，简历包括雇主想看到的所有信息。
在编写故事时，更倾向编写一整块完整蛋糕那样功能完整的故事。
编写封闭的故事
一个封闭的故事是指随着一个有意义的目标的实现而结束的故事，让用户觉得使用后能完成某个任务。而不是开放性，比如管理简历就是个开放性的故事；而保存简历，删除简历，更改简历的信息，就是封闭式的故事。好处在于每个故事都是一个闭环，用户会有一定程度成就感。
卡片约束
任何必须遵守而不需要直接实现的故事，设定为约束。如“系统必须要支持最大50个并发用户的峰值”。约束卡片不需要估算，也不会被安排到迭代中，可以作为其他可能关联故事实现时候的提醒。
不要过早的涉及用户界面
项目早期应该对系统设计还没有一个深入设计，很多需求都只是一个构想，如果过早的设计用户界面，那么会将用户界面细节陷入故事。软件设计是个渐进明细的过程，请不要违背这个过程。例如，如果项目刚开始就设计一个“用户可以在搜索界面上从日期部件上选择日期”，那么其实对于开发人员来说是比较困难去开发的，因为在早期软件可能还没有设计搜索和日期相关的功能，尽量不要因为过早设计页面左右了真实需求。软件只有在越来越完整的时候，并且从全新的功能转向修改或扩展现有功能的时候。
在故事中包括用户角色
如果项目已经识别了角色，那么请在故事中使用已经识别的角色。这样可以让用户在开发人员脑子里保持着最重要的位置。例如不要写“用户可以发布简历”，应该描述为“求职者可以发布简历”。这样开发者会联想到实际的，真切的用户，开发出满足用户需求的软件。
只为一个用户编写
当故事只为单一用户编写时，故事的可读性通常是最强的。如“求职者可以删除简历”，应该描述成“求职者可以删除他自己的简历”。从单个用户角度思考问题，会让故事更清晰。
故事发布计划
Must have 必须有(基本功能)
Should have 应该有(很重要但是短期内有可替代解决方法的功能)如果项目时间没有约束，应该有的功能应该是强制性的
Could have 可以有(如果没时间，可以在发布中不考虑的功能)
Won’t have this time 这次不会有(客户期望有，但是承认需要在后续发布中实现的功能)
排列优先级
用户对故事进行优先级排序，一般会从广泛性和重要性开来判断。
如果用户的优先级和开发人员实现的顺序不一样时，应该客户说了算。在确定优先级时，应该先对故事进行估算，这样用户可能重新调整优先级，根据估算大小，评估发布顺序让价值最大化。
迭代计划
讲解故事，澄清问题，优先级排序，任务拆分，任务认领，评估任务是否能完成。
拆分任务
1 实现故事的开发人员一般不是一个人
2 故事拆分为开发人员的待办事项(to do list)时团队透明，团队集体智慧有助于不容易遗忘
3 拆分任务的同时也是一个即时设计短脉冲的过程，这个过程类似瀑布过程的前期设计阶段
4 团队成员自愿认领和执行任务
5 团队围绕共同目标执行迭代，在迭代后期如果有人任务无法完成，团队其他人应用于承担，避免有人任务完成，还有人的任务列表还有待处理的情况。。
用户故事的优势
强调口头沟通，人人都可以理解用户故事，用户故事大小适合做计划和迭代开发。
用户故事鼓励延迟细节，并根据沟通适应随机应变。鼓励参与性设计和传播阴性知识。此部分难以理解，目前我们仍然使用prd记录和描述用户需求，尽可能记录清楚用户诉求自己可能场景和用例。此处和书上描述避免使用过详细的记录相悖论。我们因为部门墙的存在，用户可能没办法和研发团队频繁交流，且反馈环拉的很长。我们产品经理就处于与用户沟通和设计产品的角色，所以大家还是希望产品能将沟通记录和结果记录清晰。
至此，这本书我已经读完了。下个月开始新的学习。
标签：优先级,故事,读书笔记,开发人员,用户,求职者,敏捷,简历 From： https://www.cnblogs.com/joranger/p/17357629.html