隨著組織進入第四次工業革命，他們越來越必須開發創新的數字解決方案以保持領先於競爭對手。 新的工作方式、實踐和方法，例如敏捷，可以加速軟件交付、提高 IT 生產力、改進軟件質量、提高客戶和員工滿意度，並幫助組織隨著業務優先級的變化快速調整技術。1個
然而，儘管業務和 IT 部門採用了敏捷，但許多組織並未在其實施中充分考慮或嵌入風險、合規性和保證功能，導致採用不受控制、不合規且效率較低。 嘗試將舊的項目交付和控制框架改造為新世界可能會導致傳統思維侵蝕迭代開發的價值。
但它不必是這樣的。 通過了解一些細微差別和誤解，風險團隊可以在組織投入敏捷時提供有價值的持續反饋和支持。
一個常見的誤解：敏捷本質上會削弱控制
叛徒團隊使用他們的敏捷方法作為缺乏正式或紀律的理由的故事比比皆是。 例如，團隊可能會以快速、持續集成或交付的名義放棄強制性項目文檔或繞過所需的批准。
這些故事往往會積累成一個更廣泛的神話，即對於風險管理，敏捷不適合成熟的內部控制環境，或者對於工程師來說，轉化為“你在拖慢我的工作速度”。 事實上，當一個組織成功地走向敏捷時，合規部門往往會試圖將老式控制快速改造到開發週期中，這可能會導致敏捷生產力收益受到侵蝕。
但是，如果設計和實施得當，敏捷方法以及 DevOps 工具和流程可以以精益高效的方式實現風險控制目標，並增強整體控制環境。 這意味著企業必須著眼於可擴展性和可持續性，並充分利用他們所掌握的工具和功能。
將控件集成到敏捷環境中
將全局控制和標準要求集成到敏捷環境中非常重要，例如質量和控制標准或運營和風險報告。
但企業還應考慮需要在其組織內實施治理、新流程和控制的領域。 對於領導團隊來說，敏捷組織將意味著不同於他們習慣的可見性——進步、風險、挫折、與目標的一致性和投資回報率可能比傳統的線性生產更難看到。 解決可能會阻礙敏捷承諾的持續發展的遺留技術也將取決於領導層。
對於項目管理辦公室，了解如何為預期變化和演變的生產製定預算將是至關重要的，並且必須更改以線性順序發生的任務管理流程以適應迭代開發。 報告機制以及如何將項目的準確狀態傳達給所有項目利益相關者也存在挑戰。 特別是，對於同時運行敏捷項目和傳統項目的組織來說，這可能是一個問題。
負責確保組織系統穩定、合規和安全的風險和審計人員將需要在不減慢交付速度的情況下實施控制措施，以保護投資價值和運營風險敞口。 為了與團隊協作，需要打破孤島 期間 交付過程（而不是在完成產品的最後）。 隨著新的工作方式和更快的交付速度，這些團隊將需要能夠盡快適應，以確保技術、風險規避和安全性都與生產保持同步。
敏捷/DevOps 環境中有效控制的框架
有效的控制可以嵌入到組織的敏捷交付框架、劇本和/或通過使用敏捷/DevOps 工具。 例如，為了確保職責分離（因為工作可能重疊或同時發生），確保生產代碼更改只能由具有內置測試流程的自動化工具進行可能是有意義的——只能由經批准的管理員配置。 或者，為了在不需要全面文檔（通常被視為與敏捷背道而馳）的情況下確保活動的責任性，企業可以使用跟踪流程的工具（例如敏捷“史詩”、“特徵”或“故事”）並包括批准，測試和發布信息。
每個組織都應考慮其所需的特定控制和活動。 幸運的是，許多成熟的控制框架（例如 COBIT5）已經接受了敏捷原則。 如果不確定從哪裡開始，敏捷、風險、合規和保證團隊可以使用以下內容作為指導：