DevOps Master教练十二条原则

作者：北京老李：EXIN授权EXIN DevOps Master（大师级）讲师(首批全国十名) 、EXIN授权EXIN Agile Scrum 、Product  Owner、Lean IT 认证讲师、首批ITIL Expert讲师、PMP、Prince2专家级、EXIN云安全管理、EXIN 云服务管理、ISO20000 LA、ISO27001 LA等多项认证。先后在北京、上海、广州等地主导软件开发、系统集成、咨询服务等工作，主要研究方向云安全管理、DevOps落地实施。

 1.DevOps Master教练十二条原则（一个中心、二个基本点、九大操作问题）：北京老李总结，持续改进中（引用必须写明出处）
1.不能促进业务、开发、运维等多个专业团队的合作就不是DevOps  Master（教练）【核心问题-DevOps】

2.不能充当DevOps拥护者，并在整个组织中推广CLAMS 原则和DevOps价值，就不是DevOps  Master（教练）【基本点问题-CLAMS】

3.不能转变成为仆人式领导者，不能投入到团队当中去完成工作任务就不是DevOps  Master（教练）【基本点问题-敏捷领导力】

 4.不能帮助团队成长，并提升业务交付价值，不断快速提高业务输出能力，就不是好的DevOps  Master（教练）【操作问题-关注业务问题】

5. 不能让团队在探索框架内的实践并且不断审视自己，就不是好的DevOps Master【操作问题-放权问题】

6.不能保证不公开地批评团队成员，不能心平气和地沟通与交流，就不是好的DevOps  Master（教练）【操作问题-文化建设问题】

7.不能帮助DevOps团队消除障碍，不能让DevOps团队顺利完成目标，不能将DevOps团队生产力最大化就不是好的DevOps  Master（教练）【操作问题-OKR目标导向问题】

8.Scrum不是敏捷方法及DevOps教练的全部，但不懂Scrum一定不是好的DevOps Master（教练）【操作问题-敏捷方法问题】

 9.不能将团队分解为7（加减2）人的小组进行 ，就是不是好的DevOps Master（教练）【操作问题-高效团队问题】

10.不负责迭代周期正常进行，就不是好的DevOpsMaster（教练）【操作问题-短迭代快速交付问题】

11.不引入CI、CD、AI等自动化手段，就不是好的DevOps Master【操作问题-自动化问题】

12.不能支持持续实验与学习改进，并研究、引入、推广业界先进的(DevOps，AIOps)敏捷思想就不是好的DevOps Master（教练）【操作问题-改进问题】

2.敏捷教练1.0
敏捷教练1.0最早敏捷教练出自《Scrum》和《极限编程》中针对于教练的定义，有相关的管理角角定义。

其中应用最广的为《Scrum》方法引入的 Scrum Master角色。Scrum是在1993年，Jeff Sutherland读到了两位日本管理教授竹内弘高和野中郁次郎介绍制造业里出现的新的产品开发方法Rugby（橄榄球）的文章。这种方法的特点是整个流程都由一个高性能、跨功能的团队执行到底。他受到启发，结合自己多年的经验，与Easel公司的John Scumniotales和Jeff McKenna一起开发了一套方法，取名为Scrum（来源于橄榄球术语，不是缩写）。

 Scrum Master（教练）： 为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。

根据《敏捷教练：如何打造优秀的敏捷团队》总结敏捷的所有这些失败模式都对团队有相似的影响。即不能实现仆人式的领导。当失败模式产生时，敏捷教练已经成为了团队的焦点。

 敏捷教练需要具备很强的以下几种能力：mentoring，teaching，coaching，facilitating。在此基础上，敏捷教练的发展路径有可能成为 Technical Mastery，Business Mastery或者Transformation Mastery，这三个路径取决于敏捷教练自身的兴趣和拥有的经验。 

3.敏捷教练2.0
 敏捷是“一棵树”，而不是一种方法，树根是敏捷价值观，树干是敏捷方法论，输叶则是各种实践。树根的特点是隐蔽，平时看不见很容易忽视，并且给树一个始终不变的定位；树干的特点是少而精，指导了实践发展；输叶的特点是能不断发展变得越来越繁茂，可能还会有枯叶会自然脱落。这就是敏捷的特点。 

敏捷教练2.0的基石
敏捷教练2.0最大的特点是引入多种敏捷方法，包括精益（Lean看板）、持续交付、轻量级的ITSM(ITIL 4)、敏捷多种实践方法引入，例如XP、TDD、BDD、DDD、CI、CD等，从管理到技术全方位进行转型敏捷应用。就像《EXIN DevOps Master》课程体系总结的一样。

DevOps Master课程体系
敏捷教练2.0需要遵从《DevOps Master教练十二条原则》帮助企业实现敏捷的第二次转型。

敏捷的第二次转型：需要DevOps Master教练
4.敏捷课程建议

北京老李：看到持续交年费就头痛，所以那个培训没有推荐
北京老李：看到持续交年费就头痛，所以那个培训体系没有推荐，课程双多，也要维护。。。哎。。。

入了IT行业.....是有就难....如果想学，学点不用维护的吧

5.敏捷教练2.0的招聘要求

某企业的敏捷教练2.0的招聘信息
6.欢迎爬楼
欢迎爬楼，看更多北京老李-DevOps相关内容，ITIL内容请关注”豆列“

DevOps Master课程：事半功倍的系统化学习  https://www.douban.com/note/717180422/ 

 https://www.douban.com/note/713613037/  DevOps professional课程：只讲技术之CHEF（1）

https://www.douban.com/note/709308373/ DevOps Master ：招聘DevOps工程师必问的12个问题（送DevOps实现的三个路径）

https://www.douban.com/note/708968150/ DevOps Master课程总结：知否知否，应是DevOps肥ITIL瘦（送ITIL4前生今世）

https://www.douban.com/note/708218842/  DevOps Master课程总结：学习没有捷径（送DevOps安灯正确方法）

https://www.douban.com/note/694641377/ DevOps Master凤凰项目沙盘总结：DevOps黄金三步法

https://www.douban.com/note/700603657/ DevOps Master凤凰项目沙盘总结：履霜坚冰至，转型应自强不息

https://www.douban.com/note/693053178/ DevOps Master凤凰项目沙盘总结：通过DevOps实现IT组织转型

https://www.douban.com/note/689504940/ DevOps Master凤凰项目沙盘总结：DevOps起始质量之独孤九剑

https://www.douban.com/note/645016138/ DevOps凤凰沙盘：一场精益敏捷探索之行

https://www.douban.com/note/629890513/DevOps凤凰沙盘：一场百玩不厌的质量感悟

https://www.douban.com/note/630638887/DevOps课后总结之DevOps游戏系列-DevOps的独孤九剑

https://www.douban.com/note/637665261/DevOps Master课程:回忆我与DevOps之父Patrick的交流

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://www.douban.com/note/647732431/ DevOps：10本DevOps推荐书及47个DevOps兼容工具

https://book.douban.com/review/9110485/ DevOps：转型从正确地认知开始

https://www.douban.com/note/651734552/ DevOps：从I型人才到E型人才

https://www.douban.com/note/651734953/ DevOps：智能服务台是企业不能缺少的基石

https://book.douban.com/review/8928323/ DevOps布道师:终身学习是终身成长的源动力

https://book.douban.com/review/8820627/ 《把读到的知识转化为能力三步法及完美学习的四步法》

https://www.douban.com/note/643862694/ DevOps Master课程:脚踏实地学Pre-Master，一步一个脚印成为DevOps Master

https://book.douban.com/review/8805640/ DevOps布道师为深度工作写的序：深度工作是心身的一种修练方法

https://book.douban.com/review/8795275/ 咨询基本功：咨询顾问基本功之书面沟通及“补充大餐”

https://www.douban.com/note/643251358/ DevOps定义编年史：通过DevOps定义看DevOps发展

https://www.douban.com/note/637838681/ DevOps应用：光大银行DevOps1.0到DevOps2.0研讨会

https://www.douban.com/note/639093367/ DevOps应用：民生银行IT一体化管理与自动化发展（1）

https://www.douban.com/note/638965340/ DevOps应用：工商银行DevOps进行时

https://www.douban.com/note/696842302/ DevOps应用：工商银行DevOps进行时（2018年）

https://www.douban.com/note/641427886/ DevOps应用：DevSecOps云下安全与云等保（云博会内容提前曝光）

https://www.douban.com/note/646007197/ 敏捷辩论 

https://www.douban.com/note/655617439/ 敏捷服务管理：数字化转型核心

https://www.douban.com/note/696148785/ DevOps Master课程总结：IT运维的昨天、今天、明天（IT运维四大“坑”）

艾利·高德拉特  “在瓶颈之外的任何地方作出的改进都是假象，在瓶颈之后作出任何改进都是徒劳的，而在瓶颈之前作出的任何改进则只会导致瓶颈处堆积更多的库存。” 

【1】精益管理方法的术语

【2】高维度思考法

【附】高德拉特《目标》五个聚焦步骤：

第一步是确认约束点，直到确定那的确是整个部门层面的约束点，对非约束点的任何改进都只是幻觉，得不到实际任何价值；

第二步是利用约束点，寻找突破这些约束的办法，确保不让约束点浪费任何时间，永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项，一直都要这样；

第三步，使企业或部门的所有其它活动服从于第二步中提出的各种措施；

第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是整个部门的约束点；

第五步，回到步骤1，别让惰性成为约束，持续不断地改善；