敏捷开发之用户故事.pdf

用户故事 用户故事的3C Card,Customer,Commumication 用户故事原则——INVEST Independent-独立的 Negotiable-可商榷的 Valuable-有价值的 Estimable-可估算的 Small-足够小 Testable-可测试的 用户故事模版 作为“用户” 我想“任务” 从而实现“商业价值” 好的用户故事要回答以下问题： 这个用户故事是为谁所做？（作为X ） 需要完成什么任务？（我想做Y ） 要实现的业务目标或者商业价值是什么？（因为我可以Z ） 注意：在最初阶段每个人都理解用户故事的商业价值和目的是超级重要的！ （用户故事的终稿阶段就太晚了） 好的用户故事 用户故事必须以用户和业务的视角 作为信用卡申请的审核员，我想知道申请人的银行流水单，从而为我批准申请提 供必要信息 描述happy path(最佳场景) 从UI入口，到UI出口(垂直切分用户故事) “记录一个交易记录”或者“在数据库里加一项”都不是用户故事 有意识的模糊一些，这样很明显需要更多的必要信息 不会因为信息的不精确和不完整而视为错误 有没有限制实现的方法 “我需要Excel格式的报告“不是一个好的故事 遵循INVEST原则（independent,negotiable,valuable,estimable,small,testable ） 每个级别的用户故事精度要一致（master,release and iteration level ） 用户故事例子 提出一个交易申请 需要从用户和业务角度出发-没人知道这个故事是什么意思，目标 是什么？ 重写的时候要关注商业价值（有非常多的原因要提出一个交易申 请） 专注商业价值可以帮助客户交流和发现很多关联性 专注商业价值可以清楚准确的发现真正的测试场景 专注“我想”后面的任务（我想看以保存的交易）可以发掘更多的 验收条件的功能。 更改后的结果 提出一个交易申请 作为一个银行柜员 我想浏览交易的细节 这样我可以回答客户提出的问题 独立的 用户故事必须是独立的 用户故事可以有和其它故事的接口或者依赖，但是作为故事本身，我 们需要把他描述成独立的。 如果故事不能独立，就要合并，或者如果某些故事会阻碍其它的用户 故事在一个迭代内完成最好将他们分解 作为写用户故事的指导，故事可以围绕“一个任务”而有一定独立性， 并且提同可测性 独立的 不好的Story写法 从账单库里获取账单信息 好的Story写法 作为客户代表，我想创建一个账单，从而客户可以给公司付款 解释 “从账单库里获取账单信息”不够独立。客户代真正需要的是一个打印出来的账单，这 样他可以邮寄给客户。可以将‘打印账单’与这个story合并。如果将数据取出，打印 一个迭代做不完的活，可以进行垂直划分。将取得账单一部分信息并打印作为一 个story，然后得取得另一部分信息并打印作为另外一个story，直到可以取得所有 信息并打印完成。 永远也不要平行的划分用户故事(例如:数据库存数据，从数据库取数据）。原 因有很多，但是最重要的是story必须有商业价值，并且可以独立的交付或者 展示。 可商榷的 Sotries是可商榷的 用户故事可商榷可以让需求更灵活。简洁勿需精确。 用户故事细节的讨论空间可以让分析师，开发，客户共