用户故事_用户故事地图 - CSDN
精华内容
参与话题
  • 用户故事示例

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

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

    展开全文
  • 一、用户故事的概念 概念这种东西我喜欢说文解字的方式去理解和阐述;用户故事=用户+故事=人+故+事,那就是一个人因为什么原因要做什么事,提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户...

    一、用户故事的概念

    概念这种东西我喜欢说文解字的方式去理解和阐述;用户故事=用户+故事=人+故+事,那就是一个人因为什么原因要做什么事,提炼出来三要素就是who、why、what。从需求角度描述就是一个用来确认用户和用户需求的简短描述。

    二、用户故事的三要素

    用户故事在软件开发过程中被作为描述需求的一种表达形式。为了规范用户故事的表达,便于沟通,用户故事通常的表达格式为:作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>。

    一个完整的用户故事包含三个要素:

    1. 角色(who):谁要使用这个
    2. 活动(what):要完成什么活动
    3. 价值(value):为什么要这么做,这么做能带来什么价值

    三、3C原则

    用户故事的描述信息以传统的手写方式写在纸质卡片上,所以Ron Jeffries(2001)对这三个方面称为3C:卡片(Card)、对话(Conversation)和确认(Confirmation)。

    (1)卡片(Card):用户故事一般在小卡片上写着故事的简短描述,规则和完成标准。

    卡片的正面书写故事的描述,格式为:作为一个<角色>, 我想要<完成活动>, 以便于<实现价值>描述需求;卡片背面书写完成用户故事的规则和完成标准,格式为:Given…When…Then。

    (2)交谈(Conversation):用户故事背后的细节来源于和客户或者产品负责人的交流沟通;确保各方对故事的理解正确。

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

    四、INVEST原则

    好的用户故事除了格式规范,要素完整外,还应该遵循INVEST原则:Idependent(独立的);Negotiable(可协商的);Valuable(有价值的);Estimatable(可评估);Small(小的);Testable(可测试的)。

    1. Idependent(独立的)

    要尽可能的让一个用户故事独立于其他的用户故事。用户故事间保持独立性不仅便于排列和调整优先级,使得发布和迭代计划更容易制定,便于独立地理解、跟踪、实现、测试以及频繁交付,也使得用户故事的大小估算所涉及的范围更清晰,从而估算偏差更小。

    2. Negotiable(可协商的)

    一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事只是对用户故事的一个简短的描述,不包括太多的细节;具体的细节在沟通阶段产出。一个用户故事带有了太多的细节,实际上限制了用户、团队的想法和沟通。

    3. Valuable(有价值的)

    每个故事必须对客户具有价值(无论是用户、购买方还是公司内部角色)。用户故事对于最终的用户是有价值的,因此应该站在用户的角度去编写,描述的是一个一个的feature,而非一个一个的task。

    这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变,使团队中的每个人知道自己每天做的工作价值。

    4. Estimatable(可评估)

    计划会议里面一个很重要的环节,那就是故事点的估计。实际上就是对要开发的User Story进行一个粗量级的估算,以便于团队能够知道这个user story的复杂度(工作量)。

    重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事,如果不能完成,给出理由,由PO来决定是否拆分或者重新设计用户故事。

    让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

    5. Small(小的)

    一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

    6. Testable(可测试的)

    一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。

    五、三个准则

    用户故事在遵循了INVEST原则后,基本就是一个好的用户故事了。再重点分析三个准则,帮助在产出用户故事时更好地符合原则。

    三个准则是:一个用户、完整价值、不依赖。

    1. 一个用户

    只包含一个用户,因为多个用户常常有细微的差别。一般是典型的用户,常常有共同的某类需求。

    2. 完整价值

    完整地交付一个客户价值。一个完整的用户故事意味着这个故事完成后,用户可以达成一个明确的、有意义的目标。

    3. 不依赖

    依赖性的三种常见类型是:重叠、顺序和包含。

    总体上来说,故事之间功能点相互重叠是需要避免的;顺序关系是现实存在,在多数情况下可以通过一些手段解决;包含关系对复杂系统是有帮助的,对排定发布和迭代计划的影响需要注意。

    (1)重叠依赖

    重叠依赖是带来最多困扰的依赖形式,特别是多个用户故事包含多个不同的重叠部分时,很难找到一组用户故事可以代表该最小可行产品的功能集合,该集合应该包含且仅包含一次需要的功能。

    解决方式:

    • 将重叠部分单独剥离出来做为独立的用户故事;
    • 合理拆分用户故事,并且将重叠部分只保留在一个最有内聚性的用户故事中;
    • 使用Scrum开发模式。

    (2)顺序依赖

    顺序依赖是指要使某用户故事完成,另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的,而且有一些方式可以减轻这种依赖。

    从敏捷开发的角度,整个系统是从初始的最小可行产品逐步演化为强大的产品,后面的每一步是建立在前面的基础之上的。

    但从另外的角度,不必要的顺序依赖使得排列和调整优先级变的比较困难,进而影响制定发布和迭代计划,也使得用户故事的大小估算更难以把握。

    解决方式:

    • 一个迭代内的用户故事尽量做到没有内在依赖;
    • 保持迭代之间只有单向依赖,在时间上只有后面迭代的故事对前面迭代故事的单向依赖(前向依赖);
    • 剥离出核心依赖作为独立的故事,不要把有依赖和无依赖的需求混在一个故事里。

    (3)包含依赖

    包含依赖是指在组织用户故事时使用有层级的管理,比如常见的特性-故事两级管理,一个特性包含多个用户故事,这样就构成了特性对其属下故事的包含依赖。

    解决方式:

    • 用户故事一级用来做迭代计划,避免用特性一级做粗粒度迭代计划,特性一级可以用来做发布计划;
    • 特性一级同样可以进行拆分,直至拆分到最小市场化特性的程度,并将其包含的用户故事分别归到新拆分出的特性中去;
    • 遵从最小可行产品的理念,一个特性分多个用户故事多个迭代实现,每一个迭代可形成潜在可交付或者提供内部或外部反馈。
    展开全文
  • 用户故事详解

    万次阅读 2019-01-29 10:55:35
    在敏捷开发中, 用户故事 (user stories) 是一种轻量级,更灵活的替代品指定软件需求的传统方法 - 软件需求规范,用例规格等。 实际上,可以说用户故事是最重要的敏捷开发 (Agile Development) 中的工件 ...

    介绍

    在敏捷开发中, 用户故事 (user stories) 是一种轻量级,更灵活的替代品指定软件需求的传统方法 - 软件需求规范,用例规格等。 实际上,可以说用户故事是最重要的敏捷开发 (Agile Development) 中的工件 (Artifacts),因为它是主要将值流传递给用户的容器,敏捷开发就是快速实现价值 (Value)。

    用户故事也可以作为我们整个增量价值交付 (incremental-value-delivery approach) 方法的隐喻,即:

    定义有价值的用户价值故事 - 在短时间内实施和测试 - 演示和或交付

    它对用户 - 捕获反馈 - 学习 - 永远重复!

    我在更广泛的白皮书 “精益和可扩展” 的背景下简要讨论了用户故事敏捷企业需求信息模型 与企业敏捷性大局 1 其中,与主题,史诗和功能一起,它们是敏捷团队使用的主要需求工件。

    在本白皮书中,我们将更详细地描述用户故事,因为在这里我们将找到其中一个关键的敏捷实践,帮助我们将我们的解决方案直接与用户的特定需求保持一致,并帮助确保质量在同一时间。

    用户故事概述

    在引用的白皮书和相关的博客系列中,我突出了许多贡献企业敏捷实践的Scrum模型,例如,产品所有者的定义角色,这是我们的要求实践不可或缺的。 但是对于XP来说,我们欠用户的发明故事,它是XP的支持者,已经发展了这个神器的广度和深度。 然而,因为用户故事现在经常出现,所以这不像是“路上的方法论分叉” 在Scrum培训的构建中教授,作为构建产品积压和定义Sprint的工具内容。 也许我们让Mike Cohn感谢大部分的整合,因为他开发了用户在他的书“ 用户故事应用 [Cohn 2004]”中广泛讲述了他的 故事 ,并且他一直非常积极地参与其中Scrum联盟也是如此。

    出于我们的目的,我们将用户故事定义为:

    “ 用户故事”是一份简要的意向声明,描述了为用户执行的操作的系统需要。

    在XP中,用户故事通常由客户编写,从而直接将客户集成到客户中发展进程。 在Scrum中,产品所有者经常使用来自的输入来编写用户故事客户 (Users),利益相关者 (Stakeholders) 和团队 (Team)。 但是,在实际操作中,任何团队成员都有足够的领域知识可以编写用户故事,但是产品所有者 (Product Onwer)可以接受并优先考虑这些故事进入产品积压 (Product Blacklog)。


    用户故事是一种工具, 用于以开发人员和用户都能理解的方式定义系统的行为。用户故事将工作重点放在用户定义的价值上, 而不是功能分解结构上, 这是传统上工作的任务方式。它们为管理系统的需求提供了一种轻量级且有效的方法。

    用户故事在索引卡上捕获功能的简短声明,或者可能使用在线工具。

    例子:

    登录我的网络能源监控门户网站

    看我每天的能源使用情况

    检查我当前的电费计费率

    系统行为的详细信息不会出现在简要声明中,稍后将继续开发团队与产品所有者之间的对话和验收标准。

    用户故事帮助桥接开发人员 - 客户沟通差距

    在敏捷开发中,开发人员的工作是说出用户的语言,而不是用户的工作说技术语言。 有效的沟通是关键,我们需要一种共同的语言。用户故事提供了用于在用户和技术之间建立理解的通用语言球队。

    XP的创造者之一Bill Wake用这种方式描述 [2] :

    洋泾浜语 (pidgin language)是一种简化的语言,通常用于交易,允许不能用他们的母语沟通的人,但仍然一起工作。 用户故事的行为就像这样。 我们没有期望客户或用户以与程序员相同的方式查看系统; 用户故事充当了洋泾浜语, 双方都能达成一致同意有效合作的语言 。

    通过用户故事,我们了解彼此语言的必要条件无需和熟练到足以制作十四行诗 (sonnet)的程度; 我们只需要了解对方就知道我们什么时候适当的交流!

    用户故事不是软件需求

    虽然用户故事完成了以前由软件需求规范 (software requirement specification)、用例 (use cases) 等所做的大部分工作,但它们在许多微妙但关键的方面却有着本质上的不同。

    • 它们不是详细的要求规范(系统 应该做的事情)但是而意图转让的表达式(它需要做一些事情 好像是这样 )
    • 它们简短易读,易于开发人员,利益相关者 用户理解
    • 它们代表了有价值的功能的小增量,可以在a中开发几天到几周的时间
    • 它们相对容易估计,因此可以实现功能迅速确定
    • 它们不是大型的,笨拙的文件,而是组织在可以的列表中随着新信息的发现,更容易安排和重新安排
    • 它们在项目开始时并未详细说明,而是在时间基础上详细阐述 - 从而避免过早的特异性,延迟开发,需求库存,以及解决方案的过度约束声明•它们几乎不需要维护,实施后可以安全丢弃
    • 用户故事以及此后快速创建的代码作为输入文档,然后逐步开发

    用户故事3Cs: 卡 (Card),会话 (conversation) 和确认 (Confirmation)

    另一位XP的创造者Ron Jeffries描述了我们最喜欢的用户故事的思考方式。 他使用卡片 (card) , 对话 (conversation) 确认 (Confirmation) 来描述这三者的用户故事的元素:

    卡片代表2-3句话,用来描述故事的意图。这一意图值得提醒以便将来进一步发展。,它概括了意图,代表了一个更详细的要求,其细节有待确定。

    注意:在XP和敏捷中,故事通常是手动编写的索引 。 更典型的是在企业中采用电子表格或敏捷项目管理工具为文本和附件捕获“card”元素,但团队通常仍然使用卡片进行早期规划和头脑风暴,如我们稍后会看到。

    对话 (Conversation) 代表团队,客户,产品所有者和其他利益相关者,这是必要的实现意图所需的更详细的行为。 其他话说, 卡片也代表了“谈话的承诺”意图。

    确认 (Confirmation) 代表验收测试 ,这是如何客户或产品所有者将确认故事已经存在实施令他们满意。 换句话说,确认表示将适用的满足条件确定故事是否符合意图以及更详细的要求。

    通过这个简单的头韵,我们有一个关于如何实现敏捷质量的对象课程比以后,实际的代码开发。 我们通过简单地确保每个新用户故事都是这样做的 a)以必要的细节进行讨论和改进,b)进行测试以满足关键

    利益相关者。

    用户故事声音

    在过去几年中,应用了一种新的标准化表格,增强了用户故事构建显着。 表格如下:

    作为<role>我可以<activity>以便<business value>

    哪里:

    • 角色 - 表示正在执行操作的人员或可能正在接收该值的人员来自活动。 它甚至可能是另一个系统,如果那是启动活动的那个系。
    • 活动 - 表示系统要执行的操作。
    • 商业价值 - 代表企业的价值。

    我们称之为用户故事表达的“用户语音”形式,并发现它是一个非常有用的结构。 [5] 因为它跨越了问题空间(<业务价值>交付)和解决方案空间(<活动>)用户执行系统)。 它还为团队提供了用户优先(<role>)透视图他们专注于商业价值并为真实的人解决实际问题。

    这个用户故事的形式,大大提高了 为何以及如何理解,开发人员需要实现一个真正满足用户需求的系统。

    例如,家庭能源管理系统的用户可能想要: [6]

    作为消费者, (<role>)我希望能够看到我的日常能源使用情况(<我对系统的处理方式>)

    这样我就可以开始了解如何随着时间的推移降低成本 (<我收到的商业价值>) 。

    每个元素都提供重要的,扩展的上下文。 该 角色允许对产品进行细分功能,通常为活动提取其他基于角色的需求和上下文。 活动通常代表角色所需的“要求”。 和 传达为什么活动需要,这往往可以引导团队找到可能提供的替代活动减少努力的相同价值。

    用户故事详情

    用户故事的详细信息主要通过产品所有者和产品之间的对话传达团队,从一开始就让团队参与其中。 但是,如果需要有关故事的更多细节,它们可以以附件(模型,电子表格,算法或其他)的形式提供,其中附加到用户故事。 在这种情况下,用户故事充当“令牌”,其也携带更多对团队的具体行为。 应该随着时间的推移收集额外的用户故事细节(及时 Just-in-time) 在此之前和期间通过与团队和其他利益相关者的讨论和协作发展。

    用户故事接受标准

    除了用户故事的陈述之外,还可以有其他说明,假设和验收标准与用户故事保持一致。 关于团队和客户之间的故事的许多讨论可能会采取在故事提交代码之前和期间放置。 活动中的替代流动,接受界限和其他说明应与故事一起捕捉。 其中很多可以将故事变成验收测试用例或其他功能测试用例。

    例如,

    作为消费者,我希望能够看到我的日常能量使用量,以便我可以开始了解如何使用随着时间的推移降低我的成本

    验收标准:

    • 每10秒读取一次DecaWatt仪表数据,并以15分钟为增量在门户上显示并在每次阅读时显示在家庭显示器上
    • 阅读KiloWatt仪表以获取可用的新数据,并在每小时和每小时显示在门户上每次阅读后的家庭显示
    • 目前 没有多日趋势(另一个故事)。
    • 等等…

    验收标准不是功能或单元测试,而是满足的条件放在系统上。 功能和单元测试在测试所有功能流程时更加深入,例外流程,边界条件以及与故事相关的相关功能。

    INVEST - 好用户故事

    敏捷团队花费大量时间(可能多达一半或更多)来发现,详细阐述,理解用户故事并为其编写验收测试。 这是应该的,因为它代表了以下事实:

    为理解的目标编写代码不一定是软件开发中最难的部分,相反,它是理解的代码的真正目的什么。

    因此, 投资于良好的用户故事,尽管是在最后一个负责任的时刻,是值得努力的球队。 比尔·威克(Bill Wake)创造了第 7个 缩写词INVEST [7]来描述一个好的用户故事的属性。

    Independent  (獨立)

    Negotiable ( 可商议的)

    Valuable (有价值的)

    Estimable (可估计的)

    Small (细小的)

    Testable (可测试的)

    INVEST模型相当普遍,许多敏捷团队根据这些模型评估他们的故事属性。 以下是我们对团队投资价值的看法。

    独立

    独立意味着可以自己开发,测试甚至可能传递故事。因此,它也可以独立评估 。

    随着产品功能的构建,许多故事将具有一些自然的、连续的依赖性,但是每一个故事都可以独立地交付价值。例如,一个产品可能显示一条记录,然后显示一个列表,然后对列表进行排序,筛选列表,准备多页列表,导出列表,编辑列表中的项目等。这些项目中的许多都具有顺序依赖性,但每个项目都提供独立的值,并且产品可能通过任何开发停止点进行发货。

    但是,许多非价值的依赖关系,无论是技术的还是功能的,都倾向于找到自己的方式积压和这些我们需要找到并消除。 例如,非值函数依赖可能:

    作为管理员,我可以设置消费者的密码安全规则,以便用户需要创建并保留安全密码,保证系统安全。

    作为消费者,我需要遵循管理员设置的密码安全规则,以便我可以保持我的帐户的高安全性。

    在此示例中,消费者故事取决于管理员故事。 管理员的故事只是在设定,清除和保留政策方面是可测试的; 但它对消费者的强制执行是不可测试的。此外,完成管理员故事不会使产品处于潜在的可交付状态 - 因此,没有独立的价值。

    通过重新考虑故事(以及系统的设计),我们可以通过拆分来消除依赖性这些故事以不同的方式 - 在这种情况下通过应用的安全策略类型和在每个故事中将设置与执行相结合:

    作为管理员,我可以设置密码有效期,以便用户被迫更改他们的密码定期。

    作为管理员,我可以设置密码强度特征,以便用户需要创建难以破解的密码。现在,每个故事都可以独立存在,并且可以独立开发,测试和交付。

    可面议......并可协商的

    与传统要求不同,用户故事不是特定功能的合同,而是一个占位符,用于讨论,开发,测试和接受的要求。 这个谈判过程企业和团队之间认识到商业投入的合法性和首要地位,但是允许通过协作和反馈进行发现。

    在我们之前的孤岛组织中,通常需要书面要求来促进有限的部门之间的通信带宽,并作为过去协议的记录。 敏捷,然而,它建立在一个基于团队的方法更有效地解决问题的概念的基础上动态协作环境。 用户故事是实时的和结构化的,以利用这种有效和直接沟通和协作方法。

    最后,用户故事的可转让性有助于团队实现可预测性。 缺乏过度约束和过于详细的要求增强了团队和企业进行权衡的能力功能和交付日期之间。 因为每个故事都具有灵活性,团队具有更大的灵活性达到发布目标,增加可靠性并促进信任。

    有价值

    敏捷团队的目标很简单:在给定现有时间和资源的情况下提供最大价值限制。 因此,Value是INVEST模型和每个用户故事中最重要的属性必须为产品的用户,客户或利益相关者提供一些价值。 积压的优先顺序是价值和业务根据团队可以提供的价值成功或失败。

    团队面临的典型挑战是学习如何编写可以的小型增量用户故事有效地提供价值。 传统方法已经根深蒂固地创造了功能性细分基于技术组件的结构。 这种用于构建软件延迟的技术分层方法值递送,直到多次迭代后将所有层放在一起。 Wake [8] 提供了他的垂直而非技术层次的视角。

    将整个故事视为多层蛋糕,例如网络层,持久层,逻辑图层和表示层。 当我们[横向]分割一个故事时,我们只提供一部分那个蛋糕 我们想给顾客整个蛋糕的精髓,最好的方法是垂直切片穿过图层。 开发人员通常倾向于仅在一个层上工作一次(并使其“正确”); 但是完整的数据库层(例如)几乎没有价值客户,如果没有表示层。

    创建有价值的故事需要我们将功能分解结构从水平重新定位到垂直方法。 我们创建的故事贯穿整个架构,以便我们能够为其提供价值用户并尽可能早地寻求他们的反馈。

    虽然通常价值集中在用户与系统交互,但有时价值更高适当关注客户代表或关键利益相关者。 例如,也许是营销导演要求对网站上展示的广告提高点击率。 虽然故事可能是从最终用户的角度编写:

    作为消费者,我可以看到其他吸引我的能源定价计划,以便我可以参加程序更适合我的生活方式......为了提供一个更清晰的真实价值观,它会更恰当地写出来营销总监的观点:

    作为公用事业营销总监,我可以为用户提供新的定价计划,以便他们更多可能会继续从我这里购买能源。

    团队面临的另一个挑战是阐明代码重构等技术故事的价值,组件升级等。例如,产品所有者如何确定以下值:

    重构错误记录系统。

    将技术解决方案的价值阐述为用户故事将有助于与业务沟通相对重要性。 例如:

    作为消费者,我可以在产品的任何位置收到一致且明确的错误消息,以便我知道如何解决这个问题。 要么作为技术支持成员,我希望用户随时随地收到一致且明确的消息应用程序,以便他们可以解决问题,而无需调用支持。

    在后面这些例子中,价值对于用户 - 对产品所有者 - 利益相关者 - 以及对团队。

    可估计

    一个好的用户故事是可以估计的。 虽然任何规模的故事都可以在积压中,但为了它在迭代中开发和测试,团队应该能够提供它的近似估计完成它所需的复杂性和工作量。 估算的最小投资是确定它是否可以在一次迭代中完成。 额外的估计准确性将增加团队的可预测性。如果团队无法估计用户故事,则通常表明故事太大或不确定。

    如果它 太大而无法估计,则应将其拆分为较小的故事。 如果故事太不确定无法估计,然后可以使用技术或功能尖峰故事来减少不确定性,从而使一个或多个可估计用户故事结果。 (以下各节将详细讨论这些主题中的每一个)。

    估算用户故事的主要好处之一不仅仅是获得精确的大小,而是来自提出任何隐藏的假设,缺少验收标准,并澄清团队的共享了解这个故事。 因此,围绕估计过程的对话是(或更多)

    重要的,比实际估计。 估计用户故事的能力受到大小的影响很大这个故事,我们接下来会看到。

    足够小

    用户故事应足够小,以便能够在迭代中完成,否则他们不能提供任何价值或在此时考虑 完成 。 但是,即使是较小的用户故事也能提供更敏捷性和生产力。 这有两个主要原因: 吞吐量增加减少复杂性 。

    增加吞吐量

    从排队论 (queuing theory) 来看,我们知道较小大小的批量可以更快地通过系统。 这是其中之一精益流动的主要原则在Little定律中得到了体现:

    在一个稳定的系统中(吞吐量,单位时间内可以完成的工作量是不变的),我们必须减少在制品(我们正在处理的事情的数量),以减少周期时间(过程开始和结束之间经过的时间)。 在我们的例子中,这意味着 更少,正在处理的小故事会更快出来 。

    而且,当系统加载到容量时,它可能变得不稳定,并且问题变得复杂。在负载较重的系统中,较大的批次移动速度不成比例地降低(吞吐量降低)系统。 (想想高峰时段的高速公路系统。摩托车的吞吐量要高得多汽车和卡车。 通过加载系统可以有更多空间来操纵较小的东西。)因为开发团队通常完全分配到或超过容量(80-120%),他们陷入“匆忙”小时“公路类别。

    当容量达到80%左右时,较大的物体会比较小的物体增加周期时间(减速)对象。 更糟糕的是,周期时间的 变化会增加,这意味着预测何时变得更难批次实际上可能退出系统,如在图1的下方 9 中可以看到 。 反过来,这种可预测性较低对计划,承诺和团队的可信度造成严重破坏。

    图1

    大批量生产量较低,循环时间变化较大复杂性降低较小的故事不仅因为原始的,按比例的大小而更快地通过,但它们经历了更快,因为它们的 复杂性降低 ,并且复杂性与大小有非线性关系 。

    在测试验证功能所需的测试排列时,最容易看到这一点随着函数本身的复杂性以指数速率增加。 这与我们的建议相关关于开发清洁代码,正如罗伯特马丁[马丁2009]注意到他的写作规则

    软件功能:

    • 规则1:做一件事
    • 规则2:保持小
    • 规则3:使它们小于那个

    这是Fibonacci估计序列(即1,2,3,5,8,13,21 ......)的主要原因之一有效估计用户故事 - 努力估计随着故事规模的增加而非线性增长。

    论规模与独立的关系

    关于规模和独立性之间的关系,出现了一个公平的问题,因为这似乎是合乎逻辑的较小的故事增加了依赖的数量。 然而,较小的故事,即使有一些增加依赖性,提供更高的吞吐量并提供比大型故事更快的用户反馈。 所以agilist总是倾向于较小的故事, 然后使它们变得更小。

    可测试

    在正确完成的敏捷中, 所有代码都是经过测试的代码 ,因此故事必须是可测试的。 如果一个故事似乎不是可测试的,那么故事可能形成不良,过于复杂,或者可能依赖于积压中的其他故事。

    为了确保 故事如果不能脱离, (成功测试)很多敏捷, 就不会进入迭代今天的团队采取了一种先试后试的方法。 这开始于使用Test Driven的XP社区开发,在编写代码以通过测试之前编写自动化单元测试的实践。

    从那时起,这种方法哲学被应用于故事接受标准的制定和在编写故事本身之前进行必要的功能测试。 如果一个团队真的知道如何测试它,那么他们可能也知道如何编码。

    为了确保可测试性,用户故事与模糊的需求共享一些常见的可测试性缺陷。

    诸如 快速,管理,漂亮,干净等词语很容易编写,但很难测试,因为它们的意思对不同的人有不同的东西,因此应该避免。 虽然这些话确实提供了可转让性,提供一些明确,客观的界限将有助于团队和业务共享对产量的期望并避免重大意外。

    拆分用户故事

    用户故事通常以特征或史诗开头 - 一个大而模糊的概念我们想要为用户做的事情。 我们经常发现这些大模糊的故事在我们的发现过程中,并在积压中捕获它们。 但是,这些是 复合故事 ,如右图所示,通常都太大了在迭代中实现。 为了准备迭代工作,a团队必须把它们分解成更小的故事。

    没有用于将用户故事分成迭代大小的其他方式的例程比一般指导使每个故事提供一个垂直切片,一些用户价值,通过系统。 但是,基于最近的一些工作理查德劳伦斯,我们建议适当选择 十个常见模式来分割用户故事 ,如表1表示 [10]:

    1.工作流程步骤

    确定用户完成特定工作流然后实现的具体步增量阶段的工作流程。

    作为一个实用程序,我想更新和发布为我的客户定价计划

    ......我可以向客户发布定价程序家用显示器

    ...我可以向客户的网站发送消息门户

    ...我可以将定价表发布给客户智能恒温器

    2.业务规则变更

    乍一看,有些故事看起来相当简单。但是,有时业务规则更复杂或者比第一眼看到的还要广泛。在这种情况下,将故事分成几个可能是有用的处理业务规则复杂性的故事。

    作为 (As a) [一个实用工具],我可以 (I want) [按客户排序不同的人口统计]

    ...按邮政编码排序

    ...按家庭人口统计排序

    ......按能耗排序

    3.重大努力

    有时故事可以分成几个部分,其中大部分工作将用于实施第一。在下面显示的示例中,应构建处理基础架构以支持第一个故事;添加更多功能应该在以后相对简单。

    作为 (As a) 用户,我希望 (I want) 能够选择/更改我的定价程序与我的实用程序通过我的门户网站

    ...我想使用使用时间定价

    ......我想预付我的精力

    ...我想报名参加Critical-Peak-Pricing

    4.简单/复杂

    当团队讨论故事时,故事似乎越来越大(“x怎么样? -你考虑过吗?“),停下来问”什么是最简单的东西可能有用?“抓住它简单版本作为自己的故事,然后将所有的变化和复杂性分解成自己的故事。

    作为 (As a) 用户,我基本上想 (I want) 要固定价格,但是我还希望得到关键峰值的通知定价事件。

    ...回应时间和持续时间关键的峰值定价事件

    ......回应紧急事件

    5.数据的变化

    数据变体和数据源是范围和复杂性的另一个来源。考虑添加故事 -

    在构建最简单的版本后及时。此处显示了本地化示例。

    作为 (As a) 一个实用工具,我可以 (I can) 发送消息顾客

    ...用英语讲。

    ...在西班牙语中

    ......用阿拉伯语等

    6.数据输入方法

    有时复杂性在用户界面而不是功能本身。在这种情况下,分开故事使用最简单的UI构建它,然后再构建更丰富的UI。

     作为用户,我可以查看我的能耗在各种图表中

    ...使用每周比较的条形图消费

    ...在比较图表中,所以我可以比较我的用于具有相同或相似的人家庭人口统计学

    7. 推迟系统质量

    有时,最初的实施并不是那么困难,而且努力的主要部分在于快速实现- 或可靠 - 或更精确 - 或更具可扩展性。但是,团队可以从基地学到很多东西实现,它应该对用户有一些价值,否则他们将无法完成所有这些工作。 在这案例,将故事分解为连续的“能力”。

    作为用户,我希望看到实时从我的仪表消耗

    ...插入最后一次已知读数的数据

    ...显示来自仪表的实时数据

    8. 操作(例如:创建读取更新删除(CRUD))

    像 管理控制这样的词是一个赠品,故事涵盖了多个操作,可以提供一个分裂故事的自然方式。

    作为用户,我可以管理我的帐户。

    ...我可以注册一个帐户。

    ...我可以编辑我的帐户设置。

    ...我可以取消我的帐户。

    ...我可以在帐户中添加更多设备

    9.用例场景

    如果已经开发了用例来表示复杂的用户到系统或系统到系统的交互,那故事通常可以根据用例的各个场景进行划分。

    “(I want) 我想参加节能活动通过零售经销商进行计划。“

    用例/故事#1(快乐路径):通知实用程序消费者有设备

    用例/故事#2:实用程序提供设备和数据,通知消费者

    用例/故事#3(备用方案):处理数据验证错误

    10.突破一个尖峰

    在某些情况下,故事可能太大或太复杂,或者实施可能很差了解。 在这种情况下,建立一个技术或功能峰值来解决它; 然后基于分裂故事结果。(请参阅以下部分中的Spikes)。

    表格1

    用于分割用户故事的十种模式团队通常会使用上述技术的组合来调整故事大小。有了这个技能,团队将能够以更快的速度向前发展,在发布和迭代时分割用户故事将边界规划成一口大小的块以供实施。

    Spikes

    Spikes是XP的另一项发明,是一种特殊类型的故事,用于消除风险和不确定性用户故事或其他项目方面。可能出于多种原因使用尖峰:

    1. 团队可能不了解新域名,并且Spikes值可能用于基础研究以使团队熟悉新技术或领域。
    2. 故事可能太大而无法进行适当估计,团队可能会使用Spikes分析隐含的行为,这样他们就可以将故事分成可估计的部分。
    3. 故事可能包含重大技术风险,团队可能需要做一些研究或原型设计,以获得对允许的技术方法的信心他们将用户故事提交给未来的时间框。
    4. 这个故事可能包含重大的功能风险,因为故事的意图可能会有要理解,目前还不清楚系统如何与用户进行交互来实现利益暗示。

    技术峰值和功能峰值

    技术Spikes用于研究解决方案中的各种技术方法域。例如,技术Spikes值可用于确定构建与购买决定,评估新用户故事的潜在性能或负载影响,评估可应用于解决方案的特定实施技术,或者出于任何原因,当团队需要对a进行更自信的理解时在将新功能提交给时间盒之前所需的方法。

    只要用户如何存在重大不确定性,就会使用功能Spikes可能会与系统交互。功能Spikes值通常最好通过评估某种程度的原型设计,无论是用户界面模型,线框,页面流量,或任何最适合从客户那里获得反馈的技术利益相关者。某些用户故事可能需要两种类型的Spikes值。 例如:

    作为一个消费者,我想在直方图中看到我的日常能量使用,这样我就能很快理解我的过去,现在,可能是近期,未来的能源消耗。

    在这种情况下,团队可能会创建两个Spikes值:

    技术Spikes值 :研究将客户显示更新为当前使用所需的时间,确定通信要求,带宽以及是否推送或拉取数据。功能峰值:在门户网站中对直方图进行原型设计,并获得一些用户对演示文稿的反馈大小,样式和图表属性。

    Spikes指南

    可估计 Estimable,可证明 (Demonstratable) 和可接受 (Acceptable)

    与其他故事一样,Spikes值被放入积压,可估计和大小以适应迭代。秒杀结果是与故事不同,因为它们通常产生信息,而不是工作代码。穗可能导致决策,原型,故事板,概念证明或其他部分解决方案,以帮助推动最后的结果。在任何情况下,钉子应该只发展足以解决问题的信息能够识别和调整隐藏在Spikes下面的故事的不确定性。

    Spikes的结果对团队来说是可以演示的。这给研究和结果工作带来了能见度, 也有助于建立集体自主权, 并对正在作出的关键决定分担责任。

    和其他故事一样,当峰值的验收标准得到满足时,产品所有者会接受峰值。

    例外,而不是规则

    每个用户故事都有不确定性和风险——这就是敏捷开发的本质。团队通过讨论、协作、实验和协商发现正确的解决方案。因此,从某种意义上说,每个用户故事都包含Spikes级别的活动,以消除技术和功能风险。敏捷团队的目标是学习如何接受并有效地解决每个团队中的这种不确定性。

    在考虑未来工作的Spikes时,首先考虑通过策略分解故事的方法上面讨论过。使用Spikes作为最后一个选项。

    考虑在单独的Sprint中实现Spike

    由于Spikes代表一个或多个潜在故事的不确定性,因此计划Spikes和Spikes在同一次迭代中产生的故事是有风险的,通常应该避免。但是,如果穗是小而直接,可能会找到快速解决方案,没有任何问题在同一次迭代中完成故事。小心使用索引卡进行故事建模

    使用索引卡进行故事建模

    进行故事编写和可视化建模值传递提供了强大的视觉效果和动态的手段让整个团队参与积压开发。有很多这种互动方式的优点:

    索引卡的物理大小会强制文本长度限制,要求故事作者阐明他们的想法只用一两句话。这有助于保持用户故事小而专注 - 一个关键属性。有形的,卡片的物理性质使团队有能力在视觉上和空间上将它们排列成各种各样的配置以帮助定义积压:

    • 卡可以按特征(或史诗或主题)并且可以写在相同的颜色上卡作为视觉区分的特征。
    • 卡也可以按大小排列,以帮助开发人员看到之间的大小关系不同的故事。
    • 卡可以按时间或迭代排列,以帮助评估依赖关系,理解逻辑排序看到对团队速度的影响,更好地协调和沟通不同利益相关者优先事任何

    任何团队成员都可以写一张故事卡, 将这些小的、有形的 "价值对象" 移动到桌子周围的物理行为都会创建一个互动的动态学习设置, 参与者可以 "看到并触摸" 他们即将为自己的价值创造的价值。利益 相关 者。

    经验表明, 具有共同愿景的团队更致力于落实这一愿景。使用物理故事卡建模价值交付为所有团队成员和利益相关者提供了一个自然的参与模型, 并为所有人提供了一个共同的、有形的愿景。

    摘要

    在本白皮书中,我们概述了用户故事的衍生和应用敏捷团队使用的主要要求代理。除了背景和历史,我们已经描述了alliteration Card,Conversation 和 Confirmation,定义用户故事的关键元素。我们根据 INVEST 提供了一些开发良好用户故事的建议模型,并具体描述了故事如何提高吞吐量和质量。一组模式还将描述将大型故事分成小故事,以便每个结果故事都可以在迭代中独立地交付价值。我们还提供了创建峰值的指南,作为故事 -

    用于了解和管理开发风险的积压项目。总之,我们已经提出过这样的建议团队使用物理索引卡应用可视化建模来开发用户故事并创建共享愿景使用这种独特的敏捷需求构造实现用户价值。


    参考书目

    科恩,迈克。2004. 用户故事应用:敏捷软件开发。马萨诸塞州波士顿:Addison-韦斯利。

    马丁,罗伯特。2009年 清洁守则:敏捷软件工艺的手册。波士顿:MA:Pearson教育。

    Poppendieck,Mary和Tom Poppendieck。2007. 实施精益软件开发:来自现金的概念。马萨诸塞州波士顿:Addison-Wesley。

    杰弗里斯,罗恩。2001年8月。“ 基本的XP:卡片,对话和确认。“XP杂志。


    其他用户故事相关文章

     

     

    展开全文
  • 敏捷:什么是用户故事(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)- 通过验收测试确认用户故事被正确完成。

    展开全文
  • 用户故事

    千次阅读 2019-05-25 20:14:53
    什么是用户故事(user story) 用户故事就是从用户的角度来描述通过做什么操作,达到什么样的价值,如作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们...
  • 理解用户故事

    2018-05-21 20:54:59
    用户故事很重要用户故事很重要,是实施敏捷开发和持续交付的重要开端。所谓用户故事就是含有一定业务价值的端到端交付。瀑布开发是把项目按照不同生命周期阶段横向拆分的过程。而敏捷开发是把项目或产品或业务目标竖...
  • 在软件开发和产品管理中,用户故事是对软件系统的一个或多个特征的非正式的自然语言描述。用户故事是敏捷软件开发中使用的工具,用于从最终用户的角度捕获软件功能的描述。用户故事描述了用户的类型,他们想要什么...
  • 在最近的咨询过程中,经常有客户问到“用户故事和用例是什么关系?”、“用户故事是不是取代了用例?”、“什么时候用用例、什么时候用用户故事?”、“特性和用例是什么关系?”。以下把我的想法整理了一下,首先先...
  • 划分用户故事(user-story)的原则

    万次阅读 2012-05-02 21:53:15
    在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中,用户故事的划分对于迭代和开发起着举足轻重的作用。 用户故事从其名字来看是站在用户...
  • 转自:http://duweizhong.blogbus.com/logs/112151436.html 、http://www.zentao.net/book/zentaopmshelp/103.html http://www.iamniu.com/2013/06/30/user-story-and-use-case/ Invest描述: I dependent(独
  • 作者:陈勇 出处:blog.csdn.net/cheny_com 用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现... 前言:为何需要讨论用户故事的颗粒度 其实需求颗粒度的问题由来已久,即
  • 1.用户故事地图  User Story是敏捷开发和管理的核心,User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为...
  • 如何用7个步骤开发用户故事地图 (User Story Map)什么是用户故事映射 (User Story Mapping)?用户故事映射是一种技术,允许您为积压 (backlog) 添加第二个维度。可视化使您能够看到Product Backlog的大图。它给你...
  • 敏捷开发中,团队成员认领的是任务还是用户故事
  • 在这样一个周六的下午,小编参加了一次北京敏捷社区(微信号:Agile1001)组织的活动:《用户故事地图User Story Mapping 实战工坊》,虽然对用户故事地图是第一次接触,但也有一些小小的体会,回到家中是在按捺不住...
  • 敏捷开发用户故事系列之一:何为用户故事

    万次阅读 多人点赞 2012-07-30 14:23:04
    这是敏捷开发用户故事系列的第一篇。(栏目目录)全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等等若干问题,力求将此中问题尽量解决干净。本系列...
  • 这是敏捷开发用户故事系列的第八篇。(栏目目录) 本文内容来自火星人团队对火星人产品中300个用户故事编写后总结的经验和成果,欢迎致力于敏捷开发而又对用户故事感到困惑的开发者参与讨论。本篇文章尤其适合参加...
  • 关于用户故事

    千次阅读 2016-06-17 12:09:38
    用户故事,User Story,这个词儿来自于敏捷方法Scrum。到底什么是用户故事,因为近期重拾Redo一些项目方面和产品方面的工作,来整理整理相关知识。用户故事与另外几个概念,如用户故事切分、用户故事地图、用例、...
  • 敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆。就算是最终打算一试,也经常会不知...
1 2 3 4 5 ... 20
收藏数 113,955
精华内容 45,582
关键字:

用户故事