Scrum中如何确定迭代周期

Posted 2021-04-25 麒麟敏捷社区

Scrum以迭代开发为基础，每一个迭代完成相应工作量的任务。俗话说，“一口吃不成胖子”。Scrum迭代的目的是将产品的主要功能先搭建起来，后续再进行添加修改，每个迭代都能给出用户交付物。为了更好的达到Scrum迭代目的，合理的安排迭代周期，适当衡量每个迭代的任务量是迭代开发的关键。

我在scrum实践麒麟团队工作一年时间，麒麟团队产品为ADCloud敏捷交付云平台。ADCloud平台打通从需求到开发、测试，到发布上线进入运维的各个环节，促进开发、测试、运维更紧密地合作，提高系统发布的效率。跟随我们麒麟团队产品的开发及后期优化，我们团队的迭代周期分为了两个阶段：第一阶段迭代周期和第二阶段迭代周期。

第一阶段迭代周期

麒麟团队第一阶段迭代周期为两周（十个工作日）。

第一阶段的迭代周期的具体每日安排示意图如图一所示。每一个迭代从周一开始，下一个周的周五为迭代的最后一天。在迭代期间内，我们会召开相关的会议。

1．迭代计划会。迭代计划会在每一个迭代第一天上午召开。迭代计划会也标志着这个迭代的正式开始。届时也会要求整个团队的成员都参加。迭代计划会将各个需求按照优先级，将它们从高到低分配到各个迭代中进行开发，形成了Sprint Backlog（迭代看板）。将迭代看板中的任务分配给合适的开发人员，并由整个团队一起预估工作量。

2．迭代回顾会。迭代回顾会实际是对上一个迭代的故事任务进行验收回顾。迭代回顾会是scrum中最重要最有意义的会。这个会议将总结上个迭代中团队遇到的问题，并且给出解决方案。并回顾上个迭代交付的故事，评估是否能够进行生产上线，如果评估通过，则进行上线操作。

3．需求澄清会。需求澄清会是为下一个迭代做准备，在迭代倒数第二天召开。需求澄清会参会人员为PO（Product Owner）产品负责人，SM（Scrum Master）团队的导师，以及整个开发团队。在需求澄清会上，PO将产品的功能需求提出来，列入ProductBacklog（产品看板）中，并为这些功能确定优先级别。

迭代周期的最后一天进行准发布测试以及回归测试。开发团队人员从迭代的第二天开始进行开发工作，整个团队的总体故事点按需求给出。开发团队每天给出相应的交付任务。任务的交付周期比迭代周期推迟一个工作日。任务交付周期和迭代周期示意图如下图所示：

第二阶段迭代周期

第一阶段迭代周期中，麒麟团队完成了ADCloud平台项目开发工作。当开发工作完成后，由于ADCloud平台是服务于业务开发的平台，租户业务开发的周期调整为一周，需要ADCloud平台适应业务的变化，所以第二阶段迭代周期进行了相应的调整，调整为一周（五个工作日）。每一个迭代从每个周的周二开始，下个周的周一为迭代的最后一天。

与第一阶段迭代周期安排相比较，各项会议都正常召开，只是由于迭代的周期缩短，任务量相应减少，各项会议的时长也相应减半。

麒麟团队建立了自己的团队公约，团队的成员按照团队的公约进行工作与合作。每天工作结束统计当天的任务完成数量，每天进行准发发布环境与新上线功能测试。迭代最后一天都是进行准发布测试及全量回归测试工作。由于迭代周期为一周一迭代，所以我们加入自动化测试，包括自动化单元测试，自动化接口测试和自动化UI测试，由此减少全量回归测试的时间。

在迭代周期随业务要求进行了调整之后，我们关注故事的交付效率（最终完成的任务数/总任务数）。第一阶段的迭代故事交付率和第二阶段迭代故事交付率如下图所示：

对比两个统计结果，第一阶段的故事交付率基本在80%左右，第二阶段的故事交付率也有升有降，但总体基本也维持在80%左右。从故事交付率来说，迭代周期的调整并没有影响任务的交付量。并且还能及时和业务保持同样更新速度。

总 结

我在麒麟团队工作了近一年的时间，深刻的理解并参与了scrum实践。正确的迭代周期，能够帮助团队更合理化的成长。我们新的迭代都是一个新的开始。每一个迭代都产出交付物，都是一个小小进步。只有不断的进步，最终才能真正实践scrum的精髓。