我们如何用敏捷交付合规项目

一、先说结论：敏捷和合规不是二选一，而是「如何把合规嵌入迭代」的工程问题

2021年第三季度，我们团队接手了一个医疗器械行业的软件项目。甲方在合同里写得很清楚：交付物必须符合《医疗器械软件注册技术审查指导原则》，所有代码变更要有完整审计轨迹，测试用例与需求条目要一一对应，且不允许出现任何“先上线再补文档”的操作。而他们找我们的原因也很简单：之前一家传统瀑布式外包团队已经拖了14个月，文档堆得比代码还厚，但能跑起来的系统连Demo都算不上。

我们被要求在6个月内完成可注册申报的最小可用版本。这意味着，我们必须在每个迭代里同时回应两个看似冲突的诉求：一边是小步快跑的敏捷交付节奏，一边是医疗器械注册对过程合规、文档完整性和可追溯性的强制要求。

当时团队内部有过一次激烈争论。产品负责人问我：“我们真能用Scrum交付合规项目吗？还是说这本身就是个错误的选择？”

我的回答至今没变：合规要求和敏捷开发之间的矛盾，绝大多数不是方法论层面的不可调和，而是工程实践层面的未被解耦。我们后来用6个月零11天完成了交付，并帮助甲方通过了药监局的注册检。这篇文章，我想把那次项目里真正起作用的判断、做法和踩过的坑完整拆出来，给同样面对这个问题的团队一个可参照的实战框架。

二、这个项目真实长什么样：一个必须“可审计”的敏捷项目全景

1. 需求端的合规约束

医疗器械软件注册有一条硬性要求：软件需求规格说明书（SRS）必须与风险分析报告、系统测试用例形成双向追溯矩阵。这意味着每一条用户故事都不是“写出来就能做”，而是必须回答三个问题：这条需求对应哪个风险项？它在哪个测试用例里被验证？它最终在哪个版本里被实现？

我们面对的需求池包含217条初始需求，其中47条与安全性直接相关。甲方质量保证部门（QA）要求我们提供从需求到代码提交的完整链路证据，不是“事后整理”，而是“随时可查”。

2. 团队端的现实约束

项目团队配置如下：

• 后端开发：3人（其中1人有医疗行业经验）
• 前端开发：2人
• 测试工程师：2人（1人专职自动化测试）
• 产品负责人（PO）：由甲方业务专家担任
• Scrum Master：由我方项目经理兼任
• 甲方QA代表：全程参与每个迭代评审

这个配置里最关键的角色是甲方QA代表。很多人以为敏捷项目应该尽量减少外部干预，但在合规场景下，把QA角色排除在迭代之外是灾难性的，他们会在最终审计时一口气提出大量追溯问题，而到那时候再补文档的成本远高于过程中同步确认。

3. 过程端的审计要求

药监局注册检不仅看最终交付物，还会抽查开发过程记录。具体来说：

• 代码变更记录：每次提交必须关联到具体的需求条目或缺陷编号
• 代码评审记录：至少两名开发人员参与评审，且评审意见需留痕
• 测试执行记录：每条测试用例的执行结果、执行人、执行时间必须可查询
• 迭代回顾记录：每个迭代的回顾会议结论和改进项需要存档

看清楚这些约束之后你就会明白：合规项目的真正挑战不是“能不能用敏捷”，而是“敏捷实践里原本那些轻量级、口头化的协作方式，能不能被改造成可留痕、可追溯、可审计的样子”。

三、三个最常见的误区，几乎每个团队都会踩一遍

1. 误区一：先把功能做出来，文档后面再补

这是我们在项目启动时就明确否决的方案。原因很简单：医疗器械软件的需求-测试-风险追溯矩阵不是“整理”出来的，而是“生长”出来的。

如果开发人员在写代码时不知道自己这条需求对应哪个风险项，测试人员在写用例时不知道这条用例覆盖了哪条安全需求，那么事后要补出一个完整的追溯矩阵，本质上等于把所有需求、风险、用例重新对一遍，这不是补文档，是二次开发。我们在上一个项目就看到过这样的悲剧：一个团队花了3个月“补文档”，补到一半发现很多代码逻辑跟文档根本对不上，最后不得不重写了将近40%的模块。

正确判断：合规文档必须在迭代内部同步完成，不能推迟到迭代之外。这不是理想主义，是成本核算，同步完成的边际成本远低于事后重构。

2. 误区二：合规项目必须用瀑布，Agile就是不够严谨

这个观点的支持者通常会搬出“变更控制”来说事：敏捷欢迎需求变更，而合规要求所有变更都必须经过正式评审和批准，两者天然矛盾。

但我们的实践证明：敏捷并不是“随便改需求”，而是“让变更过程可见、可讨论、可按影响评估做出决策”。医疗器械软件注册本身就允许在设计冻结前进行需求变更，只要变更过程被记录、影响被评估、相关测试被更新。Scrum的Sprint Review和Backlog Refinement恰恰提供了一个定期审视需求变化的节奏，这比瀑布式“冻结后才发现问题、硬着头皮走下去”要健康得多。

3. 误区三：选对工具就能解决合规问题

这是最危险的误区。工具可以帮你记录追溯关系，但没有任何工具能自动判断“这条需求对应的风险分析是否合理”或者“这个测试用例的覆盖度是否足够”。合规项目的质量底线，最终靠的是团队对业务风险的理解和测试策略的设计，不是工具生成的漂亮报告。

我们在这个项目里使用了PingCode来承载需求管理、迭代规划和追溯矩阵的自动关联，这是后面要展开讲的部分。但必须提前说清楚：工具解决的是“关联效率”和“留痕自动化”的问题，而不是“合规判断”的问题。

四、我们的核心判断逻辑：把合规要求拆解为可迭代的“合规单元”

1. 什么是“合规单元”？

在启动这个项目之前，我们花了两天时间做了一件看起来跟“敏捷”毫不沾边的事：邀请甲方QA代表一起，把《医疗器械软件注册技术审查指导原则》里跟软件开发过程相关的条款逐条拆解，然后映射到Scrum框架的每一个实践环节。

拆完之后我们发现：绝大多数合规要求都可以被归类到三个维度，可追溯性、评审留痕、变更控制。而这三个维度恰好又对应Scrum的三个核心工件：Product Backlog（需求可追溯）、Sprint Backlog（任务可追溯）、Increment（交付物评审留痕）。

基于这个映射关系，我们定义了一个核心实践概念：“合规单元”。一个合规单元包含：

• 一条用户故事（含明确的验收标准）
• 与之关联的风险项编号（从甲方提供的风险分析报告中获取）
• 对应的一条或多条测试用例（至少覆盖验收标准中的所有场景）
• 代码提交记录（通过Git集成自动关联）
• 一次代码评审记录（至少两名参与人）

判断逻辑很简单：每个迭代交付的每一个用户故事，都必须是“合规闭合”的，也就是说，它必须包含上述所有要素，才算“Done”。如果一个故事只完成了代码但没有关联风险项，或者测试用例还没通过，那么在Sprint Review上它就不能被演示为“已完成”。

2. 为什么“合规单元”能解决两难问题？

传统做法里，合规检查是放在项目最后阶段的“大闸门”：所有东西都做完了，审计人员来检查文档是否齐全。这种做法的问题在于，开发人员在整个开发周期里根本感知不到合规要求的压力，直到最后被审计卡住才开始慌乱补文档。

“合规单元”的做法把审计点前移到了每个迭代内部：开发人员在做故事估算时就知道这条故事需要关联风险项，在提交代码时就知道Commit Message里必须带上故事编号。因为不做这些事，故事就无法被标记为“Done”，而Done的定义是整个团队在Sprint Planning时就达成共识的。

这个方法还有一个隐性收益：甲方QA代表可以在每个Sprint Review时直接抽查已完成故事的合规闭合情况，而不是等到项目结束时一次性提出几百条整改意见。我们把这种模式称为“增量审计”，审计不再是项目终点的审判日，而是每个迭代末的常规检查。

3. PingCode在这个逻辑里扮演的角色

前面说过，工具解决的是“关联效率”和“留痕自动化”的问题。在PingCode上，我们做了以下几件事：

• 史诗-特性-用户故事的三级需求管理：把217条需求按功能模块组织为史诗和特性，用户故事直接挂载在对应特性下，确保需求层级清晰、可追溯
• 自定义字段关联风险项：在每个用户故事上增加了一个自定义字段“关联风险项编号”，PO在创建故事时同步填写
• 与Git仓库集成：开发人员在提交代码时，要求在Commit Message中写入故事编号（格式为 #[StoryID]），PingCode自动将提交记录关联到对应故事下
• 测试用例与故事关联：测试工程师在编写用例时，直接选择关联的用户故事，形成故事-用例-执行结果的追溯链路
• 迭代看板状态流定制：在看板中增加了“待合规确认”列，当一个故事从“开发完成”移动到“测试完成”之前，必须经过“待合规确认”状态的检查（由Scrum Master确认关联完整）

这些配置没有用到任何“高端”功能，都是PingCode标准版本自带的。但它们的价值在于：把合规检查从“人盯人”变成了“流程自动校验”。当一个故事从“开发中”拽到“已完成”时，如果它缺少风险项关联或测试用例关联，看板上是会直接暴露出来的，用不着Scrum Master一个一个去核对。

五、六个关键实践：我们具体是怎么做的

1. 需求管理：史诗、特性与用户故事的三级拆解 + 风险关联

面对217条初始需求和47条安全相关需求，我们没有简单地把它们扁平化为一个Product Backlog列表。这也是我们从PingCode的建议流程中学到的一件事：在合规项目里，需求的结构化比需求的优先级排序更重要。

我们的做法是：

1. 首先由甲方PO与业务专家一起，将需求归类为6个史诗（用户管理、数据采集、算法分析、报告生成、系统管理、安全审计），每个史诗再拆分为2-5个特性
2. 特性内部包含若干用户故事，每个故事都明确定义了验收标准
3. PO为每个故事填写“关联风险项编号”，安全相关需求会被标记为高优先级并单独高亮

这个结构的直接好处是：当药监局审查员要求出示“某个功能模块的需求追溯矩阵”时，我们可以在PingCode里直接筛选出该史诗下的所有用户故事，连同它们的风险关联、测试用例和执行结果，一键导出为完整的追溯报告。这个操作在最终注册检时帮我们节省了至少两周的文档整理时间。

2. 迭代规划：故事点估算 + 合规工作量显式预留

传统的Scrum迭代规划只看故事点的总量和团队速率。但在合规项目里，安全相关的用户故事往往需要2-3倍于普通故事的测试和文档工作量。如果不把这种差异体现在规划里，迭代结束时这些故事的“合规闭合率”一定会拖后腿。

我们的调整是：在Sprint Planning时，除了常规的故事点估算，还给每个故事标记一个“合规复杂度”系数（简单=1，中等=1.5，复杂=2）。一个普通功能故事如果是3个故事点、合规复杂度为1，那么它的总工作量估算是3点；而一个安全相关故事如果是3个故事点、合规复杂度为2，那么它的总工作量估算就是6点。

这个系数由团队在Refinement会议上根据风险项等级和验收标准复杂度共同判断，不做过度量化，它能帮助我们在迭代规划时不至于乐观地把太多安全故事塞进一个Sprint里。

3. 迭代开发：代码提交强制关联 + 角色化的代码评审

在第一个Sprint结束时，我们遇到了一个典型问题：开发人员提交代码时忘记在Commit Message中写故事编号，导致PingCode上无法自动建立追溯关联。事后补了一次之后，我们做了一个简单但有效的改变：在Git仓库中配置了Commit Message格式校验钩子，要求每次提交必须包含 #[数字] 格式的引用。

代码评审方面，我们规定了双人评审制度：

• 常规故事：至少1名同组开发人员 + 1名测试工程师参与评审
• 安全相关故事：至少1名同组开发人员 + 1名测试工程师 + 甲方QA代表参与评审

评审结论会直接写在PingCode的评论区内，与故事关联，形成永久记录。在最终审计时，我们可以直接筛选出任意安全相关故事的评审历史，展示完整的审查证据链。

4. 站立会议：从“三个问题”升级为“三个问题+合规状态确认”

标准的每日站立会议三个问题大家都熟：昨天做了什么、今天计划做什么、有什么阻塞。我们在合规项目里增加了一个第四个问题，或者说把第三个问题扩展了一下：“有什么阻塞，包括合规关联上的问题？”

这听起来是个小调整，但效果显著。因为在日常开发中，合规问题往往被归类为“不紧急但重要”的事情，很容易被功能开发的压力挤掉。当Scrum Master每天问一次“你那几条安全相关故事的合规关联搞定了吗”，它就变成了一个不可忽视的日常提醒。

另外，我们在每日站立会议时直接打开PingCode的迭代任务板，所有故事的状态一目了然。如果有故事卡在“待合规确认”列超过两天，Scrum Master会在当天会后立刻找相关人员解决。这个做法把“合规延迟”暴露在了阳光之下，避免了到迭代末才发现一堆未闭合故事的情况。

5. 进度跟踪：燃尽图 + 合规闭合率双指标

传统Scrum项目看燃尽图就够了，故事点烧完了，迭代就完成了。但合规项目不行。一个故事可能代码写完了、测试通过了，但评审记录没补全、风险关联缺失，从合规角度看，它仍然是“未完成”状态。

所以我们引入了第二个指标：合规闭合率。公式很简单：

合规闭合率 = 当前迭代中已完成合规闭合的故事数 ÷ 当前迭代计划故事总数 × 100%

这个指标和燃尽图同时呈现在PingCode的迭代概览页面上。到了迭代中期（通常第5天左右），如果合规闭合率明显低于已消耗故事点的比例，Scrum Master就会在每日站立会议上重点讨论原因，并决定是否需要调整迭代范围。

这个做法有一个重要的隐含逻辑：合规闭合率不是事后统计，而是迭代内的动态管理工具。它让团队在迭代中段就能提前预警可能的风险，而不是等到Sprint Review当天才发现一堆故事不合规。

6. 评审与回顾：演示 + 合规抽样 + 回顾改进

Sprint Review在合规项目里承担了双重角色。除了常规的功能演示，它还有一个重要环节：甲方QA代表对当期已完成的“合规单元”进行随机抽样检查。

抽查规则是每个迭代随机抽取3-5个已完成故事，检查以下内容：

• 故事验收标准是否全部通过
• 代码提交记录是否关联到该故事
• 代码评审记录是否完整（至少2人参与）
• 测试用例执行结果是否通过
• 风险项关联是否正确

如果抽样中发现任何一项缺失，对应的故事会被打回“进行中”状态，在本迭代内完成整改。如果本迭代时间内无法完成，则移至下一个迭代的Sprint Backlog，并在回顾会议上讨论原因。

Sprint Retrospective则专门增加了一个固定议题：“本迭代的合规闭环中有哪些值得改进的地方”。这个议题让合规问题从QA的单向监督变成了团队内部的持续改进话题。我们后来总结出了不少实用的改进措施，比如“安全相关故事在开发启动前先做风险评审会”就是从一个回顾讨论中产生的。

六、我们踩过的三个深坑，以及复盘后的改进

1. 安全故事过多集中在一个迭代导致合规闭合率骤降

Sprint 3时，PO为了尽快完成安全模块的开发，在迭代规划时塞进了8个安全相关故事（占该迭代故事总数的60%）。结果到了迭代中期，合规闭合率卡在25%上不去，因为每条安全故事都需要甲方QA代表参与评审，而QA代表的时间窗口根本覆盖不了这么高的密度。

复盘后我们定了一条规则：每个迭代的安全相关故事不超过该迭代故事总数的30%，且当安全故事超过4条时，必须在迭代规划时就与甲方QA代表确认其评审带宽。

2. 过度依赖自动化工具导致对风险分析质量的忽视

设置了Commit Message校验钩子之后，有一段时间团队里出现了一种“形式主义”倾向：提交信息格式完全正确，但关联的故事编号是错的，或者关联了一个跟这次代码修改毫无关系的需求。因为自动校验只检查格式，不检查内容逻辑。

这个问题是在一次Sprint Review抽查中被发现的。Scrum Master随机查了一条已完成的算法故事，发现合并请求里的代码修改跟故事描述的功能完全对不上，原来是开发人员在做另一个人任务时顺手修复了一个Bug，但提交时用了手上正在做的那条故事的编号。

复盘结论：自动校验是安全保障的底线，不是天花板。代码评审环节必须包含“提交内容与所关联需求是否一致”的实质性检查。我们随后在代码评审清单中专门增加了这一项。

3. 低估了“非功能需求”的合规复杂度

项目进行到中期时，我们意识到一个严重的问题：很多安全相关的非功能需求（如数据加密强度、操作日志保留周期、权限分离粒度）很难被拆分成标准的用户故事。它们不直接对应某个“用户操作”，却是合规审计的重点对象。

我们的解决办法是把这些非功能需求明确标注为“技术故事”或“约束故事”，与功能故事一样纳入Product Backlog管理，设定验收标准，分配故事点，并在追溯矩阵中建立与对应功能模块的关联。这样一来，非功能需求不再是“大家都知道该做但没人跟踪”的模糊地带，而是和功能需求同等管理、同等追溯的明确条目。

七、不同项目阶段的行为建议：启动期、执行期、收尾期各要做什么

1. 项目启动期（前2个Sprint）

核心任务：建立合规基线，而不是追求开发速度。

• （1）合规要求翻译会：邀请QA、法务、业务三方一起，把项目中涉及的所有合规条款逐条翻译成“开发团队能听懂的语言”，即拆解为验收标准、追溯要求和评审规范。不要假设开发人员读过法规文件。
• （2）工具配置与验证：提前配置好需求管理工具（如PingCode）中的自定义字段、看板状态流、代码仓库关联等，然后用2-3条虚拟故事跑通整个“合规单元”的流转链路，确保工具链没有断点。
• （3）团队合规意识对齐：在第一个Sprint Planning上，由Scrum Master带领团队逐条过一遍“Done的定义”，其中必须包含合规闭合的所有要素。这不是走过场，是明确告诉所有人：做不到合规闭合的故事，不算完成。
• （4）建立合规样本库：从甲方提供的风险分析报告中提取3-5个典型的“需求-风险-测试”关联样本，作为后续所有故事编写的参考模板。

2. 迭代执行期（第3个Sprint到倒数第2个Sprint）

核心任务：保持合规节奏，用数据驱动调整。

• （1）每日站立会议的合规确认：Scrum Master持续关注“待合规确认”列的故事数量和停留时长，对于超过2天未闭合的故事主动跟进。
• （2）Sprint Review的合规抽样：坚持每个迭代由QA代表随机抽查3-5个已完成故事，做到问题早发现、早整改。
• （3）合规闭合率趋势监控：如果连续两个迭代的合规闭合率低于85%，就必须在Retrospective上做专门复盘，找出系统性原因而不是个案处理。
• （4）安全故事的评审带宽管理：每个迭代规划时与QA代表确认其可投入的评审时间，并据此控制安全故事的纳入数量。
• （5）避免“合规债”累积：严格做到“本迭代的合规问题本迭代内闭环”，绝不允许将未闭合的合规单元滚入下一个迭代（除非经PO和QA共同同意）。

3. 项目收尾期（最后1-2个Sprint）

核心任务：整理完整的追溯证据链，准备审计材料。

• （1）全量合规闭合检查：在倒数第2个Sprint结束时，由Scrum Master与QA代表一起，对全部用户故事进行一次完整的合规闭合状态审查。这不是抽查，是全量检查。
• （2）追溯矩阵一键导出：利用PingCode的筛选和导出功能，按史诗维度生成完整的需求-风险-测试追溯矩阵，作为注册申报材料的一部分。
• （3）关键决策记录整理：回顾整个项目过程中的重要变更决策（如需求优先级调整、范围裁剪、技术方案变更），确保每一次决策都有对应的会议记录或评审意见作为支撑。
• （4）审计模拟演练：在正式注册检之前，由QA代表模拟审计过程，对随机抽取的故事链进行全链路审查，提前发现可能遗漏的证据项。

八、不同情况下的取舍：当你资源受限时，哪些可以妥协、哪些绝不能妥协

不是所有团队都有甲方QA代表全程驻场的条件，也不是所有项目都像医疗器械注册这样有严格的外部审计压力。以下是我基于不同类型项目给出的取舍建议：

1. 强合规场景（如医疗、金融、政务），绝不能妥协的事项

2. 中等合规场景（如企业内部审计、ISO认证），可以做的简化

如果你面对的不是药监局、银保监会这类强监管机构，而是企业内部的合规审计或ISO认证，可以在以下方面做合理简化：

• （1）追溯粒度降级：从“故事级别”降为“特性级别”，即一个特性模块对应一组风险项和测试用例，而不要求每个用户故事都一一对应
• （2）代码评审参与人数减少：常规故事可以单人评审，仅有安全相关或核心模块需要双人评审
• （3）审计准备周期缩短：不需要在倒数第2个Sprint就做全量检查，可以在最后一个迭代集中整理材料
• （4）合规闭合率阈值放宽：从强合规场景的90%以上放宽到75%-80%，给团队多一些灵活空间

3. 弱合规场景（如合同约定的交付物审查），最低保障线

如果合规要求仅来源于甲方合同中的交付物审查条款，最低保障线是：

• 保证需求与测试用例的关联关系可查询
• 保证代码提交记录与需求条目可关联
• 保证每次Sprint Review的演示记录和结论有存档

这三条做到了，就足以应对绝大多数合同级别的交付物审查。但需要注意的是：弱合规不代表零合规。把这三条融入迭代常规流程的成本非常低，但一旦缺失，事后补救的代价依然很大。

九、这个项目结束后，我们沉淀下来的三样东西

1. 一套可复用的“合规-敏捷阵型”模板

项目复盘时，我们把整个实践过程抽象成了一个“合规-敏捷阵型”模板。它包括：

• 角色定义：在标准Scrum三角色之外，明确增加“合规审计人”角色的职责边界，这个人可以是甲方QA代表，也可以是团队内部经过合规培训的质量工程师
• 仪式设计：Sprint Review中固定嵌入合规抽样环节，Sprint Retrospective中固定设置合规改进议题
• 工件定义：Product Backlog中规范了合规单元的要素要求，Sprint Backlog中增加了合规闭合状态的可见性设计
• 工具体系：基于PingCode的史诗-特性-故事三级结构 + 自定义字段 + Git集成 + 看板状态流的配置方案，可在新项目启动时快速复制

这套模板后来被我们应用到了另一个金融行业的项目里，启动时配置工具和流程只用了不到三天。不是因为工具多强大，而是因为团队已经知道“合规单元”该怎么定义、看板该怎么设、QA该怎么参与，经验内化成了肌肉记忆。

2. 一个关键认知：合规不是质量的敌人，是质量的另一种表达

做完这个项目之后，我越来越坚定一个观点：医疗器械注册要求的追溯矩阵，本质上是在回答一个问题，“你怎么保证你做的软件不会因为一个隐蔽的缺陷而伤害到患者？”

这不是官僚主义，这是对软件质量的一种严肃追问。如果我们把追溯矩阵看成“质量保证的证据链”，而不是“额外增加的无用文书”，心态和做法都会完全不同。这也是为什么我们把“合规单元”定义得那么严格，不是为了满足药监局的纸面要求，而是因为那些安全相关的用户故事，确实关系到使用者的生命健康。

3. 对团队和读者的三个实用建议

如果你所在的团队正在或者即将面对一个合规项目，我建议你做三件事：

1. 在下一个项目开始前，先做一次“合规冲击分析”。花半天时间，邀请QA或法务同事，把项目中涉及的合规要求逐条拆解，然后判断：哪些要求可以嵌入现有Scrum实践？哪些要求需要调整我们的Scrum实践？哪些要求本质上与敏捷不兼容、需要保留瀑布式流程？做完这个分析，你会清楚知道自己在面对什么级别的挑战。
2. 找到一位愿意“深入迭代”的合规角色。无论是甲方的QA代表，还是团队内部培养的质量工程师，这个人必须全程参与迭代节奏，而不是只在项目终点出现。如果没有这样一个人，合规就会变成开发团队的“对手”，而不是“战友”。
3. 先跑通一条合规单元的全链路，再谈规模化。不要在第一个Sprint就试图把所有故事都做到合规闭合，选3-5个典型故事，把需求-风险-测试-评审的全链路跑通，在这个过程中发现工具配置、团队协作和流程设计上的问题，跑顺了之后再扩展到整个Backlog。

敏捷交付合规项目，从来不是一个方法论选择问题。它是一个工程实践问题、一个团队协作问题、以及一个“你愿不愿意在迭代内部多做一点，换一个项目结束时不用临阵磨枪”的取舍问题。我们的答案是值得这么做。希望这篇文章能帮你在自己的项目里验证这个答案。