Please enable JavaScript.
Coggle requires JavaScript to display documents.
EPC (0、需求协作管理 (Level1 (需求批量提，批量测, 需求无唯一受信源，变更未周知和记录, 没有目标预估, 需求分析与沟通滞后且仓促,…
EPC
0、需求协作管理
Level1
需求批量提，批量测
需求无唯一受信源，变更未周知和记录
没有目标预估
需求分析与沟通滞后且仓促
bug明确记录到受信源
Level2
需求小批量提，小批量测
需求有唯一受信源，变更及时周知和记录
需求来自多方面并统一计划
区分优先级，考虑技术因素
每天评估遗留bug
Level3
编码前有测试用例，开发测试对齐无异议
提测前有产品和测试mini review
需求单个提测，提测点均匀
周期结束对bug进行分析总结，制定改进措施
上线后数据分析和总结
Level4
根据验证结果做出恰当决策
30%需求能明确列出需求假说，其中80%能做AB试验，及时分析总结，记录在tapd，辅助决策
Level5
Data Informed成为整个产品团队的工作习惯
80%需求进行AB试验，及时分析总结，记录在tapd，辅助决策
1、配置管理
Level1
源代码全部放入代码仓库
Level2
自动化测试代码放入代码仓库，并可与产品代码同源管理
每个需求有版本管理
Level3
需求--每次代码变更--制品互相跟踪
软件配置信息做版本管理，与二进制分离
业务配置信息做版本管理
数据进行版本管理（启动元数据、测试数据）
Level4
从代码库中分离二进制（或标明来源）
数据进行版本管理
配置进行版本管理
部署流水线相关配置进行版本管理
构建、测试脚本做版本管理
Level5
N/A
2、制品库管理
Level1
部分构建产物具有统一的生产环境制品管理和研发过程制品管理
Level2
有统一的生产环境制品库管理，清晰的产物库管理制度
有统一的研发过程制品管理
Level3
所有制品由统一授权环境生成，与持续继承平台联动，统一进行版本管理
组件、插件进行版本管理
Level4
第三方制品被各自产品线统一管理，可进行历史使用的追溯和安全审计
每个制品有元描述信息
制品与源程序版本进行管理并一一对应
Level5
第三方制品被PCG集中统一管理，并可与进行历史使用的追溯和安全审计
3、分支管理
Level1
特性分支开发，主干集成，分支发布。
50%分支生存周期小于等于5天
Level2
70%分支生存周期小于等于3天
特性分支有统一命名规范
70%的提交少于300行（除布局文件和配置文件）
Level3
每个特性分支同一时间段只做一件事，至少每人每两天MR一次代码
70%的提交代码少于200行（除布局文件和配置文件）
Level4
主干开发，主干集成，分支发布
80%的提交代码少于200行（除布局文件和配置文件）
Level5
主干开发，主干集成，且主干代码可随时发布
4、代码质量管理
Level1
制定并宣讲了代码规范
有CR
Level2
不低于PCG代码规范
强制执行代码规范扫描
问题数不新增
CR有效率达到20%
CR时关注技术债问题
关注代码安全性
Level3
对函数圈复杂度、TODO个数制定管理机制
技术Leader关注CR有效评论
CR有效率达到30%
CR时强调代码可读性
对代码可测性提出明确要求，CR时关注
定期安全扫描
Level4
建立代码owner机制
函数圈复杂度持续走低，或保持在低标准
CR有效率达到60%
强调代码可测性，并重点检查
架构设计、性能、安全成为CR重点
Level5
N/A
5、测试管理
Level1
启动开发前，各方对验收标准达成一致
发布前所有bug为已解决或挂起状态
团队有常规的bug bash活动
Level2
使用统一管理平台管理手工用例，有修改历史记录
测试用例覆盖100%需求点
测试用例集与被测软件部署包一一对应，可追踪查询
Level3
启动开发前完成测试用例评审
完成需求后立即开展验收，及时反馈缺陷，立即修复
测试用例集与被测软件提测包一一对应，可追踪查询
集成发布周期2天内
测试角色60%时间用于自动化测试用例编写，以及手工探索性测试
Level4
每天下午4点前发现的bug，90%当天修复
对测试过程的数据进行分析，调整测试策略
集成和系统测试发布周期少于8小时
测试角色80%时间用于自动化测试用例编写，以及手工探索性测试
Level5
使用数据分析方法和工具挖掘缺陷，优化质量管控策略，改进测试用例质量
持续探索先进测试技术提高效率和质量
整体的系统集成测试开始至灰度开始的周期小于2小时
测试角色90%时间用于自动化测试用例编写，以及手工探索性测试
6、持续集成管理
Level1
使用持续集成工具
每次代码合入都构建
提交构建内容必须包含冒烟自动化测试
Level2
MR的频率70%为3天以下
MR时进行代码规范扫描，进行自动化单元测试，自动化冒烟测试，失败禁止提交
MR后提交构建，失败立即修复，20分钟不修复自动回滚
每日至少一次全量自动化测试，团队持续集成成功率90%
提交构建时间小于20分钟
Level3
对服务或组件进行持续集成
个人MR间隔在2天以下
每次提交MR前完成一个相对完整的技术任务
MR前运行覆盖新代码的自动化测试用例并修复失败
MR后提交构建，成功后立即执行次级构建
提交构建时间小于20分钟，次级构建时间小于40分钟
Level4
提MR前自主运行mini非功能测试
提交构建包括mini非功能自动化测试
提交构建时间小于15分钟，次级构建时间小于30分钟
Level5
次级构建包含所有自动化测试用例
7、自动化测试
Level1
引入单元测试用例和工具
有覆盖率报告
明确单测用例分类分级标准
明确标记不稳定测试用例
创建冒烟测试集
Level2
修正不稳定用例，保证CI顺畅
冒烟测试的自动化率大于90%
增量代码的自动化测试覆盖率大于50%
small级自动化测试对代码覆盖率大于10%
Level3
新增重要特性都有自动化测试覆盖
自动化测试用例之间互相独立
small级自动化测试对代码覆盖率大于30%
次级构建跑完自动化测试后，手工发现的缺陷小于3个
Level4
自动化测试覆盖率满足：增量代码大于60%或全量代码大于50%
small级自动化测试覆盖率满足：增量代码大于40%或全量代码大于10%
次级构建跑完自动化测试后，手工发现的缺陷小于2个
Level5
所有的bug修复都有对应的自动化测试用例
所有的变更都有对应的自动化测试用例
自动化测试覆盖率满足：增量代码大于80%或全量代码大于70%
small级自动化测试用例覆盖率满足：增量代码大于60%，全量代码大于30%
次级构建跑完自动化测试后，手工发现的缺陷小于1个
8、开发测试与测试环境管理
Level1
发布前全部使用测试环境测试
手工搭建测试环境
Level2
生产环境与测试环境分离
开发环境与测试环境分离
自动化测试环境与人工测试环境分离
Level3
每个人有自己的开发测试环境
Level4
开发人员有云开发测试环境
Level5
一键自动化建立全新的开发测试环境
9、发布
Level1
每月一个灰度包，且不增加研发流程负担
每月一个正式包，且不增加研发流程负担
灰度到全量2周
Level2
两周一个灰度包，且不增加研发流程负担
两周一个正式包，且不增加研发流程负担
灰度到全量1周
Level4
每周一个正式包，且不增加研发流程负担
内测到灰度到全量，一周内完成
每周一个灰度包，且不增加研发流程负担
Level3
一键出多渠道包
建立内测群收集新特性问题
Level5
app一键上架
10、架构
Level2
各模块并行开发，相互独立，接口方式开放调用
产品作为一个整体打包分发
分层模块化，模块边界清晰
Level5
50%的大功能集轻客户端化
配置由云端下发
代码部署与特性发布分离
Level3
微核架构，组件边界清楚，依赖较少，通过微核交互
有特性开关，配置云下发
Level4
部分功能被轻客户端化
对开关机制提供良好支持
Level1
单体架构，功能之间互相影响较多
11、数据觉察
Level3
易：非专业人员可以定制监控与报表；统一的实时与离线数据分析平台
智：数据监测系统可以自主发现技术类监控问题
快：自动化数据收集与监控，及时发现问题。数据落地到展示小于10分钟，能够快速修复。
Level4
开关系统
用户分群系统
AB试验与分析平台
完善的数据对比分析图例与方法
易：非专业人员通过两天培训就可以自定义查询相关数据
智：数据监测系统可以自主发现业务数据波动异常
快：80%的数据从上报到展示小于1分钟；80%的AB试验从得到数据到作出行动小于10分钟
Level2
全
Level5
智：可以自主修复所发现的技术和业务问题；自动回滚版本；自动更新配置、开关。
Level1
准