jennie

个人签名

10篇博客

电商客户端Apple Pay接入实践

jennie2018-05-25 13:31

移动端项目特殊性

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

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

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

需求冻结

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

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

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

代码冻结

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

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

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

制度的补充

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


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

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

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

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

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

结束语

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


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