六、Sprint 4

《Scrum指南》中讲到，SM有三个服务对象：开发团队，PO和组织。在我看来，这也是服务的三个层次。到了Sprint4，对于开发团队的服务，应尽量采用授权的方式。就像农民一样，给予庄稼必需的水、土、空气等条件就可以了，而庄稼的成长则依赖于本身。此时，SM服务对象的重点就要从团队转向PO了。

6.1 详细规划得稍远一点点

Mike Cohn在《Agile Estimating and Planning》中用洋葱图将规划分为了六个层次（图36）。我们之前的规划主要集中在最里面的两个层次（图中的“Day”和“Iteration”），它们都是由开发团队负责制定、实施和完成的。外面一层的发布规划（Release）则是PO的重要职能之一，而到目前为止，其仍停留在“诗史”（Epic）这个粒度。这对于多团队的合作，以及在应对技术和需求的不确定性上仍是不够的。换句话说，除了当下冲刺中的PBI，我们还应该要至少考虑以后两个冲刺中要做的PBI（也就是细化到Story或Task这个粒度，并且符合INVEST原则）。

图36 规划洋葱图

（来源于Mike Cohn的《Agile Estimating and Planning》）

敏捷规划不是应当在最后责任时刻才敲定计划吗，为什么还要提前做好2-3个冲刺的规划？因为我们需要在规划的短期和规避尽可能多的风险之间取得平衡，就像在黑暗中使用电筒照明，不能照射太远而看不到脚下，也不能照射太近而看不到两步之外的水坑。这其中，也许会产生一些浪费（比如发现之前的假设不正确，而导致之前的讨论作废），但总体效益是正向的就值得去做。

提前两到三个冲刺的详细规划，可以更方便预先发现并解决团队间的依赖。比如说，我们产品的一些重要基础模块的开发依赖于国外专家团队的评审，而在圣诞节前后，国外团队的专家成员一般都会有2-3周的休假（类似我国的春节假期）。如果我们不能提前预先得知这些需要评审的任务，并在冲刺的工作安排中提高相关PBI的优先级，就有可能导致重大的延期事故。虽然说，表面原因是由于国外专家的休假，但圣诞节休假这种情况是可预知的，根本原因还是在于自身的规划不够细致。

提前两到三个冲刺的详细规划，还可以更好的应对技术或需求的不确定性。有时，当我们在冲刺规划会上仔细分析考虑细节时，才会发现有些技术或方案是我们所不熟知的。在当前冲刺才去做Spike，不仅仅会导致规划会上无法对Story进行正确的规模估计，还有可能导致Story不能如期完成。这种不确定性，若能提前2-3个冲刺发现，就可以将Spike工作分离安排，而不用仓促上阵，手忙脚乱。

道理讲明白了，该如何实施呢？在实际工作中，我摸索出一套实践，其不用在每个冲刺占用太多精力，而且在操作两个冲刺后（这里以详细规划到未来第三个冲刺为例），便可以一劳永逸，实现滚动式规划。

如图37所示，假设我们从冲刺N当中开始实施。我们对冲刺N+1的PBI进行梳理，流程同规划会第一部分的前三个步骤一样（请见3.1节）：即根据速度，为合适大小的PBI进行规模估计，需要所有开发团队成员参加。

图37 滚动式规划

（以规划到未来第3个冲刺为例）

在冲刺N+1的规划会第一部分中，我们就继续为冲刺N+2的PBI进行梳理。这个步骤结束后，再回头对冲刺N的PBI根据当前最新的状况进行调整。因为N+1的大部分PBI已经在上次的梳理会上整理过，所以整个会议的时长和之前普通的规划会差不多。

到了冲刺N+1，再重复冲刺N中的行为，直至冲刺N+2的规划会。这样，到了冲刺N+2，以及后来的冲刺，我们就不必继续在其中安排梳理会了，因为我们已经得到了冲刺N+4（或未来第三个冲刺）的PBI，能够规划到未来第三个冲刺了。

在以后冲刺的规划会上，我们便可重复冲刺N+1的流程：先梳理未来第三个冲刺的PBI，再回头最终确定当前冲刺的PBI。

上面的操作很简单，但带来的收益很大。PO和团队会随之进入更快的飞轮节奏：解决依赖从容不迫，不再突然出现各种“坏消息”，一切都那么平静、美好。大家开始有时间和精力去学习新的知识，也有勇气尝试更有挑战性的任务。就像《孙子兵法》里所说：善战者无赫赫之功。每个人在此时都成为了运筹帷幄的大将军。

6.2  目光放得再远一点

每个组织的产品、环境，以及PO的类型不一样，PO的规划策略也不应该一样。在《Professional Product Owner》里，PO被分为如图38所示的五种类型。在越小的公司里，PO的类型越靠右，对产品的话语权也越大，同时责任也相应的变大。之前在初创公司，公司的创始人就兼任着PO，也就是最右边的“企业主”；而我当下的公司隶属于某世界五百强集团，PO们大都属于靠左第二种，也就是“代理”类型，并非需求的直接提出者。

图38 按预期收益划分的PO类型

（来源于Don McGreal和Ralph Jocham的《Professional Product Owner》）

“代理”类型的PO，对需求的范围控制权很弱；而我所在的企业，由于各种原因，软件发布的时间非常固定，除非重大事故，不允许改动。所以我们的产品可以被定位成固定日期且强范围（也就是范围基本固定，但在一定范围之内仍存在很小的弹性空间）的类型。对于这种类型的产品，仅仅靠6.1节中能详细规划到未来三个冲刺是远远不够的，因为无法推测在固定日期前是否可以满足交付需求。所以，我们还需要把眼光放得更远一些，但不必像6.1节中那么细致。

具体做法便是用“T恤尺码”方法（这种方法的描述网络上很多，可以自行查阅）针对各个史诗级故事来做快速大致的估算。对于特别大的史诗还需要进一步拆分，并对优先级排序。工作量加总后，根据团队的速度，便可得知需要大概多少个冲刺能完成这些史诗。将预估时间和固定日期对比后，PO便可以对范围进行微调，以保证在固定日期前完成尽可能多的史诗；对于不能完成的低优先级需求，需要尽早进行沟通，规避风险。这种规划应当在后续持续进行，因为在开发过程当中，不确定的信息渐进明细，有可能发现和之前的假设不一致。

6.3  小结

对于PO应当如何做产品规划和发布规划，有书籍根据环境的不同，列出了很多对应的方法。但灵活运用比死记硬背要实用得多，这些方法本身也应该采用敏捷的方式被采纳，根据实际情况不断调整和优化。如果产品的开发仅限于在一个团队内部，没有对外的依赖，技术也比较确定，只详细规划到当前冲刺，我觉得也没什么不好；如果产品在市场上过于超前，需求不是特别明确，也没有明显的固定日期，花精力去做长远的规划估算也是种浪费。当一种做法不产生价值时，就应该考虑是否陷入了僵化陷阱，需要放弃或者进化到新的方法。