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

本项目组首次采用敏捷开发方法并设定了三周迭代周期，投入资源包括一名前端开发工程师、一名后端开发工程师、一名测试工程师、一名产品所有者（PO）和一名Scrum Master（SM）。前后端开发工程师各自不熟悉对方的技术领域。

第一周结束时发现前端开发人员面对新技术的挑战及后端工程师与测试工程师投入不足导致估算工作量与实际有较大偏差。顾问建议的调整包括缩短迭代周期至一周、重新进行迭代策划、按角色估计工作量以及让测试人员更早参与开发。

新的迭代策划过程中，全员参与了迭代策划会议，涉及到多方面的人员，包括PO、前后端开发工程师、测试工程师、外部测试工程师和QA人员等。其中，PO调整了用户故事的优先级，删除和澄清了一些故事，前后端工程师识别出可以复用的功能，测试工程师帮助澄清需求，以确保所有成员对需求有共同理解。

工程师们独立估算每个用户故事的工作量，并在第一次迭代结束后根据需要调整。前端、后端和测试工程师用斐波那契数列选择故事点数，并在估算不准确时选择偏大的点数。他们还为每个用户故事预估了各自的工作量，并计算了总工作量。

PO负责给用户故事划分优先级，并在团队成员的意见基础上，微调了优先级。迭代周期被设定为一周，每位工程师的每周可投入工时也被记录下来，以表明他们的开发能力。

总工作量与实际开发能力进行匹配时发现超出预期，导致增加迭代次数和增聘额外的前端开发工程师。根据优先级挑选了第一周要完成的故事，并确定第一个迭代周期为六天。用户故事的拆分工作留给责任人自行处理。

新的迭代策划会议耗时1.5小时，估算了11个用户故事，总工时保持在186.5小时，但删除了一个17小时的故事。虽然估算结果相似，但本次策划经历了更充分的需求沟通，且在能力平衡基础上制定迭代计划，增强了项目组成员按计划执行的信心。

项目在迭代策划会议上的敏捷实践打破了常规方法，通过变通执行带来了更好的效果，表明敏捷软件开发是经验型过程控制，可以根据项目实际情况灵活变通。