2010-09-17 23 views
14

我們的IT經理正在推動ITIL,我只是非常熟悉ITIL,並且想知道ITIL是否適合敏捷的工作週期?ITIL能融入敏捷世界嗎?

從我最初的印象來看,我不會這麼認爲,主要是因爲我們的經理提出的是要對所有事情制定時間表,向業務部門陳述SLA對「高優先級任務必須在x小時內完成」等等......我們如果我們不符合這些SLA的標準,就會受到開發者的懲罰。

如果有什麼我更喜歡談判策略,其中時間軸是基於速度和故事點的敏捷方法來協商預期的時間框架給最終用戶。

我們有我們的敏捷開發實踐,測試驅動開發,持續集成,還有需要改進的地方,但我們正在努力。

ITIL和敏捷方法一起工作的其他經驗是什麼?

+0

您的問題是關於[ITIL Stackexchange]上的主題(http://area51.stackexchange.com/proposals/89073/itil?referrer = x5X3k7r_NAmvg4ZTdjTOlw2) – SQLMason 2015-08-12 17:33:09

回答

4

在我公司ITIL框架用於服務交付(生產和事件支持)。對於這個SLA是合適的,就好像你說每小時丟失客戶/錢一樣,那麼預計業務應該有一些跡象表明什麼時候將會修復。它與發展方法學沒有直接關係。只有當您決定需要緊急修補程序並獲得批准時,纔可能完成一些開發。但修補程序通常非常小,目標是修復缺陷,並且不應引起敏捷方法的任何問題。新的要求永遠不會做爲修補程序更改並在正常的開發/測試/發佈過程中進行。

+2

那麼你會如何說正常的開發過程可以免除ITIL方法,並讓ITIL完全專注於基礎設施/事件支持領域? – 2010-09-17 08:46:04

+0

@Brett在上面的評論中增加了一個與我自己的答案相關的更新。 – eglasius 2010-09-17 09:17:03

+1

事件發生也可以是軟件相關的。例如。在一個複雜的企業環境中可能會有一些應用程序由於不良數據而無法工作。或者因爲之前的工作中止等而自動失敗的批處理作業失敗等等。支持所有這些可能需要數據修復或配置文件或時間表更改等。很少會發現一個真正的缺陷,並且需要立即修復爲緊急代碼更改和發佈。 ITIL應該照顧這一點。 – softveda 2010-09-17 10:30:11

3

這看起來不太好,如果是這樣的話,它確實不適合敏捷。

如果ITIL真的需要這樣做,特別是因爲「高優先級任務必須在x小時內完成」不再適合敏捷,它不適合軟件開發,即所有任務都不是天生平等的。

更新:

所以,你會說,正常的發展過程可以從ITIL方法論被免除,並且擁有ITIL純粹專注於基礎設施/事件支持的領域?

我不認爲這是相互排斥的。雖然ITIL不適用於你如何管理團隊,但並不意味着它沒有有效的領域會影響你開發的東西。

開發需要在設計/產品中包含基礎架構/支持所需的注意事項,並且這些注意事項可能與ITIL中建議的實踐有關。

也許一個更合適的問題是:ITIL的管理方面/實踐是否適用於管理軟件開發?我不知道,但懷疑是在ITIL中專門處理的。至少我知道ITIL 3引入了與企業架構實踐相關的變更,這些變更絕對與敏捷(實際上是啓用者)兼容---但至少與那些與固定估計/任務跟蹤/開發響應時間相關的任何內容。

+0

我傾向於同意,我們的經理是基礎架構/支持團隊的一員,並且試圖對軟件任務和支持請求應用相同的規則。試圖解釋這一點似乎並沒有好轉。 – 2010-09-17 08:43:22

+1

@Brett我建議你找到超越敏捷的參考。試圖將發展基礎/支持的本質應用於發展完全是一種不同的野獸,它是雙向的 - 技能不會相同/每一方的人往往會錯過另一方的許多關鍵部分。 – eglasius 2010-09-17 09:11:10