扯两句时间盒 | IDCF-技术圈

来源：敏捷传习录
作者：陈连生

第一生产力

时间盒在Scrum中是一个极度重要的概念，它表示的是“最长不能超过”的事件长度。类比于女生的首饰盒、梳妆盒就能明白，这种盒子“最大容量”是刚性的，不可以任意突破。

设计时间盒之初是为了应对“帕金森定律”[1]，即“有多少时间用多少时间”。这种方法在根本上证明了“Deadline是第一生产力”的至理名言。

在Scrum中比较常见的几个时间盒如下：

迭代（冲刺）本身的时长，根据团队约定；
计划会根据8小时/4周的迭代，根据迭代时长等比例变化；
站会的时间为15分钟；
评审会为4小时/4周迭代，根据迭代时长等比例变化；
回顾会为3小时/4周迭代，根据迭代时长等比例变化。

时间盒在这里最明确的优势有两个：

提供的信息细节要满足时间盒要求，不能过于细节；
给与会者一定压力，让其更有效率的进行会议。

这些都与上面的帕金森定律保持一致，就不再赘述。我们要说的其实是另一种情况，即在时间盒范围内如果没有完成，我们能得到什么提示呢？

迭代

迭代本身的时间盒比较特殊，不可以延长也不可以缩短，必须要完完全全到了迭代时间到了之后才可以结束，除非是PO要求取消迭代。

迭代自身的时间盒也是“Deadline 是第一生产力”的最典型代表。

计划会

每周2小时的计划时间盒是足够的。而随着时间等比例延长，该时间盒也是同样等比例增加。从我们的工作经验来看，该时间盒设定是合理的，很少发生时间不够的情况。

但是，如果团队配合一段时间后依然不够，你就要思考是否是因为你的梳理会没有开好，从而导致计划会做了一部分原本梳理会该做的事情？

而对于新团队而言，偶尔也会发生时间不够的情况。但这种不够大部分是因为团队配合的原因，这种不够可以在回顾会提出并通过优化流程得到改善。

当然也有一些其他情况，比如因为故事过于复杂且前期没有达成一致导致的时间盒超标情况，或者团队在进行Conversation（用户故事3C之一）的时候讲嗨了。这种情况下我的常规操作是适当延长该时间盒，但是在计划会之后要告诉团队时间超标了，这就行了。这种情况下是否需要回顾会处理呢？从经验来看不需要，团队会在计划之后就内部消化掉这个问题。

站会

站会的时间盒会更加严肃一些，毕竟每天都会遇到这个事件。

常规情况看来，站会的15分钟算是一个“金标准”，可以作为团队的判断依据。如果时间超了，基本上可以判断要么团队规模超标了，要么是站会细节太多了，要么两者兼备。

而对于分布式团队而言，时间盒可以适当放宽，比如放到20分钟左右，在站会时可以说点其他缓解气氛的事情，比如天气或者有趣的见闻，这对原本见不到面的团队配合有莫大帮助。

一个小技巧，约束团队发言时长，除了SM 控制之外，做一些其他的有趣的尝试也未尝不可。比如我们尝试过平板支撑、脚尖站立等做法，效果还不错。

有人会说如果随着团队锻炼起来了，大家平板支撑都能做5分钟怎么办？这里就不用担心了，毕竟平板支撑都能做到5分钟了，SM 早就教会团队怎么开站会了。

评审会

个人感觉4小时会议对评审会来说是太长了，如果只是演示功能以及获得反馈的话，4小时绰绰有余。

如果这个时间盒超标了，可能的原因要么是过分深入细节，要么就是前期没有达成一致导致了评审会上寻求一致。

现在一种更加流行的做法是，讲评审会打散而非只开一次。当完成了一项功能后，马上给相关方查看并获得反馈，争取本迭代内将反馈解决。但这种做法容易超过边界，即客户反馈越来越随意且过分频繁，甚至会进入非常细节的程度，这会让你的时间成本大增。因此迭代内的“反馈处理循环”需要做好约束，避免被滥用。

回顾会

整体而言，3个小时的回顾会时间算是合适的，不算太长也不算太短。

在日常工作中，回顾会一般不会超过这个时长，正常都在1.5小时，即90分钟左右是比较合适的时间——太长团队受不了，太短回顾不够深入。即使你使用了2周的迭代，我们也建议这个时长不要低于1个小时，否则可能会出现回顾效果变差等情况。

偷偷告诉你，和计划会一样，随着团队配合默契度提升，这场会的时间会持续缩短。

当然，偶尔的超时也是OK，比如某次迭代团队认为改进点比较多等情况下。

Spike

严格意义上来说，Spike不是专属于Scrum，而是偏向于针对业务、技术的不确定性而做的一些尝试。正常情况下这些spike都是有明确的时间盒长度的，而且spike的时间盒长度是“硬性规定”，无论是否达到目的，都需要立即终止后，再决定下一步动作。因此Spike的时间盒是绝对不能突破的。

问题：时间盒长度怎么选择？

从Scrum Guide这个官方白皮书的建议来看，时间盒设定都是相对来说合理的，如果你是一个没有经验的SM或者团队也不成熟的话，建议还是严格按照官方推荐的时间执行即可。

如果你是有经验的SM或者团队，且对自身业务了解也很到位，加之你的业务有一定的特殊性的话，你可以自己设定你的时间盒，但是你需要明确知道为何设置这种时间盒以及你想要达到的目的，否则大概率会发生“我选择是因为我喜欢而不是我需要”的情况发生。

帕金森定理：https://zh.wikipedia.org/wiki/%E5%B8%95%E9%87%91%E6%A3%AE%E5%AE%9A%E7%90%86

#IDCF DevOps黑客马拉松挑战赛，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合。

2022年首场将在美丽的海滨城市-大连举办，5月14-15日，36小时内从0到1打造并发布一款产品。

企业组队参赛&个人参赛均可，赶紧上车~👇