原文：APP标准研制流程整理

APP研制办理是我这两年的作业重心，不久将挑战下个作业阶段，在此前对它再做一次整理做个强化

中心思路：依据团队的结构，拟定流程的履行标准，并依据团队改变及时调整，一同保存必定的灵活性，在红线以外应当给足各直接参加者自主抉择的权力。

绝大多数软件研制都要阅历产品规划、研制、测验、发布这四个阶段。这是研制流程的骨架，需求合作规划履行阶段的流程标准，拟定各阶段的衔接标准，才能让整个产研流程顺畅的作业，就像一个大型机械中的大齿轮与小齿轮的联系，任何一个环节堵塞低效，都会直接拖累产研这台大机械的作业功率。

APP 研制过程存在它自身的特别性，针对这些特别性的细节把握如同给齿轮打润滑油，非常重要。

处理需求来源：

  • 产品部需求

  • 运营部需求

  • 客服部需求

  • 技能迭代需求

  • APM收集的问题

  • 上级、老板需求

产研流程要坚持必定的灵活性，但要维护一线员工的作业少受干扰，授予一线成员直接拒绝需求的权力，一同规则临时需求估时超越2小时的不允许接，引导至直接主管对接。一般他们都有清晰的排期，再加上对优先级判别的信息缺乏，“帮个小忙”往往会严峻影响他们自身的作业进展，或许形成不必要的作业负荷。

需求上游不必定能精确识别需求的紧迫程度，汇总之后需求从全局审视优先级再行审视，优先级判别缺乏的辅助快速上升获取资源。有时他们提的不是需求而是一个处理计划，比方加个按钮加个提示，这些都需求引导至对应产品接收。

需求内审：

不管是产品部，技能中台，运营团队提交给研制的需求都要进行内审。从自身需求目标出发，与需求触及其他事务功用担任人或团队进行对齐信息，一是把关功用规划是否可行，二是合并版别。比方订单侧要新增需求要与商品、财政、仓库等上下流团队对齐，数据埋点需求要习惯新事务变化，尽量跟随需求同期上线。

需求初审：

最开端收到需求后会马上拉群组织需求评定，测验、研制、UI规划等项目成员一同参加。随着项目变大，人员大增，有的需求评定就需求十多个小时，评定可能会导致需求做较大调整，还需求重复评定，在正式投入前耗费较多时刻。

通过不断的总结复盘，建立了初审环节，下降正式评定时的作业量：

  • 产品需求供给整个团队的需求清单与全局唯一优先级
  • 正式评定前组织大前端、后端小组长评价大体上的技能计划，过滤大部分存在危险或不合理的需求规划，产品会后重新规划
  • 计划承认后各小组长大略评价工时，结合优先级，承认本次可评定的规模，是否做版别拆分

需求评定：

此环节的关注点：进步会议质量，下降不必要的人力耗费

  • 在会议开端前，大需求最少提早2天将需求文档等资料发至项目组成员
  • 对需求文档中发现的问题与疑问优先在文档上谈论，未处理的在会上按需求讲解次序发问，防止开大锅会
  • 会议过程中提出的未承认的问题，产品记载会议纪要，会后同步至项目大群，与之后的项目问题一致进行状况更新维护
  • 针对部分参加人员触及的模块足够独立，上下流依靠程度低，可在会前定好可只参加相关部分时段
  • 产品要先担任UI规划的审阅，承认往后再交给研制。UI规划稿最好是在需求评定时一并供给，研制评价需求会更精确

技能评定：

这部分一般会花1-2天的时刻，但不是必须的。

这儿特别要注意的是部分团队首次合作时要做好通用的技能计划规划，比方后端有C，PHP，GO，JAVA等不同的服务，但前端开发需求促进一致的接口交互标准：

  • 要预备的服务器环境，测验环境、预发环境、出产环境
  • 接口API标准、接口文档标准、接口通用根数据模型、统筹强类型与弱类型的字段类型规划
  • 后端开发要接口先行，针对新增接口，要做进行接口评定，防止形成瀑布式开发

预估工时：

仅拿APP来看，即使是能力不错的中心事务担任人，也容易出现工时预估精确度的问题。特别是前端多少存在面向UI开发的固化思维，往往是越了解的模块估时越是过于乐观，形成进展危险。

所以在APP侧咱们要求：

  • 估时以是谁担任谁估时为准
  • 预估工时前要整理开发计划RoadMap，触及老代码要详细到类与接口。（这一步是为了将了解代码，整理代码结构的时刻前置，供给估时的精确度）
  • 依据工时模版表，将UI开发与联调使命计数与估时分开（表格将自动算估时状况，核算各模块实践进展）
  • 各端小组长审核估时，一般是在总估时的基础上依据难度系数的判别乘一个系数

项目排期：

这一步的中心是作为项目担任人要统筹协调各端的开发联调时刻节点，依据项目实践状况确定各模块是一同提测仍是分阶段提测，承认提测时刻、提测次序的组织。

研制：

  • 每天在项目办理渠道更新使命进展，填写工时耗费
  • 碰到项目问题要及时抛出到大群，并@直接主管与项目担任人，防止单聊导致问题处理滞后
  • 开发不能够私行接私活或暗里需求改变使命，要上升到项目团队
  • 提测包由CI自动构建，防止绕过代码审查，lint检查等安全措施

冒烟：

此部分完全由测验主导，把控冒烟是否要求开发到场帮忙，是否能够分批冒烟。针对特别项目状况，调整冒烟颗粒度

  • 硬性准则：冒烟不通过将面临严峻的绩效赏罚

提测：

测验过程要求：

  • Bug重复扭转时未解须写明原因
  • 影响流程的Bug开发必须日清，无法完结则需求上升到项目团队
  • 测验每日在大群报告测验进展，是否面临堵塞问题，对后续测验作业的影响阐明
  • 特别要注意版别更新兼容性测验，此功用一坏对APP来说就是灭顶之灾

上线：

APP的上线过程要确保版别信息与安装包的安全高效的传递，要确保测验做正式验收的包传递到运营小伙伴时中间要线上全自动化，不能有人为参。
由产品发起简道云APP上线流程，填写发布版别与渠道等信息。流程将通过测验正式验收，运营上架市场，关键节点将会自动通过企业IM同步至相关担任人。

针对体量大的APP一般都需求先走灰度观察APM状况，用户数据状况，没有反常再进行全量发布。面临反常要先发布回滚版别掩盖灰度的用户，并制造修正版别重新走研制流程。

线上版别补救：

APP根据其自身的特性，不能像Web一样快速补救，由于受限于缺乏日志，用户网络场景，联系用户本钱高级条件APP排查线上问题一般都比较困难。

这儿需求遵循一个重要的计划选择次序：

  • 是否支撑容灾
  • 从运营侧关闭进口或替换内容，优先止损
  • 服务端能不能兼容处理，不需求APP发版别
  • APP 热更新（一般公司IOS基本用不了）
  • APP 新增版别掩盖修正

项目复盘：

健康的团队越做越健康，不健康的团队越做死的越快

浏览橘子树其他文章：橘子树的个人写作记载