敏捷开发story_敏捷开发 story - CSDN
  • 作为自己在工作的一种记录,因为我一直认为产品经理(Product Manager 简称PM)算是一种新行业、(都说PM始于宝洁,但是也可能更早之前就...敏捷开发之用户Story 用户Story也叫用户故事只需要X度一下,全部都是相...

    作为自己在工作的一种记录,因为我一直认为产品经理(Product Manager  简称PM)算是一种新行业、(都说PM始于宝洁,但是也可能更早之前就出现过做着PM做的事,但他是其他职位的人。)进入中国不超过15年。所以需要我们不断的与其他的PM或人进行讨论、实践、总结,再讨论、实践、总结。形成进步学习的闭环。

    敏捷开发之用户Story

    用户Story也叫用户故事只需要X度一下,全部都是相关的介绍和说明,我这里就不再过多的需求。他们每一篇的内容大致都是说用户故事需要遵守INVEST原则。

    INVEST原则

    Independent:独立性

    用户故事之间应该具有独立性,不应该依赖于其他的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。

    Negotiable:可协商

    用户故事是由客户或者PO同开发小组的成员共同协商制定的,用户故事代表了一个用户群体的需求,而这个需求是零散的,通过相关人员的沟通,协商经常可以丰富用户故事。

    Valuable:有价值

    用户故事对于最终的用户是有价值的,因此应该站在用户的角度去编写,描述的是一个一个的feature,而非一个一个的task。

    Estimable:可评估

    对于一个用户故事的划分需要足够的领域知识,使得在划分故事之时就能大致了解故事开发的周期,为了减少估算的不确定性,故事本身不能太大。

    Small:短小

    故事应该尽量的短小,当然也不是说越小越好。短小的故事可以减少分解过程中估算的误差,最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。

    Testable:可测试

    如果一个用户故事无法进行测试,那么也就无法判断该故事是否真的完成。所以,用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。

    来源:@百度www.baidu.com

    下面我就说说我的看法吧。希望对各位和我都起着小黄鸭的作用吧:)。

    用户Story

    一、用户Story的作用

    用户Story,我认为是在我经历过的项目中起一个特殊的地位。在开发中你可以不使用Story,你都可以完成整个流程的开发。这样的结果只是会被“锤脑壳”。。。至于原因嘛Emmmm...

    除了减少“挨打”的次数,用户Story还是以简短的话语尽量还原”场景“下的用户需求。用户是在怎样的一个情况下提出这个需求的。

    二、用户Story—基本要素

    写用户Story的时候我们需要围绕三个基本要素来写。用户(角色)、需求(目的)、原因(好处)三点。

    通过一定的需要修饰就组成了我们常见的Story语句。

    来源http://thebside.ca/未商用侵必删

    三、用户Story—用户(角色)

    在写用户Story时我们最先写的就是用户(角色),作为Story的开头,用户(角色)十分的重要,因为我们产品出发点都是从用户(角色)出发,不同的用户(角色)他们的需求和原因都是大不相同的。不同用户(角色)之间,都会存在着相互矛盾、相互冲突的需求。(就像在居民楼里休息的上班族与居民楼外广场上跳舞的阿姨,他们就可能存在着冲突)所以我们在”创建用户“时一定要给他附带属性。如:学生、程序员、Coser等或者在这些属性前加上特殊字以便自己更好的确定用户属性。如:秃顶的程序员(疯狂暗示)、没钱的学生、富LuoLi

    来源:@百度 未商用侵必删

    四、用户Story—需求(目的)

    在前面明确了用户(角色)之后,我们就需要确定他的需求(目的),一方面可以从我们的商业价值来表述。另一方面也可以从用户需求来描述(其实我觉得他俩就是一个,能够解决用户需求的产品,能够解决的方式,方法也是他的商业价值)。

    我们在描述需求(目的)的时候,我们需要尽可能地不要直接去描述功能(虽然知道是什么功能)。至于原因,我个人认为是为了更加偏向于”真实需求“。

    举个例子:在是古代,人们只能骑马,从西藏到黑龙江需要几十年(瞎掰)。

    这个时候有个传令官需要从西藏到黑龙江。这个传令官就是角色那个的需求是什么?按照我们现在的思维的话,他需要的飞机,直接飞过去。几个小时就可以达到。但是这个需求是真实的吗?肯定不是,那他的真实需求是什么? 他的真实需求可能只是能够更快的到达目的地(黑龙江)罢了。

    把时间换成现代,马儿变成车,但是他的需求还是不是飞机这个”功能“还是只是能够更快的到达目的地(黑龙江)罢了。

    这样在后期开发就尽量避免出现我只想要个指甲刀,结果你给我一把瑞士军刀,延长了开发周期和资源成本。

    来源:@百度

    五、用户Story—原因

    最后一部分就是用户Story中的原因,是什么样的原因促使前面的用户(角色)产生了前面的需求(目的),是开发没有女朋友吗?是后端的纸片人没有更新吗?更或者是为了治疗秃顶?

    原因其实很简单只需要从实际出发,而非凭空想象,即可。

    六、常见的Story模板

    一、我是(角色),我希望(功能),这样(好处)。

    二、作为(角色),我想要(商业价值),以便(原因)。

    三、作为(角色),我想(目标),以便(某种原因)。

    在写Story的时候我们需要尽可能的保持刚刚好的详细,让用户Story有“笔直性”。避免增加过多的细节要求,让Story变得复杂。

          结尾大家也来试试写一些用户Story。

     

     

     

     

     

    展开全文
  • 敏捷开发——User Story

    2019-09-23 09:54:27
    敏捷开发流程: 1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的; 2、Scrum Team根据Product Backlog列表,做工作量的预估和安排; 3、有了Product...

    敏捷开发流程:

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

    3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    user story 定义:

    Story就是一个可测试的小功能点Story:功能点=11)、或者是多个继承性的小功能点组成的一个StoryStory:功能点=1:N)、或者是一个无法再分割的功能点(再分割这个功能点就无法进行测试了)包含多个StoryStory:功能点=N1)。

    1Story

    Story最原始的目的是指导开发工作量的划分,Story是将一个大的特性划分成小颗粒度的功能块,方便分配工作量,以便获得快速反馈;

    2、特性:

    敏捷中的特性类似于在双V模型或者其他模型中的子系统、子模块或者说是较大的功能模块,是由很多的功能块组成的,一个特性是耦合度很高的子模块;

    3、功能块:

    敏捷中的功能块类似于双V模型或者其他模型中的较小的模块,从子模块里划分出来的较小的功能模块,是由很多的功能点组成的;

    4、功能点:是不可再分割的可测试的小功能模块;

    5特性团队

    特性团队是指由设计人员、开发人员、测试人员、资料人员、特性团队组长等人一起组成的一个完整的团队(7人左右),特性团队是按特性进行划分的团队,团队成员对该特性的交付全权负责

    6头脑风暴

    由特性团队中所有成员一起就一个Story的方案、设计、用例设计验收标准等内容而进行的团队中的讨论会,以澄清Story的设计,用例,测试验收标准等;

    7Story验收标准

    每一个Story都需要在进行头脑风暴时,由团队里的人一起制定该Story的验收标准;

    Story划分时以测试功能点作为依据,实现Story与功能点的融合,测试时基于功能点进行设计测试用例,开发基于Story进行开发。

    转载于:https://www.cnblogs.com/alinawang/p/6809027.html

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

    展开全文
  • 谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度...

    谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度大小的问题。

    然而, 事实的真相是如何呢?

    首先, 先从敏捷开发实践的本身说起:

    敏捷开发之所以强调 “敏捷” , 主要是希望藉由 User Story 的划分 , 能帮助开发人员, 有效的管理版本开发上需求的复杂度, 而使开发人员能在最短的时间内 “发现自身的问题”, “发现自身的不足”, “发现因自身的问题、不足与外部的变化所造成的风险” 。

    所以, 敏捷开发的核心基础, 最强调的便是: “User Story 必需要是可测的” 与 “User Story 间的持续集成” 。

    接下来再谈一下, 人的思维、人的一念之间是如何严重的扭曲了敏捷开发?!

    当一个开发人员, 他 (她) 只是在证明自己“没做错事” 时, 而不是在 “发现自身的问题” 时, 那在拆分User Story 上, 便会发生这些场景:

    1.       将 User Story 拆的需 3 周甚至一个月以上才能完成; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “测试的” 。但, 却只是被 “测试人员可测试的” ; 也就是说, 有的开发人员希望将 User Story 要拆的 “够大”, 只是要掩饰自身无法做 “有效” 的 “开发者自动化测试” 罢了。

    2.       将 User Story 拆的只需完成单一且极简单的 “功能点”; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “如期交付的” ; 也就是说, 有的开发人员希望要将 User Story 拆的 “够小”, 只是要掩饰自身无法理解与掌握 “完整的业务场景” 与 “软件架构” 罢了。

    所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 而是应协助开发人员能诚实的发现与面对自身的不足与所面临的问题, 并给予开发人员适当且必要的赋能与协助。因为, 唯有如此, 开发人员的能力提升了, 则开发人员便自然能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度越高” 的User Story。

    所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 我们应该真正专注的是: 如何能使开发人员能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度高” 的 User Story。

     

     

    展开全文
  • scrum 敏捷开发story 规范讲解 标准story 写法,达成的目标
  • 对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。 Story概念: User Story 是从用户的角度对系
  • 1 从这里开始 第一部分我们将快速浏览什么是user stories...如何来编写测试用例,来证明你的Stories已经被成功编写的细节,最后将阐述几条编写好的Story的指导建议。 当你学完这部分之后,你就可以定义、编写、测试你
  • 敏捷开发-Story划分

    2010-05-27 12:22:41
    1 Story划分能够根据INVEST原则:独立的(Independent)、可商讨的(Negotiable)、有价值的(Valuable)、可以估计的(Estimatable)、足够小的(Small)、可测试的(Testable),支撑后续分迭代进行开发;...
  • ...Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如
  • 对于story来说,一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估中的Function Point,因为story point只是用来粗略的相对的估计story的大小,而Function Point则是用来衡量功能模块的精确...
  • 如何编写敏捷开发中的user story 分类: 程序的性格2009-11-03 14:34 2704人阅读 评论(0) 收藏 举报 user敏捷开发测试junit任务框架   对于敏捷开发来说,User Story是开发的基础,它不同于传统...
  • User Story敏捷开发和管理的核心,要确保Story的输出质量。Story划分这里强调几点要求: 独立性:一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。 可测试性:要...
  • 敏捷开发的文档

    2019-06-20 06:43:35
    需求不写文档只写故事卡片,一般我也会写验收条件,或者写改动点(看具体情况,目的是开发能理解需求到底是什么),通过大量的Conversation完成细节。这些动作都是按Story的3C原则落实的。同时继续维护Use Case文档...
  • ■User Story 是什么? User story是对软件的用户或买主有价值的功能点的描述。 1.他是用来制定计划和作为提醒的一段书面描述 2.用来充实story的细节的谈话 3.测试用例,用来表达和记录细节并且能够在story实现...
  • Epic-Story-Task Epic Epic是User Story逻辑上的集合, 一个Epic可以被break down成多个小的User Story; 一个Epic可能需要多个Sprint才能完成. User Story vs. Task 在JIRA中,User Story与Task可以算作同一级别,其中 ...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发中,团队成员认领的是任务还是用户故事?
  • 背景需求文档解析成本太高。RD解析一遍,QA解析一遍。 我们的产品需求是用户真正需要的吗? 需求文档!=记录产品需求 应该代表用户需求。
  • 我把原文去粗取精了一下,保留了一些核心思想,去掉了小日本的广告. 1 任务板 任务是分解到手头的实际的工作 把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上....可以画一些横的泳道来表明任务...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
1 2 3 4 5 ... 20
收藏数 4,408
精华内容 1,763
关键字:

敏捷开发story