中大型团队在敏捷DevOps转型过程中常见的实践总结
目录
1、聘用外部DevOps顾问
2、建立DevOps共识
3、采用“DevOps改进”而非“DevOps转型”
4、构建“比学赶超”的组织氛围
5、规范化DevOps实践
1、聘用外部DevOps顾问
小型团队可以不用聘用昂贵的外部教练，因为小型团队的组织结构简单，通过团队内部自主决策就能推动DevOps转型。
中大型团队一般职能分工明确，DevOps转型需要向多个全功能组织发展，需要处理的是组织内部的复杂关系，重新切割和划分组织边界，此时组织内部就会出现矛盾，而DevOps顾问则是承接和转化矛盾最理想的人选。
聘用外部DevOps顾问需要注意哪些？
第一、外部DevOps顾问至少有两个以上企业的转型经验，且有自己的案例总结。不同企业的组织特点决定了不同的痛点和方法，不应该只“复制”自己过去的经验，拒绝结合组织形态学习新的知识。转型是一门艺术，面对什么样的组织采用什么样的话术和方法，这些细节将影响DevOps转型的效果。
第二、DevOps转型涉及管理提升和技术提升。外部DevOps顾问要具备精益、敏捷管理实践，也要具备自动化测试、运维、持续交付等技术能力。没有管理实践，技术实践往往沦为“工具赌博”，导致引入的工具没有起到效果；没有技术实践，管理实践无法通过自动化取得进展。技术实践是落地管理实践的手段和工具，只有两者紧密结合才能发挥最好的效果。
第三、DevOps顾问要和团队一起实践，而非一边“指挥”。既要知道也要做到，任何一个实践的落地和见效都需要投入精力和实践，“魔鬼”都藏在细节里，如果没有实践经验就很难避开转型上的“暗礁”。
总结：聘用一个DevOps顾问，不仅要看转型案例，还要关注他的管理和实践经验，不要光听方法论还要让他讲采用什么工具，如何落地，落地的困难点，关键点。DevOps专家的工作也会受组织制度的制约，为了能够在组织生存下去，避免风险，他自然会避免矛盾的发生，而突破这些矛盾才是转型的关键。经验来看，聘用一个DevOps专家很难解决一些“顽疾”，如果继续做会面对同事之间的矛盾。
2、建立DevOps共识
DevOps刚兴起的时候，大家在纠结“DevOps是什么？”，DevOps是一个抽象概念，缺少一个准确定义，因此每个人对DevOps的理解各不相同。随着DevOps的发展以及管理实践、技术实践的总结，DevOps概念下产生了大量的内容，此时大家更关注的是“DevOps能做什么？”
在中大型团队中推广DevOps是一件困难的事情。一方面：DevOps发起人有自己的诉求，为了达到效果中途要解决各种其他相关部门的问题。另一方面：在以职能分工的组织内，中层管理人员看到的是自己利益点和关注点，没有统一认识，DevOps改进分散，没有合力，导致转型效率低下，会遭到部门内部的反对和抗拒。
所以，DevOps转型的前提是在全组织建立DevOps改进共识（领导牵头），无论是提升质量还是效率。目标统一后，就需要根据组织的现状来给出改进优先级，有几个小技巧如下：
（1）按照“三部工作法”的第一步，构建从左到右的交付流程图，包括步骤内容、责任人对应的角色、工作事项、交付物等。
（2）和每个角色单独沟通，了解各个环节的痛点和问题，以便获取更多的信息和信任。
（3）将所有碎片拼起来，构成一条完整、可视化的流程。首先和每个人单独确认，确保没有信息遗漏，然后在一个公开的会议上集体确认，会议上只说事情本身表现出来的结果，不要追究角色和人的责任，否则你会失去一些当事人的信任，为日后开展工作带来不便。
（4）在公开场合允许大家提出不同的观点，但是要指明那些是“事实”，哪些是“假设”。
（5）和所有人确认问题和痛点后，结合优先级发一封给所有人的邮件，之后要定期更新这些问题的进度。
3、采用“DevOps改进”而非“DevOps转型”
大家很可能认为“转型”是短时间内的巨大改变/变革。如果拿两个时间间隔较长的观测点来看是“转型”，但是把这个变化细分到每一天就是“改进”，这也更加符合DevOps的精神---持续改进。一个事物在旧状态下突然引入变化，会经历4个时期：抗拒期、混乱期、集成期、新状态期。这也符合萨提亚改变模型：
所以，转型指的是现有状态下，在一个固定的周期里，引入了多少实践去改进，短期内引入的实践越多，对个人或组织带来的影响和抗拒越大，反弹几率越大。如果把这些实践逐步引入，即在巩固好前一个实践的基础上引入带来的抗拒会小，但时间会长。推荐改进流程如下：
在最差的团队开展试点DevOps转型；
小规模组织将试点团队的实践进行推广；
推广团队总结实践经验；
在阶段性转型会议上给所有团队负责人说明，让他们根据自己的情况进行评审和采用；
4、构建“比学赶超”的组织氛围
DevOps是一个自上而下的任务，他带来的压力和负面印象居多，这也是DevOps落地难的原因之一。所以定期要给大家一些激励，营造一些良好的气氛非常重要。比如根据转型标准设计了团队排名，并定期公开结果和奖励，要求排名靠前的团队进行分享，把一些经验总结到统一的DevOps知识制度规范中。
团队之间有了竞争，团队之间的学习、追赶和超越就成了自发的行为，这样DevOps的转型就由被动化为主动。
5、规范化DevOps实践
在DevOps改进过程中，我们把很多实践文档化、规范化以用来复制和流转，否则大家的理解和执行往往不一致，在小团队这样的问题不明显，但是在大团队中传播和理解就会成为很大的问题。所以需要建立一个规范化的文档中心，让所有的知识和要求有单一可信的来源。规范化实践需要注意以下几点：
（1）名词最好只有单一解释和定义，并进行引用；
（2）步骤说明和注意事项要齐全，每个步骤落中一定有很多细节；
（3）好坏例子都要保留，并对例子有说明；
（4）要有效果和度量；
制度树立起来后需要认真执行并不断完善。每个团队、每个人都可以根据自己的实践来不断更新规范文档，这样团队会有参与感，才会愿意执行和维护这样的制度，否则很难执行下去。
让每个文档能够帮助和指导实践，而不是单纯记录。用文档的约束和定义来考评团队各方面的表现，这个文档就会被利用起来。
在组织里也要养成执行和建立规范的文化。在遇到事情前，首先问问有没有制度规范，如果有就执行，如果没有就想办法建立。在执行后也要能够根据实际的使用抢矿和DevOps改进目标进行调整，而不是一味的死守制度。
规范化是DevOps发挥规模效应重要一环，在开始时就需要建立，并结合实践一起使用。
翻译读研发质量保障与工程效率之埃森哲千人规模组织级DevOps改进。
