如今，敏捷是一种趋势. 即使是 过去反对敏捷的人 现在已经加入了这个潮流，并且 积极地宣传敏捷，而不是 总是理解这意味着什么，而且经常 插入与他们相同的非敏捷障碍 一直在实践他们的敏捷审计版本. 当 适应敏捷实践，有必要 首先，一套原则和价值观 去理解它是什么，不是什么. 这也很有帮助 对于希望成为更审计部门的人 高效和交付更高价值的审核学习 关于如何实施敏捷的实用技巧.
什么是敏捷?
敏捷范式是一种革命性的发明 资讯科技项目的方法1 这是用来传递 快速连续功能齐全，经过测试和 期望的IT系统的可接受的版本，每一个 包含更多功能的版本. 因此,它 目前还不清楚它是否适用以及如何适用于 IT项目之外的领域. 尽管目的 编写软件就是要有一个功能完备的系统 这两种软件都不能让客户满意 开发或被审核方满意度都是直接审核 目标. 董事会不太可能成为客户 参与实际事务:它依赖于审计; 在其他防御措施中，保持对风险区域的了解 以及处理这些问题的实际方法. 然而,审计 本质上是项目，而敏捷是关于项目的 管理. 因此，似乎有些 敏捷概念已经被证明是有效的 项目管理可以延续到审计.
敏捷不是Scrum、看板或XP
Scrum、看板和极限编程(XP)可以 是敏捷框架，但它们不是独立的 敏捷. 敏捷是关于原则和价值观的. 它是 不是特定的方法、工具、框架、配方或 对某些具体工作方式的背书. It 不是告诉团队如何工作或替换 现有的繁文缛节和经过认证的敏捷繁文缛节. 在 相反，它的两个原则是:
- 围绕有动力的人建立项目， 意思是给他们环境和支持 他们需要并相信他们能够完成工作.
- 最好的架构、需求和设计 从自组织团队中脱颖而出..
一个是敏捷，当你遵循敏捷的价值观和 原则，而不是遵循特定的方法 或框架. 例如，告诉审计团队 他们必须使用sprint，这是Scrum术语的简称 一段时间间隔(通常为两周) 预定义的目标集(软件中的功能) 必须达到开发或审核步骤(审核); 不完全遵循这些原则吗. 一些 敏捷宣言的创始人是以下方面的支持者 极限编程(XP)2 而不是Scrum. 组织或审核团队应该 采纳关于原则和价值观的宣言 非常务实的商业世界就是这些 原则和价值观表明，它们可以做到这一点 积极的结果.
及时完成一个有价值的产品是一项重要任务 需求，包括IT软件和审计(其中 产品是报告)，敏捷是由报告驱动的 需要确保生产出有价值的产品 在时间. 敏捷方法考虑到了这一需求 账户. 例如，在Scrum中，项目是分开的 在部分(冲刺)中，每天检查进度. 每个单独团队的进度报告 成员必须简短，以免分散注意力 生产活动和花费时间增加. 如果一个 组织正在使用Scrum方法，比如 sprint，但是对于每个sprint，团队都必须解释 给一个经理，他不参与 项目，它可能会给过程增加额外的时间 而不是使过程更有效率.e.,包括 额外的一层人没有做实际的 工作与敏捷原则完全相反). 敏捷 方法论本身不会使过程变得敏捷， 它们甚至可能适得其反.
主管不应该 涉及到的细节 实际审计，除非他们是一部分 团队成员.
实施敏捷也意味着给予团队更多 自由而不是微观管理. 原则12 敏捷宣言指出:“每隔一段时间， 然后，团队反思如何变得更有效 相应地调整它的行为.”3 这意味着 虽然主管们仍然发挥着作用(e.g.，设置 目标审核，排除障碍，提出问题 有了更高层次的管理(如果需要的话)，自由就是 从主管转到团队. 监事 是否应不参与细节的实际审核 除非他们是团队的一员.
考虑一个敏捷审计的例子，其中团队 使用由选择和组成的Scrum sprint 完成一些子任务并同意 被审核方在一个期间内可能采取的措施 然后决定下一个子任务 新的冲刺. 在每次冲刺结束时，结果是 是否与审核管理层讨论并达成一致 先与被审核者谈，再审核管理 决定下一个冲刺是什么. 但这可能不是 采取最好的行动. 首先，冲刺使 对于开发团队不依赖于外部方的IT项目来说，这是最有意义的. 为 例如，如果一个IT开发团队的成员 接受一项任务，并承诺交付一个经过全面测试的产品 具备X功能的软件在两周内 团队成员没有其他因素需要考虑 除了它自己兑现承诺的能力 功能. 不期望也不需要帮助， 包括对其他方的依赖. 最多一个 一定是同意了一套规格吗 可能的接口.
审计的情况并非如此. 对于审计来说 审计中被审计区域的一个子集将是 在两周内完成是不可能完成的 对审核组的控制或必要的生产力. 除非组织有自动化的过程来 审核员可以访问任何数据的程度 需要和不需要的信息是什么 字段(很少有组织这样做，因为应该这样做) 作为单一的数据所有者，不希望共享数据 对数据负责)，完成的是sprint 取决于被审核方合作的及时性.
此外，人们不知道数据有多广泛 分析将是. 这是感知风险的函数， 哪些只有在分析之后才能可靠地评估. 当然，风险可以而且应该在 这个攻略，但大家应该记住这一点 估计或多或少是被审核方的感觉 通常高度乐观.
如果一个sprint无法完成，因为团队 在等待数据或被审核方输入时，敏捷解决方案是什么 要同时完成可以完成的任务， 不管他们是否是当前冲刺的一部分 or not; therefore, if a delay occurs in one of the audit 子任务，没有时间浪费，因为所有的数据已经 要求在需要时尽快交付 出现后，团队就会处理所有的数据 任何给定的时间，不管数据是否属于 到当前sprint中测试的控件. 不用说， 审计中需要的所有数据都应请求 越早越好，不管他们到哪个sprint 属于. 如果一个组织希望在审计中做到敏捷，那么它可以做到 必须接受这种灵活性. 如果团队有能力 有了动力，它会优化自己的时间，而不需要 填写文件，记录X的运动量 在时间框架Y.
这是审计和软件之间的关键区别 发展. 在软件开发中，团队 对要编程的功能有充分的了解，并能准确地计划如何实现 该功能. 在审计中，团队并不总是 知道了最终的结果，目标就陈述得多了 更广泛的术语:处理风险和有效性 指定区域中控件的. 最重要的是IT 敏捷项目中的开发团队通常只有 在任何给定的时间只做一个项目. 在审计, 事实未必如此，审计人员也可能如此 同时在两个或多个团队中处理 不同的审计.
使用sprint通常意味着输入as 完成可交付内容需要做很多工作 截止日期前. 但当一个人有多次审计时， 谈判严格的冲刺可能会成为一个问题 而不是一个解决方案:当一个人沉浸在 一个问题是，切换进出需要时间 记住自己在哪里，在澳门赌场官方软件. 冲刺的好处到底是什么? 同意 行动可能会更早开始? 通常，商定的审计 补救行动比冲刺要长得多 时间框架.
同样，如果审计管理没有实际参与 审计时，它不应该干扰如何定义 团队合作. 简而言之，借用一个框架 敏捷和将其作为法律并不能使一个人变得敏捷.
有了敏捷审计，团队就没有了 更需要开什么处方 他们会事先检查(以及如何检查) 查看数据.
如何变得敏捷
虽然环境各不相同 没有放之四海而皆准的解决方案， 下面的一组指导方针可能会有用 实现敏捷过程.
设定目标
一个组织，在这个例子中是审计部门，
应该问问自己为什么需要成为敏捷和
它希望通过变得敏捷来改进什么. If
它正在寻求提高效率和增长
审计的质量，然后成为敏捷
可行的选择. 通过减少或消除繁文缛节;
parallelizing tasks; and abolishing the strict tollgate
规划、实地工作和报告的分离;4
审计可以更快地完成，并专注于问题
的物质. 有了敏捷审计，团队不再需要
规定他们之前要检查什么(以及如何检查)
查看数据. 然而，敏捷并不是灵丹妙药
这将解决所有问题. 例如，如果延迟是
由于组织间的纠纷，有一个敏捷
审计程序不会完全解决这个问题. 如果延误是
主要是由于提取数据的困难
从IT系统来看，敏捷将不再是核心解决方案，
但是它可以通过请求极大地缩短处理时间
将数据立即取出而不是当一个完成
并有批准的审核程序. 一旦
需要解决的问题是确定的
接下来的步骤很明确:移除绊脚石.
能力与动机
敏捷原则可以帮助审计团队找到方法
消除这些绊脚石，使审计更快
更有效率.
例如，敏捷宣言的原则5要求: 我们的团队有能力和积极性吗? 我们吸引到我们真正想要的人了吗 剩下的? 敏捷并不适用于非敏捷的团队 有能力是因为有太多的指导和 监管要求. 这一点在《澳门赌场官方下载》中也有说明 国际内部审计师准则(IIA 《内部审计专业实践 “所需监管的程度将取决于 内部审计师的熟练程度和经验 约定的复杂性.”5 这并不意味着 所有的团队成员必须在所有方面都具有同等的能力 方面，但每个成员必须能够胜任 完成他们的任务. 能力是一个关键的组成部分 敏捷宣言. 原则9明确指出 持续关注技术精益求精 设计提高敏捷性.”6
一旦建立了一个有能力的团队
组织必须确保保持积极性.
团队成员应该在材料中得到奖励吗
道路? 他们的工作质量应该表扬吗
关键绩效指标(kpi)，如
完成审核的次数用于评估
团队和审核员的表现? 评估质量
通常比bean计数复杂得多
指示器:如果一个人评估了一些豆子，那么
重点将是提供更多的豆子，而不是更好的
豆子。. 因此，这不是一个有效的激励因素.
最终，拥有一个有能力的团队是理想的
喜欢、自豪并相信自己的工作
有不同的方法可以做到这一点.
例如，驱动式审计(i.e., compliance-type
审计，审计员填写复选框，没有
深入探讨问题7, 8)可能会受到鼓励
那些重数量轻质量的人——有一个不是
需要灵活地填写复选框.
敏捷审计管理: Auftragstaktik
Auftragstaktik，可以粗略地翻译为
任务或契约战术，是一个二战德国人
可以用来描述敏捷的军事词汇
方法. 最高级别的指挥(如.g.,
将军)设定目标(例如.g.(拿下那座山)但是
离开了外勤人员.g.(船长)来决定
确切的攻击方法. 类似地，在敏捷中，审计
管理层设定目标(例如.g.，证券
对组织的虚拟专用网进行审计
[VPN]，范围和资源)，但细节，包括
哪些区域可以省略作为较少的材料，是
一个高度称职的审计团队的责任. 如果
团队需要在每个行动之前获得批准
要么是审计管理的一部分
团队或团队不应该使用敏捷审计.
敏捷代表灵活性，并且 契约恰恰相反， 因为它们代表了协议 刚性更强.
Auftragstaktik 这并不意味着审核组是孤立的 在野外. 就像船长可能会要求的那样 炮击或空中支援时，可以攻击山丘 审核组决定需要专家协助或 计算机设备. 选择需要什么 什么时候是由现场的人(e.g., 队长或审核小组)而不是管理层 离田地很远吗. Auftragstaktik 也一般 结果是更好的决策，作为责任 失败的责任就落在了队长或审计团队和他们的身上 决定，而不是别人. 这让团队 一个更好的不失败的激励. 它也会带来更好的结果 通过给团队成员机会来领导 承担更多的责任，做更多的决定.
审计管理是否有作用?
一些审计经理可能不喜欢这种自由
敏捷审计给他们的团队带来了什么，因为他们冒着风险去寻找
过时了. 理想情况下，审计管理应该包括
有能力理解自己的人
团队和其主要目的是进行质量检查
他们团队的研究结果. 敏捷审计的基本前提——
或者任何敏捷项目——是团队的能力
足够和信任来完成他们的任务，而不需要
需要监督. 也就是说，管理不是
可能很快就会消失，而且有充足的
这是有历史先例的. 事实上，曼哈顿
制造原子弹的项目9 当然
参与了非常有能力和积极性的团队，
但它们仍然需要管理，而且都处于高位
在关卡和细节设计上，有选择的地方
关于实际执行的问题.
审核管理的作用包括:
- 与组织的管理层沟通— 审计委员会通常倾向于这样做 有一个单一的接触点来保留一些 保密. 例如，如果管理是 关心系统X的安全问题， 这通常不会传达给整个团队 组织，但首席审计执行官(CAE) 是否应该意识到这些问题并加以指导 审计小组到那个区域. 这仍然是有效的 敏捷管理功能.
- 消除障碍-取决于 组织、被审核员可给予较高的优先级 对他们上司的要求 审计人员. 他们的主管可能会给更高的薪水 优先考虑CAE的要求，而不是审计员的要求. 这也是一个有效的管理功能 敏捷，但是，取决于组织 结构和文化，这可以由 较低的审计管理功能，不一定 CAE，他可以作为最后的手段.
- 在团队中充当仲裁者-这可能是 例如，当不同的方法时是有益的 提出了哪些建议，但并不是所有的建议都能实现 或在质量检查期间确保有报告 是正确的，可以理解的，在某些情况下， 保持正确的政治平衡. 这不是 在技术层面上与敏捷团队合作 因为团队可以提供质量控制 他们拥有审计的所有权. 决策 能否在团队内部处理，如由多 高级审计师. 因为CAE并不总是具有技术能力(特别是对于IT) 审计)，这实际上可能是必要的.
- 对审核员进行人员配备和培训——自从敏捷审计以来 尤其严重依赖于审计师的能力， 理想情况下，CAE或类似的审计经理需要 能够雇佣和培训相应的员工.
什么时候不应该采用敏捷
敏捷并不总是答案. 敏捷几乎不赚钱 对于没有经验的审核员或审核员来说 缺乏技术能力. 此外，常见的 采用敏捷的绊脚石是合同和法律 义务. 敏捷代表灵活性和契约 是完全相反的，因为它们代表协议 刚性更强. 例如，如果不同的法律 实体参与项目并获得报酬 根据花了多少天，那么敏捷就变成了 有问题的. 审计团队通常没有 control over such budgetary issues; therefore, it can 由团队组成的团队很难实施敏捷 来自不同法人实体的人员.
有些案例声称在某些领域是敏捷的 以合同为主，如采购.10, 11 原则上，采购是一个非常不灵活的领域 因为通常会涉及到合同. 固定价格 是否已商定交付固定和商定 功能齐全，交付完全令人满意 产品内容太模糊，不能写在合同上 代表潜在的无限供应商责任. 因此，敏捷采购实际上是敏捷的 内部约束条件. 组织可以做得更多 或者在给定的约束条件下不那么敏捷 在采购的情况下，这可以参考使用 采购小组(i).e.，创建小型团队 来自不同部门的专家，而不是不同 独立工作的部门)12. 值得注意的是 这有时更像是一种标签.
另一个关于采购的更敏捷的标签 可能是成本加成合同(i.e.，合同 收取实际发生的费用加上差额 利润). 这样的成本加成合同使 敏捷性在团队成员中是他们的一部分 供应商有动机专注于生产 产品的质量和初心是开放的 规范或设计，知道自己的努力 会得到奖励. 但这种灵活性并非如此 for a fixed price contract; however, cost of the end 产品可以显著超过预测. 被 完全敏捷并不总是一个现实的选择.
另一种情况是敏捷不太可能带来的 好处是合规审计(i.e.，审计，其中 现状与理想是直接比较的 情境和异常只有在它们不同时才会被提出， 不管差异的实质还是 效率)，因为主动性少而少 团队需要做出的决定. 高层 competence is also typically not required; hence, 灵活性并不那么重要.
审计工作不是在真空中进行的. 审计团队 必须与组织的其他部分协作. 根据敏捷宣言的原则4， “业务人员和开发人员必须一起工作 在整个项目中每天.”13 然而，这并不有效 如果每个答案都需要被审核员的批准 他们提供了. 简而言之，有一个敏捷岛 审计，当组织的其他部分不是敏捷的时候， 会破坏敏捷的有效性.
在审计中有一个敏捷孤岛， 当组织的其他人 是不是不敏捷，破坏了 敏捷的有效性.
结论
随着审计部门努力变得更加敏捷， 必须明白，这本身并不是目的 而是一种提高效率和交付的方法 更高的价值. 这是实现时，有一个明确 对组织正在努力改进的方面的看法 以及敏捷如何帮助实现这一目标. 只是复制或 在没有理解的情况下遵循敏捷框架 采纳基本原则和价值观 不能使审计变得敏捷，而且，在某些情况下，它 能产生与目标完全相反的效果吗 敏捷. 任何影响审计效率的因素 而有效性是敏捷性的障碍. 敏捷 审计就是简单地识别和删除——或者至少 减轻障碍的不利影响.
消除这些障碍并成为 敏捷的包括:
- 招聘或培训高能力的审核员
- 保持审核员的积极性
- 删除所有不必要的繁文缛节，如严格 收费站分离(规划、实地调查、报告)
- 允许审计员在没有 非生产性约束和提供帮助 在需要的时候
- 避免盲目地采用敏捷 框架，除非有具体的例子 具体来说，这个框架将影响效率 和有效性. 如果采用这种框架， 重要的是要确保感知到的收益 实现.
尾注
1 贝克,K.; 等.《澳门赌场官方软件》，2001; http://Agilemanifesto.org/
2 敏捷联盟，“极限编程(XP)” http://www.Agilealliance.org/glossary/xp/
3 Op cit 贝克
4 Alexiou,年代.; “敏捷 Audit,” ISACA® 杂志,卷. 2, 2017, http://1bn.kingpaq.com/archives
5 内部审计师协会(IIA)， 《澳门赌场官方下载》，美国，2016; http://na.theiia.org/standards-guidance/public%20documents/ippf-standards-2017.pdf
6 Op cit 贝克
7 钱伯斯,R.; “Drive-By Auditing: Don’t Be Guilty of ‘Hit and Run,’” 内部审计人员2012年8月2日 http://iaonline.theiia.org/drive-by-auditing-dont-be-guilty-of-hit-and-run
8 干了,.; R. Rampell; “Drive-by Audits Have Become Too Common and Too Dangerous,” 《澳门赌场官方下载》， 2002年8月9日 www.《澳门赌场官方下载》.com/articles/SB1028822538710052160
9 原子遗产基金会，Leslie R. 园”, http://www.atomicheritage.org/profile/leslie-r-groves
10 GEP，“敏捷采购——超越传统采购”，2019年4月22日; http://www.《澳门赌场官方软件》.com/blog/strategy/敏捷-procurement-going-道路-beyond-traditional-procurement #: ~:文本=敏捷% 20采购% 20是基于% 20的% 20,% 20需要% 20 % 20 % 20采购
11 史,P.; “Better for Cost, 人才, 客户:奥地利A1电信集团的敏捷采购,麦肯锡公司, 2020年7月16日, http://www.mckinsey.com/business-functions/operations/our-insights/better-for-cost-talent-and-customer-Agile-procurement-at-a1-telekom-austria-group
12 同前.
13 Op cit 贝克
Spiros Alexiou博士.D.a、c、c、f、c
在过去的14年里一直担任大型澳门赌场官方下载的IT审计员. 他在IT系统方面有超过25年的经验，并编写了许多复杂的计算机程序. 可以通过电话联系到阿列克谢乌 spiralexiou@gmail.com.