MIUI每周更新一个版本，按雷军的说法：“用互联网模式开发手机操作系统”。传统软件的开发周期非常长，而操作系统就更长了，而互联网模式的特点就是快速迭代，及时响应用户需求及修复问题，这很符合敏捷开发的原则。对于新生、竞争激烈的移动互联网行业来说，快速进行版本迭代非常有必要。
在这2年的iOS开发工作中，迭代了许多版本，迭代流程也发生过变化，在这些迭代版本之间碰到了许多问题，这些问题可能是特有的，但也有些团队开发通常碰到的问题。而这些问题会影响版本周期的稳定性，常常导致无法按时发布，扰乱开发节奏，如：出现同时开发3个版本的情况。以下列出我碰到过影响迭代周期的因素：
App Store审核
iOS的App Store渠道是需要审核的，而这个时间基本有一定的不可预测性，Apple会以某些理由拒绝你。一般等待审核至少要1周，这个时间MIUI都更新一个版本了。这个时间是不可能停止开发，而等审核通过的。这就造成了一个版本的周期还没有结束，已经开始了下一个迭代版本的开发周期。
版本的开发周期
这个版本的定义还是类似于传统软件的定义，只不过周期更短，功能更少。我觉得这跟敏捷开发中快速迭代版本相差甚远。由于还是预先定义好版本的功能，因此给临时插入需求提供了机会。
需求
在稍微大一点的公司，需求可能分为2类：功能需求和非功能需求。功能需求我认为是App本身应该具备的功能，能够解决用户的实际问题。非功能需求基本大多来自于运营或合作。在版本的开发周期中，总会碰到紧急的需求，要求必需在当前迭代的版本完成。
质量
代码质量也是影响发布的重要因素，《人件》有说，“质量是免费的”，只需要花费点时间。如果团队够小够精干这个问题不大。但如果团队不小，并非所有成员都是精干，而需求也各种各样，这就可能造成许多代码质量不高。这就对团队中的软件工程化提出了更高的要求。如何管理迭代分枝的代码？是否采用特性分枝的开发模式？QA的工作如何快速的展开？持续集成如何展开？是否有单元测试？如何更好的进行跨部门合作？
针对这些问题，如何制定适合公司环境的流程，来保证迭代周期的稳定性变成了一个有意思挑战。