移动端项目的冻结制度小谈

移动端项目特殊性

 移动端项目的交付产物以客户端版本为主，配合有WAP页面、H5页面及后台服务器等相关支持。受渠道发布流程（苹果应用商店一般至少需3-5个工作日审核，安卓渠道一般1-2个工作日审核） 和移动端设备中更新策略（系统自动更新、用户手动更新等）的影响，一旦客户端版本出现重大缺陷问题，仅仅靠更新客户端版本往往是无法立即解决问题的，很容易影响用户使用，并可能给公司造成一些不必要的损失。

以电商移动端项目为例，一般迭代周期为一个月左右。假设有个购物车模块相关的需求，它涉及客户端、WAP页、后台、主站等多方面及各种接口定义联调，同时可能还涉及支付模块配合。倘若该需求，产品方迟迟没有确定方案，改来改去一直等到迭代中期才给出需求方案进行初步评审，那么留给开发测试的时间将只有不到两周。技术团队还要协调各方接口联调，协调类似支付模块等其他第三方依赖等。单就这一个需求点的延误就将可能产生较高风险。万一此时推广计划已敲定了，例如已和苹果约定申请推荐位等，提交审核时间必须某日进行，情况就更复杂了。很有可能出现的情况是开发到最后一天才完成代码稳定。距离提交审核只有几个小时，测试同事才拿到与用户要使用的完全一致的客户端版本，很难保证所有隐患都能排查出来。就算此时排查出问题，恐怕也没有时间去纠正了，要么就硬着头皮提交要么就错过约定好的推荐申请。

在笔者经历的考拉app2.1项目中通过需求冻结和代码冻结两个措施来预防这种局面的出现，有一些改善。

需求冻结

在快速迭代项目中，已没有特别大块的需求，基本分解为细粒度的，在一个迭代期内需求不可能无休无止的改来改去。需要适当冻结以满足快速交付的要求，为下次迭代中需求变     

更留有余地。有一点需关注，需求冻结不影响拥抱变化，需要团队自身去评判。

在考拉app2.1项目中，只有不到一个月的研发周期，团队承接了看似不可能完成的大量需求。项目启动第一周，完成需求评审并进入需求冻结。迭代中后期也没有频繁大块需求改动困扰，有零星的改动也都在可控范围之内。团队在迭代前期第一周就已开始技术方案评估，开发和测试同事，协调碰头确认配合进度安排，包括诸如购物车功能相关等所有模块。团队成员都已清楚自己的工作安排及时间节点。无论是接口联调还是与支付模块依赖，都可以在接下来的工作中定期确认进展，游刃有余的展开工作。

代码冻结

冻结代码，代码另起分支，但并不是完全就停止代码更新。允许谨慎可控的缺陷修复等。需特别强调的一点是，代码冻结期，原则上讲是禁止新增任何需求或者任何调整功能点的开发任务的。

在考拉app2.1项目中，团队在迭代结束前三天完成所有代码稳定工作，并另起分支，冻结代码，给出将要提交审核的客户端版本。这三天时间里，测试同事继续各种测试，同时邀请公司内同事安装试用，对之前缺陷大扫除暴露问题进行验证。线上服务器也按要求部署上线，客户端完全满足最真实用户体验要求。倘若此时真的发现问题，评估后必须得修复，还是有时间去争取的。但须注意一旦代码冻结，所有修改必须经过慎重评审确认再提交。最终，app2.1版本紧张刺激中顺利完成，也成功通过苹果审核和各安卓渠道审核。

代码冻结并不是时间越长越好，还要顾及到整体的迭代进度，尽量在一个月的迭代周期内以合理的时间成本去执行代码冻结。具体冻结期长短取决于团队自身情况。对于从未做过代码冻结的移动端团队，建议迭代末期至少能争取临近发版前三天的代码冻结。

制度的补充

项目排期中，需求冻结时间点和代码冻结时间段建议列入在时间轴中，直观体现。

为保障冻结能有效执行，需做好准备工作。

1.关于需求。需求冻结的前提是需求的质量足够高，建议将需求评审拆分为大评审小评审。

小评审，尽可能点对点沟通，为避免过于分散影响研发效率，可以考虑类似集中每周二周五两天晚上小评审等。

大评审，最终需求确认会，可在需求冻结当天或之后一天召开。意义在于将信息传递到全体项目组成员。

2.关于代码。代码冻结只是保障版本质量最后几道屏障之一，不能把所有的质量都寄希望于代码冻结阶段去解决。建议重视平时的提测质量及开发自测等。代码质量重在平时习惯养成，等到最后需要代码冻结时再重视就晚了。

结束语

所有的制度终归还是为项目服务的，当项目情况发生一些改变，制度已不能满足需求时，制度本身也可以改进迭代。总之，在不断磨合中前进，在不断沟通中成长，该冻结就冻结，该拥抱变化就拥抱变化，最终目标是项目成功交付。

     本文来自网易实践者社区，经作者吕广川授权发布。