敏捷开发故事点_敏捷开发 故事点 - CSDN
  • 故事点这个概念大家应该很了解了,实际上就是对在sprint里面要开发的user story进行一个粗量级的估算,以便于团队能够知道这个user story的复杂度(工作量),但是这里有个容易引起混淆的地方,就是传统意义上的敏捷...

    彼此上篇文章说完了计划会议,我们今天来一起探讨一下计划会议里面一个很重要的环节,那就是故事点的估计。

    这里写图片描述
    故事点这个概念大家应该很了解了,实际上就是对在sprint里面要开发的user story进行一个粗量级的估算,以便于团队能够知道这个user story的复杂度(工作量),但是这里有个容易引起混淆的地方,就是传统意义上的敏捷,是用来度量规模和复杂度。使用‘规模’和‘复杂度’这两个词,是要表达‘用完成任务所需时间来表示难度’。

    从上面可以看出,由于故事点事对于规模和复杂度的估算,所以,首先他是一个不精确的值,第二,它应该是一个相对的值,由此来看,故事点是一个粗略的相对估算而不是精确估算。

    那么故事点的估算目的是什么呢

    这里写图片描述
    作为PO来讲,他在梳理PBI和SB的时候,可能是想知道团队多久能交付产品,每个迭代能够交付多少用户故事,所以故事点可以解决PO的这个困惑。我们可以通过估算故事点,然后统计多个迭代团队交付的故事点数,然后相对的得到一个团队的交付能力,比如说每个迭代交付20个点的用户故事,那么如果PO有一个由100点的用户故事组成的产品,那么可以得知5个迭代完成这个任务。

    也可以得到团队的交付速率和交付能力的历史数据,用来进行团队回顾的数据依据。

    在估算的过程中,因为所有团队成员都要参与,大家对于故事的理解不一样会造成估算的不同,这样就需要PO和团队成员之间进行需求的澄清,也是一个分析用户故事需求和澄清的过程,能够让大家更好的理解用户故事。

    故事点估算的到底是工作量还是复杂度

    这里写图片描述
    在现实开发环境中,大家往往会有一个理解上的难点,到底故事点估计的是工作量还是复杂度呢?
    从PO角度来讲,肯定需要得到的是工作量,这样也能第一时间知道产品开发的进度还有风险,但是如果估计的是工作量的话,那么要和实际开发的人有关系的,因为同样一个特性,对于熟练工和新手的工作量是完全不同的。

    如果只是作为复杂度来估计的话,那么产生的问题是:产品开发的复杂度在不同团队和不同人员之间也是不一样的,而且在现实开发环境中,对于复杂度的操作很难进行,有的时候大家会觉得费时费力。

    从我个人来讲,在敏捷不断演进的过程中,现在故事点实际上是一个综合的对于用户故事的复杂度,规模,甚至还要加上承诺时间的一个度量了。也就是说团队可以不必过度纠结在用户故事的度量上,而是重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD来完成这个用户故事,如果不能完成,给出理由,由PO来决定是否拆分或者重新设计用户故事。这样带来的一个问题可能是PO在梳理PBI的时候无法得知整个产品的全部完成时间,因为团队的历史交付数据可能不是一个稳定的速率(每个sprint交付的点数差别会比较大,因为更注重用户故事本身和交付承诺)

    怎样更好的运用故事点估计在计划会议中

    可以分为几种情况:
    1. 如果是新的一个团队,那么建议针对用户故事进行估点,这样一个能够使得团队尽快的熟悉起来,澄清需求,建立很好的沟通机制。
    2. 如果是一个很成熟的团队,对于产品比较熟悉,那么这个时候故事点估计就不是十分必要了,因为大家都很熟悉产品特性,所以对于所需的工作量也是相对准确的,这个时候可能就需要团队给出工作量的估计,让PO对于产品的开发更好的进行进度和风险控制。
    3.如果可能的话,针对不同的用户故事类型设计不同的基准故事点,比如说开发的故事基准和测试的故事基准,实际上的工作量和复杂度是完全不一样的。

    展开全文
  • 作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了; 基于小时的估算是不精确的,不同人在同一个...

    一个团队/个人花 10 小时能完成的任务,另一个团队/个人或许需要 100小时;

    也有可能团队花了 100小时但是什么都交付不出来;

    作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了;

    基于小时的估算是不精确的,不同人在同一个任务上要花不同的小时数;

    花了几个小时在一个任务上不等于这个任务有一部分被完成了, “部分完成”是一个隐藏问题的危险状态,应该避免使用;

    故事点估算更简单和敏捷,虽然它很难使用。  

     
    基于“小时估算”及基于“故事点”监控的差异,一直是一个具体而微妙的问题,令很多初涉敏捷的组织迷惑。(引用作者的用词,)这真是一个“干净利落”的案例。 能正确使用“故事点”来估算及后续监控,理应不会出现任何异议。但学界也仍然有诸如Mike Cohn 等导师级人物仍认为 Ideal Hours是可用的。我个人的理解,其思路与作者有一点关键不同:在燃尽图更新时,视角并不是记录“已消耗工时”,而是再次估算“剩余工时”。换个角度看,燃尽图的更新体现了一个不断估算的过程。再者,遵守“只有彻底完成的Task才能在燃尽图上获得分数”的规则,也可能有效的避免此问题。 个人体会:从 Burn down的价值取向分析,(彻底)完成了多少、(到底)剩余多少,是重要的;既有的成本投入,不太重要。

    展开全文
  • (之一,之二,之三,之四,之五,之六,之七) 直接估天数或用故事点估天数,都很“程序员”。如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统计公司绩效并想进行项目乃至行业间的比较,这两种方法...

    这是敏捷开发绩效管理的第六篇。(之一之二之三之四之五之六之七

    直接估天数或用故事点估天数,都很“程序员”。如果在项目的甚早期,面临与客户相关的报价问题,或高层领导要统计公司绩效并想进行项目乃至行业间的比较,这两种方法都很难使用。

    敏捷开发内部之所以没有进化出来能做项目间比较、行业间比较、用于早期报价的估算方法,是因为敏捷的发明者和后来的实践者多数都不管这些事情。而这三样事情,比天数、故事点,在老板眼中更接近生产率绩效。

    这时候就需要功能点估算。

    功能点估算


    由来

    功能点估算是另外一个世界的事情。每100个懂敏捷的人中,可能才有1个懂CMMI;而懂CMMI的人中,可能才有100个懂功能点,而100个懂功能点的人中,也只有1个人懂敏捷……这就是三个世界,但每个世界都和敏捷世界一样热闹,一样有可操作的方法,只是互相不通信而已——结果是,每个世界都不知道别人已经早就解决了自己冥思苦想的问题

    用功能点度量软件的目的,是在早期获知软件开发的工作量,进而推算开发成本。 由于这个目的,使得它实际上是与开发工作量的相关性也最强(远远超过Delphi/代码行/故事点/用例点……多个国家的政府使用此估算采购软件,中国大约2年就后采用),而且居然和用户故事还有很好的对应关系。

    功能点本身很复杂,大家可以在网上查到一些资料,这里不多说了。标准功能点分析尤其复杂,有一次有一个欧美发包商来到中国,问“我们现在已经有100多页文档,谁看过之后知道这个项目要多少钱才能开发出来,以及为什么,我们就把这个项目给他。”笔者介入了此事,也知道标准功能点能解决这个问题,但是却不能在给定的时间内完成(只有2天的时间解决此问题,而用功能点至少需要10~15天)——国外ISBSG也转发度量Guru Capers Jones的邮件称“只有极少数的项目采用了功能点估算,因为成本太高”。这件事情促使笔者尝试找简单的功能点估计方法,直到后来在另外一个世界发现有人早就解决了大约10年了……那就是NESMA的简化功能点,如果不嫌麻烦请参阅http://www.nesma.nl/section/fpa/(点击左边 Advanced 下面的 Early&Fast FPA)。

    不过建议直接看下面。下面的概念作了很大的调整以便于用有限的文字理解,如果有懂FPA的读者看出破绽不要奇怪(本人是正规做FPA培训和研究的)。

    什么是简化的功能点估算

    在我们的开发工作中一共有两类东西要开发,一种是数据,一种是操作。

    所谓数据,就是比如要编写一个CRM,其中有“用户、角色、权限”这三种东西,就是要管理的数据,这里权且记下用户有“3个数据”要管理。

    所谓操作,就是对用户,应该有增、删、改、查、加入角色……这些称之为操作,这里权且记下对用户,用户会做“5个操作”。

    倘若角色和权限没有操作(虽然这是不可能的),那么在NESMA简化方法中由于每个数据是7点,而每个操作是4点左右,那么就可以算出来一共有:

    3 × 7 + 5 × 4 = 21 + 20 = 41点。

    ISBSG/IFPUG包括中国的CSBSG等都有不同行业/不同类型软件的生产率统计,如果你在中国,用C#或Java开发一个类似OA/CRM这样的业务流转软件,那么生产率大约是9小时/功能点(来自于10多个学员的课后数据),也就是上面那个小软件,要用9×41 = 369小时大约是46人天。

    “什么?这点内容我不到一星期就能做完。”是,也不是。这一时间的包含了需求分析/设计/编码/测试/集成/上线部署期间的所有时间,还包括开会讨论的时间,和别的功能联调的时间,培训的时间,修改万恶的Bug的时间,提升性能的时间,改善易用性的时间,上网找图标的时间,上班看博客的时间——总之一个真实项目中可能发生的时间全都平摊在这里。

    听起来够简单了,但其实还不够。

    谁能拿出2页纸的需求文档(假设昨天老板在酒桌上刚从客户那记下来的),就猜出有多少个操作?而且还不遗漏?增删改查好猜,“加入角色”就不好猜了。

    怎么办?请看下文。

    点击下载免费的敏捷开发教材:《火星人敏捷开发手册

    转载于:https://www.cnblogs.com/JPAORM/archive/2011/08/26/2510453.html

    展开全文
  • 敏捷开发目前已成为互联网公司的首选方案,为应对市场的快速变化,我们公司也在大力推广敏捷,最近在读《用户故事与敏捷方法》一书,我想边读边做一些分享,传播知识的同时加强记忆。 1.  基于用户建模是一个比较...

               敏捷开发目前已成为互联网公司的首选方案,为应对市场的快速变化,我们公司也在大力推广敏捷,最近在读《用户故事与敏捷方法》一书,我想边读边做一些分享,传播知识的同时加强记忆。

    1.       基于用户建模是一个比较好的起点。

    产品团队可以采用头脑风暴等形式,挖掘出产品实际存在或者潜在的用户或客户,给他们一些角色。

    多种角色出现重叠时,再将重叠部分成立一个独立角色。

    比如“运维角色”和“部署角色”都需要做一件事情:做数据修改,那么我们就考虑一个“数据修改角色”专门做这个事情,然后“运维角色”和“部署角色”就都不包含这个职能了。

     

    再然后呢,给每个角色找一个生动的虚拟人物来代替,让团队熟悉这个人,就像身边的一个朋友一样了解。

    例子:“借款人角色”,代表人物叫“张穷”,30岁,小餐馆经营者,这两年生意做得不错,想扩大店面,但是手头吃紧,正绞尽脑汁想找一笔贷款。

     

    用户建模时,可以考虑一些特殊的人群,他们有助于发现一些细致的需求。比如老太太需要屏幕字体够大。

     

    2.       寻找用户。

    最理想的方式是能够找到软件真实的使用者,了解他们的需求。

    条件不成熟的情况下就只有寻找用户代理,不同的人群都可以担任用户代理,但是要注意不同的用户代理看待问题大多是从个人需要出发的,要摸清他们的一些小脾气。

    实际用户的经理:他们对于产品细节的关注度可能不高,因为他很可能平时不做实际操作,对于群众疾苦了解得不够;他们可能会过分关注一些管理功能,比如任务调度、查看每个手下现在的任务完成情况等,而这些功能很可能不是产品核心的东西。

    开发经理:他们通常缺少对软件的实际体验,其内心驱动因素很可能是业务压力或者成就感,这样的动机很容易背离产品核心业务价值。

    销售人员:他们的核心价值观通常是尽量多的订单,为了不丢单,他们总会承诺“没问题”,各种稀奇古怪的东西都想丢进产品里面,使得产品没有规划、随遇而安。

    领域专家:他们通常能够在产品设计上提供很大的帮助,但要小心他们弄出一个太“高大上”的东西,不接地气,让小白的用户觉得软件极其难用。

    系统分析师:他们是很有想法的文艺青年,既懂技术又懂业务,是很好的用户代理。但要小心他们的空想症,他们有可能花上两天去精心设计一个业务流程,但根本没有做过任何调研。最坏的结果是最后不得不推翻一个精心雕琢的楼阁,浪费、肉疼。。

     

    3.       切割故事。

    传统的切割方式大多是按实现层面或者技术栈来切割,比如一个功能别切割为前台、后台、数据库几个任务,或者按照技术栈切割为java相关、C#相关、移动端几个任务。

    这样的切割方式最大的问题是:单个任务不能产生业务价值、相互依赖导致无法快速交付并得到反馈。

    推荐做纵向的切割,每个故事尽量是一个功能闭包,一个故事完成意味着一个功能可交付。

    以京东提交订单功能为例,其业务流程为:基于预先选好的商品信息,先选择支付方式、再选择配送方式,然后提交保存。

    传统的切割方式可能为:

    T1: 前台交互实现(选择支付方式、配送方式),形成可提交的订单数据后提交给servlet

    T2:后台接收订单数据,保存到数据库,给成功提示。

     

    考虑换一种切割方式:

    S1:基于预先选好的商品信息,使用默认支付方式和配送方式,提交订单并保存。

    S2:支持用户选择支付方式并保存订单。

    S3:支持用户选择配送方式并保存订单。

     

    我们不要写哪种大而全的故事,一个故事只为一种客户编写,只满足其一个小小的业务价值。

    编写故事时尽量避免涉及界面的描述,这会诱导开发人员按照某人脑海中印象来实现功能,这实际是把设计意图强加到故事之中,更致命的是会隐含的扩大故事范围。

    比如这样一个故事:

               在首页的右上方,用户可以看到“注册”按钮并点击它,之后弹出一个对话框,用户录入注册信息后,点击提交按钮,若注册成功就回到首页,并发送激活邮件。

    它的问题:

               涉及太多的界面信息,它阻止了开发人员或者分析师跟客户做进一步沟通的欲望,也许这样的交互设计是蹩脚的呢?

    考虑写成这样也许更好:

               在首页醒目位置可以进行用户注册,注册成功需要发送激活邮件,注册失败需要失败提醒。

     

    下期分享:故事估算和制定计划,谢谢围观~~

    展开全文
  • 敏捷开发中,团队成员认领的是任务还是用户故事
  • 简要介绍《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后,成功向敏捷开发转型的故事。 作者通过4个迭代开发过程,展现了主人公是如何从一个敏捷开发的新手...
  • 敏捷故事点与时间

    2017-03-13 15:29:32
    在Scrum培训中,经常有人问:故事点和时间怎么对应?忘记了那本书上曾经有个大牛举了个例子,把系统中最简单的一个功能时间作为故事基准点,比如一个网站登录功能,从开始到发布大概需要8小时也就是1个人天作为故事...
  • 一期:活动描述,之一,之二,之三,之四,之五二期:活动描述,之一,之二,之三,之四,之五,之六三期:活动描述,之一,之二,之三,之四,之五 利用功能数据对业务数据和业务操作进行早期快速估算陈勇-创业-...
  • 再次参与敏捷开发项目2年多了,期间有敏捷教练的指导,也有实践的一点感悟:由于...有价值与小步快跑:也决定了它以故事点—有价值的小颗粒的形式,进行交付。这块的核心就是:以Story的形式进行迭代价值交付。Part2
  • (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致...
  • 故事点敏捷项目管理和开发中的一种抽象的度量单位,用于估计实现一个或多个用户故事的复杂度,它是对工作量的一种描述方式。一个故事点就是一个数字,透过这个数字告诉整个团队用户故事的复杂度。复杂度包括功能...
  • 高质量的估算能够帮产品负责人优化效率和冲突。因此,精准估算的重要性毋庸置疑。...敏捷估算并不是什么性命攸关的大事,就只是估算而已,事实就这么简单。我们不用要求团队周末加班加点来弥补一项...
  • 初识敏捷,接触到下面这些这些新词汇。...Scrum来自英式橄榄球,敏捷开发的团队就好比一只橄榄球队,他们拥有明确的最高目标,而且每时每刻都朝着目标努力,他们熟悉最佳实践,高度自我管理,高度协作...
  • 对于一个故事,开发人员和客户可能会讨论很多,讨论的内容可以以测试用例的形式记录下来,这样就为我们故事测试做了铺垫,目前敏捷开发中测试大约有如下2个步骤  1、将测试要点记录到敏捷的故事卡的背面,任何时候...
  • 敏捷开发故事

    2015-04-19 15:45:48
    需求澄清后,SE把所有的故事卡贴到故事墙上,等待开发人员的开发故事墙的模板为: 分析 : 需求澄清完成后,SE把所有的故事卡都贴到分析阶段 等待开发开发人员和SE确认了需求,明确了做什么以及怎么做以后...
  • 浅谈敏捷开发

    2020-04-11 14:29:17
    浅谈敏捷开发 敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 章节 ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 什么是用户故事? 用户故事(user story)是一个用来确认用户和用户需求的简短描述,作为什么用户,希望如何,这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为:作为一个&...
  • 通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster. ...
  •   敏捷估算,就是在敏捷开发中,对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下,软件开发过程中有很多未知数:技术更新,需求变更,系统之间的依赖关系等,它们都会影响估算结果,所以说...
1 2 3 4 5 ... 20
收藏数 18,389
精华内容 7,355
关键字:

敏捷开发故事点