问题和现状
产品会在临上线一两天提出需求变更
在需求评审阶段，看不出问题，在执行阶段，发现逻辑需要修改。
领导临时加需求，往往导致加班
上线压力大，有点乱，有点急，风险高，容易出现遗漏问题，临时版本多
在开发过程中，需求仍然不确定，导致反复修改，相关人员对同一问题的理解偏差较大
后端扩展个信息，测试增加测试案例等等都可能导致客户端进行修改。
原因分析
从后台到移动客户端整个流程太长，涉及人员太多。沟通不充分和依赖等待造成的浪费很大
单纯的word文档，或者口头说，比较抽象。评审环节必不可少，不过光靠评审是不够的。发现的风险，评估的工作量等都不是很准确。
交互设计毕竟是模型，跟实际程序相差比较大。如果做高保真模型，产品将挤占更多的开发测试时间，导致设计和实际程序落差更大，开发的加班更多
PC和APP共用一套后台，耦合严重，APP开发“PC思维无线化”现象严重
开发版本直接上线运行，中间缺少缓冲，风险较大
缺乏概要设计和充分的验证，导致边开发边改需求，造成不必要的浪费和混乱。
开发、验证、上线三个关键动作集中处理，压力大，风险高
如何解决？
在APP和后台服务之间增加“独立网关”，独立开发，独立部署，作为“APP的后台，后台服务的前端”。
APP和PC各自拥有“独立网关”，根据各自特点独立开发，独立部署，实现解耦，解决“PC思维无线化”问题。
以上两点可以参考1号店架构师王庆友写的架构文章一个可供创业公司参考的移动APP服务端架构演进方案
- 以APP的“独立网关”为切入点，将整个流程分为“APP开发”和“后台开发”两个相互独立的部分，解决流程过长的问题。
- “APP开发”适合用“迭代开发”的思维，与产品和运营做更充分的沟通。主要任务是快速应对需求端的变化，并将需求变化集中在前端，为后台开发提供一个相对稳定的环境。
- “后台开发”适合采用传统的“瀑布模型”，面向“独立网关”进行服务开发，与终端用户、产品、运营等实现解耦。主要是实现高并发，稳定可靠的服务，从本质上提升用户体验。
- 版本模式分为开发版本，内部试用版本，生产版本。
- 开发版本采用内部release的方式，接开发服务器，使用者主要是开发和测试。
- 内部试用版本接“独立的真实服务器”，用户总数受控制，比如100个。iOS版本在审核期间也可以接这个版本，可以提供提供几个“超级用户”，方便审核人员审核。使用者主要是产品，运营，以及经过筛选的“认证用户”，比如公司领导、外部合作商户、内部员工、铁杆粉丝等等。
- 生产版本接“正式的生产服务器”，用户比例受控制，采用“灰度发布”的方式，逐步放开用户量。使用者主要是产品和运营。
- 将发布、验证、上线三个关键节点在时间上错开
流程改进
- 第一级：“瀑布模型”，分为“APP开发”和“后台开发”两个阶段，面向“独立网关”进行开发。
- “APP开发”优先，主动应对领导、产品、运营等的变更需求；让抽象的设计尽早变成实际可用的产品。
- “后台开发”待变更基本稳定之后，基于特定的APP产品提供具体的实现，专注于高并发的处理和安全性。
- 第二级：“APP开发”实行“迭代开发”。“后台开发”采用“瀑布模型”。
- 视觉、开发、测试、网关等组成“虚拟的小团队”，指定一个负责人，面向具体业务开发。
- 人数限定在10人左右。
- 实行“每日站立会议”制度，每人限时1分钟，讲清楚（a）昨天做了什么（b）今天做什么（c）需要什么协助。
- 如果能能将“虚拟的小团队”的座位调在一起，成立“作战室”，效果会更好
- 管理工具适合迭代模型的“JIRA”
- 第三级：在一个迭代周期中，实行“瀑布模型”。分为“概要设计”（5工作日），“开发测试”（10工作日），“版本验收&&下一版本的需求评审”（5工作日）三个阶段。总时间约为4周，1月1次版本迭代。可以简单地以月初为起点，月末为截止点。
- “概要设计”：本阶段的输入是“评审后的交互设计”，需求已经基本稳定。
开发进行概要设计，在团队内部讨论实现方案，对于原型中逻辑不落地的情况及时提出修改意见。
“独立网关”设计API接口，能接的后台系统就接上，不能接的，提供修改界面，给测试录入测试用例数据。
测试设计测试用例，并在“独立网关”上输测试用例，创建Mock数据。
视觉进行页面设计，有问题或者变更及时和开发测试沟通。
领导、产品、运营等需求方原则上不要再变更需求，不过实在有必要，这是最后的变更机会，这个阶段变更的代价还是可接受的。- “开发测试”：开发、网关、测试、视觉等进入实际的执行阶段，以“虚拟小团队”模式进行，“每日站会”也可以开展起来，团队内部及时沟通。
领导、产品、运营等需求方在这个阶段不要提需求变更，给执行团队一段稳定的干活时间。如果有兴趣，可以参与相关“虚拟小团队”的“每日站会”，及时了解进展状况，能提供相应帮助就更好了。- “版本验收&&下一版本的需求评审”：产品和运营团队接管产品，进行验收。如果条件允许，可以切换到“内部试用真实服务器”，这取决于后台开发状况。根据实际产品体验情况，提出下一版本的需求变更。评审下一版本的需求。
开发在这个阶段做新需求的技术预研，验收阶段的hotfix，代码重构，历史遗漏bug的解决等事项。为下一阶段的开始做好充分的准备。- 管理工具适合瀑布模型的“禅道”
独立网关
APP端的API为iOS、Android、weex、H5统一提供数据服务
对多个后台服务做聚合，对APP提供粗粒度的数据，以减少远程网络调用次数。比如当前的首页要访问4次网络，可以在这里进行“聚合”，让APP只要一次网络访问，就能展示必要数据。
提供服务器切换功能。根据版本号，可以切换“开发服务器”，“内部试用服务器”，“正式服务器”三种。对APP提供统一的访问地址。
提供后台配置功能，有些地方叫CMS。在开发阶段，可以给测试配置测试案例，正式使用时给运营配置动态数据。
提供缓存数据服务。如果后台服务没好，可以在这里提供开发需要的Mock数据，让整个流程形成闭环。
提供公共逻辑，比如安全，监控，日志等，也可以配合后台加锁，加队列，减轻数据库访问压力等等。
提供“智能升降级”功能，隔离问题接口
提供流量控制开关，为“灰度发布”提供技术基础
关键点
与传统模式的核心区别是：由“后台功能推动” 演变为 “前端需求拉动”。后台可以延后一个或者半个周期实现，面向“独立网关”的数据接口编程。在沟通上，大家讨论的“标的”由以前的“想法、Word文档、交互原型、设计图、动画、demo... ...”转变为“实实在在的产品”（应该说是半成品，后台数据落地就是成品了）。
App开发和PC开发相互独立，互不影响。PC和APP的特性不同，没有必要强调一致，也没有必要同步发展。
由后台“技术驱动”，改为前台“需求拉动”，将一个很长的技术链分为两个阶段，面向“独立网关”这个接口编程
是中间产品，是半成品，并不仅仅是Mock数据。在开发服务器上，70%以上的接口都是真正接上的，只有不超过30%的新增接口，才会在“独立网关”上先定义APP API，然后提供Mock数据。并且这个mock数据由测试选取“典型的测试案例”，“独立网关”提供通用的key-value数据库，以这个API的id为key，内容就是一个json。在后期的性能提升中，这个通用的key-value数据库还可以作为缓存服务存在。
真正的开发时间还是“2周不变”。“设计一周”是为了加强技术团队内部的沟通，包括开发之间，开发与测试之间的沟通。“验收一周”是为了加强技术部门与需求部门之间的沟通。
瀑布模型优点是风险管控严格，适合后台开发。迭代模型优点是沟通方便，适合APP客户端。以“独立网关”为切入点，两边用不同的开发模型
职能型组织有利于专业技术积累。项目型组织有利于消除部门墙，利益趋向一致。“开发的两周”采用项目型组织，专注于目标的达成；“技术和验收的两周”采用职能型组织，重点在技术的积累。
