用户故事_用户故事地图 - CSDN
  • 敏捷开发中如何写好用户故事

    万次阅读 2018-08-21 14:04:04
    什么是用户故事用户故事(user story)是一个用来确认用户和用户需求的简短描述,作为什么用户,希望如何,这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为:作为一个&...

    什么是用户故事?
    用户故事(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:可测试
    如果一个用户故事无法进行测试,那么也就无法判断该故事是否真的完成。所以,用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。

    展开全文
  • 用户故事示例

    2020-07-30 23:31:50
    适用于软件工程课程编写用户故事时使用此示例,完整的描述用户故事
  • 敏捷需求描述:用户故事

    千次阅读 2019-02-12 11:11:38
    用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。 什么是用户故事用户故事是从希望新功能的人(通常是系统的用户...

    用户故事是敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。

    什么是用户故事?

    用户故事是从希望新功能的人(通常是系统的用户或客户)的角度讲述的功能的简短描述。它们通常遵循一个简单的模板:

    作为<用户类型 (Type of User) >,我想<某个目标 (Some Objective) >以便<某些原因 (Benefit) >。

    As a < type of user >, I want < some goal > so that < some reason >.

    ç¨æ·æäºçåçæå°çµæ

    用户故事通常写在索引卡片或便利贴上,存放在鞋盒中,并安排在墙壁或桌子上,以便于规划和讨论。因此,他们强烈地将重点从撰写有关功能的内容转移到讨论它们。事实上,这些讨论比任何文字都要重要。

    你能展示一些用户故事的例子吗?

    敏捷用户故事的一个好处是它们可以以不同的细节级别编写。我们可以编写用户故事来涵盖大量功能。这些大型用户故事通常被称为史诗。以下是来自桌面备份产品的史诗敏捷用户故事示例:

    • 作为用户,我可以备份整个硬盘。
    • As a user, I can backup my entire hard drive.

    ç¨æ·æäºçåçæå°çµæ

    由于史诗对于敏捷团队来说通常太大而无法在一次迭代中完成,因此在处理之前会将其拆分为多个较小的用户故事。上面的史诗可以分成几十个(或可能是数百个),包括这两个:

    • 作为高级用户,我可以根据文件大小,创建日期和修改日期指定要备份的文件或文件夹。
    • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
    • 作为用户,我可以指示不备份文件夹,以便我的备份驱动器没有填满我不需要保存的内容。
    • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

    如何将细节添加到用户故事中?

    可以通过两种方式将详细信息添加到用户故事中:

    • 通过将用户故事分成多个较小的用户故事。
    • 通过添加“满意的条件”。

    当一个相对较大的故事被分成多个较小的敏捷用户故事时,很自然地会假设已经添加了细节。毕竟,已经写了更多。

    满意的条件只是一个高级别的验收测试,在敏捷用户故事完成后才会成立。请将以下内容视为另一个敏捷用户故事示例:

    作为营销副总裁,我想在审查过去广告活动的表现时选择一个假日季节,以便我可以识别有利可图的季节。

    通过添加以下满意条件,可以将详细信息添加到该用户故事示例中:

    • 确保它适用于主要的零售假期:圣诞节,复活节,总统日,母亲节,父亲节,劳动节,新年。
    • 支持跨越两个日历年的假期(无跨越三年)。
    • 假日季节可以从一个假期到下一个假期(例如感恩节到圣诞节)。
    • 假日季节可以设定为假期前的几天。

    谁写用户故事?

    product owner user storiesçåçæå°çµæ

    任何人都可以写用户故事。产品所有者 (Product Owner)有责任确保存在敏捷用户故事的产品积压 (Product Backlog),但这并不意味着产品所有者是编写它们的人。在一个好的敏捷项目的过程中,您应该期望每个团队成员编写用户故事示例。

    另外,请注意,撰写用户故事的人远不如参与讨论的人重要。

    什么时候写用户故事?

    用户故事是在整个敏捷项目中编写的。通常在敏捷项目开始时举办故事写作研讨会。团队中的每个人都参与创建产品待办事项的目标,该产品待办事项完整地描述了在项目过程中添加的功能或其中的三到六个月的发布周期。

    其中一些敏捷的用户故事无疑将成为史诗。Epics稍后会被分解成更小的故事,更容易融入到单个迭代中。此外,新故事可以随时由任何人编写并添加到产品待办事项中。

    用户故事是否取代了需求文档?

    敏捷项目,尤其是Scrum项目,使用产品待办事项,这是在产品或服务中开发的功能的优先列表。虽然产品积压项目可以是团队所需的任何内容,但用户故事已成为最佳和最流行的产品积压项目形式。

    虽然产品积压工作可以被视为传统项目需求文档的替代, 但在有关该故事的讨论发生之前, 重要的是要记住, 敏捷用户情景的书面部分 ("作为用户, 我希望......") 是不完整的。

    通常最好将书面部分视为指向实际要求的指针。用户故事可以指向描绘工作流程的图表,显示如何执行计算的电子表格,或产品所有者或团队所需的任何其他工件。

     


    Agile Software Development

    scrum 文章集合

    展开全文
  • 在你撰写用户故事或列出待办事项清单时,有两个问题很重要:用户故事够完整吗?你如何才能知道自己已经完成了任务?比如,我们看一看斯托尔写的用户故事:“作为特种部队的医生,我必须为学生们传授基本的生理学知识...

    在你撰写用户故事或列出待办事项清单时,有两个问题很重要:用户故事够完整吗?你如何才能知道自己已经完成了任务?

    比如,我们看一看斯托尔写的用户故事:“作为特种部队的医生,我必须为学生们传授基本的生理学知识,这样他们才能了解人体。”

    关于一则用户故事是否完整,我经常用一套标准来衡量。这套标准是比尔·韦克(Bill Wake)发明的。他认为,一个好的用户故事应该满足 INVEST 标准:

      • 可协商性Negotiable)——用户故事的内容要是可以协商的,用户故事不是合同。一张用户故事卡片上只是一个简短的描述,不包括太多的细节。具体的细节在沟通阶段提出。如果一张用户故事卡片带有太多的细节,实际上会限制和用户的沟通。
      • 有价值Valuable)——每个用户故事必须对客户具有价值。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事,并不是一个契约,而且可以进行协商的时候,他们将非常乐意写下故事。
      • 可评估Estimable)——开发团队需要衡量用户故事,以便确定优先级和工作量,并便于安排工作计划。
      • 规模小Small)——一个好的故事要尽量维持小规模,至少要确保在一个Sprint周期中能够完成。用户故事越大,在安排计划、工作量评估等方面的风险就会越大。
      • 可测试Testable)——一个用户故事要可以测试,以便确定它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。

    斯托尔的故事是独立的,因为他的学生们就在老挝,他不必考虑学生们前往老挝所需的直升机燃油费之类的事情,他能够独立完成任务。

    他的故事是可修改的,因为虽然他一开始打算为学生们传授基本的生理学知识,但如果他到了那里之后发现学生们已经具备这样的知识,或是已经有了一定的了解,那么他有其他的教学方法可以用。他的故事有价值:学生们学到人体知识之后,可以派得上用场。他的故事规模小:他只给学生们传授基本的解剖学知识,而不是教他们运用这些知识去开展外科手术。他的故事可测试:他很清楚自己想要传递的信息,也可以对学生开展一些小的测试,以便确认他们是否真的吸收了这些信息。

    每个有待落实的用户故事都应该要有“完整”的定义(比如是否符合INVEST标准),同样,最后的结果也要符合“完成的定义”(比如必须符合什么条件、通过什么测试才能结束等)。在现实中,我们发现,如果用户故事足够完整,那么团队在落实项目的过程中速度就会加快一倍。此外,如果一个阶段的Sprint完成了相应的用户故事,那么,这个团队的速度会再次加快一倍。这就是我们能够达到事半功倍之效的一个原因。

    来源:《敏捷革命:提升个人创造力与企业效率的全新协作模式》  【美】Jeff Sutherland  Scrum之父作品

    该书的PDF版本我有上传,如需要可自行下载。

    不要盲目执行任务,要领会用户故事(如何写用户故事1)

    用户故事宜短不宜长(如何写用户故事2)

    展开全文
  • 敏捷:什么是用户故事(User Story)

    万次阅读 2018-05-30 10:51:17
    这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧:如何以用户故事管理项目. 什么是用户故事(user story) 假定这个项目的客户是个饮料自动售货机的制造商。他们要求...

    摘要:

        一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧:如何以用户故事管理项目.

    什么是用户故事(user story)

        假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

        因此,我们的客户就是他们的市场经理。谈需求的时候,有一回他这样说:“用户往售货机每塞一个硬币,售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时,代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮,售货机就放一罐饮料到出口,然后找零钱给他。”

        上面的话描述的是一件事情,一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说,上面我们的客户所说的话,就是在描述一个用户故事(user story)。
        (我解释一下为什么用故事这个词,没兴趣也可以忽略。在一个系统面前,每个用户要完成同样的目标,都要做这个系统设定的例行的事,这件事情不是一个例子,所以不叫事例,这也不是故事,也不能算一段历程,而是一个例行的事。)

        如果我们想要记下这段用户故事,我们可能会用这样的格式:

        名称:卖饮料

        事件:

        1. 用户投入一些钱。

        2. 售货机显示用户已经投了多少钱。

        3. 如果投入的钱足够买某种饮料,这种饮料对应的按钮的灯就会亮。

        4. 用户按了某个亮了的按钮。

        5. 售货机卖出一罐饮料给他。

        6. 售货机找零钱给他。

        注意到,一个用户故事里面的事件可以这样描述:

        1. 用户做XX。

        2. 系统做YY。

        3. 用户做ZZ。

        4. 系统做TT。

        5.  ...

    用户故事只是描述系统的外在行为

        一个用户故事只是以客户能够明白的方式,描述了一个系统的外在行为,它完全忽略了系统的内部动作。比如,下面有下划线的那些文字,就属于不应该出现在用户故事中的系统内部动作:

        1. 用户投入一些钱。

        2. 售货机将塞进来的钱存在钱箱里,然后发送一条命令给屏幕,屏幕显示目前已经投入的金额。

        3. 售货机查询数据库里面所有饮料的价格,判定钱足够买哪些饮料,对于钱足够买的那些饮料,对应的按钮的灯就会亮起来。

        4. 用户按下一个亮起来的按钮。

        5. 售货机卖出一罐饮料给用户,然后将数据库里面该饮料的存货数量减1。

        6. 售货机找零钱给用户。

        不管是口头描述的,还是书面形式,这样的内容是描述用户故事时一个很常见的错误。特别的,千万不要提及任何有关数据库,记录,字段之类的对客户一点意义都没有的东西。

    评估发布时间

        用户故事是用来干嘛的?假定客户希望在50天内递交这个系统。我们做得了吗?为了解答这个问题,我们就要在项目开始的阶段,试着找出所有的用户故事,然后评估一下,每一项历程需要多长的开发时间。可是,怎么评估呢?
        比如,我们现在收集了下面这些用户故事:

        卖饮料:如上面所说的。
        取消购买:在投入了一些钱后,用户可以取消购买。
        输入管理密码:授权的人可以输入管理密码,然后增加存货,设定价格,拿走里面的钱等等。
        补充饮料:授权的人可以在输入管理密码后增加存货。
        取出钱箱里的钱:授权的人在输入管理密码后,可以取出钱箱里的钱箱里面的钱。
        安全警报:有些事情经常发生的话,系统会自动打开安全警报。
        打印月销售报表:授权的人可以打印出月销售报表。

        然后找出里面最简单的用户故事(这里的“简单”,意思是说实现周期最短)。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如,我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说,这个用户故事算1个“故事点(story point)”。
                           
    用户故事          故事点
    卖饮料       
    取消购买       
    输入管理密码   1
    补充饮料       
    取出钱箱里的钱       
    安全警报       
    打印月销售报表       

    不过一般我们不会列出清单,而是做出一堆卡片贴在墙上,每张卡片记录一个用户故事,然后将故事点写在卡片上面:

    image

    这样的一张卡片就叫“故事卡(story card)”。

     

     

    用户故事通常按照如下的格式来表达:

    英文:

    As a <Role>, I want to <Activity>, so that <Business Value>.

    中文:

    作为一个<角色>, 我想要<活动>, 以便于<商业价值>

    举例:

    作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

    需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

    Ron Jeffries的3个C

    关于用户故事,Ron Jeffries用3个C来描述它:

    卡片(Card) - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。

    交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

    确认(Confirmation)- 通过验收测试确认用户故事被正确完成。

    展开全文
  • 用户故事(实例)

    2020-04-05 00:11:12
    3.0、用户故事 3.0.0.1作为产品研发部的总监,我想对通用价格进行管理 故事点:3、故事编号:107 描述: 1、 通用价格的数据展示,导出数据,通用价格的调价功能,调价的记录 验收标准: 1、课时单价与学费两项都可...
  • 一、用户故事的概念 概念这种东西我喜欢说文解字的方式去理解和阐述;用户故事=用户+故事=人+故+事,那就是一个人因为什么原因要做什么事,提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户...
  • 用户故事

    千次阅读 2019-05-25 20:14:53
    什么是用户故事(user story) 用户故事就是从用户的角度来描述通过做什么操作,达到什么样的价值,如作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们...
  • 在软件开发和产品管理中,用户故事是对软件系统的一个或多个特征的非正式的自然语言描述。用户故事是敏捷软件开发中使用的工具,用于从最终用户的角度捕获软件功能的描述。用户故事描述了用户的类型,他们想要什么...
  • 用户故事详解

    千次阅读 2019-01-29 10:55:35
    在敏捷开发中, 用户故事 (user stories) 是一种轻量级,更灵活的替代品指定软件需求的传统方法 - 软件需求规范,用例规格等。 实际上,可以说用户故事是最重要的敏捷开发 (Agile Development) 中的工件 ...
  • 本文来自作者 刘华 在 GitChat 上分享「用户故事还可以这样写」,「阅读原文」查看交流实录 「文末高能」 编辑 | 娜美 用户故事很重要 用户故事很重要,是实施敏捷开发和持续交付的重要开端。 ...
  • 用户故事与用例

    千次阅读 2019-07-03 09:42:34
    用户故事与用例是一回事吗?”人们经常会问这个问题,关于敏捷团队是否应该练习使用故事与使用案例的纠纷已经存在多年。用户故事和用例是一样的吗?如果没有,哪个更好?你应该使用哪一个?或者可以同时使用? ...
  • 如何拆分用户故事

    千次阅读 2018-08-14 11:10:25
    大家好,我是来自IT修真院的一枚PM~~今天和大家来分享一下如何拆解用户故事~ 一、为什么要拆分用户故事 二、如何拆解用户故事 三、更多讨论 四、文献参考   一、为什么要拆分用户故事 所谓用户故事就是含有...
  • 用户故事地图》摘录

    千次阅读 2019-03-03 11:22:00
    用户故事地图》 JeffPatton 故事地图是一门在需求拆分过程中保持全景图的艺术。 故事地图可以使我们专注于用户和用户体验,产生更好的沟通效果,最终做出更好的产品。 使用用户故事的目的并不是为了写出更好的用户...
  • 用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素: 1. 角色:谁要使用这个功能。 2. 活动:需要完成什么样的功能。 3. 商业价值:为什么需要这个功能,这个功能带来...
  • 用户故事的简要历史

    千次阅读 2016-08-14 12:27:41
    正因为此,笔者试图整理了用户故事的历史,所费时间不多,错漏难免,请大家点评,纠正补充,进而得到更加全面准确的记录】1998年,用户故事首次提出。 用户故事的起源是来自与XP极限编程的计划游戏环节,据现在能够...
  • 用户故事宜短不宜长,以便于对其进行评估。可以想象一下如果亚马逊公司让你设计程序,你会怎样撰写它的用户故事。你可能会写道:“用户想要一家全球最大的在线书店,这样用户随时都能买到想要的书。”这个用户故事...
  • 用户故事,史诗故事和主题故事

    千次阅读 2019-07-30 18:31:35
    本文转自:scrum中文网 ... 敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在...我们发现用户故事是最好的描述方式,这种形式能够捕获到特性足够多的信息,并促进产品负责人和团队在...
  • Scrum 之 用户故事

    千次阅读 2016-03-30 20:06:18
    什么是用户故事?  用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:   1. 角色:谁要使用这个功能。   2. 活动:需要完成什么样的功能。  3. 商业价值:为...
  • 用户故事驱动开发是敏捷开发的核心管理实践,本系列将从用户故事的来源,用户角色建模,用户故事的搜集,编写用户故事用户故事的澄清与开发,用户故事的测试与验收等整个过程、多个维度进行探讨,力求给大家呈现出...
1 2 3 4 5 ... 20
收藏数 111,936
精华内容 44,774
关键字:

用户故事