前言

从2001年敏捷宣言诞生到现在，敏捷已经走过了20个年头，越来越多的团队采用了敏捷软件开发模式，其中作为框架指导的Scrum方法应用最广，Sprint计划会议作为核心的事件成为敏捷开发中必不可少的一个环节。众多团队在每个迭代开始都会召开计划会议，可是经常出现“开始计划特别好，结果交付乱糟糟”，在一次敏捷线上分享活动中，就有开发者提出一个疑问：一个好的计划会议的标志是什么？开了这么多的计划会，如何知道每次开的好好不好？今天我们就一起来探讨一下这个话题。

问题分析

作计划这个事我们从小到大都进行，现在也需要经常作计划，学习计划，读书计划，出行计划，攒钱计划，购房计划，脱单计划，恋爱计划，成长计划……等等，这些都是和个人相关的，计划其实主要解决两个事：做什么和如何做。同样到敏捷中的计划会议也是一样，会议的核心就是解决这个Sprint做什么以及如何做的问题。所以要是把这两个事说明白，就可以认为是一个成功的计划会议。这样问题就聚焦到把做什么和如何做这两件事情说明白。

解决方法

做什么——迭代待办列表

确定做什么的过程，就是形成迭代待办列表的过程。通常一个迭代是两周，在计划会议中确定团队接下来的两周做什么任务，这里面有三个核心内容：产品待办列表、团队速率和迭代目标。

产品待办列表

在敏捷开发中计划是分层进行的，不同的团队会对环节进行删减和个性化设置，常见的分层计划形式有：

• 5层计划：愿景、产品路线图、发布计划、迭代计划、每日计划
• 4层计划：产品路线图、发布计划、里程碑计划、迭代计划
• 3层计划：发布计划、迭代计划和每日计划。

不论是哪一种，计划的顺序都是自上而下，先有上一级，再有下一级。更多关于敏捷计划的相关内容可以参考《关于敏捷规划你需要知道的几件事》

所以在我们的迭代计划会议之前，首先要有一个发布计划，形成一个根据发布计划、按照优先级顺序排列好的产品待办列表。作为会议的任务输入项才能确定接下来这个迭代做什么。

关于产品待办列表的更多内容，可以参考《规划与设计—产品待办列表》。

团队速率

团队速率简单来说就是团队在一个迭代中能够完成多少任务，也就是团队的生产能力。常用的表示有两种方法。

一种是采用故事点数。比如：某Scrum团队1个迭代可以完成 30个故事点，那么30个点就是他们的速度；通常这个数值是默认等于最近一次迭代中的速度，Beck和Fowler称为昨日天气法。有些团队还喜欢使用平均值的方法，可能是过去3次迭代的平均值。如果是新的团队或者没有历史迭代就需要他们预计自己的速度。

另一种是采用工时描述。比如：团队7个人，每个人可用于工作的时间在70%，其他30%用于迭代之外的工作和缓冲（支撑其他团队、会议、回复邮件等），这样团队在两周的迭代中可用的工时就是 7*8*10*70%=392小时，其中还要如果有请假等不能工作的情况要从可用工时中减去。

如果采用故事点数，就是和产品待办列表的单位对齐；采用工时，就是和迭代待办列表中的任务相同。两种方法团队都可以尝试使用，最后选择适合自己的方法。

迭代目标

除了产品待办列表和团队速率两项内容还有一个重要的信息，就是迭代目标。迭代目标通常由产品负责人PO根据业务的情况去确定。团队基于这个目标，按照团队的速度，从产品待办列表中选择适当的条目形成迭代待办列表。

如何做——故事分解为任务

得到了迭代待办列表之后，列表中的条目都是故事的形式，通常代表产品的某个功能或者特性，如何将这些特性实现，接下来需要拆解为具体的任务，由团队在迭代内完成交付。

比如：迭代中有个故事为“作为管理员应该可以进行积分管理”，这个是从用户的角度去描述。开发团队实现这个功能，就需要分解为团队可以理解的任务描述形式：积分功能业务逻辑开发、积分功能数据库设计和实现、积分规则设计。如下图所示。

在拆分任务的时候，任务的颗粒度可以参考在1天（8小时）内完成，这样可以保证在每日站会的的时候大家都有进展可以汇报，避免积压出现瓶颈。

分解为任务之后，团队可以对每个任务进行再次估算，得到这个迭代要完成任务的估算总和，将它和团队的生产能力进行比较，了解当初的承诺是否合适，可以进行调整，避免承诺不足或者过度承诺。

在计划会议上搞清楚本次迭代团队需要完成哪些故事，以及如何完成这些特性，基本上这个会议就是一个成功的会议，过程图如下所示。

除了上面两个核心的问题，计划会议还有其他的一些要素需要关注下。

计划会议的其他要素

参会人

建议整个项目团队（产品负责人、开发人员、测试人员、UI设计师等）和干系人（客户、项目发起人、职能经理等）都参加计划会议，这样可以让大家项目的进展和团队当前正在完成的工作有所了解。通常干系人时间有限，可以只参加确定做什么这个阶段，后面的如何做阶段保证团队成员都参加即可。

会议时长

在敏捷中的各种会议都有一个可参考的时间盒，基于团队的规模和迭代的长度。5-9人的团队、长度为2周的迭代中，计划会议时长通常在4个小时以内。

谁来做——任务领取

前面解决了做什么和如何做这两个问题，下一个问题就是谁来做。在敏捷中提倡团队成员主动领取任务，而不是被动的等待分配任务。从心理学的角度上，主动领取代表着一种承诺，会增加成员的仪式感和责任感。关于领取任务的时机，可以在计划会议上领取，也可以在迭代中即时领取1-2项，做完手中任务再去领取新的任务。

这两种方法团队都可以尝试，选择适合自己团队的方式。通常建议采用后面的方式，因为计划会议是团队对本次迭代的内容共同进行承诺的一个过程，敏捷强调团队共同责任制，而这时候领取任务就会变成个人负责制，弱化了团队对任务的所有权。还有在迭代过程中也会有一些意外情况导致任务的重新分配，所以不建议计划会议上领取任务，包干到个人。

写在最后

敏捷方法旨在管理不确定性，这里的不确定性是指与目的（客户的目标和需求）相关的不确定性和与手段（技术和人）相关的不确定性。敏捷方法用来应对不确定性的一个方法是，基于在迭代开发中获得的进展和收集到的新信息，进行频繁的重新计划。所以在前面的分层计划中可以看到迭代计划之后还有每日计划，迭代计划不是一劳永逸的，在迭代过程中要根据情况实时调整，调整的核心是聚焦于迭代目标的实现，交付有价值的产品。

参考附录

1.Scrum精髓：敏捷转型指南.Kenneth S. Rubin.北京：清华大学出版社，2014

2.敏捷软件开发实践：估算与计划. Mike Cohn. 北京：清华大学出版社，2016

3.敏捷项目管理：快速交付创新产品(第2版) .Jim Highsmith. 北京：电子工业出版社，2019.11