CAD 迭代工作流程

版次：2021年11月01日 第4版
类型：程序文件
作者：CAD组
上海维宏电子科技股份有限公司
修改历史
文件版本 修改前文件版本 主要修订内容和原因 修订人 修订日期
R1 新增文档 CADCAM 组 2013-3-5
R2 R1 修改完善迭代会议安排 朱延晓 2019-7-2
R3 R2 按照最新代码管理方式更新部分开发过程以及调整文件格式 朱延晓 2019-9-19
R3.3 R3 变更迭代周期，同时增加要求 张艳丽 2021-1-29
R4 R3.3 添加发布准出条件，更新迭代变更内容注意事项（已标为红色） 杨梅 2021-11-1

1 目的

为规范 CAD 组成员在迭代开发工作中的行为，明确各个环节实施人员的相应责任，提高研发产品质量，特制订本工作流程。

CAD 组实行敏捷开发的方式，每月为一个迭代周期（紧急 BUG 除外），每个周期的关键活动又分为一些子活动和具体要求，大致包含以下内容：

  • 迭代负责人确定。

  • 迭代范围和目标的确认。

  • 迭代计划制定（每月计划表）。

  • 迭代方案评审（个人评审+团队评审）。

  • 编码及代码审核。

  • 迭代测试、代码合并和迭代验收。

  • 迭代计划跟进（迭代开始前会议以及每周一次例会）。

  • 迭代发布。

  • 迭代变更。

  • 迭代回顾总结会议。

2 迭代负责人选定

每次迭代开始前首先确定迭代负责人（在月度计划时指定迭代负责人）。

迭代负责人采用轮流制，主要的职责有：

  • 迭代前的准备，内容包括：

    • 检查迭代周期的工作内容是否已经创建了工作项（由工作项的开发人员或是质量保证团队责任人创建），并且工作项能够在当前迭代周期检索到。

  • 迭代开发分支的确定（原则是减少迭代分支，解决发布版本过多的问题。）

    关于分支确定的原则：

    • 原则上新增功能在独立分支上开发；

    • 一个迭代周期的 BUG 在同一个分支上解决，目前一般为 DEV1 分支专门用来解决 BUG （如果 BUG 导致代码变的多且复杂，则需单独在另外一个分支上解决）；

    • 新增功能和 BUG 需要在分支上验证通过后再签入主干验证，但并不是所有的分支修改都需要提交测试版本；

    • 代码评审人员和迭代负责人评估确定是否需要发布分支版；

    • 开发人员要对自己的代码以及功能负责，充分自测验证以及进行自动化测试，不要仅仅为了心里安慰而所有分支功能都发给质量保证团队测试。

  • 迭代计划的跟进，每周组织一次迭代例会，当进度和质量出现问题时，及时组织评审。

  • 迭代计划测试版和正式版的发行时间确定和跟进

  • 迭代验收后问题的跟进。

  • 迭代回顾与总结等

3 迭代范围和目标的确认

3.1 迭代范围确认前期准备

迭代负责人：

  • 检查本迭代周期计划解决的事情，是否都按要求创建了 Task 或 Bug；

注意：工作项的难度、开发人员的能力、工作项的优先级等，特别是优先级的定义要明确。优先级划分建议如下：P1 为迭代必须发布的；P2 为根据后期的开发进度评估是否可以在本次迭代发布的；P3 为可以从本次迭代移除的。

根据优先级以及工作的饱和情况，修改 TFS 对应的 Iteration 以及优先级字段，详细的填写要求见《CADCAM 组工作流程简述.docx》以及《CADCAM 组 TFS 填写规范.docx》。

  • 确定迭代目标，一般有以下几类：
  1. 调研任务：调研类的产出是调研报告（调研报告需要进行竞品分析，现在主要参考柏楚、FastCam、大族激光、Camworks 或其他）；
  2. 方案预研：方案预研的需要有方案分析报告或是总结；
  3. 规格文档：需要按照规格模板，输出规格文档。所有任务或 BUG 都必须有规格文档，对于 BUG 工作项，在维护代码的同时，开发人员需要同步维护规格文档，不能出现代码维护了，但规格文档未维护的问题。
  4. 方案设计：按照方案设计文档的模板，输出方案设计文档（必须明确设计目标）。所有的 Task 必须有方案设计文档，BUG 超过 2 天编码工作量的，必须上报评审（以沟通清楚方案为主要目的，不需要出具具体的方案设计文档）；BUG 解决工作量超过 5 天的，必须有设计方案文档；外部 BUG 解决方案必须上报评审。
  5. 发行软件：紧急的或是优先级高的，需要在本次迭代发行软件。

组内发行软件时，针对功能和优先级不高的 Bug，原则上一月一个迭代发行，特殊情况时，需要迭代负责人说明原因，避免中间紧急发行软件的情况。

3.2 召开迭代范围确认会议

主要内容为对已筛选的 Task 和 bug 进行确认。

  • 迭代负责人提前一天进行会议安排（需要有投影仪的会议室以及能够连接 TFS），并通知相关人员；主要目的是明确任务安排。

  • 迭代会议参与人：开发人员、质量保证团队，必要时邀请业务线相关人员等。

4 迭代计划制定

每月月初前 3 个工作日内，各组负责人完成迭代计划表的编制。迭代计划中包括开发任务以及测试相关任务。

迭代范围确认会议后，各工作项负责人在迭代确认会议第二日下班前，填写 TFS 工作项中的时间安排（工作项对应的开发人员为工作项的责任人，需要主动找测试协商测试时间，必须发行软件的，需要有明确的测试版发行时间、代码合并时间、正式版交付时间）。

  • 计划时间安排填写要求有：
  1. 开发需要与 CAD 组测试负责人沟通测试时间；
  2. 本次迭代发布软件的工作计划需包含需求分析、需求审核、方案审核、编码、自测、代码审核、测试版发行、测试、代码合并、回归测试、正式版发行；
  3. 最大颗粒度：2 天，超过两天的工作量需要拆分，工期计量单位以天计算；
  4. 预留 10% 的时间作为风险时间。
  5. 如根据业务线要求以及总工评估后，需要变更迭代范围，则应及时告知相关责任人修改迭代计划。
  • 迭代周期内，迭代负责人根据上述计划安排，确定迭代周期内的测试版发行要求：

  1. 为保证验收的及时性，原则上 5 天左右发布一个测试版，控制发布分支测试版在 3 个；

  2. 并不是所有的分支修改都需要提交测试版本。代码评审人员可以和迭代负责人员评估确定是否需要发布分支版；

  3. 制定迭代测试版发行计划时，可以初步确定分支发布的日期，包含以下内容：

    如迭代周期：7.15~7.26

    日期 分支提测版本 计划包含内容

    7.18 dev-xxxx Task-xxxxxxxxxx

    7.23

    7.26

  4. 软件发行由迭代负责人指定专门人员发行，并填写相关信息，解决发行人员过多，发行信息混乱，遗漏问题。

原则上采取每 5 天发布一个测试版的方法，避免内部版本数太多。代负责人根据迭代计划中大家给出的发布软件时间，跟进发布测试版的情况。

  • 迭代结束前 5 天，dev 签入代码锁定，不允许再签入到 dev（可放到下个迭代开始时签入）（除特殊情况外，比如业务线已经明确答应客户，或是P1级的工作，但是特殊情况不允许成为例行）

5 迭代规格、方案设计、测试方案与评审

Task 和 BUG 工作项必须有规格文档、方案设计文档、自测报告（规格中的所有内容需要验证、需要补充自动化测试的，自动化编码必须完成，已有自动化测试的，自动化测试必须通过）、Checklist 完成文档。

测试要求：单功能测试必须覆盖测试模板和标准测试方案中的测试点。

凡是工作量超过 5 天的任务和 BUG，必须召开团队评审，团队对规格、设计方案、测试方案进行评审，由任务负责人主动安排。如果编码工作量超过 3 周的，在方案确定后的第一周，需对代码进行团队评审。

6 编码及代码审核

因为 CAD 组使用分支方式管理代码，所以要求做到尽可能早的审核代码，保证代码及时审核，及时发现问题，及时修正，最晚审核时间为软件发测试之前。代码审核需要通过代码审核工具，并留下审核意见。没有代码审核记录的，质量保证团队拒绝测试，特殊情况需要上报对应负责人。

为统一大家代码审核的标准，CAD 组每月会举行 1~2 次代码评审分享（团队评审时分享）。

代码评审要求包括：

  1. 编码过程中需要代码互评，并将评审记录保留；
  2. 审核人员需要同时审核测试范围是否存在问题；
  3. 已有库需要保证通过 cppcheck 以及编译器的检查，无任何 error 和 warning，并且通过库的功能自动化测试；编译器的 output 无内存泄露相关提示（若存在但并非自己模块的请及时通知相关模块负责人以及总工）；如果是新增加的库，必须有对应的自动化测试模块。计算类的库，必须进行相关性能测试（自动化）。

凡是编码工作量超过 5 天的，需每周评审一次（个人评审），便于及时发现问题，进行修正。

7 代码合并和迭代验收

代码管理的要求：

  • 代码与变更集关联的相关性和独立性
  1. 每个变更集必须与特定的 BUG 工作项或对应 Task 关联；
  2. 如果代码是解决 BUG 的，此时变更集需要同时关联 Task 和 BUG 工作项，不能只与 Task 关联或是与不相关工作项关联，且需要每个变更集对应单独的 BUG ，不能几个 BUG 修改后签入在一个变更集中。
  • 分支和主干的关系
  1. 修改 NcEditor 的代码，默认情况采用分支上开发，经过验证后再合并到主干的方式，且在发布测试版本前，必须经过代码审核；
  2. Libs 下的各个库因为修改频率较低，且不存在同时多人修改的情况，所以不采用分支的方式开发，但如果修改周期大于 10 天，采用分支开发的方式。
  • 分支和主干的同步、合并操作
  1. 每次迭代开始前以及分支发行测试版本时，分支代码需要将 Dev 代码同步至开发分支代码（Dev -> Devx）；
  2. 分支测试版本通过后，发行正式版时，需进行分支->主干的合并操作，合并需要在本地解决冲突（冲突手工解决，不可以自动解决冲突）、再提交服务器，然后发行正式版。

代码签入时，请先签入代码，再签入 readme 或 publish.log，保证签入变更集与填写内容一致。

迭代验收分为两个部分，一是分支测试版本的测试，二是主干正式版的验收。开发在发行测试版本时，需要按照发行要求填写。

测试准入条件：

  1. 开发自测必须覆盖功能基本场景、典型异常场景以及边界等情景，需提供开发自测报告，详见测试报告模板，路径：$/cadcam/V15/Doc/01规范制度/02开发工作流程与规范；
  2. 符合《软件测试流程&过程规范》中给出的准入条件；

8 迭代发布

迭代发布日期一旦确定，必须在迭代发布日期前（含发布日期）发布，如发现无法准时发布，迭代负责人需及时上报。

测试环节验收时，如发现严重问题，可能会影响发布，需及时反馈。

迭代验收通过后，由质量保证团队进行发布通知的填写，将发布记录上传 Wiki，并发布通知，同时通知到业务线。

现在业务线修改的 CAD 所属功能必须由 CAM 组验收，质量保证团队需要对这部分工作项增加发布说明以及影响范围。详细信息见：http://172.16.10.17:86/#!CamTest/05 发布说明

发布准出条件：

  1. 所有的 task 均验收测试通过，所有用例执行通过， task 下不存在未处理的 bug，拖迟处理的必须开发调查过，并与质量保证团队负责人确认可以延后处理。
  2. 发布之前所有功能的自动化测试全部测试通过。
  3. 如果是手工打包，需要保证人工测试界面上所有功能的基本流测试通过。
  4. 软件系统测试必须测试通过，测试范围见对应项目的系统测试方案。
  5. 发布当天，测试迭代负责人，需要再梳理一遍 Bug，严重的 bug 必须全部解决，确保修复的 Bug 均验收通过。

以上若在发布日期之前达不到，则必须向上反馈。

开发工作流程图如下：

CAD开发工作流程

详细流程图具体路径为：\\file01.weihong.com\02.各部门受限\12.CAD 平台\20.CADCAM 组\01.cadcam 组开发过程\CADCAM 开发流程图-R1.2.vsd

迭代发布之后，开发人员和质量保证团队进行相关文档的整理，并将文档上传至 168 服务器 CAM 源代码管理：Dev\Doc 目录。

持续集成与包管理注意事项的相关内容见以下路径：[\\file01.weihong.com\02.各部门受限\12.CAD 平台\20.CADCAM 组\01.cadcam 组开发过程\ NcEditor 开发注意事项-R2.docx](file:///\172.16.10.66\NWfile02\01.安全内网文件夹\01.研发部文件\01.各组文件\20.CADCAM组\01.cadcam组开发过程\ NcEditor开发注意事项-R2.docx)。

9 迭代插入和变更

原则上迭代范围确认后，不再变更，但对于严重或致命 Bug（包括外部反馈以及内部测试发现的发布版本存在的），严重影响客户使用的，需及时响应和修复，并向质量团队负责人和迭代负责人汇报，质量负责人须要第一时间通知相关各业务线，明确告知影响范围以及需要业务线暂停止当前的发行，等待问题修复后再继续发行。由质量保证团队触发对应 Release 版本和开发迭代负责人确定发布Release时间，并更新 SDK 发版计划告知业务线。

根据问题发现的版本，修复有几种情况，但是原则为：优先修复发现问题版本，再同步至其他版本。

  1. 如果问题发现在 Release 版，则最先修复 Release 版，然后再同步至 Beta 分支，紧接着从 Beta 分支同步至 Dev 分支。
  2. 如果问题发现在 Beta 版，则最先修复 Beta 版，然后再同步至 Release 分支，紧接着从 Beta 分支同步至 Dev 分支。
  3. 如果问题发现在 Dev 版，常规情况下：最先修复 Beta 版，然后再同步至 Release 分支，紧接着从 Beta 分支同步至 Release 分支。此时根据影响程度决定，版本修复的顺序。

10 迭代回顾总结会议

迭代周期结束后，质量保证团队发起开展回顾会议，回顾会议主要讨论迭代过程中存在的问题（低级 Bug、严重 Bug、代码评审执行情况、开发和测试过程中可以改进的点等），其中：

  • 回顾会议召开之前，开发人员和质量保证团队梳理 Bug 的出现原因，并在回顾会时统一分享，需要按照纠正预防的方式进行总结，从人、机、料、环、法、测几方面分析，确保措施的可执行性；

  • 每次迭代会议时对本次迭代中有突出表现的人员进行表扬和奖励。

  • 回顾会议之后，对于总结措施具体实施要求。

11 工作项的填写要求

详见《 CADCAM 组 TFS 填写要求-R4.doc》，工作项的具体填写要求参照以下路径：$/cadcam/V15/Doc/01 规范制度/03 测试工作流程与规范

12 原则和约束

1、 本次迭代安排的任务引出的 Bug，需要在本次迭代完成，若本次不修改的，需及时通知负责人，并由负责人决定放在延迟处理或者下个迭代。新创建的 BUG 原则上都要处理，如果调查后任务解决复杂度高，或是影响不大，认为可以不处理的，需要找负责人沟通，不可以擅自决定不处理，由相关责任人标记是否处理。如发现开发人员擅自决定不处理 BUG，将根据 BUG 实际造成的影响对开发人员进行惩罚。

2、 迭代版本发行之日，所有迭代相关开发人员、迭代负责人需待版本发行之后，才能下班，有特殊情况时，需向迭代负责人请假说明，如出现未请假而提前离开的情况，由提前离开人员，在总结会议时表演一节目。

3、 严格执行 checklist 的检查条目，仔细阅读，对于内容不确定时及时沟通。如 checklist 未执行到位，视具体情况进行相关惩罚。

4、 冒烟测试不通过，视具体情况进行相应的处罚。

5、 出现外部反馈因未按用例执行反馈的 Bug，视具体情况进行处罚。

6、 出现外部反馈因未覆盖测试模板中和标准测试中测试点的 Bug，视具体情况进行处罚。

7、 原则上影响客户加工的外部问题处理优先级最高，迭代计划中的工作优先级高，对内的需求优先级低，如果不能确定事情的优先级，及时找相关负责人进行确认。

8、 开发人员需尽可能的帮助质量保证团队复现一些不能稳定复现的 Bug；

9、 如果出现崩溃、蓝屏、死机的问题，开发必须优先解决；

10、 Bug 的原因尽量描述清楚，可以使用业务语言和代码原因两种描述方式；

11、 变更集跟着 Bug 走，checklist 跟着工作项走。所有 Task 和 BUG 必须都要有 checklist 检查表。

12、 当工作项关闭之后，新增需求不在之前的需求单之内的继续维护，需要重建工作项；

13、 若因需求、时间、方案变更，或发现任务时间预估不够，需要走变更流程。变更流程为：申请人向对应负责人提出申请，同时将变更记录登记在 TFS 工作项中；

14、 关于迭代任务里的 Bug ，如果确实需要延期，需经迭代负责人和质量保证团队负责人同意批准；

15、 Task 引入的 Bug 原则上必须解决，才可以签到 DEV，否则不允许签入 DEV，如需签入需上报总工审批；

16、 如果工作方案不确定，或者对代码不了解，可以通过调研，晚些给出工作计划。

13 其他

非迭代任务的开发流程，开发要求与迭代开发流程要求一致。

编制：CAD组 审核：张艳丽 批准：陈豫