迭代过程审计

迭代过程审计 Checklist落到【标准项目模版】-迭代【标准化项目管理模版】-迭代审计Checklist中进行模版管理
各项目中的迭代审计Checklist均由【标准化项目管理模版】-迭代审计Checklist中的模版工作项生成，生成更新时间为每日晚上10点/早上8点，默认给未生成的迭代生成或更新

| PM | 基于产品原型设计进行方案评审，确定需求整体逻辑框架，确定原型方案的可行性 |
1. 设计评审、需求管理中的有关评审的工作项，且工作项为评审通过状态
2. 输出产品原型文档以及相关的UI设计稿

| 技术优化迭代，不涉及产品参与 | （1）需求风险
⑥方案和产品内部没有对齐；
（8）设计和实现风险
⑥实现功能不美观 | | | 2 | | * 需求评审 | PM | 由产品经理明确本迭代需求范围、需求优先级、需求用户故事，澄清需求细节及团队成员提出的需求疑点，达到全员理解并确认统一需求

|
1. 迭代用户故事列表（需明确用户故事验收标准）
2. 评审会议记录（ Wiki 链接）
3. 产品经理在产品管理中维护新增或更新模块
4. 识别风险评估并记录：风险工作项
（识别是否涉及性能、兼容、其他客户端、新增服务、数据迁移、私有部署等）
|

| （1）需求风险
⑦需求理解不一致 | | | 3 |

| 需求反讲 | 迭代团队 | 研发理解需求之后，各成员站在各自的角度对产品需求进行5-10分钟讲解，再次统一确认需求

注：需求反讲前，测试需输出需求分析xind |
1. 需求反讲会议记录
|

|

| | | 4 | 规划 | 迭代计划会 | 迭代团队 | 研发人员对迭代规划需求的任务拆分并进行估算，以实现拆分后的每个用户故事可独立交付。
再次明确验收标准，使用敏捷扑克估算等方式进行故事规模的估算

注：用户故事定义与估算

| 1.拆分独立的用户故事以及和明确的验收标准
2.故事的规模估算大小

| 迭代规模或规划期望通过拆分任务预估工时得出 | (2)计划编制风险
①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致； | | | 5 | | * 技术方案评审及任务拆分 | 迭代团队 | 团队所有成员针对每个用户故事进行任务拆分与关联。
测试任务拆分输出测试计划
研发人员完成技术实现方案输出和评审，以及研发任务的拆分

注：拆分工作粒度建议不超过1天的工作量，可跟踪可量化
技术方案评审流程https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/HZFfFhw4

|
1. 技术方案工作项且状态流转为“评审通过”（描述中附有技术方案 Wiki 链接）
2. 测试提供测试计划
3. 任务拆解工作项列表（前后端研发任务、测试任务）
4. 识别风险评估并记录：风险工作项
|

|

| | | 6 | | * 迭代规划 | SM | 全员review拆分的任务，确认各角色对用户故事的理解一致，评估预估工时合理性，确定迭代最终的交付目标，预约发版时间

注：
预约发版日历https://ones.ai/wiki/#/team/RDjYMhKq/space/YDAdbsfS/page/CD3gE3PP |
1. 迭代概览中的迭代规划，以及迭代属性字段维护
2. 迭代描述中输出中各用户故事的提测时间以及各关键里程碑节点
3. 预约发版日历或同步上车信息

|

| (2)计划编制风险
②计划是优化的，是”最佳状态”，但计划不现实，只能算是”期望状态”；
③计划基于使用特定的小组/成员，而那个特定的小组成员其实指望不上；
④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；
⑤完成目标日期提前，但没有相应地调整产品范围或可用资源； | | | 7 | 执行 | 用例设计与评审 | 测试工程师 | 测试输出测试用例并进行用例评审，保障需求所涉及的测试点覆盖率，避免测试过程中遗漏测试点

注：用例评审有两轮，测试组内用例评审通过后才能进入迭代小组用例评审
用例评审需在开发过冒烟测试前完成 | 1.testcase中输出该迭代的冒烟用例与全量用例（ testcase 链接）
2.用例评审记录 | 无功能更新（例如：重构等） | （10）质量风险
①没有对产品功能形成检查点；

| | | 8 | | *研发执行 | 迭代团队 | 研发根据拆分的任务进行研发，Project内及时流转任务状态并登记工时，及时暴露风险 | 1.研发任务列表中的任务状态变更
2.研发任务完成后工时登记记录
3.测试日报 |

| （8）设计和实现风险
①设计质量低下，导致重复设计；
②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
③代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
④过高估计了增强型工具对计划进度的节省量； | | |

| | 迭代计划变更 | SM / PM | 针对开发实现过程暴露的风险及问题等解决方案而产生的必要的变更动作，必须由全员确认变更

注：变更管理流程https://ones.ai/wiki/#/team/RDjYMhKq/space/BAmFKYjn/page/NW5ET7FX | 1.变更申请工作项，且工作项状态为变更完成 |

| （9）过程风险
⑧过程中产生的变更，没有追踪及应对策略； | | |

| | *风险跟踪 | SM | 迭代过开发过程中遇到的可能会导致迭代进度不符合
预期影响各种问题，迭代负责人需在迭代各个过程中及早识别风险，记录风险，定期回顾风险

注：风险应对及监控
https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/TuZtaLub | 1.风险列表
（风险工作项中需提供风险原因、规避措施） |

| （4）人员风险
②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；
③缺乏激励措施，士气低下，降低了生产能力；
④某些人员需要更多的时间适应还不熟悉的软件工具和环境；
⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；
⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；
⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；
⑧没有找到项目急需的具有特定技能的人。
（9）过程风险
⑥风险管理粗心，导致未能发现重大的项目风险。 | | | 9 | | 研发执行自测、冒烟测试 | 前、后端工程师 | 研发完成一个用户故事或计划所确定阶段性需求范围的代码实现后，研发通过自测跑通冒烟用例确保提测功能主流程跑通 | 1.研发冒烟测试计划执行结果（ testcase 链接） | 无法以用例形式输出（例如：es优化等）
重构确定影响范围可以用产品库用例生成冒烟 | （10）质量风险
④研发输出达不到可验证状态 | | | 10 | | 研发提测 | 前、后端工程师 | 研发自测通过后，提供用户故事提测申请。提测申请中包含提测环境，提测范围与代码影响范围，包括是否影响构建服务等

注：研发代码改动影响范围输出指引https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/SfgL3nmZ
研发提测模块例子：
https://ones.ai/wiki/#/team/RDjYMhKq/space/JhCsWMTr/page/XzMC7wKv | 1.研发提测文档（ Wiki 链接） |

| （10）质量风险
⑤研发改动影响其他功能，测试不了解； | | | 11 | | * 用户故事测试 | 测试工程师 | 根据研发提测功能/用户故事和测试影响范围，从业务常见输出可能影响的场景模块针对性测试 | 1.用户故事工作项且工作项状态为测试通过 |

| （9）过程风险
②前期的质量保证行为不真实，导致后期的重复工作；
⑦已经识别的问题没有跟踪完成； | | | 12 | | * PM、UI、PO 验收 | 测试工程师 | 根据测试完成的用户故事进行产品验收，确保研发所实现的产品需求与预期一致

注：产品设计验收申请模版例子https://ones.ai/wiki/#/team/RDjYMhKq/space/JhCsWMTr/page/9odHtmtR | 1.验收结论（wiki链接） |

| （9）过程风险
③太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；
④过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作； | | | 13 | | * Code Review 通过并提供影响范围 | 前、后端工程师 | 研发同步完成bug回归且确保 code review 通过，如有改动需提供code review影响范围

注：影响范围记录不局限于code review，包括日常代码修改产生、合并代码冲突等

| 1.研发提测文档（更新记录其他影响范围） |

| （10）质量风险
⑤研发改动影响其他功能，测试不了解； | | | 15 | | 迁移检查
（迁移过程中写入数据场景及春生处预跑） | 后端工程师 | 后端工程师针对本次迭代的迁移输出迁移检查文档，对迁移时间内容等进行评估

注：迁移质量保障流程
https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/AxkhMKZh | 1.迁移检查文档（ Wiki 链接） | 无数据迁移 | （10）质量风险
⑦迁移过程中，新数据插入，迁移失败； | | | 16 | | 前、后端新增或修改服务、配置、数据库面向基础设施组演练 | SM、后端工程师 | 提前在预发布环境进行迭代演练，确保无故障上线
注：演练需在上线提前至少4个工作日
配置之应用于私有部署：钟庆豪
新增服务或其他：春生

注：演练文档https://ones.ai/wiki/#/team/RDjYMhKq/space/KHiPBucv/page/NPANrDwv | 1.演练文档（ Wiki 链接） |

| （8）设计和实现风险
⑦修改配置、服务、K8S方案不确认； | | | 17 | | *迭代演示 | 测试工程师 | 通过所有【利益相关者】参与迭代内的过程活动（定期演示）提前体验及review，做到产品研发及业务的信息对齐及有效沟通，及时发现问题，及时提出反馈改进。

注：目前开放能力与插件相关迭代属于震荡期，该类型迭代均采用线下演示
迭代演示流程及模版
https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/SrXPwmmM
问卷地址
https://ones.ai/wiki/#/team/RDjYMhKq/space/BAmFKYjn/page/VhFfQgkC | 1.迭代演示文档（ Wiki 链接）
2.迭代演示反馈结论（ Wiki 链接） |

| （6）客户风险
①客户对于最后交付的产品不满意，要求重新设计和重做；
②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；
⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长； | | |

|

| * 迭代回归集成测试 | 测试工程师 | 测试针对迭代范围，进行功能测试、迁移测试、私有部署测试、性能测试、兼容性测试并输出标准测试报告并评审通过

注：测试报告模版（包含内容：功能测试覆盖范围、兼容性测试覆盖版本、接口压力测试数据指标、测试结论、DI值<8）
https://ones.ai/project/#/testcase/team/RDjYMhKq/report |
1. 测试报告评审为通过状态（测试报告评审工作项）
2. 缺陷已关联测试用例
|

| （10）质量风险
⑦迁移过程中，新数据插入，迁移失败； | | | 20 |
上线 | *合并至预发布验证 | 前、后端工程师 | 迭代测试报告评审通过后，前后端将代码推至预发布环境，测试在真实的数据情况下进行迭代验证 | 1.预发布环境验证结论 |

|

| | | 21 | | *迭代发布 | 迭代团队 | 通过一系列发布部署活动准备检查及审批流程，确保上线发布工作顺利完成

注：打包checklist
https://ones.ai/wiki/#/team/RDjYMhKq/space/YDAdbsfS/page/D35Pd3sq | 1.发布管理发布申请单 |

| （8）设计和实现风险
⑧镜像还未构建完，导致发布失败； | | | 22 | | * 线上验证 | 测试工程师 | 产品发布上线后，确保线上环境运行正常，如有问题及时发现应对解决 | 1.发布申请单状态流转为验证通过/不通过
（不通过需标记“不稳定”，且说明验证不通过原因） |

| （10）质量风险
⑩无法保证预发布环境/线上功能正常； | | | 23 | | * 迭代总结 | SM | 回顾总结版本发布的经验教训，并对问题提出解决方案，确定可执行的改进计划，明确改进点及负责人，下次迭代开始由改进负责人监督改进

注：迭代回顾会
https://ones.ai/wiki/#/team/RDjYMhKq/space/DCBqNWkS/page/Gz5JAXLn | 1.总结 Wiki 地址
- 迭代度量数据（参考模板） （质量/进度/资源投入等）
- 改进计划 |

| （3）组织和管理风险
无法未效能提升，做出形成改进措施 | |