微軟DevOps的轉型旅程

這一兩年在軟體或是資訊界比較熱門的詞除了Scrum外，大概就非DevOps莫屬了，且說真的不知道為什麼，現在不管什麼工具或產品，最後都要去跟DevOps扯上關係，就如之前在許多研討會上，有很很多DevOps的大神說過，關於DevOps的定義每一個人都會有一種不同的解釋或詮釋方式去說出他對DevOps的認知與見解。也因為這樣，怎樣做好DevOps這件事情，其實也就沒有標準答案了

上個月有幸與微軟西雅圖總部交流了一下DevOps轉型的議題。這真是一個非常棒的體驗，雖然，這之間的交流時間不算長，但也發現微軟在進行DevOps轉型中的有些行為模式跟自己的團隊運作還滿相似之處。 DevOps很難去說誰是對誰是錯，所以，能與各種實際有在進行DevOps公司交流，互相吸取對方的經驗與過程，作為自己團隊或企業的借鏡是相當好的

疑?怎沒有Story Point

在討論之中，突然看到對方，在Story中沒有去設定Story Point，忽然讓我覺得怪怪，一般來說以Scrum進行方式，因該會團隊針對每個Story去評估該Story的Story Point，進行該Sprint可以完成的Story項目。所以，就特別問了一下講者，講者給我這四個要點

Usage

Acquisition

Engagemnet

Satisfaction

Churn

Feature Usage

Velocity

Time to Build

Time to Self Test

Time to Deploy

Time to Learn

Live Site Health

Time to Detect

Time to Communicate

Time to Mitigate

Customer Impact

Incident Prevention Items

Aging Live Problem

SLA Per Customer

Customer Support

We don』t watch

Orginal estimate

Completed Hours

Line of code

Team Capacity

Team Burndown

Team Velocity

of bugs found

原來在整個DevOps循環中，開始關注速度部分則是交付的時間有多快，也就是說當我一個Story完成後，可以多快交付上線，確實如果從這層面考量，完成定義就會被定義在真正有被交付到環境上才算完成，因此，在對方DevOps轉型中，就不太需要關注在開發者設定預估時間上。在自己實務經驗上，似乎也是如此，對於團隊來說，就是要趕緊把東西交付出去，尤其，有時候又會被限制時間完成，那樣去預估一個Story的大小，似乎意義就不大。

何時要做UI自動化測試

這一個問題主要是我想要知道對方是怎樣進行UI自動測試，卻得到對方怎樣去進行一個系統測試比重分布，畢竟做UI測試這件事情，實務上要去做到全自動化的難度並不清，如果從技術角度上是簡單，但UI測試其實也就是整個系統的整合性測試，再加上每次要是UI有所變化，基本上寫的測試案例就必須要重新再變更，讓整個測試效益會比較低

原本是整合測試比重較多，慢慢增加小量的單元測試，以及測試API服務的測試比重，未來將會是以單元測試為主軸，會後思考一下，就經濟效益來說確實是這樣會比較划算，不僅有自動化可以幫忙，也可以縮短交付時程。再加上後續採用微服務架構化，基本上進行到L3的測試，也大概完成所有測試的80%

關於Microsoft DevOps轉型前後

Microsoft開發團隊轉型成為DevOps歷程結果，其中有幾點跟自己團隊是滿像的，尤其是團隊只剩下PM和Engineering，換句話說就剩PO和開發團隊了，微軟移除QA團隊這件事情，想必是大家都知道。移除QA團隊，就不代表不做QA，只是把QA這件事情轉移到開發團隊，其中最大好處當然對於要執行自動化測試這件事情來講就會容易許多。當然，這其中也可以讓開發者和PM針對所謂的Bug進行優先權處理，早期若是有QA團隊，對於QA來說是必須修復好所有Bug，才算合格。但實務上並非所有Bug都是對產品或是系統有直接的影響，若無法針對Bug去進行優先權處理，某程度上就會讓整個系統產品上線時程延後或是延長布署時間。就目前實務來說，也確實如此，如果整個團隊都不斷進行迭代，或許可以有些對用戶完全不影響的缺陷，是可以延後修復的

有幸借鏡微軟轉型過程，由於時程因素，講者沒有辦法把所有細節講完，但是整體而言，讓我知道自己團隊還有在DevOps之路還有更多改善空間，畢竟產業組織特性不同，也不能完全複製微軟這套過來，還是必須做一些小小改良來符合企業文化與流程。

Study4 Love

關注我們

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！