timg1

如何高效实施迭代计划

作者:李洁(Jerry Li),CSP,CSM,Scrum中文网资深敏捷顾问和培训师,敏捷教练

“Scrum的会议太多、开会时间太长!”——我常常听到团队这样批评Scrum。大部分自行学习和实施Scrum的团队,往往都会把Scrum会议开得过长。我曾经见过有团队开了一整天的迭代计划会议(迭代周期为2周),这样的迭代计划确实是太长。
今天我来分享一下如何高效实施迭代计划会议,以帮助这些团队提高计划效率。

传统团队实施迭代计划的常见问题

传统团队在刚实施Scrum时,往往会按照传统的项目计划方式实施迭代计划会议:

  • 在会上,详细讲解每一条需求的细节。
  • 在会上,针对每一条需求,做任务分解和工作量估算,并分配到具体的开发人员。
  • 在会上,汇总得到完整的迭代进度计划。

这样一来,就导致了两个结果:

第一,会议时间过长。比较典型的例子是:花一整天时间来开一个迭代周期只有两周的迭代计划会议。
第二,把目标分散到个人身上,使得团队成员在迭代中只关注自己的目标,而不关注团队整体目标,团队变成了一盘散沙。

因此,这种传统项目计划是以项目经理为核心的计划方式,不合适于敏捷团队,该抛弃掉。

如何高效实施迭代计划

对于时长为两周的迭代,我们通常只需要要半小时就能完成迭代计划。

具体方式如下:

1 做好Backlog梳理

需求讲解、技术方案分析等工作应该在迭代计划会议前完成,而不应在迭代计划会议上进行。Scrum中的“Backlog梳理”活动,就是完成这项工作的。

在本迭代中,我们在开发和交付本迭代工作的同时,还要完成下迭代的Backlog梳理工作。这样在下个迭代的计划会议前,团队便已经熟知每条需求细节。

请注意:在迭代计划会议前团队就已经熟知需求细节,是高效实施迭代计划的前提。

2 基于团队容量的迭代计划过程

我们在实施迭代计划时,采用的是类似于“填土游戏”的方式,以真正基于团队能力规划迭代需求量。

1)设计团队容量表格

我们的迭代计划,是基于团队容量(团队一个迭代能够完成的工作量)来进行的。为了形象地展示团队容量,我设计了团队容量表格这个工具。

假设:在一个web开发团队中,前端工程师为2人,后端工程师为4人,测试工程师为2人,迭代周期为1周(5天)。我们可以把团队容量表格设计成图1的样子。

微信图片_20201021120353

图1 团队容量表格

2)往团队容量表格中填充迭代需求

现在,我们可以往团队容量表格中填充需求了。

对于每一个需求,我们分析前端开发工作量、后端开发工作量和测试工作量,以及考虑团队如何通过协作来尽快完成,然后把它填充到表格中。

假设:第一个需求,需要1天的前端开发工作量(1名前端工程师)、2天的后端开发工作量(可以由2名后端工程师共同完成)、0.5天的前后端联调以及1天的测试工作量。

微信图片_20201021120405

图2 填充需求1后的团队容量表格

如图2所示 ,我们可以把需求1填充到表格中。

接下来,我们可以继续分析和填充下一条需求。

我们在填充需求时,要注意以下几点:

  • 按照需求优先级,一条一条地分析和填充。
  • 要预留出一定的裕量,以应付突发事件以及完成下迭代的Backlog梳理。

3)何时停止以及如何处理异常

何时该停止填充?并没有严格的规定。一般来说,如果团队容量表格基本填满了,就不会再填入新的需求。
但是,往往事情并不会那么理想地发生。所以我们还会以如下方式来处理异常:

  • 如果有部分职能已经填满,而部分职能仍然存在空闲,该怎么办?这种情况下,我们可能会进行跨职能的工作调剂,例如:让开发人员也承担一部分测试工作。也可能会安排一些只需要空闲职能就能完成的工作,例如:补充接口自动化测试用例。
  • 如果团队容量表格基本填满,仍然不能满足PO的期望,该怎么办?例如:PO期望本迭代能完成一个包含7条需求的完整价值闭环交付版本。但按照团队容量,只能填充6条需求。这时候,PO和团队共同来审视业务上的紧迫性以及团队完成全部7条需求的可行性,协商达成一致。结果可能是:团队通过加班来完成全部7条需求,并在本迭代结束时交付一个可用版本。也可能是:在下迭代优先完成剩下的1条需求,并在完成后立刻交付一个可用版本。

该何时确定人员的工作安排

传统团队在实施迭代计划时,会习惯性地把工作分配到人。在前面的章节,我已经说过这种做法的危害。

那么该在何时确定人员的工作安排呢?应该在每日站会上,在规划每个需求的开发工作时,明确团队如何分工和协作,以尽快完成需求的开发和交付。

您有何经验

您是如何组织召开迭代计划会议的?对于为期两周的迭代,您的迭代计划会议需要花费多长时间?您会在迭代计划会议上把工作任务分配到个人吗?

欢迎在评论区留下你的观点。