App开发流程改进建议

问题和现状

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思维无线化”问题。

以上两点可以参考1号店架构师王庆友写的架构文章一个可供创业公司参考的移动APP服务端架构演进方案

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