• ■User Story 是什么? User story是对软件的用户或买主有价值的功能点的描述。 1.他是用来制定计划和作为提醒的一段书面描述 2.用来充实story的细节的谈话 3.测试用例,用来表达和记录细节并且能够在story实现...

    ■User Story 是什么?
    User story是对软件的用户或买主有价值的功能点的描述。
    1.他是用来制定计划和作为提醒的一段书面描述
    2.用来充实story的细节的谈话
    3.测试用例,用来表达和记录细节并且能够在story实现的时候对进行验证
    每个Story都有每个Story存在的价值,编写stories的关键点在于让客户让你们的主管和经理们认可Story的价值。

    ■如何去编写Story
    1.使用5W1H的方式去编写Story
    5W1H:what, when, where, why, who, How
    在编写Story的时候,用尽可能短的语言去表述清楚what,where,why就可以了
    至于How,when, who则可以在planningMTG中通过和客户,领导等沟通去决定。

    Story例:某某功能的内部処理を設計、実装和测试
    问题点:某某功能是what?这个Story的完成基准又是什么?在这个例子中,都没有明确的说明。那么该如何去判断做什么,又如何去判断完了呢。
    在优秀的软件中,每一行代码都为了完成一个或者多个功能而存在的。在Story中把真正what, where, why用最简单的方式去说明清楚吧。
    設計、実装、测试、DR等等是How,是为了完成这个Story的手段。
    因为Story做成提倡尽可能短,所以不要将How放入Story中。将How作为Story的一个补充说明才是上上之策。

    2.一个Story必须要有一个明确的Goal
    简单来说一个Story在作成完了后,必须能够判断他的Goal条件。如果Story中无法明确传达Goal条件的话,也就失去了用Story来管理进度的意义了。
    至于你使用机能点还是测试点或者是成果物单位来对Story进行分解,这个是次要的,关键是每个Story要有一个明确的完成基准。

    3.根据是否有明确的最终Goal分开考虑作成Story
    明确最终Goal的项目中,用TopDown的方式,分解Story,每一个Story就是一个Goal,所有的小Story达成后,最终Goal也就达成,如果你的Story中有和最终Goal没有关系的小Goal,那么就把这个Story果断的去掉吧。
    当没有明确最终Goal的项目中,用BottomUp的方式,把眼前能够要做的该做的先做好后,再去和客户检讨式样把。检讨以后再作成Story。如果能做到的话,就可以"拥抱变化"了。

    4.不明确事项,检讨项目也需要管理
    项目开发过程中,有太多的TBD项目,有太多的暧昧的地方,这就是软件开发。
    这些地方也请你用Story或者其他方式将他管理起来,在早会时定期联络。不要在你的Story中出现这些不确定的内容。
    如果你的Story因为某些不确定原因而无法着手的话,请果断将这个Story挂起,并及时通知ScrumMaster吧。

    ■如何去使用Story
    1.Story需要定期维护吗
    在刚开始软件开发的阶段,并不需要也没有必要把所有的Story都分好详细列出,因为软件开发中存在太多的不确定的因素。客户的需求也不是一成不变的。
    刚开始只要列出一个完成开发的大致的脚本就可以了,当真正开始做之前,再把故事脚本细化为可以量化的Story。什么时候明确了需求,再去考虑为了完成需求的具体的Story。理论上在PlanningMTG的时候把近1~2周的计划列出来,进行相对的工作量估算后,就开始冲刺。如果能够这样的话,团队的效率是最高的。
    所以敏捷开发中提倡的就是一边开发一边去作Story。

    2.StoryPoint如何确定
    根据书上所说,先选出一个大小适中的Story作为模板,将Point分为1,3,5,8,13等相对数值来标示一个作业的工作量。每个Story最好能够在3天之内完成。
    我觉得相对于花时间去想去决定Point,还不如把时间花在项目本身上,Point只是一个工作量的标示罢了。每个项目都有每个项目的特殊性,Point也好,对一个Story使用百分比也好,只要能够将进度实现可视化就可以了。

    3.进度的自我管理
    用Story管理也好,用白板管理进度也好,用其他的进度管理方式也好。都只是进度管理的方法而已。真正清楚进度的人并不是项目主管,项目经理,也不是客户,应该是担当该要件的人。当你发现进度提前或者落后的时候,就主动想好原因对策以后,找ScrumMaster沟通吧。世界上没有完美的项目进度计划,项目中每个人的进度情况构成了一个项目的进度情况。使用好Story去管理进度,而不要依赖于Story去管理进度。

    4.Story仅仅只是为了进度管理吗?不是。
    进度管理只是他一部分的作用,利用Story不仅仅是进度管理,Story也是要件担当者和项目关系者(主管,项目经理,测试员,客户)之间的一个沟通模板。
    利用好这个沟通模板,才能更好的挖掘出客户的潜在需求,才能更好的将自己的成果频繁主动的展示给你的项目经理。拿着你做好的Story主动和他们去沟通吧。
    敏捷开发提倡频繁的沟通,如果没有良好而频繁的沟通,Story的作用效果也就大打折扣了。

    结束语:如果一个要件是一部电影的话,担当要件的人就是总导演,Story就是为了完成电影的一个个镜头。在设计软件之前,请先设计好你的Story把。一个个短短的镜头就构成了一部电影。做一个优秀的导演,从先设计好一个个短短的镜头(Story)开始。

    展开全文
  • scrum 敏捷开发story 规范讲解 标准story 写法,达成的目标
  • 对于story来说,一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估的Function Point,因为story point只是用来粗略的相对的估计story的大小,而Function Point则是用来衡量功能模块的精确...

    介绍:

    对于story来说,一个很重要的衡量它的大小的因素就是story point,它不等同于软件工作量评估中的Function Point,因为story point只是用来粗略的相对的估计story的大小,而Function Point则是用来衡量功能模块的精确大小并且要参与到公式计算的,这里澄清下。


    story point的估算是一门很深的学问,而且我们不能马虎,因为如果我们估算少了,那么就会导致实际我们的花费时间远高于估算时间从而导致team加班加点,如果估多了,会导致我们team很闲,team productivity很低,从而会面临削减resource的风险,因为这个很关键,所以我们估算必须要慎重, 而且都必须让一些很有经验的人估算,比如在我们team,这件事情多数由我和一个最资深的前端工程师来共同完成。


    实现方式:

    其实估算story point要根据历史数据,这些历史数据来源于我们的过去的报表,我们跑了几十个Sprint了,然后我们可以通过很典型的若干的sprint的比较,然后看那些sprint我们团队的运行能力来粗略的估算出我们团队能容忍的合理的story point的区间。


    比如我们列出如下的历史数据报表:


    104220815.png

    就拿最近5个sprint (S35-S39) 来说,我们可以比较 "Planned Story Point"和"Actual Total Effort" 2列。然后结合发生过的事情,有如下的证据:

    (1)Sprint 39是一个非常糟糕的例子,因为在这个sprint我在休婚假,所以并没有参与到Sprint Setup Meeting ,然后并没有去估算story point,事后也没时间去重新review, 所以整个团队在一个预先估计的一个很乱的story point下工作,大家都累瘫了。所以,虽然planned story point才22 ,但是实际上团队一共贡献了356.5小时去完成这些分配的story和sub-tasks,以至于最后3天我一看形势不对,我自己都去参与开发写代码了,因为我的主要职责是领导team和技术方面的support,很少能逼我冲到一线去写代码的。最终虽然按时完成了,但是实在太累,我后来反思了下,这个sprint应该安排在40个story point才算合理。

    (2)Sprint 35是另外一个极端的例子,这个sprint中,我们team接受了3个新成员,因为他们需要一定的上手期和获得可以使用的账号,权限等,所以这个数据毫无参考价值。

    (3)从纵观Sprint 36,37,38,总的说来这3个sprint都是运行的比较稳健的3个sprint,分别是276.2,276,269小时的总effort, 但是Sprint 36,team 非常忙,就算在code frozen day,我们还在做最后的bug fixing.而Sprint 37,我们有很高的质量,ST 只报告了1个defect, Sprint 38,虽然team 不紧不慢,但是我们是在最后一天才完成所有任务的。


    所以综上所述,我觉得对于我们的团队来说,放22-26个story point是一个很合理的区间。



    总结:

    在估算Story Point时候,一定要参考历史数据,历史数据越多,那么分配Story Point总量时给出的数据就更合理,否则无论算多或者算少,对于团队都是不利的。





    本文转自 charles_wang888 51CTO博客,原文链接:http://blog.51cto.com/supercharles888/1261146,如需转载请自行联系原作者
    展开全文
  • 对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。 Story概念: User Story 是从用户的角度对系

    Agile概念的比较详细的说明见:http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html

    Story概念:

    • User Story是敏捷开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。
    • User Story是从用户的角度对系统的某个功能模块所作的简短描述
    • 一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值
    • User Story是敏捷开发和管理的核心,要确保Story的输出质量。

    Story优点和好处:

    • Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
    • Allowing developer and client to discuss requirements throughout the project lifetime
    • Needing very little maintenance
    • Only being considered at the time of use
    • Maintaining a close customer contact
    • Allow projects to be broken into small increments
    • Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
    • May be easier to estimate development effort

    User Story划分原则(INVEST规则):

    • 独立性(Independent):一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。
    • 可谈判性(Negotiable):Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。
    • 有价值性(Valuable): Story需要体现出对于用户的价值。
    • 可估计性(Estimable):Story应可以估计出Task的开发时间。
    • 大小合适(Sized Right):关于Story的粒度,建议的开发工作量是3-5天(包含针对Story所做的开发者自测工作量),如果Story不能拆分到3-5天的开发粒度,则一定要确保该Story在一个迭代周期内可开发测试完成。
    • 可测试性(Testable):要从可测试性考虑需求,同时要考虑能够独立测试,每个任务都应有Junit Test。另外注意,伴随Story要同时输出可接受性测试用例(Acceptance Test Case,以下简称AT),用于验证Story是否开发完成,可以给测试人员做Story测试。AT用例在Story协作阶段只是对测试要点、场景的描述,在迭代开发阶段可以继续补充和完善。

    Task:

    • 为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。
    • 每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

    User Story模板:

    • User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that  I can <get some value>
    •  翻译成中文就是:作为一个<某种类型的用户>,我要<达成某些目的>,我这么做的原因是<开发的价值>。

    一些经验:

    • 永远不要在User Story中使用And和Or,因为这是些分支词就表示分支任务,把它们拆成两个Story.
    • 数据整理:通常情况下1个sprint(2周一次迭代)可以做4~5个Story,极端大的Story不可大于1个sprint。
    • 数据整理:通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
    • User Story用于描述用户故事,不要包括任何的技术,框架等内容。Task可以包括框架,技术等内容。

    展开全文
  • Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的...
    Story 演示活动可以帮助敏捷开发团队提高开发质量、降低返工带来的质量低下与进度滞后的可能性。本文以作者黄文海的实际敏捷开发与管理的经验为基础,分享了具体实施 Story 演示的注意要点以及如何控制 Story 演示的成本。本文分享的不仅是一个具体的敏捷开发实践,更是一种敏捷开发的思想和思维方法。
    此文发表在IBM developerWorks网站上:
    [url]http://www.ibm.com/developerworks/cn/rational/r-cn-agilestorydemo[/url]
    展开全文
  • 敏捷开发——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

    展开全文
  • 敏捷开发-Story划分

    2010-05-27 12:22:41
    1 Story划分能够根据INVEST原则:独立的(Independent)、可商讨的(Negotiable)、有价值的(Valuable)、可以估计的(Estimatable)、足够小的(Small)、可测试的(Testable),支撑后续分迭代进行开发;...
  • 谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度...
  • 1 从这里开始 第一部分我们将快速浏览什么是user stories...如何来编写测试用例,来证明你的Stories已经被成功编写的细节,最后将阐述几条编写好的Story的指导建议。 当你学完这部分之后,你就可以定义、编写、测试你
  • 对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。优点和好处Being very short. They represent small ...
  • 这几年关于敏捷开发在互联网企业越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  •  User Story敏捷开发和管理的核心,User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值...
  • 什么是敏捷开发中的Spike? Spike,如果需要翻译的话,中文可以翻译成“探针”,但是一般不会翻译而直接使用Spike这个词。 Spike可以理解为:以回答问题或收集信息为目的的任务,而不是生产非专业产品的任务。有时...
  • User Story敏捷开发和管理的核心,要确保Story的输出质量。Story划分这里强调几点要求: 独立性:一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。 可测试性:要...
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 敏捷开发中怎样保证开发任务的适宜呢?答案是任务分解。而任务分解的前提则是需求确认。 敏捷开发中的需求确认 我们都知道需求的来源渠道很多(如用户调查问卷,用户访谈,客户服务人员/商务人员的反馈,产品的...
  • 敏捷开发---Story设计

    2011-10-26 17:32:59
    在迭代开始后,通常以一个一个Story分别完成开发的。先由SE给Story开发人员、测试 人员以及资料人员进行需求串讲工作,详细介绍Story的业务实现和功能要求。 开发、测试、资料人员以头脑风暴的形式一起讨论...
  • 敏捷开发---Story编码

    2011-10-26 17:26:27
    Story编码 编码规范学习:开发人员在开始代码前,PL要组织大家对编码规范进行学习,在编码过程要严格按照编码规范进行执行。 功能代码实现:开发人员开始实现功能代码,做好UT,并及时重构。有条件的可以按TDD...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,...
1 2 3 4 5 ... 20
收藏数 4,310
精华内容 1,724