敏捷開發和ITIL是兩種流行的IT方法論，它們分別在不同時期因人們對「舊式」業務模式的不滿而興起。乍一看，它們似乎互不相容。 ITIL 方法論 旨在規範 IT 組織為以可重複的方式持續交付價值而應採取的流程和思維方式。 敏捷 力求大膽創新，勇於提問，克服「打破常規」的恐懼，以便在不斷變化的環境中快速創造價值。

然而，這兩種方法都有各自的優勢，可以彌補對方的不足，為 IT 組織提供了一個藍圖，使其能夠在不犧牲當今商業世界非常重視的敏捷性的前提下，為利益相關者帶來最大價值。

本文將闡述一種方法如何向另一種方法學習，從而為團隊、利害關係人和客戶創造價值。

為什麼敏捷方法在現代商業中如此受推崇？

敏捷技術旨在盡可能消除想法與結果之間的障礙。與強調嚴格依照明確規定的服務等級協定 (SLA) 執行方法的 ITIL 不同， 敏捷方法論 鼓勵組織賦予小型團隊自主、積極工作的能力。

團隊由…組成 多元學科專家他們需要每天優先考慮工作重點。這些努力的預期成果是快速交付的可見結果。團隊以「衝刺」的方式進行工作。 製作迭代原型 這有助於他們明確參數，並為設定後續目標奠定基礎。一旦完成一次迭代，就可以透過另一系列迭代來改進。

这 基本四大原則 -

1. 流程和工具上的個體和交互
2. 工作軟體勝過全面的文檔
3. 客戶合作有關合同談判
4. 響應變化而不是遵循計劃

Agility 是關鍵 在快節奏的環境中，這種心態可以應用於 ITIL，以幫助 IT 服務團隊欣然接受變化。

為什麼 ITIL 在敏捷世界仍然適用

ITIL方法論誕生於1980年代末，當時數位技術正日益深入地滲透到商業環境中。 原始指南 為 IT 服務管理 (ITSM) 提供了一個可重複的路線圖。

ITIL 的優勢在於一切都以書面形式記錄下來。團隊成員清楚知道他們的報告對象、需要處理的問題以及實施任何變更、修復或改進的流程。文件使得審核變更或追溯到特定操作變得輕而易舉。

這種僵化的方法在敏捷環境中會面臨挑戰，使團隊無法在需要時調整或偏離既定的行動方案。例如， 如今，遵循 ITIL 指導的團隊必須能夠持續預測和管理變更風險。

「ITIL流程的永久性可能過於嚴密，」Nancy Van Elsacker Louisnord在《CIO“幾乎沒有辦法偏離最初預先設定的計劃，這就是非敏捷環境的定義。”

ITIL 方法論提供的是可預測性和問責制：服務等級協定 (SLA) 形成書面記錄，明確了預期和交付成果。但該系統並非萬無一失。團隊即使履行了 SLA，也可能仍然會讓使用者和利害關係人感到不滿，因為列出的參數可能並未反映這些方的真實業務需求，或者這些需求可能已經改變。

鑑於這項挑戰，一些團隊可能會發現，在保持 ITIL 流程基礎不變的情況下，採用敏捷的 IT 管理方法具有優勢。

例如，團隊可以跳出服務等級協定（SLA）的局限，拓寬視野，明確自身的真正目標。團隊應該 包括來自真實用戶的回饋在報告中收集客戶和利害關係人的回饋，並利用這些回饋來確定工作優先順序。他們也應該制定能夠準確反映這些意見的指標。向技術的實際使用者徵求回饋意見，可以確保IT團隊不會因為某些問題沒有違反服務等級協定（SLA）就對顯而易見的問題視而不見。

ITIL指導下的組織應用敏捷方法的另一種方式是組建一個或多個創新團隊，並賦予他們所需的自主權，使他們能夠跳脫服務等級協定（SLA）和組織日常需求的限制視角。這些團隊可以針對小型使用者測試小組進行試點項目，或嘗試識別那些可能顯著提升組織效率的、先前未被考慮過的變革——所有這些都將為所有參與者創造價值。

組成內部「秘密研發」團隊可以解決一些長期存在的痛點，例如IT事件數量過多。它還能開啟新的機會之門。開發如今廣為人知的企業聊天客戶端Slack的團隊最初只是想解決公司內部溝通的問題。由於團隊獲得了創新所需的資源，他們最終創造了極具價值的工具——無論對公司內部或外部都極具價值。 外部.

敏捷IT管理旨在消除複雜組織結構中固有的諸多冗餘和微觀管理。如果允許團隊在無需持續報告、監督和等待批准的情況下運作， 擔任領導職務的人可以「全心投入到只有他們才能做的高價值工作中：制定和調整公司願景；優先考慮戰略舉措；簡化和聚焦工作；為任務分配合適的人員；加強跨職能協作；以及消除前進的障礙。”

在敏捷環境中保持 ITIL 的價值

並非所有流程都能從敏捷方法中獲益。重複性強、可預測性高，且在穩定的業務環境中進行的工作，可能會發現敏捷IT管理技術具有顛覆性。此外，有些工作已經重複執行過無數次，各個部門都已製定出明確的解決方案，令各方都感到滿意，這意味著創新會帶來不必要的風險。

考慮到 ITIL 的這些積極特性，敏捷型組織至少應該制定一些衡量成功、處理危機或滿足基準預期等方面的基本規則，作為服務等級協定 (SLA) 的一種形式。如果這聽起來太僵化，團隊可以將該文檔視為一個「迭代」文檔，可以根據業務需求進行調整和完善。

團隊還應測試和評估流程變更，以確保它們不會破壞關鍵業務功能。雖然實驗性敏捷團隊可以在壓力較小的環境中開發原型產品或與關鍵業務功能相關的項目，但最終迭代的產品應該是經過嚴格審查和測試的穩定產品，並遵循可重複的流程。

敏捷團隊也必須了解自身的目標以及誰負責實現這些目標。這樣，就能降低最初ITIL團隊試圖避免的組織混亂的可能性。

在評估 ITIL 與敏捷方法時，最重要的經驗是：每種方法都有其優勢，IT 團隊應該了解這些優勢並根據具體情況加以利用。 ITIL 框架包含一些最佳實踐，這些實踐仍然適用，並且可以進行調整以應用於敏捷方法。

現今的商業世界瞬息萬變，支撐它的科技環境亦是如此。 IT團隊必須緊跟最新技術及其相應需求的步伐。不僅如此，他們還必須不斷更新服務概念。 業務服務管理解決方案在當今的IT文化中，任何使用的框架都應該適應敏捷的目的，而不是反過來。