敏捷开发之用户故事.pdf

《敏捷开发之用户故事.pdf》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、用户故事用户故事的3CCard,Customer,Commumication用户故事原则——INVEST>Independent-独立的>Negotiable-可商榷的>Valuable-有价值的>Estimable-可估算的>Small-足够小>Testable-可测试的用户故事模版作为“用户”我想“任务”从而实现“商业价值”好的用户故事要回答以下问题：>这个用户故事是为谁所做？（作为X）>需要完成什么任务？（我想做Y）>要实现的业务目标或者商业价值是什么？（因为我可以Z）注意：在最初阶段每个人都理解用户故事的

2、商业价值和目的是超级重要的！（用户故事的终稿阶段就太晚了）好的用户故事用户故事必须以用户和业务的视角>作为信用卡申请的审核员，我想知道申请人的银行流水单，从而为我批准申请提供必要信息描述happypath(最佳场景)从UI入口，到UI出口(垂直切分用户故事)>“记录一个交易记录”或者“在数据库里加一项”都不是用户故事有意识的模糊一些，这样很明显需要更多的必要信息>不会因为信息的不精确和不完整而视为错误有没有限制实现的方法>“我需要Excel格式的报告“不是一个好的故事遵循INVEST原则（independent,

3、negotiable,valuable,estimable,small,testable）每个级别的用户故事精度要一致（master,releaseanditerationlevel）用户故事例子提出一个交易申请>需要从用户和业务角度出发-没人知道这个故事是什么意思，目标是什么？>重写的时候要关注商业价值（有非常多的原因要提出一个交易申请）>专注商业价值可以帮助客户交流和发现很多关联性>专注商业价值可以清楚准确的发现真正的测试场景>专注“我想”后面的任务（我想看以保存的交易）可以发掘更多的验收条件的功能。更改后的

4、结果提出一个交易申请作为一个银行柜员我想浏览交易的细节这样我可以回答客户提出的问题独立的用户故事必须是独立的用户故事可以有和其它故事的接口或者依赖，但是作为故事本身，我们需要把他描述成独立的。如果故事不能独立，就要合并，或者如果某些故事会阻碍其它的用户故事在一个迭代内完成最好将他们分解作为写用户故事的指导，故事可以围绕“一个任务”而有一定独立性，并且提同可测性独立的不好的Story写法从账单库里获取账单信息好的Story写法作为客户代表，我想创建一个账单，从而客户可以给公司付款解释“从账单库里获取账单信息”不够独

5、立。客户代真正需要的是一个打印出来的账单，这样他可以邮寄给客户。可以将‘打印账单’与这个story合并。如果将数据取出，打印一个迭代做不完的活，可以进行垂直划分。将取得账单一部分信息并打印作为一个story，然后得取得另一部分信息并打印作为另外一个story，直到可以取得所有信息并打印完成。永远也不要平行的划分用户故事(例如:数据库存数据，从数据库取数据）。原因有很多，但是最重要的是story必须有商业价值，并且可以独立的交付或者展示。可商榷的Sotries是可商榷的用户故事可商榷可以让需求更灵活。简洁勿需精确。

6、用户故事细节的讨论空间可以让分析师，开发，客户共同讨论，从而消除僵化-进而了解Story真正的意图？用户故事如果过于精确会给人一种不合理的感觉-例如，如果细节过多会让开发觉得我只需要做成这样。这种情况下违背了用户故事3C原则，Cibversation，用户故事是一个用来建立沟通的工具。可商榷的不好的Story写法>显示一个患者的检查结果，包括时间，状态和是否正常。好的Storyp写法>作为一名内科医生，我想要看到患者的检查结果，从而快速的了解结果是否正常。>注意：具体要显示的信息或许需要更多分析。需要包括时间，结

7、果状态，是否正常。解释反例其实看起来也不错。当拿到这个Story的时候，我们会感觉这个Story可以进入开发状态了。但是事实上在真实的项目中并非如此。这个Story其实需要显示更多的信息。并且这些信息还需要一些额外的分析。这个Story在真实的项目中由于被返工了两次而做了3个迭代。不要写过多的细节，可以更好的利用Notes。并且说明story本身可能还需要更多细节。有价值的Stories必须有商业价值用户故事必须以交付商业价值为目的-通常是需要实现一个业务目标，解决一个问题，并且是任务驱动的。（比如允许客户在网上

8、订购一个产品）。商业价值是相对的，story的商业价值或大或小。从下面的例子可以看出我们说的商业价值是交付的价值。不应该专注story是做什么，而是什么。有价值的不好的story写法>当延误付款的时候将字体变红。好的story写法>作为一个客户经理，我想要看到客户过期付款的记录上有可视化的提醒，从而我可以提醒客户付款。解释反例有很多问题。其中一点就是我们并不知道谁需要字体