敏捷开发中如何写好用户故事？

什么是用户故事？
用户故事（user story）是一个用来确认用户和用户需求的简短描述，作为什么用户，希望如何，这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。

因此，一个好的用户故事就包括了这三个要素：
1.角色：使用者。
2.功能：需要完成什么样的功能。
3.价值：为什么需要这个功能，这个功能带来什么样的价值。

另外，用户故事还需要遵循3C原则：卡片（Card）、会话（Conversation）和确认（Confirmation），用户故事的3C原则由Ron Jeffries在2001年提出，直到今天仍被奉为用户故事的基本原则。

1.卡片：
用户故事描述的传统形式是手工书写的用户故事卡，卡片上应该只有几句话来捕获需求的精髓或目的。

后来产品经理们通过写需求设计文档或者规格说明书，通过一个非常完整的word文档将某一个产品的需求定义出来。由于产品需求文档涉及到的内容从项目到实现效果，非常庞大，以至于后来的项目管理中出现了摒弃繁杂的需求文档的做法，或将需求文档仅作为一个参考标准。如知名项目管理软件禅道提倡将需求文档中的需求点摘出来，录在禅道的【需求描述】里面，作为一个个独立的功能点。
这其实跟卡片作用是一致的，用简洁凝练的语言，完整呈现用户故事的三要素。

2.会话：
会话指的是卡片上所记录的用户故事是可以进行讨论和细化的，它包括利益相关人（客户/用户）、产品负责人及开发团队之间进行更细化地讨论用户故事的可行性。用户故事经过会话确认后，才能正式进入开发阶段（用户故事实现）。敏捷开发的流程完整体现了用户故事（需求）的流转过程。

以敏捷开发中的Scrum为例：

scrum的基本流程如上图所示：
1.产品负责人负责整理user story，形成左侧的product backlog。 ——用户故事整理
2.发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。 ——用户故事确认
3.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，终每个任务都有明确的负责人，并完成工时的初估计。 ——用户故事分解
4.每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。 ——用户故事实现
5.演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。 ——用户故事的二次整理

敏捷开发中用户故事的细化为开发提供了可执行标准，敏捷开发的特点是快速迭代，一个用户故事的大小和复杂度应该在一个迭代中开发完毕为宜。如果用户故事太大，可能会导致对它的开发横跨几个迭代。，此时就应该将这个用户故事分解。每个任务的时间最好不要超过8小时，就是要保证1个工作日内完成，如果做计划时发现有些任务的时间超过了8小时，就说明任务的划分有问题，需要进行子任务的分解。

3.确认：
用户故事确认可以理解为对用户故事是否达到验收标准的检测。用户故事需要一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。同时要保证这个用户故事最后实现是可以带来商业价值的。

用户故事的确认由测试人员完成。测试人员在测试版本所关联的用例列表里执行用例，完成测试，然后生成测试报告。测试报告是对用户故事实现程度的最直接体现。

如果一个用例执行失败，可以直接由这个测试用例创建一个Bug，由开发人员进行二次开发和修复，直到测试通过。

写好用户故事除了要以3C原则为基础，同时需要考虑到用户故事需要具备的六个特征（也叫INVEST原则）：
Independent：独立性
用户故事之间应该具有独立性，不应该依赖于其他的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
Negotiable：可协商
用户故事是由客户或者PO同开发小组的成员共同协商制定的，用户故事代表了一个用户群体的需求，而这个需求是零散的，通过相关人员的沟通，协商经常可以丰富用户故事。
Valuable：有价值
用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
Estimable：可评估
对于一个用户故事的划分需要足够的领域知识，使得在划分故事之时就能大致了解故事开发的周期，为了减少估算的不确定性，故事本身不能太大。
Small：短小
故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少分解过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。
Testable：可测试
如果一个用户故事无法进行测试，那么也就无法判断该故事是否真的完成。所以，用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。

敏捷开发中如何写好用户故事？相关推荐

【敏捷开发每日一贴】用户故事Userstory
用户故事一.什么是用户故事? 用户故事也是一种常见的需求描述的方法,它从用户的角度来描述用户渴望得到的功能.一个好的用户故事包括三个要素: 1. 角色:谁要使用这个功能. 2. 活动:需要完成什么样 ...
敏捷开发中史诗故事与用户故事的颗粒度
作者:陈勇出处:blog.csdn.net/cheny_com 用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现一直没有定论,只好在这里原创一下. 前言:为何需 ...
敏捷开发中，团队成员认领的是任务还是用户故事？
一次敏捷workshop上,有同学问:"敏捷软件开发中,团队成员自己主动认领的,是用户故事还是被分解成的任务?"同学们一时讨论热烈. 稍具敏捷开发实践经验的同学都应该知道,答案是- ...
敏捷开发中的故事点到底是什么？如何预估故事点？
故事点是敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式.一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度.复杂度包括功能 ...
写好用户故事的10个提示
翻译自 http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/ 总结用户故事可能是在捕获产品功能方面流传最广泛的敏捷实 ...
敏捷开发中QA如何做质量管理？
敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的, ...
[敏捷开发培训] 什么是敏捷开发中的Spike？
什么是敏捷开发中的Spike? Spike,如果需要翻译的话,中文可以翻译成"探针",但是一般不会翻译而直接使用Spike这个词. Spike可以理解为:以回答问题或收集信息为目的 ...
如何编写敏捷开发中的user story
对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务. 优点和好处 Being ve ...
[转]敏捷开发中编写高质量Java代码
本文转自:http://dev.yesky.com/103/11164603.shtml 敏捷开发的理念已经流行了很长的时间,在敏捷开发中的开发迭代阶段中,我们可以通过五个步骤,来有效的提高整个项目的 ...

敏捷开发中如何写好用户故事？

敏捷开发中如何写好用户故事？相关推荐

最新文章

热门文章