迭代策划会议（Sprint Planning） 的实际案例

某项目组第一次采用敏捷方法进行开发，确定了迭代周期为三周。该项目组投入的资源如下：

前端开发工程师一名；

后端开发工程师一名；

测试工程师一名；

PO一名；

SM一名；

前后端开发采用不同的技术，熟悉前端开发的工程师不熟悉后端的技术，后端开发的工程师也不熟悉前端使用的技术。

当第1周结束后，由于前端开发人员使用的是新技术，需要熟悉新技术，而后端工程师与测试工程师的投入都不到位，因此估算工作量与实际工作量差别比较大。咨询顾问介入了解情况后，指出了本项目组在迭代策划时的错误，并指导项目组对后续开发活动进行了如下调整：

1.将三周的开发周期调整为一周一个迭代的开发周期。在不熟悉敏捷开发方法时，迭代周期要短，要及时总结经验教训，进行自我学习。

2.鉴于前期的迭代策划做得不好，需要重新进行迭代策划。

3.鉴于团队的成员不是全栈工程师，因此将按角色分别估计工作量。

4.测试人员需要尽早参与开发，而不是到第3次迭代才进行功能测试。

重新进行的迭代策划过程如下：

1.项目组全员参与了迭代策划会议。另外包括：

项目组外部的测试工程师两名；

外部咨询顾问作为主持人；

QA人员负责实时在电脑上按照更新后的模板记录估算结果，并投影出来；

其他多名观摩学习人员。

2.首先请PO讲解了每个用户故事，然后依次让前端开发工程师、后端开发工程师讲解开发要点，包括设计思路、需要处理的需求要点、是否有历史的复用功能、前后台的接口等；接着让测试工程师讲解测试要点、澄清需要测试的需求细节。

在此讨论中：

PO调低了某些用户故事的优先级；

PO删除了一个用户故事；

PO澄清了某些模糊的用户故事；

前后台的工程师指出了可以复用的功能；

前后台的工程师对某些需求的实现方式做了沟通；

测试人员贡献了很多澄清需求的想法。迭代策划会议的一个重要工作就是做需求的沟通，要求项目组的所有成员要对需求达成一致的理解。通过填写开发要点、测试要点、促使项目组成员对需求的理解进行沟通、讨论、确认。

3.前端开发工程师、后端开发工程师、测试工程师分别选择了一个故事作为基准故事，设置故事点为1，然后估算剩余用户故事的点数，从斐波那契数列中选择一个最接近的点数，犹豫不定时，选择偏大的点数。在做此估算时，前端、后端开发工程师、测试工程师都是背对背地、独立地进行估算。因为每个角色只有一个人，所以没有采用策划扑克的方法，并且充分信任每个工程师的估算结果。如果估算的结果不准确，则在第1个迭代结束后，再调整估算结果。

4.三个角色对于选中的基准故事，分别估计了自己的工作量，然后推算出其他故事的工作量，合计得到每个故事的总工作量以及每个角色的总工作量。

5.让PO对所有的用户故事划分优先级。首先请PO挑出最重要的一个需求，然后再挑选剩余故事中最重要的一个需求，如果不好区分优先级，就定义两个需求的优先级同等重要。此时，其他团队成员可以提出自己的意见，直至大家对优先级划分的结果达成一致。在划分优先级过程中：

PO主动删除了一个可做可不做的用户故事；

当对所有的故事划分完优先级、并重新按优先级顺序排列后，PO又再次做了权衡，微调了优先级；

对于成员质疑的优先级划分，PO给出了解释。

6.每次迭代周期设定为一周。列出每个工程师在未来两周中每周可以投入到本项目的工作量（小时），表示开发能力。

7.根据每周可以提供的开发能力，平衡需要的总工作量与开发能力，如果不能满足需求的总工作量，则裁剪优先级最低的需求，否则就需要提升开发能力、增加人员。由于估算的总体故事的工作量为186.5人时，超出了实际的开发能力122个工时，因此SM和领导协商增加了一个迭代，并且由于前端开发的工作量估计与实际能力差别比较大，确定再增加一个前端开发工程师。

8.根据用户故事的优先级，挑选了第1周完成第1个故事。第1个故事比较大，但是无法再进行细拆分为更小的故事，并且已确定再增加一个前端开发工程师，以确保第1个故事能够在1次迭代内完成，并将第1次迭代的周期确定为6天而不是5天。

9.在上次策划会议中已经将用户故事拆分为任务，因此本次估算没有再进行任务的拆分。留待责任人自己进行细拆分。

本次迭代策划会议共耗时1.5小时。第一次迭代策划会议估算了12个用户故事，合计估算为186.5工时；本次迭代策划会议估算了11个用户故事，总估算工时也是186.5个工时，但是删除了一个估算为17个工时的故事。虽然结果差别不是很大，但是估算的过程是不同的，上次估算并没有进行认真的需求沟通，而本次根据不同的角色分别对需求进行了充分地阐述，同时这是在能力平衡的基础上做出的迭代计划，项目组成员更有信心可以按照计划实施！

本项目针对迭代策划会议的敏捷实践，打破了常规的方法，变通执行，反而带来了更好地效果。这也意味着敏捷软件开发是经验型过程控制，只要符合敏捷的原则，可以根据项目组的实际情况进行变通。