用户户故事与估算 geeksun用户户故事用户故事（User Story）是从用户角度对功能的简要描述格式：作为一个，可以，以便于需要执行什么操作？完成操作后带来什么好处？谁要使用这个功能？用户户故事3独立性：尽可能避免故事之间存在依赖关系，否则会产生优先级和规划问题可协商：故事是可协商的，不是必须实现 的书面合同或者需求有价值：确保每个故事对客户或者用户有价值的，最好是让用户编 写故事可估算：开发者应该 能够预测 故事的规模，以及编码实现 所需要的时间 短小的：故事尽量短小，最好不超过10个理想人天，至少在一个迭代中完成可测试 ：所编写的故事必须是可测试 的用户户故事4顾客可以使用信用卡购买购 物车中的商品 注释：接受Visa、 Master和American Express信用卡用 Visa、MasterCard和American Express进行测试 （通过）用 Visa借记卡测试（通过）用 Diners Club（大莱卡）测试（失败）用正确的、错误 的和空的卡号测试用过期的卡测试用不同限额的卡测试 （包括超出银行卡的限额）用户户故事5作为一个玩家，可以通过显 示排名， 让自己在服务器中的地位获得认可。
作为一个排名靠前的付费玩家，可 以通过显 示排名，让自己在服务器 中的地位获得认可（以刺激消费）系统每周重新排名一次，而且只显示前XXX名玩家 激发玩家“斗志”，鼓励购买 道具； 实现 有技术问题 ：实时查 看不现实 ； 小玩家对自己的排名不太关心，不会为了提升排 名去购买 道具，只有少数顶级 大佬才会受此蛊惑用户户故事类类型作为一名维基用户，我希望上传一个文件到 维基，以便可以和同事进行分享作为一名客服代表，我希望为客户问题创 建 一个记录 卡，以便记录 和管理客户支持请求作为一名网站管理员，我想要统计 每天有多 少人访问 了网站，以便赞助商了解这个网站 会给他们带 来什么收益用户户故事类类型系统必须支持IE8、IE9、Safari5、Firefox7 和Chrome15浏览器作为开发人员，我想为新的过滤 引擎做两个 参考原型，以便知道哪一个更合适 两个原型要执行性能测试、规模测试和类型测试 编写简短的备忘录以描述试验、结果和建议用户户故事类类型系统必须支持IE8、IE9、Safari5、Firefox7 和Chrome15浏览器作为开发人员，我想为新的过滤 引擎做两个 参考原型，以便知道哪一个更合适。
修复缺陷跟踪系统的缺陷#256，这样可以使 客户在搜索项中输入特殊字符不会出现异常产产品订单订单高优先级产品订单（粗粒度功能）迭代订单（细粒度功能/任务）增量功能产品负责人开发团队迭代计划会议优先级名称用户故事描述估算1浏览商品作为一名顾客想购买 商品而不确定型号时，我希望能浏览 网站在售的 商品，按照商品类型和价格范围进行过滤2搜索商品作为一名顾客在查找某种商品时，我希望能进行不限格式的文本搜索 例如按照短语或关键字3注册账户作为一名新顾客，我希望注册并设置一个帐户 ，包括用户名、密码 信用卡和送货信息等4维护购 物车作为一名顾客，我希望能将指定商品放入购物车（稍后购买 ）、查看 我的购物车内的商品以及移除我不想要的物品5结账作为一名顾客，我希望能完成我购物车内所有商品的购买过 程6编辑商品规格作为一名工作人员，我希望能够添加和编辑 在售商品的详细 信息（包 括介绍、规格说明、价格等）7查看订单作为一名工作人员，我希望能登录并查看一段时间 内应该 完成或已经 完成的所有订单敏捷估算订单条目工作量版本1估算值总和估算总值 平均速率 = 迭代数量平均速率敏捷估算它是一个相对度量单位使用时，可以给每个故事分配一个 点值；点值本身并不重要，重要的是点值的相对大小。
它是一个绝对 度量单位理想时间 是某件事在剔除所有外围 活动以后所需的时间 ；一般为一天有效工作时间 的 6080% 比较合理，但绝不会是全部故事点理想时间敏捷估算：理想时间时间估算方法：团队查 看每个故事，针对 前面介绍的复杂性要素讨论 故事，然后估计要 用多少理想时间 可以完成该故事这种方式是人们平时习惯 使用的，容易理解和使用人天生不擅长做绝对 估计，很难达成共识不同人的理想时间 估算是不同的，因每个人的能力 和认识 的不同而不同每个人的理想时间 是不一样的，这种估算不能相加， 由此产生的计划肯定是不准确的敏捷估算：故事点故事点的基本做法：给一些简单 的“标准故事”设定一个“标准点数”，形成比较基线；其他故事与标准故事进行比较，给出一个相对的比例，得到该故事的一个估计值使用难点：故事点的项目或产品特征很明显，几乎无法进行跨团队 比较；如果没有历史数据，很难设 定标准故事优先级名称用户故事描述故事点1浏览商品作为一名顾客想购买 商品而不确定型号时，我希望能浏览 网站在售的 商品，按照商品类型和价格范围进行过滤22搜索商品作为一名顾客在查找某种商品时，我希望能进行不限格式的文本搜索 例如按照短语或关键字。
53注册账户作为一名新顾客，我希望注册并设置一个帐户 ，包括用户名、密码 信用卡和送货信息等14维护购 物车作为一名顾客，我希望能将指定商品放入购物车（稍后购买 ）、查看 我的购物车内的商品以及移除我不想要的物品35结账作为一名顾客，我希望能完成我购物车内所有商品的购买过 程86编辑商品规格作为一名工作人员，我希望能够添加和编辑 在售商品的详细 信息（包 括介绍、规格说明、价格等）37查看订单作为一名工作人员，我希望能登录并查看一段时间 内应该 完成或已经 完成的所有订单2敏捷估算估算原则：开发团队 一起估算，产品负责 人和Scrum主管不参与实际 估算估算产品负责人阐述和澄清指导和引导开发团队Scrum主管敏捷估算估算不是承诺，不应因其他因素而人工放大，成为团队 与管理层之间的抛球游戏最初的估算修改后基于承诺的估算敏捷估算工作量准确度足够好有害而且浪费准确与精确：估算应该 准确但不必过分精确，过于精确的估算是浪费收益递减敏捷估算应该 使用相对大小而不是绝对 大小进行估算，因为人们更擅长相对的估算1倍4倍9倍敏捷估算扑克 估算扑克是一种基于共识的估算工作量的技术 估算扑克牌的数值范围，由团队 决定 有些牌是自然数排列 有些是斐波纳契数 有些则是不连续 自然数，例如2的幂敏捷估算扑克本质上是扑克牌，它基于Delphi估算原理，可以快速地估算出需要的数字。
图片来源 http:/敏捷估算扑克敏捷扑克和普通游戏扑克一样，有54张牌，拥有4种花色（每种各13张）和两张Joker估算扑克牌正面上印刷有供估算用的数字与符号0 代表条目已完成或太小没有估算意义1/2 代表微小条目，1, 2, 3 代表小条目5, 8, 13 代表中等大小条目20, 40 代表大的条目，100 代表非常大的条目？代表对条目不理解或不知道如何估算分牌：每名参与估算的成员分得相同花色的一组牌，两张Joker不参与估算敏捷估算扑克讲解订单 故事：产品负责 人从Backlog中选择 一个条目，为大家详细讲 解该条目； 团队 成员进 行讨论 并提问，产品负责 人逐一解答大家的问题 敏捷估算扑克估算：当团队 成员确认已经对该 条目完全了解且无任何重大问题 后，大家开始进 行估算，同时选 出代表自己估算值的纸牌，在所有成员选 牌完毕后大家同时亮牌敏捷估算扑克争论与讨论 ：若每张牌估算值差距明显，代表大家 对该 条目没有获得共识，需要对评 估结果进行讨论VS共识：对该 条目重新进行估算，直到团队 的评估 数值达成一致一般情况下，最多三轮就可以得出一个比较 统一的意见；如果三轮之后依然没有得到统 一的意见，那么Scrum主管应立即中断估算， 取平均值或其他大家接受的值作为估算结果。
谢谢谢谢 大家！THANKS。