.

如何优化APP开发过程中流程的问题

时间:2019-03-27 18:12

问题和现状

1. 产品会在临上线一两天提出需求变更


2. 在需求评审阶段,看不出问题,在执行阶段,发现逻辑需要修改。


3. 领导临时加需求,往往导致加班


4. 上线压力大,有点乱,有点急,风险高,容易出现遗漏问题,临时版本多


5. 在开发过程中,需求仍然不确定,导致反复修改,相关人员对同一问题的理解偏差较大


6. 后端扩展个信息,测试增加测试案例等等都可能导致客户端进行修改。


原因分析

1. 从后台到移动客户端整个流程太长,涉及人员太多。沟通不充分和依赖等待造成的浪费很大


2. 单纯的word文档,或者口头说,比较抽象。评审环节必不可少,不过光靠评审是不够的。发现的风险,评估的工作量等都不是很准确。


3. 交互设计毕竟是模型,跟实际程序相差比较大。如果做高保真模型,产品将挤占更多的开发测试时间,导致设计和实际程序落差更大,开发的加班更多


4. PC和APP共用一套后台,耦合严重,APP开发“PC思维无线化”现象严重


5. 开发版本直接上线运行,中间缺少缓冲,风险较大


6. 缺乏概要设计和充分的验证,导致边开发边改需求,造成不必要的浪费和混乱。


7. 开发、验证、上线三个关键动作集中处理,压力大,风险高


如何解决?

1. 在APP和后台服务之间增加“独立网关”,独立开发,独立部署,作为“APP的后台,后台服务的前端”。


2. APP和PC各自拥有“独立网关”,根据各自特点独立开发,独立部署,实现解耦,解决“PC思维无线化”问题。


3. 以APP的“独立网关”为切入点,将整个流程分为“APP开发”和“后台开发”两个相互独立的部分,解决流程过长的问题。

“APP开发”适合用“迭代开发”的思维,与产品和运营做更充分的沟通。主要任务是快速应对需求端的变化,并将需求变化集中在前端,为后台开发提供一个相对稳定的环境。

“后台开发”适合采用传统的“瀑布模型”,面向“独立网关”进行服务开发,与终端用户、产品、运营等实现解耦。主要是实现高并发,稳定可靠的服务,从本质上提升用户体验。

4. 版本模式分为开发版本,内部试用版本,生产版本。

开发版本采用内部release的方式,接开发服务器,使用者主要是开发和测试。

内部试用版本接“独立的真实服务器”,用户总数受控制,比如100个。iOS版本在审核期间也可以接这个版本,可以提供提供几个“超级用户”,方便审核人员审核。使用者主要是产品,运营,以及经过筛选的“认证用户”,比如公司领导、外部合作商户、内部员工、铁杆粉丝等等。

生产版本接“正式的生产服务器”,用户比例受控制,采用“灰度发布”的方式,逐步放开用户量。使用者主要是产品和运营。

5. 将发布、验证、上线三个关键节点在时间上错开

流程改进

1. 第一级:“瀑布模型”,分为“APP开发”和“后台开发”两个阶段,面向“独立网关”进行开发。

“APP开发”优先,主动应对领导、产品、运营等的变更需求;让抽象的设计尽早变成实际可用的产品。

“后台开发”待变更基本稳定之后,基于特定的APP产品提供具体的实现,专注于高并发的处理和安全性。

2. 第二级:“APP开发”实行“迭代开发”。“后台开发”采用“瀑布模型”。

视觉、开发、测试、网关等组成“虚拟的小团队”,指定一个负责人,面向具体业务开发。

人数限定在10人左右。

实行“每日站立会议”制度,每人限时1分钟,讲清楚(a)昨天做了什么(b)今天做什么(c)需要什么协助。

如果能能将“虚拟的小团队”的座位调在一起,成立“作战室”,效果会更好

管理工具适合迭代模型的“JIRA”

3. 第三级:在一个迭代周期中,实行“瀑布模型”。分为“概要设计”(5工作日),“开发测试”(10工作日),“版本验收&&下一版本的需求评审”(5工作日)三个阶段。总时间约为4周,1月1次版本迭代。可以简单地以月初为起点,月末为截止点。

“概要设计”:本阶段的输入是“评审后的交互设计”,需求已经基本稳定。

开发进行概要设计,在团队内部讨论实现方案,对于原型中逻辑不落地的情况及时提出修改意见。

“独立网关”设计API接口,能接的后台系统就接上,不能接的,提供修改界面,给测试录入测试用例数据。

测试设计测试用例,并在“独立网关”上输测试用例,创建Mock数据。

视觉进行页面设计,有问题或者变更及时和开发测试沟通。

领导、产品、运营等需求方原则上不要再变更需求,不过实在有必要,这是最后的变更机会,这个阶段变更的代价还是可接受的。

“开发测试”:开发、网关、测试、视觉等进入实际的执行阶段,以“虚拟小团队”模式进行,“每日站会”也可以开展起来,团队内部及时沟通。

领导、产品、运营等需求方在这个阶段不要提需求变更,给执行团队一段稳定的干活时间。如果有兴趣,可以参与相关“虚拟小团队”的“每日站会”,及时了解进展状况,能提供相应帮助就更好了。

“版本验收&&下一版本的需求评审”:产品和运营团队接管产品,进行验收。如果条件允许,可以切换到“内部试用真实服务器”,这取决于后台开发状况。根据实际产品体验情况,提出下一版本的需求变更。评审下一版本的需求。

开发在这个阶段做新需求的技术预研,验收阶段的hotfix,代码重构,历史遗漏bug的解决等事项。为下一阶段的开始做好充分的准备。

管理工具适合瀑布模型的“禅道”

独立网关



APP网关接口.jpg

APP端的API为iOS、Android、weex、H5统一提供数据服务


对多个后台服务做聚合,对APP提供粗粒度的数据,以减少远程网络调用次数。比如当前的首页要访问4次网络,可以在这里进行“聚合”,让APP只要一次网络访问,就能展示必要数据。


提供服务器切换功能。根据版本号,可以切换“开发服务器”,“内部试用服务器”,“正式服务器”三种。对APP提供统一的访问地址。


提供后台配置功能,有些地方叫CMS。在开发阶段,可以给测试配置测试案例,正式使用时给运营配置动态数据。


提供缓存数据服务。如果后台服务没好,可以在这里提供开发需要的Mock数据,让整个流程形成闭环。


提供公共逻辑,比如安全,监控,日志等,也可以配合后台加锁,加队列,减轻数据库访问压力等等。


提供“智能升降级”功能,隔离问题接口


提供流量控制开关,为“灰度发布”提供技术基础


关键点

1. 与传统模式的核心区别是:由“后台功能推动” 演变为 “前端需求拉动”。后台可以延后一个或者半个周期实现,面向“独立网关”的数据接口编程。在沟通上,大家讨论的“标的”由以前的“想法、Word文档、交互原型、设计图、动画、demo... ...”转变为“实实在在的产品”(应该说是半成品,后台数据落地就是成品了)。


2. App开发和PC开发相互独立,互不影响。PC和APP的特性不同,没有必要强调一致,也没有必要同步发展。


3. 由后台“技术驱动”,改为前台“需求拉动”,将一个很长的技术链分为两个阶段,面向“独立网关”这个接口编程


4. 是中间产品,是半成品,并不仅仅是Mock数据。在开发服务器上,70%以上的接口都是真正接上的,只有不超过30%的新增接口,才会在“独立网关”上先定义APP API,然后提供Mock数据。并且这个mock数据由测试选取“典型的测试案例”,“独立网关”提供通用的key-value数据库,以这个API的id为key,内容就是一个json。在后期的性能提升中,这个通用的key-value数据库还可以作为缓存服务存在。


5. 真正的开发时间还是“2周不变”。“设计一周”是为了加强技术团队内部的沟通,包括开发之间,开发与测试之间的沟通。“验收一周”是为了加强技术部门与需求部门之间的沟通。


6. 瀑布模型优点是风险管控严格,适合后台开发。迭代模型优点是沟通方便,适合APP客户端。以“独立网关”为切入点,两边用不同的开发模型


7. 职能型组织有利于专业技术积累。项目型组织有利于消除部门墙,利益趋向一致。“开发的两周”采用项目型组织,专注于目标的达成;“技术和验收的两周”采用职能型组织,重点在技术的积累。