文档首页 > > 理论实践> 持续规划与设计>

计划扑克、相对估算与发布规划

计划扑克、相对估算与发布规划

分享
更新时间:2021/02/27 GMT+08:00

计划扑克的使用规则

在进行估算时可以使用计划扑克协助估算。

如果你认为“某个故事已经完成了”或者“这个故事只需要几分钟就能搞定”,那就亮纸牌 0;如果你对需求还不清晰, 或者对这个故事的估算没有一点概念,请亮纸牌“?”;每次只能出一张牌,不能两张牌累加;大家要同时亮牌,不能提前让别人看到你手里的牌。每轮出完之后,大家把自己的牌拿回来,下次还要继续用。

关于相对估算

  • 相对估算的练习

    我们对每个故事的估算将采用相对估算的概念。

    1. 练习课题-估算牛的凶猛程度

      我们先估算一下12生肖的凶猛程度。在开始估算之前,我们先设定一个参照物,譬如老鼠的凶猛程度,我们可以给他一个值,譬如5,接下来,我们开始估算牛的凶猛程度。

      谁对牛的凶猛程度有疑问,可以提出来一起讨论。如果没有的话,就抽取一张牌作为估算。把你的纸牌扣在桌上,直到我让你们亮出来,才能翻开,明白吗? 这样可以避免你的判断影响其他人的估算。这个规则以后也适用于我们对Product Backlog条目的真正估算。

    2. 进行练习-第一次估算

      大家纷纷举起自己的纸牌,分歧出来了:3、5、13、5、8、8、5。

      给出3的人认为牛很温顺,他家的黄牛还让他骑。

      给出13的人说到,《动物世界》里面的野牛真发起疯来啊,连狮子都没办法。

    3. 第一次估算的总结

      经过刚才的讨论,这次限定一下范围,牛应当是成年牛,既不是小牛犊, 也不是野牛,只是家养的大黄牛,再估算一次。

    4. 进行练习-再次估算

      估算结果:5、8、8、5、8、8、8。

      少数服从多数,定为8。不能少数服从多数时,那就取大,因为我们通常容易低估。

  • 关于相对估算

    在这个过程中,如果大家意见分歧大的话,请给出最大估算的那个人解释一下,没准他思考的比较细,有些内容其他人给忽略了。同时呢,给出最小估算值的那位也要解释一下,没准他有更好的解决方案, 可以更快地完成。另外,我们采用的计量单位不再是小时了,我们采用'点'这个虚拟的概念,不要简单映射成人小时或人天。具体是什么计量单位不重要,因为我们采用的是相对的概念。

  • 相对估算该从哪一个故事开始?

    在我们开始估算前,我们先选出一个故事来,看看有没有哪个故事,大家非常清楚需要做什么,怎么做,相对简单的,我们把它定为2点,以这个故事作为基准,然后大家再开始进行相对估算。

    我们其实也可以找一个故事是13点的, 以此为基准,进行估算。理论上讲是可以这样做的,但实际操作会有问题,那样估算的误差就会比较大。譬如说,让你比较两个山头的大小,和让你比较两堆沙子的大小,哪个误差会更小呢?很显然是后者。

  • 具体该如何确定一个2 点的故事?

    其实,并没有一个特别标准的做法,每个团队都可能不同,即使针对同一个项目, 也可能有不同的选择。刚开始可以借鉴一下别人的做法,有的团队定义一个2点故事,大概就是一个工程师可以在2个工作日内完成的故事。

    同样一个需求,我们假设它就是2点,A需要2天完成,B需要3天完成,这个存在个体差异是没有任何问题的!接下来, 再以此2点的故事为参照物,估算另外一个需求时,A估算是5点,那意味着A大概需要5天完成,而B完成的完成时间可能是7-8天,但是B同样也可以认同是5点!因为这是相对于2点而言的。

    当大多数故事都大于2点时,有没有一个可以被认为是5点的?如果没有,那我们就要把某些故事细分一下,最终找一个2点的出来。

关于发布规划

  • 最常用的两种发布模型

    1. 多个Sprint一次发布

      在上面的模型中,是经过多个Sprint的开发后,才最终有一个正式发布的,发布周期比较长,适合大中型软件的发布。

    2. 每个Sprint结束发布一次

      下面的模型,是在每个Sprint结束后,都会有一个正式发布。这对每个Sprint的质量要求非常高,而且软件整体规模不大,功能相对简单,比较适合小型软件或者基于Web的应用。

      像雅虎通和谷歌广告等都是采用这个模式的,Web 2.0网站如脸书和领英等,更是对这个发布模式青睐有加。

      当然也有更厉害的,能够在一个迭代内做多次发布,将发布与迭代分离, 叫"按节奏开发,按需要发布"。 采用这个发布模式,可以让一个项目或想法提前经受检验,获得反馈。从而让好的项目脱颖而出,坏的项目死得更快。

  • 多个Sprint一次发布的两种方案

    这两种方案的共同点是在正式的发布之前,都安排了Pre-Release Sprint,除了要让产品更稳定外,还要做一些扫尾性的工作,譬如完善文档和修复Bug等。第一种方案,安排了一个正常长度的Sprint,第二个方案,安排的是更短一些Sprint,临近结束时,Sprint的长度甚至只有一周一次。

PBL梳理会

初次估算会议的结果里面肯定有些水分,比如说已经完成的故事,会对尚未开工的故事产生影响,一般会使相应工作量的降低。所以,我们需要定时对尚未完成的故事,重新估算才行,至少每个Sprint结束时应该进行一遍。

那我们就在每个Sprint的中间阶段, 用1到2小时的时间, 一起过一遍Product Backlog,根据已经完成的故事,重新做一个估算。这就是对PBL进行梳理的过程,同时也能细化、澄清一些需求,定义出来验收标准(AC),为下一个迭代做好准备工作。

关于新人加入

新人进来要时间办理各种入职手续,参加公司组织的新员工培训,这之后,团队还得有专人出来给他做产品和开发流程的培训,这个时间会超过一个月。其间,大家的精力也要被占用一部分。这么一算,不仅仅短期内不能提高生产力,反而是一种消耗。

在《人月神话》里面谈到的布鲁克斯定律,向进度落后的项目中投入更多的人手往往使进度更加落后。这一方面是由于新人进来后的培训成本时间,一方面是沟通不畅引起的时间消耗。给团队配置两倍的人,并不能得到两倍的生产力。人越多,交流的成本越大,效率就越低。有人说,如果希望靠增加人员来提高软件团队的生产力,无疑是南辕北辙。

估算与规划的要点

  1. 对Product Backlog中的用户故事做估算时,如果某项太大太空难以确切估算,应及时对它拆解和细化。
  2. 使用计划扑克可以提高估算速度。一次估算中,如果任何两个人的估算值相差过大,一定要停下来澄清后,再重新估算。
  3. 团队速度是指每个Sprint总共被PO接受的故事点数,团队速度可以用昨日天气法,也就是上一个Sprint完成的点数来计算;也可以用历史平均法,及历史上若干个Sprint的平均值来计算。
  4. 计划扑克的通常使用流程:
    • 选一个适宜大小的条目作为参照,把它视为2或者3。
    • 每个人每次出一张牌。
    • 如果分歧过大,多讨论再出牌赋值。
    • 如果相差不大,使用较高的那个数。
    • 逐个估计每个条目的相对大小。
  5. 给团队配置两倍的人,并不能得到两倍的生产力。人多,沟通协作的成本越大。
  6. 用户故事或者需求的拆解要参照“吃汉堡包原则”,可以从8个维度进行:用户、接口、数据、动作、约束、环境、质量属性及风险。

按节奏开发,按需要发布(Develop on Cadence,Release on Demand )

“时代抛弃你时,不会说抱歉”。谷歌和脸书等互联网公司可以做到每天多次的发布,真正将开发与发布分离,将技术决策与业务决策分离。Etsy(易集)的技术VP约翰·沃斯帕(John Allspaw)说:“我不知道,在过去5年里的每一天,发生过多少次部署……我根本就不在乎,黑启动已经让每个人的信心强大到几乎对它冷漠的程度。”

敏捷应该是端到端的从业务敏捷到开发敏捷到发布的敏捷。最需要改善的,是发布的过程。

核心在于,将开发与发布解耦,让上帝的归上帝,凯撒的归凯撒。需要将开发和发布解耦,开发和发布是不同的动作。开发是一个技术行为,而发布更多是业务决策。是否能够发布给客户,业务听到的总是"由于技术原因,我们无法随时发布",这是业务经常对表示开发不满的原因。

偏传统的产品交付模式中,产品的交付和发布过程,需要很重的交接成本(Transaction Cost),如何将这一过程敏捷化,是个挑战。

本文内容节选自《敏捷无敌之DevOps时代》,作者:王立杰、许舟平、姚冬(清华大学出版社)

分享:

    相关文档

    相关产品