组织通过将治理实践直接整合到开发工作流程中、使用迭代过程以及促进团队之间的协作来调整数据治理以适应敏捷方法。 传统的数据治理通常依赖于前期规划和集中控制，这与敏捷对快速迭代和去中心化决策的关注相冲突。 为了弥合这一差距，团队将治理检查嵌入到 sprint 周期中，自动化合规任务，并将治理规则视为与产品一起发展的动态需求。
首先，通过将其视为完成定义的组成部分，将数据治理纳入敏捷工作流程。 例如，构建处理客户数据的功能的团队可能会将治理任务（例如验证数据沿袭文档或检查隐私合规性）添加到他们的 sprint 待办事项中。 自动化工具可以强制执行这些检查，而不会减慢开发速度。 开发人员在处理数据管道时，可以使用 CI/CD 管道来运行数据质量或 PII（个人身份信息）检测测试，然后再进行部署。 这种“左移”方法可确保治理不是事后才考虑的。 团队还可以在 scrum 团队中分配“数据所有者”角色，以监督治理任务，确保问责制，而不会造成瓶颈。
其次，迭代地制定治理策略。 团队不是预先定义所有规则，而是从轻量级指南开始，并根据反馈进行完善。 例如，处理医疗保健数据的团队可能从基本的访问控制和审计日志记录开始，然后在后续的 sprint 中，随着他们遇到现实世界的场景，添加更严格的加密要求。 回顾会议用于评估治理实践如何影响 sprint 并进行相应调整。 这种灵活性使策略能够随着法规或业务需求的变化而保持相关性。 例如，一家扩展到欧盟的公司可能会逐步更新其数据保留策略，以符合 GDPR，并在每次迭代中测试小的更改，而不是一次性地全面改革系统。
最后，开发人员、数据工程师和合规专家之间的协作至关重要。 敏捷仪式（如每日站立会议或 sprint 计划）用于尽早发现治理问题。 共享数据目录或元数据管理平台（例如 Apache Atlas）等工具已集成到开发环境中，以提供对数据使用的实时可见性。 例如，构建 API 的开发人员可以在实施期间检查数据目录，以确保他们使用的是批准的数据集。 团队还可以采用轻量级文档实践，例如在代码存储库中注释数据模型或使用 pull request 模板来提示审阅者验证治理要求。 通过使治理成为共同的责任并提供实用的工具，团队可以在不牺牲合规性的前提下保持敏捷性。