敏捷審計現在很流行，甚至是那些與敏捷背道而馳的人似乎也成為了敏捷的熱心支持者和推動者。許多人熱衷于使用Scrum，并將審計分為更短的、通常為兩周的Sprint，在Sprint中完全執行審計步驟的子集，并將發現和行動提交給管理層，與管理層討論并達成一致。盡管這可能是有益的，但僅僅使用Scrum和Sprint并不能使人變得敏捷。

　　敏捷不僅僅是一種方法或框架，還是一套價值觀和原則，其中兩項是：

　　1. 針對有動力的個人，這意味著給他們需要的環境和支持，并信任他們可以完成工作。

　　2. 最好的架構、需求和設計產生于自組織的團隊。

　　換句話說，如果你有一個有能力和有動力的團隊（本例中是審計師），就不必告訴他們如何工作。相反，給予他們信任和自由，讓他們自發地開展工作，因為他們是現場人員，最清楚問題是什么以及如何解決問題。

　　IT軟件研發和審計之間的一個主要區別在于，IT研發人員很少有過多的依賴關系。例如，負責軟件模塊的團隊成員最多只能與其他團隊成員就接口規范達成一致。相比之下，審計師在很大程度上依賴于被審計方提供的數據和解釋（在許多情況下，被審計方的日常工作時間壓力大）。如果這些工作延遲，整個Sprint都會延遲。而且，與敏捷精神和原則相反，如果一個人堅持嚴格的Sprint，最終會得到與敏捷的預期結果完全相反的結果——更低效的審計。

　　請注意，嚴格的Sprint在軟件研發中是有意義的。在軟件研發中，人們同意在Sprint期間交付某種經過測試和工作的功能，并且只提供這種功能。此外，在軟件研發中，研發人員從一開始就很清楚要執行的工作。另一方面，在審計中，審計師事先并不清楚要執行什么樣的分析以及分析的深度，因為分析取決于數據和風險，而風險將在看到數據之后而不是之前確定。

　　敏捷審計有助于打破計劃、現場工作和報告之間的隔離。例如，人們不必等到計劃完成后才要求提供一行數據，而在過去，一些審計經理會堅持這樣做，因為他們與實際審計工作幾乎沒有聯系或根本沒有聯系。用敏捷的繁文縟節取代繁文縟節是敏捷創建者最不想看到的事情。

　　考慮到這些因素，我們最不想做的就是用額外的控制點檢查每個Sprint的進度。相反，可以通過以下方式提高審計效率：

　　盡快請求所需的所有數據，因為這常常是主要的瓶頸。如果這很耗時，請將此請求分為兩部分：要求立即提供少量數據樣本，并盡快提供完整的數據集。該示例對于了解數據、理解數據告訴我們的內容以及理解如何讀取數據非常有用。例如，設計一個解析器自動讀取所有數據，并在完整數據集到達后對其進行處理，這會很有幫助。這也有助于更好地感受風險，這將指導專門用于分析的時間。

　　如果你有一個有積極性、有能力的團隊，最好不要給他們強加任何框架，而是讓團隊根據自己的想法優化工作。敏捷在缺乏積極性或能力較差的團隊中用處不大。

　　如果您決定使用Sprint（或任何其他框架，如KANBAN 和極限編程），那么應該把Sprint作為一個寬松的指導方針，您應該準備好隨時更改，無需正式記錄和獲得批準。結果可能是，一個Sprint中的一些步驟提前兩周完成，或者實際上沒有風險，而在另一個Sprint中的步驟則代表著更高的風險，需要更多的關注和時間。團隊應該能夠在忙碌中適應。

　　如果一個組織希望實現敏捷，那么敏捷審計就不能要求被審計方在回答單個問題或提供單行數據之前咨詢主管。

　　敏捷團隊需要有能力、有積極性的成員。這也適用于審計師。

　　對你想要改進的東西始終有一個清晰的認識很重要。要了解如何改進，并檢查最終結果是否達到目標。

更多信息可以來這里獲取==>>電子技術應用-AET<<