自助建站最大,wordpress 阿里大鱼,树莓派wordpress建站,wordpress+标签消失在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中#xff0c;用户故事的划分对于迭代和开发起着举足轻重的作用。 用户故事从其名字来看是站在用户的角度所描述的故事#xff0c;同时也是用户所能看…在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中用户故事的划分对于迭代和开发起着举足轻重的作用。 用户故事从其名字来看是站在用户的角度所描述的故事同时也是用户所能看懂的故事开发人员最容易犯下的一个错误就是站在自己的角度去思考和划分故事这样就背离了用户故事的初衷。   那什么是用户故事首先来说用户故事是对需求的细化和切分既然是细化就得有一个度需求的颗粒度需要多少才能称之为用户故事这就牵扯出和用户故事一起出现的另外一个关键的单词叫史诗故事epic通俗来说就是大型的故事。Epic有一些自身的特点如是由许许多多的较大的不确定的需求large fuzzy  requirements组成另外epics本身具有更低的优先级因为你不能直接通过其完成迭代和开发而是首先需要划分成较小的真正的user-story除了这两点epics因为包含了太多的模糊性需求所以常常混杂了很多不同的特性而一个特性就是一组可以归为一类的需求同时对某一特定的用户存在着交互的价值。   在用户故事的划分中有三要素分别为cardconversation和confirmation。 card 故事描述通过将故事写在note card上面除了故事本身的描述之外还应该包括故事的时间点估计及对应的测试行为等等。   conversation 通过交谈丰富内容用户故事的具体细节不是某一个开发人员或者PO自己拍着脑袋定义出来的而需要项目组中的成员与PO或者客户之间沟通得出的。   confirmation 验收测试能够确认故事已经完成用户故事划分以后是由开发人员通过编码实现但是不能仅靠开发人员自测确认故事完成需要的是一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。   关于用户的编写原则有一个通用的模板用以站在用户的角度描述用户所期望得到的功能 As a role, I want to do something or a piece of functionality, so that achieve some business value or statement of intent.  作为一个角色通过某项操作以便能够完成特定的目标。 在这个模板中有三个不同的点分别为用户角色--who某项操作--what完成的目标--whyreason。 如作为一个国米的球迷通过点击官网的最新新闻栏以便能够实时了解最新的国米动态。   一个良好的User-story的编写应该遵循INVEST原则 Independent独立性 用户故事之间应该具有独立性有点类似于UT中的test case不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级只有被依赖的用户故事完成才能继续开发依赖的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。 Negotiable可协商 用户故事不是签订的商业合同contracts它是由客户或者PO同开发小组的成员共同协商制定的如果最开始像商业合同一样设定了太多的条条框框和限制就无法更好的沟通及协商也就不可能划分出既让客户满意也能让开发认同的好的用户故事。 Valuable有价值 用户故事必须对于最终的用户是有价值的因此应该站在用户的角度去编写描述的是一个一个的feature而非一个一个的task。 Estimable可评估 对于一个用户故事的划分需要足够的领域知识使得在划分i故事之时就能大致了解故事开发的周期为了减少估算的不确定性故事本身不能太大。 Small短小 故事应该尽量的短小当然也不是说越小越好。短小的故事可以减少划分过程中估算的误差最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。 Testable可测试 个人认为这一点在所有的特性中对于用户故事的重要程度最高。首先如果一个用户故事无法进行测试那么也就无法判断该故事是否完成。除此之外对应的验收测试也最好是自动运行的这样在任何时候都能触发该用户故事的检验。最后必须在定义了验收测试通过的标准后才能认为故事划分完毕。 关于Testable有一个较为经典的例子 As  a user, I want to be able to cancel a reservation so that I can get a refund for the trip not taken. 关于此用户故事前面所提到的几个要素whowhatwhy都满足那么验收测试应该如何去做模拟的应该是实际的真正场景如退款是全退还是部分退还提前多久cancel才是有效的退还款项如何与用户之间进行确认等等。 按照刚才的假设做一个真实场景的验收测试用例通过Given-When-Then的方式来设定 Given“我”付款1000RMB预定了一个3周后从成都飞往三亚的航班。 When在航班起飞前一周“我”取消了该行程。 Then“我”应该得到预定机票半价的退款500RMB 在对用户故事设定验收测试的条件时候分别对应starting state---》event---》final state 任何的user story在验收测试的时候都必须至少设定一个defaule scenario。   https://blog.csdn.net/rxr1st/article/details/7479472  转载于:https://www.cnblogs.com/softidea/p/9609996.html