三、Sprint 1

Sprint 1如期而至。曾经在头脑中想象过多次的激动、兴奋、紧张和无助的场景，此时此刻却没有出现，因为你之前的充分准备，一切都是那么平静和理所当然。而忙碌却悄悄开始，推动着富有责任心的你继续前行。

Sprint1的目标是建立Scrum框架，并培养严格按照正确方式做事的习惯。因为习惯一旦养成再去纠正将会非常困难，Sprint1就担负着为后续的Sprint打好基础的使命。

在本章，我将以五个Event作为主线来讲述。其中，所有的会议都必须是在线下会议室进行的（即使是跨地域的团队，同一地点的也应该聚在一起），否则你只能在沙盒游戏中打造虚拟的斯巴达方阵。

我曾经接手过多个团队，最大的问题就是成员之间的不熟悉和不信任。因为自团队成立起，他们所有的会议都在线上举行，其他沟通也都是在IM中进行。信任一定是建立在互相了解的基础上的，面对面沟通会给团队成员之间带来更多的信息。肢体、表情、语调等的信息量比文字要多的多（想想一个视频，一张图片，一条语音和一段文字之间的存储量大小就知道了）。谨记敏捷原则之一：“不论团队内外，最有效的沟通方法就是面对面的交谈。”关于沟通的书籍很多，这里不再赘述。

3.1 Sprint Planning（冲刺规划会）

拿破仑曾说，没有一场战争可以在没有计划的情况下获胜。正因为如此，Sprint Planning不仅仅是一个Sprint 开始的标志，同时也是其中最重要的会议。

Planning（Sprint Planning在此文的简写）是整个Scrum team协作的过程。一个长度2周的Sprint，Planning的时长一般都在3-4小时左右，不超过4小时。如果你参加的Planning在 30分钟之内就结束了，那么这个Planning一定是假的。真相虽然残酷，但还是要恭喜你，因为下面讲述的实践会让你们团队的战斗力至少翻倍，而且立竿见影。

通常，我们将Planning分为两部分来举行。整个过程，至少在前期，都应当由Scrum Master来协调主持。

第一部分

PO和Developers参加，以及相关的stakeholders也可以参加（在提供完相关信息后就离场）。

步骤1，Developers决定这个Sprint的速度（Velocity）

速度（Velocity）指的是一个Sprint内能完成的工作量。这是一个经验值，但在Sprint1没有任何可借鉴的经验，只能先拍脑袋选取一个大致合理的范围，后续再在摸索中不断优化。

PBI的规模推荐使用故事点的方式来评估，即一种相对于某个基准PBI大小的衡量方式（故事点是个老生常谈的话题了，如果不清楚可以搜索相关文章阅读）。基准PBI对第一个Sprint来讲也不太容易找到合适的，可以采取如下几个方法尝试：

1，从Sprint 1中选取一个中等大小的PBI，赋予其5个故事点

2，从Sprint 1中选取一个最小的PBI，赋予其1个故事点

3，从Sprint 1中选取一个大概3个人天工作量的PBI，赋予其5个故事点（这个方法我用的比较多，一是简单直接，二是无形中会对PBI大小有个相对比较严格的限制）

Velocity和PBI规模的评估结果，都由Developers自己来决定，Scrum Master要尤其注意外界对其中过程的干扰。通常，来自外界的压力会认为Velocity定的太低，或者某个PBI规模的评估结果过大。施加压力除了让施加压力的本人感觉好受以外，并不会为真正的结果带来实质性的改变。相反，还会破坏信任的氛围，并欠下大量隐形的技术债务。PO的关注点应该是现在离Product目标还有多远，而不是目前已经完成了多少。

步骤2，PO提出一个和业务紧密相关的Sprint目标

目标比较“虚”，所以往往容易被“实用主义”者所忽略。但是，目标很重要，很重要，很重要，Sprint也不例外。Sprint目标对于团队在Sprint中的聚焦和协作有着无可替代的作用。要是你也对此持怀疑态度，最好的方法就是尝试一次，也许从此还会改变你的人生（瑞.达利欧的《原则》将设定目标作为五步实现人生愿望的第一步）。

步骤3， 通过与PO讨论，Developers挑选PBI放入当前Sprint中

第一步，PO在当前尚未澄清的PBI中，挑选出优先级最高的一条进行讲解，包括业务诉求和逻辑，与Sprint目标的关系等等；

第二步，主持人询问Developers是否还有疑问。没有疑问的话，所有Developers一起来评估PBI的规模大小。这里推荐使用能避免从众效应的planning扑克小程序，这样，大家评估时不会受到别人评估结果的影响，而且免安装，使用方便。如果有不一致的评估结果，请投出最大值和最小值的人发言辩论，然后再投一圈直至没有异议。估值大于8的话，需要进一步拆分。

打点（用故事点评估PBI大小的简称）的结果由Developers说了算，所以要时时排除外界在其中的干扰。

图9 Teambition的规划扑克小程序

（左图中的遮挡可以避免从众效应；只有当再点击一下屏幕，才会出现右图的数值）

第三步，回到第一步，直至Sprint的PBI规模总和达到步骤1中假定的Velocity

讨论过程当中，Developers根据Sprint目标，评估是否有所遗漏、修改或者删除的PBI，并向PO提出建议。

步骤4，Developers定下最终的Sprint目标

根据步骤3的讨论，以及完成的信心，Developers修正Sprint目标，并最终定稿。记住，Sprint目标是Sprint的承诺（Commitment）。目标没有达到，Sprint就是失败的（失败并不可怕，但只有当从失败中学习并得到进步的时候）。现在很多支持Scrum的工具中，都可以记录Sprint目标，并在Sprint看板的顶部展示。

步骤5，为这个Sprint起一个响亮的口号

口号交给Sprint的主人——Developers来命名，并要求与目标相关。这是整个Planning笑声最多的环节。

最后，别忘了将口号放在团队聊天群中并置顶（聊天群的使用频率通常比看板的使用频率高），或者在每日站会后让大家一起喊起来，这样就可以在未来“漫长”的两周内，时刻提醒团队不忘初心，牢记使命。

第二部分

Developers参加就可以了，他们在这部分一起讨论完成Sprint的计划。这种讨论可以认为是技术部分的讨论，尤其是合作将每个PBI按子任务进行拆分（即按照实现过程中需进行的活动进行拆分）。这个过程中，要让Developers明白，“架构”就是“解构”。如果不能将PBI进行拆分，那就不能说对完成这个PBI已经做好了计划和准备。

“解构”需要满足MECE原则（Mutually Exclusive Collectively Exhaustive，即“相互独立，完全穷尽”），方便实现过程中的协作与配合。另外，子任务的规模以一到两个人天为佳，这除了是对流动性的考虑，同时也便于对进度的追踪。

如果你们在使用电子Scrum看板来记录PBI及其子任务（比如JIRA），为了提高讨论效率，建议如下：

1，在每个PBI的讨论过程中，用物理白板记录讨论的结论。随时记录，随时确认，随时修改；

2，每个PBI讨论结束后，确认一个志愿者，负责会后将此PBI分解的子任务录入相关的电子系统；

3，白板书写者将志愿者的名字写在相关PBI结论的旁边，然后拍下照片。志愿者也拍下照片作为备份；

4，然后回到第1步，讨论下个PBI，直至所有的PBI讨论结束；

5，会后，白板书写者将所有照片发送至工作群，并提醒志愿者们在电子系统中录入。

这样做的好处是，讨论不会被时时的电子录入动作所中断。而且，会后这种众包式的录入，效率要远大于让某一个人来录入（这种繁重的录入工作对一个人来说其实是种痛苦）。

有时，一个非常小的PBI很难再进行拆分，这里也建议至少建立一个子任务。因为通常在Sprint看板中，PBI是按照优先级从上到下排列的，而相关子任务挂在其下的泳道按照状态进行从左到右进行排列。如果此时没有子任务的话，很难直观看到PBI的状态变化和进展。另外，有的电子系统（比如JIRA），会对没有子任务的PBI进行单独的放置，这样就破坏了对Sprint中各PBI优先级的直观体现。

图10 白板前的讨论（来源于https://cn.polyvision.com）

整个Planning会议耗时很长，全情的投入也非常耗精力。我通常会在上午进行第一部分，下午开始第二部分。午休时间可以让人得到充足的休息和放松；另外，也有较长的缓冲对第一部分讨论的结果进行更新，或针对第二部分讨论进行准备。