敏捷开发估算扑克_敏捷扑克估算 - CSDN
  • Unlimax 敏捷计划估算扑克

    千次阅读 2014-01-02 13:28:04
    用于敏捷开发的Scrum开发团队估计故事(Story)的故事点(Story Point)。 计划扑克玩法 参加游戏的开发人每人各拿一叠扑克牌,牌上有不同的数字。客户或者产品责任人为大家挑选 1 个 Story(Backlog),并简单...

    计划扑克介绍

    所谓“计划扑克”(Planning Poker)是一种标有一系列数字的扑克牌。用于敏捷开发的Scrum开发团队估计故事(Story)的故事点(Story Point)。

    计划扑克玩法

      1. 参加游戏的开发人每人各拿一叠扑克牌,牌上有不同的数字。
      2. 客户或者产品责任人为大家挑选 1 个 Story(Backlog),并简单解释其功能,以供大家讨论。
      3. 每个游戏参加者按自己的理解来估计完成这个 Story 所需的时间,从自己手中的牌里选 1 张合适数字的牌,并发展示给大家。
      4. 游戏参加者各自解释选择这个数字的原因,尤其是数字最大和最小的人。
      5. 根据每个游戏参加者的解释,重新估计时间并再次出牌,直到大家的估计值比较平均为止。

    得意 在这个游戏中需要注意的是:首先,这不像普通的扑克游戏,不是轮流出牌,而是大家考虑好之后同时出牌,这样就可以避免后出牌的人被先出牌的人干扰;其次,要告诉团队成员,他们需要估计所有的 Story,而不仅仅是他们自己将要做的那些部分,比如测试人员不能只估计测试工作所需要的时间。

    Unlimax的计划扑克  购买

    (消息) 一副扑克有4种花色,可供4人同时使用,如果团队大于4人,可使用多付扑克组合使用。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 每种花色有13张牌。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 0表示认为所选Story非常简单,根本不需要精力就能完成;

         ?表示根据已知情况,无法评估Story需要多少故事点;

         咖啡杯用于提示团队成员该休息了,实在太累了(吐舌)

    敏捷计划估算扑克 - Tennille - 观点

    (消息) 大小王分别用中英文,告诉团队如何使用计划扑克估算故事点。

    敏捷计划估算扑克 - Tennille - 观点

    (消息) Unlimax的计划估算扑克可通过淘宝网店在线 购买

    敏捷计划估算扑克 - Tennille - 观点


    展开全文
  • 估算敏捷方法:策划扑克

    千次阅读 2015-02-25 19:08:55
    策划扑克估算软件规模的一种敏捷方法。 该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度...



        策划扑克是估算软件规模的一种敏捷方法

    该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度等其他因素的度量。故事点并非业界统一的一个度量单位,不象度量长度的单位:米,大家都知道1米有多长,你说的1米和他说的1米是等长的。故事点仅对本项目具有近似相等的规模,不同的项目所定义的故事点很可能是不等的。  

             
        策划扑克法参与的人员包括了所有开发人员:程序员、测试人员、数据库工程师、分析师、用户交互设计人员等等,在敏捷项目中一般不超过10人。 产品负责人参与策划扑克法但是并不作为估算专家



        策划扑克法的步骤为:
        (1) 每位参与估算的开发人员发放一副估算扑克,扑克上边的数字标为斐波那契序列:1,2,3,5,8,13,20,40。
        (2) 选择一个比较小的用户故事,确定其故事点(3-4人天的工作量),将该故事作为基准故事。
        (3) 选择一个用户故事。
        (4) 主持人朗读描述,主持人通常是产品负责人或分析师,当然也可以是其他任何人,产品负责人回答估算者提出的任何问题,大家讨论用户故事。
        (5) 每个估算者对该用户故事与基准故事进行比较,选择一个代表其估算故事点的牌,在主持人号令出牌前每个人的牌面不能被其他人看到,然后大家同时出牌,每个人都可以看到其他人打出的牌。
        (6) 主持人判断估算结果是否比较接近,如果接近则接受估算结果,转向(3)选择下一个故事,直至所有的用户故事都估算完毕,否则转向(7)。
        (7) 如果结果差异比较大,请估算值最高及最小的估算者进行解释,大家讨论,时间限定为不超过2分钟。如果大家同意,也可以对该用户故事进行更细的拆分
        (8) 转向(5),一般很少有超过3轮才收敛的现象。


        在该方法中,参与的人员对于被估算的需求进行了充分的沟通,并综合了程序员、测试人员等各个角色的专家观点,融专家法、类比法、分解法为一体,可以快速、可信、有趣地进行估算。


        在估算完故事点后,可以凭经验估算一个故事点的开发工作量,从而得到所有的用户故事的工作量。也可以进行试验,试着开发一个用户故事,度量花费的工作量,得到开发效率,即在本项目中一个故事点需要花费多少工时,再去估算所有故事的工作量。

    展开全文
  • 敏捷扑克估算 许多敏捷和Scrum团队从基本实践入手,以使自组织团队能够更好地交付业务优先级。 实践包括承诺团队可以在冲刺中完成什么工作,举行日常站立会议以管理进行中的工作,为利益相关者主持演示以展示已完成...

    敏捷扑克估算

    许多敏捷和Scrum团队从基本实践入手,以使自组织团队能够更好地交付业务优先级。 实践包括承诺团队可以在冲刺中完成什么工作,举行日常站立会议以管理进行中的工作,为利益相关者主持演示以展示已完成的工作以及组织回顾以讨论流程改进。

    使用这些基本实践,小型敏捷团队可以通过提供渐进式改进并让利益相关者权衡新的优先事项来展示业务价值。

    [了解您的企业如何在敏捷开发中脱颖而出 | 将您的敏捷职业提升到新的水平: 如何提高您的Scrum Master技能 | 不确定“敏捷”的真正含义是什么? InfoWorld 解释了敏捷方法论 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

    随着组织和团队在敏捷实践中日趋成熟,他们通常会面临新的问题。 领导者可能会问:“您能告诉我我们优先考虑的功能何时完成吗?”或“您能与我分享在未来几个月内可能会完成的功能清单吗?” 产品负责人可能会问:“此增强功能有多昂贵和复杂?”,运营团队可能想知道,“您能否在下一个Sprint中压缩这些缺陷修复程序?”

    致力于过程改进的团队通常会在敏捷过程中遇到相关的生产率和质量问题。 许多敏捷工具可以衡量团队速度 ,或在短跑中可以完成多少团队,而团队将需要定义,测量,稳定并理想地提高他们的速度。 更高级的团队通常希望在许多sprint中查看其整体性能:处理许多小故事或几个大故事时,它们是否提供更高的质量? 如果团队成员长时间休假会产生什么影响,或者如果将新人员加入团队,他们还能承担什么呢?

    什么是敏捷估算

    如果您遇到这些问题中的任何一个,则您的组织或团队可能已准备好实施敏捷估算。 敏捷估算旨在为积压中的所有事项分配成本因素。 然后,此成本权重可用于衡量团队速度,围绕功能优先级做出更好的决策,或用于制定预测和路线图。

    关于是否实施敏捷估计存在一些争论。 #NoEstimates周围有动静 ,也有专家在使用估算值 如果您负责组织中实施估算的工作,那么通读这些论点很重要。 让人们进行估算并不容易,您可能会发现不想参与的人。 了解辩论将帮助您回应团队或个人的建议或异议。

    敏捷估算要求您提出一种方法,以了解团队应如何就估算达成共识。 您可能会听说有关计划扑克,存储桶系统,相似性映射和其他估算技术的信息 在我的工作中,我通常授权团队决定如何协同工作以得出估计值,但是我确实提供了一些指导原则。 估算应反映正在处理的问题的工作量和复杂性,并应考虑每个人的工作。

    相关视频:敏捷方法的真正作用

    似乎每个人都在谈论敏捷软件开发,但是许多组织对流程的运作方式没有把握。 观看这5分钟的视频,以加快速度。

    用故事点数与小时数进行估算

    为了给团队提供有关估算的具体指导,应该为度量单位进行讨论和确定标准。 还是在这里,关于是否要以小时为单位进行估算,这是一种称为故事点的抽象度量,还是带有T恤尺寸之类的标签,这引起了一些争论。

    一些团队从T恤尺码入手,因为它更易于理解和沟通。 与“特大号”相比,“小号”可能更容易做到,与“十小时”或“八分”的估算值相比,团队,产品所有者和利益相关者可以更轻松地思考这些术语。 。”

    但是使用T恤尺码无法量化,因此很难用于测量速度或进行分析。 随着评估实践的成熟,许多团队将从T恤尺寸上毕业。

    工时是在团队执行更为标准化的,具有较低复杂性或相关风险的任务时使用的良好指标。 如果任务的类型适合于基于工作量的准确指标,那么知道修改用户界面的故事将花费两个小时的时间就很有价值。

    但是,软件开发和其他业务流程的精确度较低,未知数更多,并且通常需要多个具有不同技能的人员做出贡献。 如果您的故事需要与新的API交互,开发前端小部件并确保交付满足目标性能标准,则可能很难在工作时间内对故事进行衡量。 使用新的API存在风险,并且两个或多个人员之间可能需要协调才能实现代码和测试用例。

    许多团队使用故事点来表示估算中的工作量和复杂性 较低的故事点表示复杂度低,工作量少的故事,而较高的故事点表示整个团队的复杂度和工作量。 许多团队根据斐波那契数列来分配分数,因此,复杂性和工作量的增加会导致故事分数的呈指数增长。

    此外,最好的团队会在分数分配中使用一些合格的语言。 例如,一个团队可以将三点故事限定为不需要任何后端或API更改的微小更改或增加的用户体验。 您会看到,这种资格限制了可能是一名前端Web开发人员的努力和风险,因为所做的更改仅在Web层中实现。

    燃尽图和技术债务还有其他含义

    通常,团队需要数次冲刺才能标准化他们的估算方法。 但是一旦完成,有几种重要的使用方法。 团队应该通过了解他们的速度以及要提交的故事类型和大小来融合故事的方式,从优化承诺和开发过程开始。 团队应该更好地了解他们可以最佳地执行多少个中小型故事。 许多团队认识到完成大型故事所需的风险和协调,因此他们在冲刺中只承诺很少的大小故事。

    现在,大多数敏捷管理工具中可用的Sprint燃尽图可以通过估算值加权,并用于优化Sprint期间的工作。 此外,史诗级和发行级燃尽现在具有更多意义,因为它们可以帮助团队在开发过程的早期专注于更高的价值和风险故事。

    对于具有自动CI / CD管道和更频繁发布的团队而言,估计的故事成为决定如何管理开发管道的宝贵工具。 可以在功能分支,具有功能标志的中型分支以及直接提交给主开发分支的较小更改中更好地管理运行时间较长的功能。

    [InfoWorld的要点: CI / CD入门:使用CI / CD管道自动执行应用程序交付 CI / CD的5个常见陷阱-以及如何避免这些陷阱 ]

    最后,团队可以开始衡量其技术债务的规模。 当发现债务并积压在债务中时,应为解决债务的工作量和复杂性分配一个估算。 当团队将技术债务案例添加到其积压中并进行主动估算时,他们现在就可以衡量总技术债务。 他们还可以报告每个Sprint和发行版中优先考虑和解决了多少技术问题。 由于大多数开发团队都对技术债务的数量充满热情,因此使用估算来衡量这是使团队参与估算过程的一个好方法。

    相关视频:如何使用CI / CD更快地交付代码

    这个3分钟的视频说明了如何使用持续集成和持续开发来更快,更高质量地交付应用程序。

    使用估计来驱动优先级

    一旦团队对他们的估计有了信心,就可以与产品负责人和业务负责人一起使用。 首先要制定一个计划过程,该过程旨在使功能的所有故事都得到编写,确定优先次序和进行估计。 一些组织在执行其开发工作的同时执行敏捷计划,而其他组织则为计划制定单独的冲刺周期 在我的《 数字驱动》一书中,我分享了一个故事写作的两个阶段,其中在第一阶段起草和评估了“故事存根”,然后在第二阶段中将优先存根完整地写成故事并重新进行了估计。

    估算功能后,团队可以与产品负责人就其范围和优先级进行更多数据驱动的讨论。 具有五个故事和35分的功能A是否比具有两个故事和12分的功能B重要? 或者,如果简化了功能A的要求,则可能导致估算值减少。

    当团队在他们的积压订单中估计多个功能时,这还可以导致更好的发布计划和与产品所有者一起制定路线图。 团队可以查看工作的类型和故事的大小,并提供有关在即将发布的版本中可以最佳使用哪些功能的选项。

    什么应该与敏捷估计完成

    在很多地方使用估计值都是有问题的。 首先是组织应用时间跟踪并希望将应用于故事的实际时间与估计时间进行比较。 在估算故事点时,这种比较效果不佳,因为点通常代表复杂性和努力。 即使以小时为单位进行估算,团队也最好根据承诺和维持或增长速度的能力来评估交付,而不是仔细检查单个估算。

    其次是管理者尝试使用估算值进行资源分配时。 他们可能建议团队中的一个人可以从事更多的工作,因为他或她分配的分数比以前的冲刺少。 这种逻辑存在严重缺陷,因为敏捷团队并未完全考虑所有团队成员参与完成用户故事的情况。 这种资源管理形式相当于微观管理,但这阻碍了敏捷团队的成功,而敏捷团队的建立是建立在信任团队做出诚实承诺的基础上的。

    一个类似的问题是管理人员是否尝试使用分配和估算来衡量个人绩效。 同样,评估和分配团队在管理其优先级时所做的并不是审查个人生产力的最佳工具。

    综上所述,今天您会发现更多的团队使用敏捷估算来提高团队生产力,质量和业务一致性。

    翻译自: https://www.infoworld.com/article/3300158/how-to-do-agile-estimation-the-right-way.html

    敏捷扑克估算

    展开全文
  • 估算是经久不衰的管理话题,大致分为两种流派。第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是...

    本文是“松结对编程”系列的第三篇。(之一之二之三之四之五之六之七之八,此系列之九及之后文章请见栏目总目录。)

    估算是经久不衰的管理话题,大致分为两种流派。

    第一种是领导指派,领导说这是10天的活,就必须当是10天的活来干,如果干不完,可以用加班、损失质量、功能缩水等各种方法曲线救场。另一个变种是大家自己估算,但是交给领导审批;领导审批其实就是砍一半的过程,还好大家之前就已经加了一倍,所以不怕。

    第二种是自我管理派(偏敏捷),就是由具体开发的人员自己说开发工作量,领导和他人不干预。尽管“自组织”了,但是领导深以为这种方法留下了偷懒的种子,而队员也觉得某人的估算很不靠谱(太长或太短),到底怎么办呢?

    共同估算吧。

    --------------------------------------------

    基本概念

    假设现在是一个计划会上,PO(产品经理,策划组长,项目经理,某销售……)刚刚讲完需求,下一步不是交给某人做估算,而是交给某个潜在的组(师傅+1~3徒弟)。

    由师傅带头打牌,对,在计划会上玩扑克:

    1. 大家各自思考可能要花多久时间完成任务,扣一张牌出来;

    2. 师傅喊开牌,大家亮牌,比较大小;

    3. 一般最小和最大的两个人PK,说出自己的观点,大家一起讨论;

    4. 差异无非来自于两个方面:做什么,怎么做;PO参与讨论回答做什么的问题,师傅和徒弟们讨论解决怎么做的问题;

    5. 讨论过后再来几轮,直到大家觉得结果差不多了。

    扑克牌估算的匿名性和开放性保证了大家不会人云亦云,也不会因为缺少沟通而难以达成一致。

    笔者的经验是一局扑克牌估算大约持续1~5分钟,还是很快的。偶然有黄庄的,一般都是因为PO那里回答不了做成什么样子,某某附加功能是否也要做……等等问题时。

    几个问题

    1. 为什么分给组而不是个人?

    不分个人就打牌使得每个人都不得不思考,因为怕出错了牌又说不出所以然。这样即使日后他不做这个功能,也对这个功能很了解。

    2. 为什么不让最后领任务的人自己估算?

    因为他很可能因为不知道某代码可用、不知道某软件不行、不懂template(我们因此扔过1个人月代码)……而选择了错误的实现方法。

    3. 为什么不让师傅估算大家采纳,他不是最厉害吗?

    师傅的想法常常是徒弟们理解不了的——比如为什么不留在女儿国而偏偏去西天取经之类的,呵呵——共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

    4. PO怎么还参加?不是不让别人干预吗?

    很多问题比如在游戏中“显示武林排行榜”,具体工作量可能不在于怎么做而在于做什么:凭什么排名?排多少名?实时排名还是每周排名?怎么显示排名?……因此PO不能写出一堆文档,然后以不便干预估算为名不参加敏捷计划会议。

    PO可以挑战估算,比如:“这真的要这么久吗?我记得上次……”但要有理有据。其实实践中更容易看到的是,团队往往过于激进乐观,PO反而要让他们意识到完整的需求和要求,做出更现实的估算。估算不准确,PO也有责。

    5. 一直无法达成一致怎么办?

    其实估算不是为了最后那个数字,而是弄清楚做什么和怎么做的问题,如果这两件事情清楚了,但结果却是偏偏有人说4天有人说6天,随便取个数就可以了(事实是应该按墨菲定理取6天)。有师傅在,一般很少会就实现方法争执不下;有PO在,一般很少会就要实现什么争执不下。

    不排除有特殊情况比如PO发现自己也没想过排行榜凭什么排行,那么就应该搁置此用户故事;又比如大家觉得如果数据库给力可能实时排名也行但又拿不准,可以暂时搁置到开发的时候再说,但把故事上标注一下“若需要每周自动排名+1天”。如果经常黄庄,Scrum Master要分析总结避免。

    6. 四个人出牌不同,师傅先说还是徒弟先说?

    想起个脑筋急转弯:科学家 医生 士兵 护士 ……等等一群人在飞机上,飞机结冰快坠落了需要有人(可能不止一个)跳下去,问谁跳?答案是从体重最重的人开始跳,因为可以少跳几个。

    因此我们是出牌数字最小的先说,和师徒无关。因为他极有可能掌握最佳实现方法。如果后来发现不是如此,请参考下一条。

    7. 都有什么理由可陈述?

    按下面的顺序,越靠前的越接近真理,感觉自己接近真理的就一定要举手先说,马后炮招人嫌:

    经验事实:我以前做过……咱们有个类库……那个方法我试过不可行……

    蛛丝马迹:谁还记得上次……听说隔壁……与上回相比……你以前不是……

    逻辑推理:理论上说……我觉得……

    几个注意事项

    1. 小组内不要有强分工,否则大家会缺省认为肯定是某人的工作。

    2. 师傅不要太抢眼,要通过估算鼓励徒弟思考,同时也掌握徒弟的真实水平。

    3. 师傅不要太较真,编程规范、易用性、易维护性这些纪律不能放松,但如果徒弟想尝试一种不同但工作量也差不多的方法,可以适当鼓励。

    4. Scrum Master监控整个过程,防止太细/争执……等问题。

    5. PO必须参加。

    ----------------------------------------------------------

    共同估算依靠PO的参与解决了做什么的问题,依靠师傅的带动解决了怎么做的问题。

    共同估算是“跨职能团队”的基础活动之一,之后他们之所以能在每日立会上分享当前进展与困难,就是因为当初是他们一起思考这一任务的,因此对这一任务后来的实际情况非常关心。在发生问题的时候,大家也更可以互相帮助,而不是毫不所知。

    下一篇将会涉及日常工作/每日立会等迭代期内的工作。

     

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

     

    展开全文
  • 敏捷估算扑克

    千次阅读 热门讨论 2010-01-20 15:33:00
     其实应该叫“估算扑克”更准确一些,本质上是扑克牌,基于Delphi估算原理,可以快速估算出需要的数字。关于扑克牌上的数字 估算扑克牌上的数字,有的牌是自然数排列,有些是斐波纳契数,有些则是不连续自然数。...
  • 敏捷估算方法 无论是团队研发一款产品或者开发某一个项目,我们都需要回答“我们大概什么时间能够完成?”, 或者到某一个时间点,我们能够做到什么程度, 因此和传统的开发模式一样,我们在故事拆分之后需要对我们...
  • [url=http://community.techexcel.com.cn/010DevSuite/070Agile_Scrum/010Posts/010Agile_Poker]敏捷估算扑克[/url] [b]关于扑克牌上的数字[/b] 估算扑克牌上的数字,有的牌是自然数排列,有些是斐波纳契数,有些...
  • 敏捷开发精准估算

    2019-09-27 08:27:19
    对软件开发人员来说,估算堪称是最难的工作之一。估算必须考虑所有能帮助产品负责人做出影响整个团队和业务决策的因素。因此,从开发到高管都为它焦头烂额也不足为奇,但这种做法是错误的。敏捷估算并不是什么性命攸...
  • 不知道是不是因为勾起了大家的牌瘾,最近一阵"扑克"估算很是火了一把,在几个项目尝试后很快蔓延开来,很多项目团队都跃跃欲试。 尝试的过程中难免产生一些困惑,干脆在这里做个澄清,把我实践下来所理解的扑克...
  •   敏捷估算,就是在敏捷开发中,对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下,软件开发过程中有很多未知数:技术更新,需求变更,系统之间的依赖关系等,它们都会影响估算结果,所以说...
  • 问题这是敏捷开发一千零一问系列的第二十七篇。(在这里提问,之一,之二,之三,问题总目录)来自提问帖 15楼 http://blog.csdn.net/cheny_com/article/details/7564388原问题摘录如下:开发组中可能同时进行几个...
  • 敏捷计划、估算考点

    2017-06-21 14:16:12
    实践 工具与技术 知识与技能 计划的概念 ...敏捷游戏(3级) ...估算 ...宽带德尔菲和计划扑克 理想时长 相对规模估计/故事点 亲和估算 时间、预算和成本估算(1级) 敏捷
  • 这是敏捷生态系统系列的第五篇(之一,之二,之三,之四,之五)。本文是2009年刚刚提出敏捷生态系统的时候参与一个MSN讨论组时的对话,当时的...“敏捷生态--Srcum敏捷开发”--msn群讨论 2009-08-25 13:52谷雨霖...
1 2 3 4 5 ... 20
收藏数 668
精华内容 267
关键字:

敏捷开发估算扑克