敏捷审计现在很流行，甚至是那些与敏捷背道而驰的人似乎也成为了敏捷的热心支持者和推动者。许多人热衷于使用Scrum，并将审计分为更短的、通常为两周的Sprint，在Sprint中完全执行审计步骤的子集，并将发现和行动提交给管理层，与管理层讨论并达成一致。尽管这可能是有益的，但仅仅使用Scrum和Sprint并不能使人变得敏捷。

敏捷不仅仅是一种方法或框架，还是一套价值观和原则，其中两项是：

1. 针对有动力的个人，这意味着给他们需要的环境和支持，并信任他们可以完成工作。

2. 最好的架构、需求和设计产生于自组织的团队。

换句话说，如果你有一个有能力和有动力的团队（本例中是审计师），就不必告诉他们如何工作。相反，给予他们信任和自由，让他们自发地开展工作，因为他们是现场人员，最清楚问题是什么以及如何解决问题。

IT软件研发和审计之间的一个主要区别在于，IT研发人员很少有过多的依赖关系。例如，负责软件模块的团队成员最多只能与其他团队成员就接口规范达成一致。相比之下，审计师在很大程度上依赖于被审计方提供的数据和解释（在许多情况下，被审计方的日常工作时间压力大）。如果这些工作延迟，整个Sprint都会延迟。而且，与敏捷精神和原则相反，如果一个人坚持严格的Sprint，最终会得到与敏捷的预期结果完全相反的结果——更低效的审计。

请注意，严格的Sprint在软件研发中是有意义的。在软件研发中，人们同意在Sprint期间交付某种经过测试和工作的功能，并且只提供这种功能。此外，在软件研发中，研发人员从一开始就很清楚要执行的工作。另一方面，在审计中，审计师事先并不清楚要执行什么样的分析以及分析的深度，因为分析取决于数据和风险，而风险将在看到数据之后而不是之前确定。

敏捷审计有助于打破计划、现场工作和报告之间的隔离。例如，人们不必等到计划完成后才要求提供一行数据，而在过去，一些审计经理会坚持这样做，因为他们与实际审计工作几乎没有联系或根本没有联系。用敏捷的繁文缛节取代繁文缛节是敏捷创建者最不想看到的事情。

考虑到这些因素，我们最不想做的就是用额外的控制点检查每个Sprint的进度。相反，可以通过以下方式提高审计效率：

• 尽快请求所需的所有数据，因为这常常是主要的瓶颈。如果这很耗时，请将此请求分为两部分：要求立即提供少量数据样本，并尽快提供完整的数据集。该示例对于了解数据、理解数据告诉我们的内容以及理解如何读取数据非常有用。例如，设计一个解析器自动读取所有数据，并在完整数据集到达后对其进行处理，这会很有帮助。这也有助于更好地感受风险，这将指导专门用于分析的时间。

• 如果你有一个有积极性、有能力的团队，最好不要给他们强加任何框架，而是让团队根据自己的想法优化工作。敏捷在缺乏积极性或能力较差的团队中用处不大。

• 如果您决定使用Sprint（或任何其他框架，如KANBAN 和极限编程），那么应该把Sprint作为一个宽松的指导方针，您应该准备好随时更改，无需正式记录和获得批准。结果可能是，一个Sprint中的一些步骤提前两周完成，或者实际上没有风险，而在另一个Sprint中的步骤则代表着更高的风险，需要更多的关注和时间。团队应该能够在忙碌中适应。

• 如果一个组织希望实现敏捷，那么敏捷审计就不能要求被审计方在回答单个问题或提供单行数据之前咨询主管。

• 敏捷团队需要有能力、有积极性的成员。这也适用于审计师。

• 对你想要改进的东西始终有一个清晰的认识很重要。要了解如何改进，并检查最终结果是否达到目标。

文章来源：ISACA