[isTMS]課程 - Azure DevOps顧問實戰

敏捷開發者的一天

到底，什麼是DevOps?
開始前，我們先問自己一個問題。

今天，你的團隊，從需求(或bugs)出現，一直到將其生產出來並且毫無瑕疵地交付到用戶手上，需要多久時間?

2021年，估計大家都有在網路上預約疫苗或是申請五倍券(或是其他甚麼券)的經驗吧? 告訴我，倘若你上網登記時發現網站故障了，你希望它多久修復好? 倘若你覺得系統很難使用或出現錯誤，而設計單位也承諾要著手改善，你希望這網站多久能夠完成更新?

每當我問學員這個問題，答案都是同一個，就是『越快越好』，最好能夠立刻、馬上、隨時。

如果，我們對其它人的網站是這麼要求的，那我們的客戶呢? 我們的客戶對我們的期待是不是也是如此?

Cycle Time 與 Lead Time

過去(大概五到十五年前)，軟體不管碰到bugs或是新功能的交付，往往必須等候數個月甚至數年，還記得以前Windows作業系統或是Office軟體的更新頻率嗎。然而，如今我們對系統更新頻率的期待已經變更為數周、數天、甚至數小時…。

而持續縮短用戶等候時間、改善Cycle Time(開始實作需求到完成交付)、Lead Time(收到需求到完成交付)，同時還能夠一併提升(而非犧牲)軟體的品質與安全性，這才是DevOps想追求的核心價值。

在上課時我會跟學員說，如果你團隊至今，不需要頻繁交付價值、頻繁修改bug、頻繁更新，也不需要確保品質和安全性，那有沒有DevOps對你來說確實也無所謂。

但如果你需要呢?

當你開始有頻繁交付的思維，從程式碼的版控開始，就跟過去有很大的不同。你需要盡可能的減少版控分支數量、縮短分支的生命週期、鼓勵團隊頻繁且持續的整合(CI)、大量提高自動化的比例、將人工測試用於探索性測試...這些，都還只是開始。

如何透過DevOps，讓你的團隊實現快速、高品質的軟體更新與功能交付，就是我們這這段落想和你談論的話題。