站在數字化轉型的浪尖，十有八九的實踐者都會採用DevOps幫助企業實施數字化轉型戰略。同時，他們也面臨各種挑戰，渴望與業界的技術專家深度交流，探尋更好的解決方案和最佳實踐，例如：
- 做DevOps轉型需要準備些什麼，才能保證轉型的順利？
- DevOps轉型中遇到了哪些坑，是怎麼解決的？
- DevOps諮詢怎麼做？
到哪裏可以找到這樣的交流對象和交流主題內容呢？這是他們首先要解決的問題。
爲此，先引薦下DevOps Master俱樂部這個“神祕”組織。
DevOps Master俱樂部，是由國際信息科學考試學會（EXIN）聯手授權培訓機構、授權講師、認證的DevOps Master和行業專家共同打造的知識交流和實踐分享的互動平臺。DevOps Master俱樂部希望通過構建高端的社區平臺幫助行業精英自我成長，賦能團隊和企業，充分體現出DevOps Master的價值，進一步培養中國DevOps實踐的優秀人才和中堅力量。
DevOps Master俱樂部的四點宗旨是：
- 持續學習DevOps實踐精髓，持續提升會員能力和經驗。
- 建立DevOps高端人脈和圈子，提升會員的行業知名度，獲取優質資源。
- 參與俱樂部沙龍等活動，獲得DevOps持續實踐學分-。
- 共創作品、行業案例、DOM專屬調研報告、出版物等行業輸出，成爲中國DevOps實踐中堅力量。
嗯，也許你已經明白我爲什麼要參加DevOps Master俱樂部了，但其實，還有更深的原因。
目前，DevOps Master俱樂部有四個專項小組，分別是：
- DevOps Master線下沙龍組；
- 實踐案例組；
- 國際DevOps出版物翻譯和評審組；
- 中國DevOps Master現狀報告調研組。
每個小組都有自己的目標和任務。比如國際DevOps出版物翻譯和評審組，今年（2019）翻譯了《Lean IT Foundation》和《Agile Scrum Foundation》兩本書，作爲DevOps專業人士的入門級教材。《Lean IT Foundation》（中文譯名：精益IT基礎）闡釋了精益IT的內涵——精益IT是精益製造和精益服務的原則的延伸，用於信息技術產品和服務的開發和管理，其目標是不斷提高IT組織爲客戶提供的價值以及IT人員的專業水平。《Agile Scrum Foundation》（中文譯名：敏捷Scrum基礎）包括了敏捷的概念，敏捷的基本原則，預測型和適應型生命週期，Scrum的框架、角色、事件、構件以及規模化Scrum，和極限編程、DSDM、看板及可視化方法等敏捷實踐。
參與每個專項小組都挺好玩，也很有收穫。
今年我作爲國際DevOps出版物翻譯和評審組的一員，就參與了《Agile Scrum Foundation》的翻譯，有幸與國際DevOps出版物翻譯和評審組的同行專家們進行交流和學習，受益多多。比如關於“預測型”和“和預測性”的探討，比如關於“ScrumBut”的理解，過程都很有意思並充滿樂趣。
- 預測型Vs.預測性 ？
《Agile Scrum Foundation》原文中關於項目交付方式和生命週期的描述，提到了Predictive Lifecycle和Adaptive Lifecycle兩種生命週期模型。將Predictive Lifecycle翻譯爲“預測型生命週期”還是“預測性生命週期”？“預測型”還是“預測性”的使用引起了翻譯組同行專家們的爭論。從“型”到“性”再到“型”，我自己也是內心糾結，反覆思考。結合上下文語境、意境、全文引用及該詞的應用場景，反覆斟酌，加之與翻譯組同行專家多次探討，經過多次修改，多次訂正，在最後的評審會議上，才最終確定爲“型”。
爲了再次體驗下“預測型”和“預測性”的美妙，此處摘引《Agile Scrum Foundation》的部分原文描述，與你同饗：
- We try to predict what we want and how it can be produced, and that’s why a common name for it is predictive.
- Predictvie lifecycles are the normal and appropriate way to develop many projects, such as a constrction project.
- Taylorism was entirely and strongly based on Predictive systems; therefore, Predictive systems dominated the whole world, so to speak.
- A predictvie lifecycle is … well，it’s more predictive!
- ScrumBut還敏捷嗎？
What？ScrumBut是個什麼鬼？僞敏捷？僞Scrum？
記得那天晚上與朋友喝完酒已經快凌晨了，在回家的出租車上，看到翻譯組的一位同行在微信羣裏問，ScrumBut應該怎麼翻？如果直譯爲“Scrum但是”，ScrumBut is not Scrum，“Scrum但是不是Scrum”，感覺很彆扭。
最初，根據當時的理解，我給出的建議是翻譯成“僞Scrum”，或者“裁剪的Scrum”。過了一個月，在仔細審閱那段文字時，重讀原文，體悟ScrumBut的真正涵義，我覺得之前把ScrumBut翻譯爲“僞Scrum”似乎不妥：ScrumBut不是Scrum，也不“僞”，它更像是一種由“But”來放寬條件的“閹割版”Scrum，“僞”字容易引起誤導。因此，我重新提議對ScrumBut做不翻譯處理，保留原文。又過了一週，在二審的評審會議上，翻譯組最終共同決議，確定ScrumBut作爲專用術語，保留原詞，不做翻譯。
對於ScrumBut的概念，以及Scrum是否可以裁剪、ScrumBut是否還敏捷的問題，《Agile Scrum Foundation》是這樣回答的（譯文如下）：
關於敏捷有很多誤解。例如，大多數人認爲他們只需將預測的範圍劃分爲更小的片段，在叫作衝刺的時間段內開發它們，就可以稱爲Scrum了，這是錯誤的。敏捷是自適應的，而不是採用一組特定的術語。……
Scrum調整的空間相對來說極低，因爲它真的非常輕量級。在Scrum中，一切幾乎都是強制性的，你不能省略任何方面。但是有些人就是那樣做！比如，他們說：
- 我們使用Scrum，但我們不遵守衝刺時間盒。
- 我們使用Scrum，但我們在衝刺計劃中設定衝刺的週期。
- 我們使用Scrum，但我們不允許產品待辦列表改變。
- 我們使用Scrum，但我們認爲沒有必要做衝刺回顧。
所有這些情況都稱爲“ScrumBut”，而不是Scrum。“ScrumBut”不是Scrum。因爲當你僅遵循 95%的Scrum 規則時，你別指望能獲得95%的收益，也許只有10%到20%的收益。
2019年12月8日，在上海召開的DevOpsDays大會上，中國銀行基於容器的DevOps平臺建設負責人韓琪女士介紹他們在西安研發中心實施Scrum敏捷項目經驗時，選用了一張看似不起眼的項目現場照片。照片上，一羣工程師圍在某個工位前，或站或坐，不知道在幹什麼。韓琪解釋道，這是一個開發小組的成員，他們晚上十點多還沒下班，圍在一起等待編譯狀態“變綠”，“變綠”後才能回家，這張照片是她當天在現場拍的“現狀”。韓女士繼續解釋說，之前他們的敏捷沒有嚴格遵照Scrum的規則，沒有這些看似低效的約束和等待，但研發效率仍然低效，問題不斷。後來，來了一個大Boss，現場蹲守、觀察了幾天，發現了問題的癥結， 重新按照Scrum框架制訂了規則，並要求嚴格遵守，慢慢的，大家的習慣改變了，研發的效率上來了，問題變少了，質量也明顯得到了提升。韓琪女士用實例證明了遵守Scrum規則對項目成功的重要性。我想，這應該也是敏捷文化中“One Team”、“Work Together”、“交付可用的軟件”等原則潛移默化的效果吧。
“當你僅遵循 95%的Scrum 規則時，你別指望能獲得95%的收益，也許只有10%到20%的收益”，請記住這句話。
提高軟件研發的效率和交付的質量，加快數字化轉型，高效實現業務價值，是企業推行DevOps的主要目的。如何幫助企業更加有效的實施DevOps轉型，是我選擇DevOps Master俱樂部的一個重要原因。賦能團隊和企業，是每一位DevOps教練的使命。
