本文是今年1月份参加Agile1001公开课后，并参考《用户故事与敏捷方法》这本书整理，阅读全文
用户故事是描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。
用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。 2.功能：需要完成什么样的功能。 3.价值：为什么需要这个功能，这个功能带来什么样的价值。 用户故事通常按照如下的格式来表达： 英文：As a <Role>, I want to <Activity>, so that <Business Value>. 中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值> 举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。 由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认（Confirmation）：通过验收测试确认用户故事被正确完成。
? 独立的（Independent）：我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
? 可讨论的（Negotiable）：故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
? 对用户或客户有价值的（Valuable）：用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
? 可估算的（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
? 小的（Small）：一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
? 可测试的（Testable）：故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。
当故事非常大时，我们将很难对它进行估计。如果故事预计在N次迭代后才进行，那么大的故事很正常。但如果估计预计在接下来的迭代中进行，那么我们就可能会对大的故事进行拆分。很大的故事基本上都能进行拆分，只要确定每个小故事都可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
分割用户故事：
1、按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文件、Excel等）。
2、从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小许多。
3、按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和caozuo.html" target="_blank">删除操作（例如预算二次导入，或者新增时需要向导、规则而比较复杂时也可以单独成一个故事来描述）。
4、考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持。
5、考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型用户故事（性能）。
在拆分故事时，我们有时也需要考虑组合故事的场景，如把bug列入产品backlog时，可以把多个类似的bug组合成一个故事。
最简单的方法就是问问客户最希望在下一个迭代中最想看到的是哪一些功能。从考虑的因素来看，我们可以从以下4个因素来考虑：
1、获取这些功能带来的经济价值，价值越高的优先级越高。
2、开发成本带来的影响。例如可能2个月后由于使用新技术只需要2周，而现在做需要2个月，这时可以考虑把优先级放低一些。
3、获取新知识的重要性。在开发中会不断的产生一些项目和产品的新知识，及早了解和开发这些新知识可以减少不确定性，所以这类功能优先级会高些。
4、故事之间会存在依赖关系，这时候被依赖的优先级会更高，需要先完成。
5、开发这些功能所减少的风险。在开发过程中，会出现进度风险、成本风险、技术风险等，对于风险越高价值越大的我们需要首先处理，对风险高价值低的要尽量避免，可以通过以下图查看确定功能优先级时综合考虑风险和价值的关系。
对每个故事进行初始估计后就可以知道项目的规模。一般采用故事点来进行这类初始评估，可以通过扑克牌来进行，扑克牌点数一般有0、1/2、1、2、3、5、8、13、20、40、100、？、咖啡。首先由产品负责人对product backlog进行讲解，然后由Scrum master负责协调进行初始评估工作。敏捷估算中不是要估计绝对的时间，而是尽量确保故事之间的相对估计是准确的。由于估计是相对的，所以需要首先找打 一个基准，我们可以先找一个不是最小的，也不是最大的来作为一个基准，可以先找出一个大家认为适合分配为2点的故事。在找2点的故事时，很可能会出现大家 意见不一致的情况，这时就需要大家都分别说明自己的见解后再重新找。有了2点基准后，就可以对每个故事进行评估了，而后面的故事都可以基于以前的故事来进 行相对估计了。在估计过程中，有可能会出现大家对故事理解不一致，这时就需要返回去修改故事，确保大家理解一致。
优秀用户故事的一些准则：
1.试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下；
2.不要让故事过早涉及用户界面；
3.实际编写故事时，要包括用户角色；
4.用主动语态编写故事；
5.为单个用户编写故事；
6.让客户编写故事，而不是开发人员；
7.用户故事要简短，它们只是提醒开发人员和客户进行对话；
8.不要给故事卡添加编号。
1、用户故事是描述对用户有价值的功能，用户故事应该包括角色、功能和商业价值三个要素。
2、优秀的故事应该具备六个特征：独立的、可讨论的、 对用户有价值的、可估算的、小的、可测试的
3、当故事非常大时，我们将很难对它进行估计，有必要进行故事拆分
4、故事优先级评定，最简单的方法就是问问客户最希望在下一个迭代中最想看到哪些功能。
5、故事评估一般采用故事点来进行这类初始评估，可以通过扑克牌来进行。
相关文章
