本文轉(zhuǎn)自Study4臺灣社區(qū)。Study4臺灣社區(qū)，成立于2011/9/25，希望藉由社群推廣的力量，讓臺下的朋友聽到來自不同縣市的大師講課，也讓臺上年輕一輩的技術(shù)傳教士能不斷的琢磨并且追上大師這是一個社群，社區(qū)希望透過分享，給偏遠(yuǎn)地區(qū)、年輕一輩、每一個人，多那么一點機會。點擊原文鏈接關(guān)注?Study4臺灣社區(qū)。

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

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

咦?怎沒有Story Point

在討論之中，突然看到對方，在Story中沒有去設(shè)定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循環(huán)中，開始關(guān)注速度部分則是交付的時間有多快，也就是說當(dāng)我一個Story完成后，可以多快交付上線，確實如果從這層面考量，完成定義就會被定義在真正有被交付到環(huán)境上才算完成，因此，在對方DevOps轉(zhuǎn)型中，就不太需要關(guān)注在開發(fā)者設(shè)定預(yù)估時間上。在自己實務(wù)經(jīng)驗上，似乎也是如此，對于團隊來說，就是要趕緊把東西交付出去，尤其，有時候又會被限制時間完成，那樣去預(yù)估一個Story的大小，似乎意義就不大。

何時要做UI自動化測試

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

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

關(guān)于Microsoft DevOps轉(zhuǎn)型前后

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

---

有幸借鑒微軟轉(zhuǎn)型過程，由于時程因素，講者沒有辦法把所有細(xì)節(jié)講完，但是整體而言，讓我知道自己團隊還有在DevOps之路還有更多改善空間，畢竟產(chǎn)業(yè)組織特性不同，也不能完全復(fù)制微軟這套過來，還是必須做一些小小改良來符合企業(yè)文化與流程。

原文地址?https://mp.weixin.qq.com/s/JUeLL727o_VDcNy-Cev9zA

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的微软西雅图总部DevOps交流总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。