DevOps實踐--團隊改造

當我決定在團隊裡面開展DevOps實踐的時候，我覺得最難的不是技術或者工具，而是對團隊的改造。在技術領域，相信無論是公司或者業界都有很多比較成熟的技術，要滿足目前業務的發展，找到適合團隊的技術選型應該難度不大。在工具的選擇上，更是已經形成了很多事實上的標準，可以參考的案例也很多。

在DevOps的實踐前期，我們需要在專案微服務化改造，環境搭建，CI建設等方面投入很多人力。在交付壓力沒有降低的情況下，需要團隊額外做上面這些事情，有些小夥伴可能就不能理解，覺得這是瞎折騰。所以在DevOps實踐之前一定要跟團隊充分溝通，讓小夥伴們都理解DevOps實踐最終能給團隊帶來哪些收益。但這個收益真的很難說清楚。因為DevOps實踐帶來的收益往往是比較虛的，起碼這個收益是間接或者長期的，並不是所有人都看得到。比如有位小夥伴問我，進行DevOps實踐以後，我們能少加點班嗎？在這個行業待了一段時間的人都很清楚的知道，任何一種先進的技術，架構，開發模式的出現，都不是為了解決加班多這個問題的.....它們解決的問題是要從原來每個星期迭代一個版本提升到迭代兩個版本，但加班時間是不能減少的。當然，我不能這樣回答那位小夥伴的問題，畢竟這樣的事實對一位小萌新來說是有點殘酷的。我只能反覆強調會給個人成長帶來的收益敷衍他的這個問題......

軟體轉型的過程中，一般認為需要打贏三場戰爭才能成功。第一是技術戰爭，第二是商業模式戰爭，第三是意識戰爭。意識戰爭往往是最難的。要讓團隊的所有的小夥伴都認同了DevOps實踐能給我們帶來收益這個觀點似乎是不可能的，所以實際操作的過程中，只要有大部分小夥伴願意嘗試，我們就可以開始了。只要我們在實踐的過程中，能不斷的給其他小夥伴一些正面的反饋，他們也會在將信將疑的實踐中慢慢轉變意識。

團隊改造的目標是打造全功能團隊，我們要打破原來產品，開發，測試，運維，運營之間的邊界，把大家融合成一個目標一致的團隊。比如原來開發和測試之間的目標就是不一致的。開發完成功能開發後肯定想著快速上線，功能交付就是開發的目標。但測試肯定要讓開發把所有bug都解決了才允許上線，因為測試的目標是保證版本的質量。當我們打破開發和測試的邊界以後，團隊的目標都定為快速迭代，快速糾錯。這時候可能版本還有一些優先順序比較低的bug，但測試也允許上線了，因為大家的目標都是快速迭代。

因為我們打破了原來產品，開發，測試，運維，運營之間的邊界，所以團隊成員的分工職責可能就沒有原來那麼明顯了，這就要求團隊的小夥伴要互相學習。除了原來自己擅長的領域要繼續保持先進以外，還需要學習其他領域的知識，比如開發要懂一些測試，測試要懂一些運維等等。

最後，我們還需要發現團隊的短板，只有迅速把短板補齊了，團隊才能高效運轉。