一、组织架构
一般来说，一个技术团队会有以下角色
对于产品强的团队，项目会被产品覆盖取代；否则的话，产品沦为需求分析和规格定义，而项目负责资源协调。设计有时会被归入产品团队。
在小于20个人的团队中，每个专业可能没有明确的组长，大概都是一个小Lead负责管理协调。只有组里人员超过5-7个人时，才会任命组长——经理级管理者。
二、发布管理（Release Plan）也可以叫上线管理
整个团队的工作，最终体现在上线上，所以，做好上线管理，是团队有机运行的核心重点。
上线最基本的配合在开发和测试，以及背后的产品和业务。基本流程是开发提交版本，测试跑用例验证，开发修改bug，测试验收，业务确认。
app版本号：x.xx.xxxx
第一位是大版本号，一般不大改不动，比如UI风格和功能结构修改；或者以年为单位
第二位是小版本号，一般是添加新功能块，以季度为单位，或者以月为单位
第三位是日常版本，小功能添加或者版本内bug修复，比如每周更新的版本
App现在审核都比较严格，小于一周的版本升级一般都是为了修改严重bug。
对于后台和H5，版本提交比较自由，一般不用版本号来标注，但是这部分也是管理容易忽略的地方，需要有一套体系来弄。
首先，也要有版本概念，而且是配合app的，所以要把一周以内的更新上线管理起来，尤其对于H5，可能每天都可以提交版本，那么就需要对提交做管理：第一、提交要有计划，第二、每个提交的定义要有复杂度，复杂度包括开发和测试，基本上可以定义1天开发完半天测完的是1级；2-3天开发完1天测完的是2级；一周开发完，2-3天测完的是3级。这样计划中不但有任务、时间还有复杂度，有利于多方协调。
到达上线要经过三步，第一步开发提测；第二步测试；第三步验收确认上线。一般来说，测试过程中包括开发的修改和重新提测，这是个反复多次的过程。最后的验收确认，并不等于测试完零bug，而是多方（项目、产品、业务、开发、测试）共同确认此版本可以上线，有哪些遗留bug。
因此，在制定某一上线版本的开发计划时，要这样倒推，上线时间减去缓冲时间减去测试时间是开发提测版本的时间。比如对于一个1级复杂度的功能计划在周二晚上7点上线，那么测试完成时间要在周二中午，而开发提测时间要在周二早上或者周一晚上。也就是说，对于最小的功能，开发也要提前上线计划时间一天提测版本，这样才不至于手忙脚乱。
