Scrum敏捷框架在内部审计中的应用

吴则建

[摘要]本文介绍了敏捷方法、Scrum框架和“瀑布审计”模式，在此基础上结合审计工作实践，对敏捷内部审计进行探讨，对Scrum敏捷方法在内部审计中的典型应用进行分析。

[关键词]敏捷方法   内部审计   Scrum   框架

由于市场瞬息万变及竞争的加剧，企业面临的风险也随之变化，若无系统、可持续的方法及时改变内部审计组织方式，仅依靠某一固定的审计计划很难有效完成内部审计目标，敏捷内部审计可有效解决该类问题。

近几年，敏捷内部审计一直是国际内部审计理论与实务研究的热点问题，巴克莱银行从2016年开始就将敏捷方法引入企业内部审计实务，但目前国内对敏捷内部审计的相关理论研究和实务还较少。

一、敏捷方法、Scrum框架与“瀑布审计”模式

（一）敏捷方法

敏捷方法起源于软件工程领域，现已在软件工程、制造业、金融业甚至家庭管理等领域成功应用，是以用户的需求进化为核心，以客户满意为主要目标，拥抱变化，频繁交付，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系且独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

（二）Scrum框架

Scrum是指迭代式增量软件开发过程，是敏捷方法中使用最多、应用最广的敏捷开发框架。由于Scrum框架的易用性等明显优势，当前Scrum框架已被广泛应用于自动驾驶、市场运营甚至家庭管理等多个领域。

Scrum框架的目标是“用最短的时间，交付最高的商业价值”，框架主要由3个角色、3个工件、4个活动组成，其中3个角色分别为产品经理（Product Owner）、敏捷教练（Scrum Master）和敏捷团队（Scrum Team）;3個工件分别为待办事项列表（Product Backlog）、迭代事项列表（Sprint Backlog）和燃尽图（BurnDown Chart）;4个活动分别为迭代计划会议（Sprint Planning Meeting）、每日站会（Daily Scrum Meeting）、迭代评审会议（Sprint Review Meeting）和迭代回顾会议（Sprint Retrospective Meeting）。

Scrum是一个增量、迭代的开发过程。整个开发过程由若干个较短的、固定时间的迭代周期组成，每次迭代的时间一般为1—4周。在Scrum中，利用待办事项列表来管理产品需求。待办事项列表是一个按照商业价值有限排序的需求列表，其表现形式通常为用户故事，是需求的一般表达，通常格式为：作为一个<用户角色>，想要<完成活动>，以便<实现价值>。Scrum方法总是先开发对客户具有较高价值的需求。

每次迭代开始前，Scrum团队会召开迭代计划会议，讨论、分析并估算得到本次迭代要完成的优先级最高的迭代任务列表。在每次迭代结束时，Scrum团队递交潜在可交付的产品增量，通过评审会议评审后，交付本次迭代的产品。每次迭代接受后，还通过迭代回顾会议总结迭代经验，并对下次迭代提供优化措施。在迭代周期中，通过每日站会回顾工作内容，优化团队工作。Scrum框架全流程见图1。

（三）“瀑布审计”模式

传统的“瀑布模型”是将软件生命周期划分为制订计划、需求分析、软件设计、程序开发、软件测试和集成维护六个基本活动，并规定自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型对各个阶段的划分很明确，并且依赖于明确、详尽的需求，以项目文档作为项目驱动，严格控制项目的变更，项目的生命周期一般较长。

与软件工程方法相对应，现有的内部审计模式可称为“瀑布审计”模式，即为完成既定审计目标，首先制订审计计划和详细业务工作方案，进而开始收集并识别信息，对信息进行分析和评价，最后形成审计报告并递交给利益相关方。整个流程必须一步一步顺序执行，直到整个流程的最后步骤，利益相关方才会看到审计结果。审计过程严格按照审计计划和业务工作方案进行，审计任务推进过程中，内、外部实时环境的变化无法快速感知，利益相关者的需求也无法得到快速响应。审计项目时间跨度越长，矛盾越明显，见图2。

二、敏捷方法在内部审计中的应用

敏捷方法可以很好地解决传统“瀑布审计”模式面临的问题。敏捷方法论中“个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划”的核心价值观，可以很自然地应用于内部审计中，“个体和互动高于审计方案、高质量的审计建议和洞见高于冗长的报告、与利益相关方的持续沟通高于审计计划、响应变化高于遵循计划”。敏捷内部审计模式见图3。

由于不同组织的组织架构、审计流程、项目组织方式有很大区别，因此将敏捷方法结合于内部审计的方式也各有特点。笔者根据自身经验，对敏捷方法应用于内部审计的一种方式进行初步探索研究。

敏捷内部审计中共有3个角色：产品经理、敏捷教练和敏捷团队。这3种角色也是构成一个敏捷内部审计团队的全部成员。产品经理要确保审计的价值，确保与组织目标保持一致的同时，还要考虑利益相关方对本次业务审计的预期，产品经理随时关注内外部环境变化，与首席审计执行官或利益相关方保持持续沟通，产品经理还拥有对待办事项列表更新、排序甚至删除的决定权。敏捷教练是整个内部审计敏捷团队的支持者和保障着，负责维持团队的敏捷秩序，并保证团队不受无关因素打扰。敏捷团队是跨职能、跨专业的内部审计人员，通过识别、分析、评估记录等程序，完成待办事项列表，并在每个迭代结束时交付一份可用的审计结果或可用的审计报告。同时，敏捷内部审计团队是一个自组织的团队，各类信息在敏捷团队内部共享。鉴于各角色的职责和权力，产品负责人可由项目组长、主审或审计专家担任，敏捷教练的职责可由具有敏捷知识的质量控制人员完成。

待办事项列表是为评估并协助改善组织的治理、风险管理和控制过程，基于风险的方法得出的业务审计待办事项列表，其中的待办事项已进行了优先级排序。待办事项列表主要由产品经理负责。

每次迭代开始前，敏捷内部审计团队召开迭代计划会议，产品经理讲解待办事项列表中重要的产品功能，对待办事项进行优先级排序，敏捷团队估计工作量，自主认领任务并作出承诺，确定迭代待办列表及本次迭代计划。

进入迭代周期后，团队在每日固定时间召开每日站会，敏捷团队成员和敏捷教练必须参加，建议产品经理参加。会议要确认迭代待办事项中哪些事项已完成，哪些正在处理，团队成员要沟通下次会议前成员计划完成的任务，对阻碍迭代进度的因素进行讨论并寻求解决方案。每日站会后将得到最新迭代待办事项列表、最新燃尽图和需要协助克服阻碍的事项。

每次迭代后期版本（审计结果、审计建议或审计报告）发布前，召开迭代评审会议。除敏捷内部审计团队成员外，所有利益相关方都应参加会议，如被审计单位相关人员、内部控制人员、质量保证人员等。会议要评审待办事项列表中的待办事项是否已完成，已完成事项是否达到完成标准。产品负责人和利益相关方要针对发布版本给出评价和反馈，这些反馈要加入待办事项列表中，并在进入下一次迭代前对这些待办事项进行重新排序和分析，见图4。

每次迭代结束后召开迭代回顾会议，总结迭代的实践经验以提高团队水平。每个团队成员都要针对“我本次迭代中做的最重要的事情是什么？”“我成功的经验是什么”“我有哪些地方可以改进”进行发言，针对有哪些地方可以改进，团队其他成员可给出改进建议，且团队成员共同确保该建议可以在下一次迭代中得到實施。

三、总结与展望

巴克莱银行用了近4年时间、无数次尝试后才将敏捷方法成功融入企业内部审计。不同的组织有不同的组织架构、不同的组织文化，敏捷思想的核心是拥抱变化，只有将敏捷的理念、框架根据企业实际情况，不断地打磨、裁剪、丰富，才能不断发挥敏捷的能量。国内企业数字化转型如火如荼，中小银行也在发力“敏捷银行转型”。随着敏捷内部审计在组织内的逐步实施，不断满足利益相关方对内部审计拥抱变化、快速响应的诉求，相信组织也会越来越依赖敏捷内部审计的力量。

（作者单位：中信银行审计部昆明审计中心，

邮政编码：650000，电子邮箱：wuzejian@citicbank.com）