Dreamland

\* 运动极少的一个月，这点坚决坚决要改正！

\* 度过了一段很纠结低落的日子，但仍旧心怀憧憬，希望后面的路能越走越宽吧。

\* 这个世上最难的是开心，但最容易的也是开心，因为它几乎可以完全脱离物质脱离外界，仅仅取决于自己。到底何时应该较劲，何时应该放手？大概需要我用一生来慢慢参透。

先后读了两本传记，《富兰克林自传》和SAP现任掌门人孟鼎铭的传记《逐梦之旅》。本没把这两个人联系到一起，读这两本书的初衷也不大一样，但越读却越发现他们有很多共同之处。《逐梦之旅》的英文是Winner's Dream，不论身处哪个时代，想要追求自己向往的生活，其中的道理并没差太多。

先说《富兰克林自传》吧，说实话，在读这本传记之前，对富兰克林并没有太多了解，无非是大家都耳熟能详的故事：起草《独立宣言》的美国国父，雷雨天放风筝的科学家。读了这本自传，“先贤”的扁平印象才丰满起来，对他的敬仰膜拜之情确是有增无减。

对富兰克林来说，政治并不算他年少时给自己人生规划的一部分。12岁时他辍学去印刷所当学徒，这之前也尝试过好几个行当，但都提不起兴趣。不知是不是对书籍的热爱促成了他与印刷的缘分。虽然早早开始了学徒生涯，富兰克林却并没有放弃任何个人追求，仍然严格地坚持着很多习惯，而每一项习惯，无疑也都为他铺平了日后的人生道路：

• 如饥似渴的读书，为了攒钱买书甚至变为素食者。我总觉得这一点是奠定了其他美德的基础。
• 积极思考并参与到身边各种事务的讨论中，并且锻炼文笔，学习如何更好地说明自己的论点，驳斥对手的论点。
  这个本事深深让我佩服，日后每当他想要做一点改革的时候，总会先写出一些文章刊在报上，或者印一些小册子，等到大家都基本认同了他的观点，他再郑重提出要办这件事，简直是水到渠成。没有这些铺垫，他也不可能那么顺利地办成很多公益项目，并从一个商人进入政界。
  那个时代的北美殖民地尚未统一，更没有取得独立，市政建设也才刚刚开始，对于如何建设家园、规划发展，总有很多大大小小的争论。小到道路修建、路灯设计，大到兴办学校、商家税收、法规制定，一切都有很多讨论的余地。那正是适合富兰克林的黄金时代，他有天生的热心和激情，又训练出聪明机警的头脑，总能洞见到问题本质，并找出对社会和大众都最有好处的提议。再加上他的积极奔走，一项项利民措施的兴建为他奠定了极高的声望。
• 虽然富兰克林参加了很多看起来“事不关己”的业余活动，但对待工作却永远是一丝不苟，不管是管理印刷所还是办报纸，干起活儿来都有股不遗余力的拼命劲头，也正是因为这样，他才从白手起家积累了足以衣食无忧的财富。
• 让我非常敬佩的还有一点，那就是他的自律。一个人如何能在商业、公益、政治、科学、文化等方面都有所建树？勤奋自律和一颗永不懈怠的心肯定是必备的。富兰克林不光列出了自我要求的十三条美德，还在随身携带的笔记本上做了表格，每天自省是否有所违背。这就是所谓“完人”背后的秘密吧，有了几十年如一日对自己的严格要求，常人看来难以企及的成就对他就成了手到擒来。

不过，读完本书让我印象最为深刻的，并不是他的智慧与勤奋，而是他看似永无止境的好奇心。他做了很多各种领域的发明，包括壁炉、路灯、眼镜等等，当然成果最丰硕的是电学领域的研究以及发明了避雷针。富兰克林第一次接触到电学的基础知识时已经四十岁了，但他依然像个学生一样投入到电学的钻研中去，并在五十多岁获得牛津大学的荣誉博士学位。要说伟人和普通人的区别是什么，不正是这种永不止息的精神力量么？作为一个八零后，我和我身边很多朋友都已在奔四的路上了，想想我们平常总会抱怨“年纪大了”，似乎常常失去上进的动力和理由，无怪乎我等众生，只能仰望先贤的背影。

我本来对美国历史几乎没有了解，读了这本书，却对美国的立国之路有了兴趣。透过富兰克林的文字，我不只看到了一位为自由、平等斗争的圣人，更看到了一个黄金时代，在那个时代，仿佛所有受过教育的人都关注着国计民生，都以建立一个更美好的社会为目标，夙夜靡怠地奋斗着。相比之下，英法殖民者所关注的，只不过是如何收缴更多税款、获得更多利益而已。

对新大陆来说，那是一段纷争痛苦的历史，却也是充满机遇的时代，正是在一批先贤的带领下，殖民地的居民们把握住了这个机遇，才有了今天的世界格局。从任何一个角度来说，美国的国父们都是一批影响了世界的人。

摘录一下富兰克林的十三条美德，以致敬伟人

1. 节制。
   饭不可吃胀，酒不可喝高。
2. 缄默。
   于人于己不利的话不谈。避免碎语闲言。
3. 秩序。
   放东西各归其位，办事情各按其时。
4. 决心。
   决心去做该做的事情，做就做到心想事成。
5. 节俭。
   不花于己于人没有好处的闲钱，杜绝浪费。
6. 勤奋。
   珍惜时光。手里总忙有益之事，剪除一切无谓之举。
7. 诚信。
   不害人，不欺诈。思想坦荡，公正；说话实事求是。
8. 正义。
   不损人利己，伤天害理的行为用不沾边，利公利民的应尽义务切勿放手。
9. 中庸。
   避免走极端。忍让化冤仇。
10. 清洁。
    身体、衣着、居所，不许不干不净。
11. 平静。
    不可为小事、常事或难免之事搅乱了方寸。
12. 贞洁。
    少行房事，除非为了身体健康或传宗接代；千万不可搞得头脑昏沉，身体虚弱，或者伤害自己或他人的平静或声誉。
13. 谦卑。
    效法耶稣和苏格拉底。

对孟鼎铭（Bill McDermott）的传记有兴趣，当然部分原因是想了解一下我司掌门人。作为销售出生的他，成为了SAP第一个非技术背景的CEO。与富兰克林的波澜不惊不同，这本书从头到尾都洋溢着满满的激情，读完也让我对销售的世界多了一点儿了解。

出身蓝领工人之家，又有几个弟弟妹妹，比尔从小就很想着如何赚钱了，从11岁开始当了报童，每天早上六点送报纸，他似乎就已经开启了一段商业赢家的人生，不知疲倦地奔忙着。十六岁时同时打着三四份工，十七岁还是个高中生时，就已经盘下了一家加油站附近的便利店，开始正式创业了。光看到这里，我就咂舌不已，想想我的中学时代都在做什么呢？能够主宰我悲欢的无疑是考试成绩，此外无非就是找时间看看小说，人生的最高目标不过定格在高考。如此一比较，无怪乎他是老板，我是员工了。

大学毕业后，比尔进入梦寐以求的施乐公司当起销售，之后凡是他所在的团队，必定年年都是销售冠军，彻底开始了全力奔向CEO的开挂人生。

要说我从比尔的传奇经历中学到了什么，那主要有两点：一是激情，敢于梦想、敢于相信自己、并且能够带动整个团队的激情；二就是勤奋，从送报开始，比尔就已经在努力追求自己想要的东西了，正如他自己说的，送报的经历、经营便利店的经历，都是他日后成功的垫脚石。做好眼前事的同事，他的心中一直有着更大的梦想，为了这个梦想，比尔时刻不停地奔跑着，安逸从来都不会是他的选择。

自己当上金牌销售也许简单，而要带领从十几人到几百人的团队超额完成任务，或带领整个公司实现预期目标，就不是那么容易了。这本书里，比尔很仔细地分享了他的心得和技巧，也分享了自己做出每一个决策的心路历程。从进入施乐的第一天，比尔的梦想就是当上CEO，在四十九岁时，他果真成为SAP的联席CEO。这本书的最后一个部分用简短的篇章回顾了当上CEO近十年来SAP的变化，这也正是我进入公司的十年。比尔在全体员工大会上说过一句话：

“世界上有很多公司在自己很强大的时候，发展很顺利的时候，没有想到要主动变革。我们不想成为那样的公司”。

希望我们能够走得更好吧。

过年在家果然是腐败堕落得一塌糊涂，虽然妈妈的晚饭基本能控制量少且素，无奈饭局实在太多，光火锅就连吃了三四顿，真是一个典型的中国年。

锻炼不够努力，开始上班后琐事颇多，读书也不够用心。一九年的开年各种不利，从国家到公司到家庭，似乎都面临着巨大挑战。其他不敢奢望，只希望能够尽力度过难关，不负这一年的韶华吧。

有一天午饭聊天，说到小孩的补课狂潮与父母的教育焦虑，连外国老板都大呼现在的小孩负担太重，要学得东西太多，没时间玩。我还以为这只是中国高速发展的产物呢，看来连发达国家的人也逃不脱这个套路。

拿英语举例子，现在幼儿园里口语流利的小朋友多得很，老板问我们：“你们当时是几岁开始学英文呢？”回想一下，五年级时我也曾跟风补了几天英文，但完全不得要领，唯一的收获只是认得了26个字母，知道了abc歌的英文发音跟一直唱的拼音歌是有区别的。真正开始学会英文的句子，就是初中时大家都熟悉的李雷韩梅梅教材了。但是，英文起步晚也曾是我的一桩噩梦，当初上了第一堂英语课就立马崩溃，怎么其他同学统统对答如流，而我下课后打开英语课本就跟天书一样，一句话也记不起来了呢！也许正因为成了后进生，让我不得不对英语格外用功，天天跟着磁带反复练习，认真对待老师留的作业，不久就没有那么大的压力了。

老板又问我们：“你们现在不是好得很么？为什么要对小孩那么焦虑呢？”作为三个孩子的父亲，我不知道他是不是真得能够做到不焦虑，但作为没有小孩的我，料想自己是做不到的。为什么呢？很简单，我当时并不需要跟幼儿园就开始学英文的人竞争。虽然从小地方来上海读大学后见识到了大城市孩子的实力，也深深认识到差距，但还是挺庆幸身边也有不少跟我一样“后进”的人陪跑。假若我当初都是跟现在毕业的小朋友们一起面试，那我肯定进不了现在的公司，不说别的，英语这关就过不了。

换句话说，如果是今天的我面试到十年前的我，那大概是不会招的。这是不是能说我现在招的人能力就都比自己强呢？有，但也不全是吧。即便我知道，英语只是诸多能力中的一个，不能代表一个人的全部，但当有那么多英语更好的人可选择，当我遇到一个英语不那么流利的人，便不会再费神去了解其他方面的能力了。

英语是这样，其他方面也是一样，如果大家普遍都有“特长”，那么没有的人就变成了“特短”，这当然不代表这人学习能力差，或不是好员工，然而，这个“特短”的能力总还是需要在某个时间补回来，否则就会拖后腿。

这个现象其实很正常，就像我们现在不用再学吟诗作对，但一定要掌握英语电脑，每一代的孩子都有自己必做的功课，跨代的比较本就不现实。没有人想按上一代的标准养育小孩，反之，大家都想参照未来的标准做准备，既然没人知道未来的标准是什么，尽力多做一些看起来就是最好的选择。

教育焦虑，大概无法破除，从古至今都一直存在。假若想让小孩日后有更多的择业选择，那就需要多准备一些技能。但别人眼里的“好工作”毕竟不是生命最重要的目标，它未必能带来一段幸福、快乐的人生。

那么，如果要让孩子做一个幸福的人，应该培养哪些能力呢？这个问题想必见仁见智，英语和电脑就未必位列其中了。幸福的能力不是几门课程可以教授的，这是太复杂的问题，但复杂不代表没有解法。我们虽然不能定义幸福，但可以说，健康的身体和心灵会让一个人更容易获得幸福。怎么培养健康的身体和心灵？这就有很多培训可以开展了。再比如审美能力、交往能力、团队合作能力等等，这些能力很难直接学会，但在完成其他活动的过程中可以得到锻炼，这不是又多了很多进课外班的理由么。

作为成年人的我们，恐怕都会时不时冒出“我要是会XXX就好了”的念头，做了父母之后肯定就想让小孩尽量少一些这样的遗憾。其实，这样的遗憾不可能避免，往往是学得越多，才越会发现自己的无知。在人类发明出芯片植入学习之前，恐怕永远都逃不脱教育焦虑这件事，即便有了即插即用的芯片，软技能也不可能马上获得，还是需要很多的锻炼和培养。只要还有竞争存在，小孩们的课外班大作战，应该就不会终结吧。

如图，最难过的一段时间，莫过于刚刚结束假期回到工作岗位。

2019挑战很多，希望我不再懒惰拖拉，比去年更能坚持。

29号回家，毫无意外进入了大吃大喝模式，除了嘴不停，其他基本哪里都不动…… 1月的最后一天，终于做了次运动。回顾一下第一份月度手收账：运动12次，完结了4本书。希望在家的假期中能坚持学习和运动，不要胖太多……

回顾下四本书：

《第五项修炼》，讲学习型组织的管理经典，学到很多新概念，特别是 系统性问题分析 和 反馈循环，可惜看了理论也并不能锻炼出一双慧眼，只能哀叹自己还没有书中描述的洞察力和解决问题的能力。

《非暴力沟通》，名声在外，改善沟通技能的实用指导，我却犹豫了很久才开始看的一本书。确实值得一读，但也吃不准改如何实践。

萧红的小说《生死场》，很多时候有点儿心不在焉，不然可能会更受震撼。两点体验：1，萧红的文字着实独一无二，无愧鲁迅先生的赞美。2，我还是更喜欢长片小说，读短篇总是很难入戏。

《大规模Scrum》，LeSS应用指导，蹭同事的一本新书。有很多实用的例子和理论，融汇贯通了很多敏捷的知识，对我来说是个不错的加深复习。

针对管理和scrum master，分别推荐了一些书单，对scrum master列表里的几本比较有兴趣，coaching技巧到底如何才能提升？总感觉不得要领，太困难了。

读到第七章 产品，也很有启发，特别是产品跟项目的区别，产品定义的步骤：

####7.1.3 指南:定义产品
决定当前的产品定义和未来潜在的扩展是LeSs采用中的一个重要步骤。这通常需要在早期不间断的讨论中或在专门的研讨会上来完成。
我们首先探讨扩展力,然后探讨约束力。采取的步骤如下。

#####步骤1:尽可能广泛地扩展产品定义
无论当前产品如何,请提出以下有关产品定义扩展的问题：

• 如果我们问最终客户"我们的产品是什么?"他们的回答会是什么?
  此问题可消除组织内部对技术性产品的关注,增加对客户方面的关注。
• 我们是否有共享组件或跨当前产品的相同功能?
  此问题有助于寻找可能会成为一个产品系列的产品。
• 我们的产品是什么的一部分?产品为最终客户解决了什么问题?
  这些问题可帮助发掘你产品所属的较大产品或系统。

#####步骤2:根据实际情况约束产品定义
通过提出以下问题来探索约束力：

• 什么是产品愿景?顾客是谁?产品的客户域是什么?
  这些问题探讨了产品中一定存在的共性。
• 哪些开发在我们公司内部进行?多大程度的结构变化是可行的?
  这些问题探讨了产品定义的组织结构边界。

#####步骤3:确定初始产品定义
将广泛的产品定义(步骤1的结果)与实际的产品定义(步骤2的结果)进行对比,探讨什么是理想的、未来的产品定义。要做到这一点,需要做出哪些改变?
这些步骤的输出便是初始的产品定义及其未来的扩展想法。

11.1.7 如何分解代办列表条目

14.1.5 培养系统思维

#DevOps实践指南

【美】Gene Kim; Jez Humble; Patrick Debois; John Willis

####导言：展望DevOps新世界

在制造业革命前，制造厂的平均交货周期为6周，能按时交货的订单不到总量的70%。随着精益实践的广泛实施，到2005年，产品的平均交货周期缩短到3周以下，按时交货的订单超过总量的95%。而那些没有实施精益实践的厂商，不但渐渐失去了市场，有的甚至破产了。

公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现。 这种冲突造成了一种恶性循环，阻碍了业务目标的实现，不但波及IT公司的内部，而且还会影响外部。这些长期冲突常常导致技术工作者交付出质量低劣的软件和服务，打造出糟糕的客户体验，每天都要采用临时解决方案、应对紧急情况。以上情景在产品管理、产品开发、QA、IT运维和信息安全管理中不断上演。

正如软件开发高管和早期的DevOps记录者之一Christopher Little所说：“每个公司都是科技公司，无论他们认为自己处在哪个行业。银行也只是拥有银行执照的IT公司而已。”

####2.2 限制在制品数
正如《看板方法：科技企业渐进变革成功之道》的作者David J. Anderson所说：“停止开始，开始结束。”

####2.6 消除价值流中的困境和浪费
浪费和困境是软件开发过程中导致交付延迟的主要因素。 下面是该书中描述的关于浪费和困境的部分类型。

• 半成品
• 额外工序
• 额外功能
• 任务切换
• 等待
• 移动
• 缺陷
• 非标准或手动操作
• 填坑侠
  我们的目标是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标。

####4.2 将日常工作的改进制度化
《精益企业》的作者Mike Orzen说：“比日常工作更重要的，是对日常工作的持续改进。”

####6.3.3 为非功能性需求预留20%的开发时间，减少技术债务
为非功能性需求预留20%的开发时间，减少技术债务。
Marty Cagan指出，如果组织不愿意支付这“20%的税”，那么技术债务将会最终恶化到耗尽所有可用资源的程度。

####第7章 参考康威定律设计组织结构
康威提出了著名的康威定律。他指出：“系统设计受限于组织自身的沟通结构。组织的规模越大，灵活性就越差，这种现象也就越明显。”

####7.3 组建以市场为导向的团队（“速度优化”）
为了实现以市场为导向，不需要进行自上而下的大规模重组，那样往往会造成大范围的破坏、恐惧和停滞。相反，将工程师及其专业技能（例如运维、QA和信息安全）嵌入每个服务团队，或者向团队提供自助服务平台，其功能包括配置类生产环境、执行自动化测试或进行部署。

####7.4 使职能导向有效
尽管看似诱人，但其实无法通过重组的方式获得持续的改进和适应性。起决定性作用的并不是组织形式，而是人们的行为和反应。

####7.5 将测试、运维和信息安全融入日常工作
一个经典的案例是Facebook。2009年，Facebook正经历着飞速的增长，同时在代码部署方面也遇到了重大问题。虽然并非所有问题都会直接影响到客户，但团队始终处于没完没了的救火状态中。生产工程总监Pedro Canahuati描述了这样一次会议：与会人员全是运维工程师；有人提议除了正在处理故障的人以外，其他所有人都合上笔记本电脑，但是没有一个人能做到。

为了提升部署效率，Facebook采取的最有效的一个措施就是让所有工程师、工程经理和架构师轮流值班，负责他们自己构建的服务的运维工作。

####7.7 投资于服务和产品，而非项目
不幸的是，对于成功的产品或服务而言，初始阶段是成本最低的阶段。

####7.8 根据康威定律设定团队边界
在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。

####9.2 应用统一的代码仓库
相比于对代码进行版本控制，为什么对环境进行版本控制能更好地预测IT效能和组织绩效呢？ 实际上，几乎在所有情况下，环境的可配置参数都要比代码的可配置参数多出好几个量级。所以，环境最需要使用版本控制。

####9.3 使基础设施的重建更容易
Bill Baker是微软的一名资深工程师。他曾有一番妙语，称我们过去对待服务器就像对待宠物：“我们给它们起名字，并在它们生病时悉心照料。现在，我们对待服务器更像对待牲畜：给它们编号，在它们生病时把它们干掉。”

####第13章 降低发布风险的架构
这就是演进式架构原则，正如Jez Humble所说：“任何成功的产品或公司，其架构都必须在生命周期里不断演进。”

####13.1 能提高生产力、可测试性和安全性的架构
另一个例子是Google Cloud Datastore，它是世界上最大的一个NoSQL服务，但其支持团队只有大约8个人，这主要是因为它是构建在一层层可靠的基础服务之上的。”（见图13-1）

####13.3 安全地演进企业架构
通过创建绞杀者应用，可以避免运用新架构或新技术复制已有功能。现有系统本身的特点使得业务流程变得过于复杂，因此复制现有流程不可取（通过研究用户，往往能够重新设计业务流程，用更简单的流程来实现业务目标）。

####15.1 用均值和标准差识别潜在问题
标准差的常见用途是，定期检查数据集的某个度量，如果与均值有显著差异就告警。例如，当每天未经授权的登录次数比均值大三个标准差时就告警。只要这个数据集呈高斯分布，我们就预计只有0.3%的数据点会触发告警。

####15.2 异常状态的处理和告警
Tom Limoncelli是《云系统管理：大规模分布式系统设计与运营》的作者之一，也曾是谷歌的站点可靠性工程师。他讲述了以下关于监控的故事：“当人们问我需要监控哪些对象时，我开玩笑说，在理想的世界里，我们会删除目前监控系统里所有的告警。然后，在每一个用户业务中断以后，我们会问什么指标能预测这个中断，然后再把这些指标加入到监控系统中，并根据需要告警，再不断重复上面这一过程。这样，我们就只会收到预防中断的告警，而不是在故障发生以后遭到报警信息的轰炸。”

####16.2 开发和运维共同承担值班工作
为此，我们会让开发人员、开发经理和架构师轮流和运维团队共同值班，就如Facebook的生产品工程总监Pedro Canahuat在2009年所做的一样。这确保了价值流中的所有人能够就他们所做的上游架构和编码决策得到直接的反馈。

以上实践还帮助开发管理人员意识到，每一项产品功能都标记为“完成”并不代表业务目标已经实现。相反，所有功能都在生产环境中按照设计正常地运行，没有引起重大的故障，也没有引发计划外的运维或开发工作，才是真的“完成”。

####16.4 让开发人员自行管理生产服务
这种机制对于运维人员来说就像是减压阀，它确保运维团队不会陷入这种境地：不得不管理脆弱的服务，同时技术债务不断累积，局部问题扩大为全局问题。这一机制还有助于保障运维部门拥有足够的能力去开展改进工作和预防性项目。

回传这一实践在谷歌由来已久，也许这是开发和运维工程师互相尊重的最佳体现。

谷歌的很多实践都是令人称奇的，其一是他们对运维工程师有一个职能定位，即“站点可靠性工程师”（Site Reliability Engineer，SRE），

####18.1 变更审批流程的危险
建设高度信任的文化可能是未来10年最大的管理挑战。

####18.2 “过度控制变更”的潜在危险
传统的变更控制可能会导致意想不到的后果，例如延长交付时间，降低部署过程中反馈的强度和即时性。丰田生产系统的核心理念之一是“最了解问题的人通常是离问题最近的人”。组织越依赖变更审批，它在稳定性（平均服务恢复时间和更改失败率）和吞吐量（部署前置时间、部署频率）方面的表现就越差。

####18.6 利用结对编程改进代码变更
Hendrickson很快注意到，许多组织能正常地执行代码评审，他们靠的是一种文化，即认可评审代码的价值不低于编写代码的价值。当尚未建立这种文化时，在过渡时期，结对编程可以作为一种宝贵的实践。

####第19章 将学习融入日常工作
这就像Steven Spear博士所说的“可恢复型组织”，能够“熟练地发现问题，解决问题，并通过在整个组织中提供解决方案来扩大经验的效果”。这些组织具有自我愈合的能力。“对于这样的组织，应对危机并不是什么特殊的工作，而是每时每刻都在做的事情。这种响应能力是可靠性的源泉。”

####19.1 建立公正和学习的文化
学习型文化的先决条件之一是，当发生事故时（这是毫无疑问的），对待它的反应要“公正”。正如Etsy首席技术官John Allspaw所说：“我们在Etsy的目标是从学习的角度看待错误、报错、失误、过失等。”

####19.4 降低事故容忍度，寻找更弱的故障信号
我们所做的全部工作都是潜在的重要假设和数据来源，而不是重复的例行公事或对过去实践的验证。不能将技术工作看成是完全标准化的，力图实现流程合规。相反，必须持续不断地寻找越来越弱的故障信号，进而更好地理解和管理运维中的系统。

####19.8 小结
正如Peter Senge所说：“组织唯一的可持续竞争优势就是比对手更快的学习能力。”

####22.6 确保软件供应链的安全
作为开发人员，“我们不再编写自定义软件，而是组装所需要的开源组件，这已经成为我们非常依赖的软件供应链了”。

报告里有如下惊人的发现： 一个典型的组织依赖于7601个构建工件（即软件供应商或组件）并使用18 614个不同版本（即软件构件）； 在这些用到的组件中，7.5%存在已知漏洞，其中超过66%的漏洞已经存在两年以上，并且尚未修复。

讨论到敏捷或DevOps转型，很多人都会问这个问题，在敏捷转型的过程中，团队经理应该扮演什么样的角色，是不是需要先接受培训？经理不懂敏捷的话团队还能转型么？很多情况下，经理们可能都是团队里最忙的人，要想抽出两三天时间参加敏捷培训非常困难，想通过自学变成敏捷教练也不现实。那么就把转型的任务交给其他人吧，指定一个负责人或教练，让此人全权代办，岂不省事。这么做到底行不行呢？从我的经验来讲，是不推荐的。

其实，为一项工作或一个项目指定负责人的做法是很正常的，任何团队里都不可能靠一个经理管着所有事，那敏捷转型有什么特殊之处，为什么不适合这么做呢？其实刚开始，我自己也有这样“偷懒”的想法，既然自己不大懂，又没空学，最简单的法子就是交给组里的积极分子，授权给他们来做，而我只要定期了解下情况，提供一些帮助就行。

做着做着，问题就来了。敏捷转型不但耗时长，执行起来也颇复杂，几乎不可能照搬现成的案例，必须要根据团队自身的情况制定计划，并随时调整。转型本身也是小步快走的敏捷过程，不能期望做好了瀑布式的规划就可以按部就班地执行。在这个过程中，转型负责人肯定需要和作为经理的我讨论计划、调整方案、争取支持和帮助。如果我自己并不了解敏捷，该怎么决断呢？其实这样的问题在工作中也不少见，很多时候我们的决策都依赖于其他更专业的人士，自己不懂没问题，只要交给懂的人做就行。如果我找到的负责人足够靠谱，提出的计划跟办法都是对的，而我要做的事只是表示支持，让他放手执行就好，这听起来多么容易，会有什么不妥呢？

不妥之处就在于，敏捷转型跟其他项目不一样，它牵涉到团队的方方面面，从团队文化、沟通风格、考评指标，到具体的任务分配与执行，可能都需要做出一些调整和改变。让一个团队改变既有习惯，培养新的做事方式，本就是非常不易的一件事，在这个过程当中必须投入很多精力引导大家，发现问题及时纠正，有了进步随时鼓励，还要能捕捉到每个人抵制或赞同背后的原因，因势利导。如果团队经理在这个过程中帮不上忙，只能依赖教练，那么难度本身就会增加。更差的情况是，如果团队经理自己的思路没转换，仍以旧方式指导团队工作，没让大家看到变化，那么其他人就更没有改变的动力了，转型的具体操作也就更难推动。

指定一个转型项目的负责人并不错，能有外部或内部的敏捷教练帮忙更好，但最能带动团队积极性的，其实还是经理。要想促进团队敏捷转型成功，经理一定要做到身体力行，先从自己开始学习和改变。只有让团队看到经理的做事方式发生了改变，大家才能更有动力跟上来，也更愿意发挥主观能动性，为转型的过程出谋划策。如果经理本身既不学习也不实践，只做个“精神支持”，那么转型这件事，在大家眼中就很容易变成一项不明就里的任务，只会被动地配合而已。

诚然，并不是每个经理都得先变成敏捷教练，才能带领团队走好敏捷之路。但在一个好的团队里，必须达到从上到下一致的认识。敏捷转型不是一部分人的事，必须是整个团队共同的目标，而团队经理，是完成这个目标必不可少的一环，自己不改变，很快就会成为阻碍转型的瓶颈，而不是整个团队的加速器。