敏捷審計現(xiàn)在很流行,，甚至是那些與敏捷背道而馳的人似乎也成為了敏捷的熱心支持者和推動者,。許多人熱衷于使用Scrum，并將審計分為更短的,、通常為兩周的Sprint,，在Sprint中完全執(zhí)行審計步驟的子集,，并將發(fā)現(xiàn)和行動提交給管理層，與管理層討論并達(dá)成一致,。盡管這可能是有益的,，但僅僅使用Scrum和Sprint并不能使人變得敏捷。
敏捷不僅僅是一種方法或框架,，還是一套價值觀和原則,，其中兩項是：
1. 針對有動力的個人，這意味著給他們需要的環(huán)境和支持,，并信任他們可以完成工作,。
2. 最好的架構(gòu)、需求和設(shè)計產(chǎn)生于自組織的團隊,。
換句話說,，如果你有一個有能力和有動力的團隊（本例中是審計師），就不必告訴他們?nèi)绾喂ぷ?。相反,，給予他們信任和自由，讓他們自發(fā)地開展工作,，因為他們是現(xiàn)場人員,，最清楚問題是什么以及如何解決問題。
IT軟件研發(fā)和審計之間的一個主要區(qū)別在于,，IT研發(fā)人員很少有過多的依賴關(guān)系,。例如，負(fù)責(zé)軟件模塊的團隊成員最多只能與其他團隊成員就接口規(guī)范達(dá)成一致,。相比之下,，審計師在很大程度上依賴于被審計方提供的數(shù)據(jù)和解釋（在許多情況下，被審計方的日常工作時間壓力大）,。如果這些工作延遲,，整個Sprint都會延遲,。而且，與敏捷精神和原則相反,，如果一個人堅持嚴(yán)格的Sprint,，最終會得到與敏捷的預(yù)期結(jié)果完全相反的結(jié)果——更低效的審計。
請注意,，嚴(yán)格的Sprint在軟件研發(fā)中是有意義的,。在軟件研發(fā)中，人們同意在Sprint期間交付某種經(jīng)過測試和工作的功能,，并且只提供這種功能,。此外，在軟件研發(fā)中,，研發(fā)人員從一開始就很清楚要執(zhí)行的工作,。另一方面，在審計中,，審計師事先并不清楚要執(zhí)行什么樣的分析以及分析的深度,，因為分析取決于數(shù)據(jù)和風(fēng)險，而風(fēng)險將在看到數(shù)據(jù)之后而不是之前確定,。
敏捷審計有助于打破計劃,、現(xiàn)場工作和報告之間的隔離。例如,，人們不必等到計劃完成后才要求提供一行數(shù)據(jù),，而在過去，一些審計經(jīng)理會堅持這樣做,，因為他們與實際審計工作幾乎沒有聯(lián)系或根本沒有聯(lián)系。用敏捷的繁文縟節(jié)取代繁文縟節(jié)是敏捷創(chuàng)建者最不想看到的事情,。
考慮到這些因素,，我們最不想做的就是用額外的控制點檢查每個Sprint的進度。相反,，可以通過以下方式提高審計效率：
盡快請求所需的所有數(shù)據(jù),，因為這常常是主要的瓶頸。如果這很耗時,，請將此請求分為兩部分：要求立即提供少量數(shù)據(jù)樣本,，并盡快提供完整的數(shù)據(jù)集。該示例對于了解數(shù)據(jù),、理解數(shù)據(jù)告訴我們的內(nèi)容以及理解如何讀取數(shù)據(jù)非常有用,。例如，設(shè)計一個解析器自動讀取所有數(shù)據(jù),，并在完整數(shù)據(jù)集到達(dá)后對其進行處理,，這會很有幫助,。這也有助于更好地感受風(fēng)險，這將指導(dǎo)專門用于分析的時間,。
如果你有一個有積極性,、有能力的團隊，最好不要給他們強加任何框架,，而是讓團隊根據(jù)自己的想法優(yōu)化工作,。敏捷在缺乏積極性或能力較差的團隊中用處不大。
如果您決定使用Sprint（或任何其他框架,，如KANBAN 和極限編程）,，那么應(yīng)該把Sprint作為一個寬松的指導(dǎo)方針，您應(yīng)該準(zhǔn)備好隨時更改,，無需正式記錄和獲得批準(zhǔn),。結(jié)果可能是，一個Sprint中的一些步驟提前兩周完成,，或者實際上沒有風(fēng)險,，而在另一個Sprint中的步驟則代表著更高的風(fēng)險，需要更多的關(guān)注和時間,。團隊?wèi)?yīng)該能夠在忙碌中適應(yīng),。
如果一個組織希望實現(xiàn)敏捷，那么敏捷審計就不能要求被審計方在回答單個問題或提供單行數(shù)據(jù)之前咨詢主管,。
敏捷團隊需要有能力,、有積極性的成員。這也適用于審計師,。
對你想要改進的東西始終有一個清晰的認(rèn)識很重要,。要了解如何改進，并檢查最終結(jié)果是否達(dá)到目標(biāo),。
更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<
