Scrum中如何确定迭代周期
2018-12-05
来源：麒麟敏捷社区 易晓媛
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的精髓。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
