标签：style blog http os 使用 io strong ar 文件
本文是今年1月份参加Agile1001公开课后，并参考《用户故事与敏捷方法》这本书整理，阅读全文
用户故事是描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。
用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。一个好的用户故事包括三个要素：
当故事非常大时，我们将很难对它进行估计。如果故事预计在N次迭代后才进行，那么大的故事很正常。但如果估计预计在接下来的迭代中进行，那么我们就可能会对大的故事进行拆分。很大的故事基本上都能进行拆分，只要确定每个小故事都可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
分割用户故事：
1、按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文件、Excel等）。
2、从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小许多。
3、按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和删除操作（例如预算二次导入，或者新增时需要向导、规则而比较复杂时也可以单独成一个故事来描述）。
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、故事评估一般采用故事点来进行这类初始评估，可以通过扑克牌来进行。
标签：style blog http os 使用 io strong ar 文件
原文地址：http://www.cnblogs.com/jetlian/p/3946359.html
