站在数字化转型的浪尖，十有八九的实践者都会采用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教练的使命。
