Scrum与监管合规：敏捷团队如何交付合规产品
「受监管行业需要瀑布式开发」这一假设是软件交付领域最顽固、危害最深的神话之一。IEC 62304（医疗器械软件）、21 CFR第11部分（制药电子记录）和欧盟医疗器械法规等监管框架并未规定组织必须采用瀑布方法。它们规定的是结果：软件必须按照已定义的流程开发；需求必须有文档记录；设计输出必须可追溯至设计输入；测试必须证明需求得到满足。这些结果中没有一项是瀑布方法特有的。如果团队将合规性构建进冲刺而非作为最终阶段处理，所有这些在结构良好的Scrum流程中都是可实现的。
Scrum团队如何实际实现合规
冲刺内的可追溯性。 将用户故事与可验证的需求验收标准相关联，并将测试结果与其所验证的故事和标准相关联。在冲刺中完成此操作，会产生一个与代码同步的实时可追溯性矩阵。在发布结束后才补充，只会产生一份没人信任且审计人员日益质疑其完整性的文件。
已验证的冲刺评审记录。 冲刺评审是展示交付物满足需求的天然机制。对于受监管的环境，这意味着冲刺评审必须被记录下来——参与者、演示内容、已接受和已推迟的内容，以及做出验收决定的依据。每次冲刺评审时填写的结构化模板，提供了许多受监管团队目前通过繁琐的事后文档化工作才能产生的审计证据。
基于风险的测试强度。 IEC 62304等法规框架通常要求测试强度与风险相称。Scrum团队应按照所实施功能的安全或合规风险对每个用户故事进行分类，该故事的完成定义应反映其风险类别所需的测试严格程度。影响药物剂量计算的功能所需的测试覆盖率，与更改仪表板颜色的功能截然不同。
具有监管意识的完成定义。 受监管环境中的Scrum团队能做出的最有效的单一改变，是将合规要求纳入完成定义。当可追溯性、风险分类、测试证据和评审文档成为故事被验收为「完成」的前提条件时，合规性就成为交付的内在组成部分，而非最终阶段的额外工作。
传统受监管开发往往将合规的外表与真正的合规相混淆。产生一份没人阅读、与实际实现的软件相背离的千页《软件需求规格说明书》，不是合规——那是一种法律隐患。美国FDA于2019年发布的关于医疗器械软件中敏捷方法的指南，明确承认敏捷方法可以满足监管要求，并在某些方面比其所取代的重文档瀑布实践产生更好的证据。受监管组织面临的问题不是敏捷是否被允许——而是其敏捷实施是否正在产生监管机构实际要求的证据。
如果您的组织正在思考如何在不失去合规保证的情况下采用敏捷方法，或者您正面临一次审计，需要当前流程难以轻松生成的证据，XNM的项目群与项目交付咨询服务与受监管组织合作，构建既满足监管义务又不牺牲敏捷交付速度的Scrum实施方案。