敏捷审计现在很流行, 看起来甚至那些曾经做过敏捷所反对的事情的人现在也成为了敏捷的热心支持者和推动者. 许多人热衷于使用scrum并将审核分解为更短的部分, 通常是两周的冲刺, 审计步骤的子集在哪里被完全执行，发现和行动在哪里被呈现, 与管理层讨论并达成一致. 虽然这可能是有益的，但仅仅使用scrum和sprint并不能使一个人变得敏捷.
Agile is not just a method or framework; it is a set of values and principles, two of which are:
- 围绕有动力的个人建立项目, 意思是给他们所需的环境和支持, 相信他们能把工作完成.
- 最好的架构、需求和设计来自自组织团队.
换句话说, 如果你有一个有能力、有动力的团队(这里是审计人员), 你不需要告诉他们如何工作. 而不是, 给他们信任和自由来组织他们的工作，因为他们是现场的人, 他们是最了解问题是什么以及如何解决问题的人.
IT软件开发和审计之间的主要区别是IT开发人员很少, 如果有任何, 依赖性. 例如, 负责软件模块的团队成员有, 最多, 与其他团队成员就接口规范达成一致. 与此形成鲜明对比的是, 审计师在很大程度上依赖于被审核方提供的数据和解释(在许多情况下，被审核方在日常工作中时间紧张)。. 如果这些都延迟了，整个冲刺就会延迟. 如果, 对比敏捷的精神和原则, 一个人坚持严格的冲刺, 一个最终的结果与敏捷应该给出的结果完全相反:更低效率的审计.
注意，严格的sprint在软件开发中是有意义的, 在哪里，人们同意交付某个经过测试的、可工作的功能, 只有这个功能, 在冲刺阶段. 也, 在软件开发中，要执行的工作从一开始就很清楚——至少在开发人员的头脑中是这样. 另一方面, 在审计, 由于分析取决于数据和风险，审计师事先并不知道分析的内容和深度, 看完数据后会决定哪一个, 在此之前. 敏捷的审计 有助于打破计划、实地工作和报告的分离. 例如, 在请求一行数据之前，不必等待计划完成, 正如过去一些与实际审计工作很少或根本没有联系的审计经理所坚持的那样. 用敏捷的繁文缛节取代繁文缛节是敏捷的创造者们最不愿意想到的事情.
考虑到这些因素, 最后需要做的是在每次冲刺中检查进度的另一个控制点. 相反，可以通过以下方式提高审计效率:
- 尽快请求所需的所有数据，因为这通常是主要的瓶颈. 如果这很耗时, 将这一要求分为两部分:要求立即提供一小部分数据样本，并要求尽快提供全套数据. 该示例对于了解数据非常有用, 了解数据告诉我们什么，并了解如何阅读数据. 例如, 设计一个解析器来自动读取所有数据并在完整的数据集到达后处理它们是很有帮助的. 它还有助于更好地了解风险，这将指导用于分析的时间.
- 如果你有一个积极进取、有能力的团队, 最好不要给他们强加任何框架，而是允许团队按照他们认为最好的方式优化他们的工作. 对于缺乏动力或能力较差的团队，敏捷不能很好地工作.
- 如果你决定采用sprint(或任何其他框架，如看板和极限编程), 然后应该把冲刺作为一个宽松的指导方针, 你应该随时准备做出改变，而不需要正式的文件和获得批准. 结果可能是，冲刺中的一些步骤在两周之前就完成了，或者几乎没有风险, 而在不同的冲刺阶段则代表着更高的风险，需要更多的关注和时间. 这个团队应该能够在飞行中适应.
- 如果一个组织希望变得敏捷, 这样，敏捷审计就不需要被审核方在回答一个问题或提供一行数据之前咨询主管.
- 敏捷团队需要有能力、有动力的成员. 这也适用于审计员.
- 对自己想要改进的地方有一个清晰的认识是很重要的, 了解如何改进，并检查最终结果是否符合目标.
编者按: 要进一步了解这个主题，请阅读斯皮罗Alexiou最近在《澳门赌场官方下载》上发表的文章， “在审计中实现敏捷:什么该做，什么不该做” ISACA杂志，第1卷，2022年.
《澳门赌场官方下载》今年创刊50周年! 与我们一起庆祝，不要忘记，您仍然可以通过访问您的 偏好中心 选择加入!
