迭代计划会议

什么是迭代计划会议

迭代计划会议是敏捷开发需要进行的会议之一，在每个迭代周期开始之前召开。

为什么要做迭代计划会议

目的是为了制定当前迭代周期的开发目标以及需要完成的工作。举办迭代计划会议，是为了让团队获得足够的信息，能够在迭代内内不受干扰地工作。

迭代规划会议的要求和注意事项

时间

迭代规划会议的时间应当是迭代开始的第一天。

根据采用的迭代规划会议的方式、团队成员的数量和纳入迭代 User Story 的数量，迭代规划会议在 1 - 2 个小时不等。

如果采用一次式迭代规划，根据 User Story 的优先级和开发计划，从最高优先级的 User Story 开始分析，直到团队承诺完成的 Task 符合团队迭代的产量。

如果采用两段式迭代规划，第一阶段需要在迭代规划会议之前完成。迭代规划会议主要完成第二阶段，即本迭代需要完成的 User Story和 Task 的分析和承诺。根据第一阶段预估的 Story 数量逐一分析，直到团队承诺完成的 Task 符合团队迭代的产量。

地点

在开迭代规划会议之前，需要提前预定一个可以容纳所有团队成员的会议室，并需要占据较长的时间。

参会人

在迭代会议中，参与的主要成员包括产品负责人、开发团队和 Scrum master，他们的责任如下：

产品负责人

产品负责人在迭代计划会议的责任如下：

分享初始的迭代目标（迭代 Goal）
展示排定优先级顺序的产品列表（Product Backlog Items）
回答团队对于产品列表提出的任何问题。

开发团队

开发团队在迭代计划会议确定够可以交付哪些特性，然后再迭代规划结束时做出一个靠谱的承诺。

如果无法承诺，就要考虑拆解至可以承诺的粒度。或者将无法承诺的部分内容移到下一个迭代。

Scrum Master

作为团队的教练，Scrum Master 在迭代计划会议中要做到以下几点：

观察规划活动
提出深入理解细节的问题
引导团队帮助团队确保有成果

注意：由于Scrum Master 不管理开发团队，所以不能代替开发团队决定或作出承诺。不过，

Scrum Master 可以提出问题挑战团队的承诺，以确保承诺切合实际并且是适当的。

其它人员

业务人员可以参加，也可以不参加，因为业务人员一般会提前和产品负责人进行客户需求的沟通。但是我们建议业务人员也参加，这样可以避免当时和产品负责人沟通的时候会出现遗漏。

准备

在迭代计划会议开始召开之前，User Story用户故事和产品的backlog应提前由PO准备好，并确定优先级。不需要准备出所有的，至少准备出一周到两周的就可以。

迭代规划的输入包括以下5点：

产品列表：在迭代计划之前，最重要的User Story 已经梳理好并就绪。
团队速率：团队在上一个迭代中实际完成的故事点数量。通过 TFS 获得。
限制：识别出业务或技术的限制，这些限制可能影响团队的交付能力。例如：方案没确定，技术详细设计不清晰，联调存在依赖，环境没有准备好，技术架构有升级等。
团队产量：生产能力要考虑到团队成员，每个团队成员都有哪些技能以及在下个迭代中他们的可用情况。例如：每天的工作时间是 9:00 - 18:00 共 9 小时。除去午休 12:00 - 14:00 还剩 7 个小时。扣除每天会议时间和沟通时间 1 个小时，每天每个人的工作时间只有 6 个小时。
迭代目标：产品负责人希望在这个迭代内完成的业务目标。

过程

迭代计划会议有两种方式：两段式迭代规划和一次性迭代规划。

一次式迭代规划

在一次式迭代规划中，选择条目和获得交付信心的两个活动交替进行。使用这种方式时，开发团队首先确定自己有多少生产能力可以用于完成工作。基于可用的生产能力，冲刺目标可能需要细化。接下来，团队选择一个工作项，然后表示有信心在当前冲刺做完它（假定其它工作项已经有团队陆续做出承诺），重复这个过程，知道团队没有余力再做更多的工作。这时，最终敲定承诺，结束冲刺规划活动。

在一次式迭代规划中，团队需要列出完成每个 Story 所要完成的 Task，放在TFS 的New栏中。并且依据 Story 的验收标准设立 Task的验收标准，并估计出完成所需要的时间。当团队承诺能够完成后纳入本迭代，并将任务移动到 Define 列。

如果团队对某一 User Story或 Task 无法在本迭代内承诺完成，则不允许纳入本迭代。直到处理了所有导致无法承诺的最后才可以纳入本迭代。

两段式迭代规划

在两段式迭代规划中，迭代规划分为两个阶段：

在第一阶段，关注点主要是工作内容，开发团队确定完成工作的产量。如，预估在迭代结束时候能够完成的工作项。

在第二阶段，关注点主要是工作方式，团队通过制定计划来获得有能力完成第一阶段预测条目的信心。并通过拆分 Task 的方式来估计每个User Story 所需要的工作量。然后团队比较任务估算的小时数和团队以小时计算的生产能力，了解当初的承诺是否现实。

如果团队发现选取的条目太多或者太少，或者选取的条目由于种种限制而不能在一个冲刺里一起开发，则可以调整预期或者重新细化冲刺目标，以满足现有生产能力和相关约束。当团队的预期与生产能力范围以及约束能够较好吻合，团队就可以最终敲定承诺，结束冲刺规划活动。

在两段式迭代规划中，填充产能阶段需要在迭代计划会议前。将迭代所需要开发的 User Story 及其 Task 列出来。在第二阶段，对 Task 的工作量进行估计，并根据产能调整目标和 Story的优先级和开发顺序。

如果团队对某一 User Story或 Task 无法在本迭代内承诺完成，则不允许纳入本迭代。直到处理了所有导致无法承诺的最后才可以纳入本迭代。

产出

迭代计划会议后，需要产出本迭代需要完成的User Story 和任务列表。所有的承诺的User Story 和Task 需要在迭代计划会议中估计出时间，并从 New 移动到 Define。当前迭代内不允许出现未承诺的 User Story 或 Task。

迭代计划会议的注意事项

不要让计划会议变成产品负责人，Scrum Master或者业务主管的个人发言；
开发团队不需要在计划会议上考虑所有的细节。产品负责人要进行引导，避免陷入太细节的讨论，也要避免陷入讨论跑题，只要开发团队能够承诺就可以。
产品负责人讲解用户故事和产品backlog的过程中，团队可以随时提问。
在不熟悉敏捷方法时，迭代周期要短，比如将三周的迭代周期调整为一周。
产品负责人不应该决定当前迭代所要完成的工作量，而是应该由敏捷开发团队共同通过承诺决定；
产品的Backlog工作项应提前准备好，包括各工作项的内容以及完成标准，这一内容其实应该在版本规划会议中完成；
针对每个工作项，不应在迭代计划会议中指定具体的责任人，而是应该在迭代实施的过程中，由开发团队自组织的完成每一个工作项，这样的好处在于更加灵活，也有利于团队内部的协作。
为了更准确的理解每个工作项的内容以及完成标准，开发团队应尽可能的针对自己不清楚的地方向产品负责人提出问题。目的在于让每个开发者都能更好的理解每个工作项。不过，一般来说，这个时候发现并澄清的问题只占60%，其余可能存在的问题或者阻碍，需要在开发的过程中逐步解决。
迭代计划会议中承诺的工作量在迭代期间，不应增多也不能减少，除非有非常紧急的问题，不过需要开发团队的协商共同决定。

在迭代计划会议中应用Scrum五个价值

1.承诺 – 在迭代计划会议中，能够承诺按时按质量要求交付任务。

2.专注 – 在迭代计划会议中，产品负责人，Scrum Master 和开发团队要专注于当前迭代，当前 User Story 或者当前 Task。

3.开放 – 在迭代计划会议中，针对于迭代目标，Story 等细节都要抱持开放的态度来讨论。

4.尊重 – 在迭代计划会议中，产品负责人和开发团队要尊重并信任对方的判断和解释。

5.勇气 – 在迭代计划会议中，当无法承诺时，要有勇气挑战任务安排的不合理。

附件：一次式迭代规划会议核查表

团队在上一迭代的速率是：

团队的容量是：

产品负责人是否完成了User Story 优先级的排序

附件：两段式迭代会议核查表

团队在上一迭代的速率是：

团队的容量是：

产品负责人是否划定了当前迭代的 User Story 的估计和任务的拆分