《引领转型》访谈录

Gruver ： 决定写这本书是基于这样的考虑，我们想帮助那些试图改进他们组织内开发过程的其他高管们。工程师们有非常多的途径去学习最潮的软件开发方法，但如果管理者们没有培养出一个适宜的环境来实现那些来自工程师们的激情电光火石的话，这些激情终会受到组织变革的阻力而窒息。因此，管理者需要去理解所必需的变化之处，理解在引领或支撑改进中他们的角色。我们希望我们自己在最初引导大规模转型前就已经知道书中所说的一切，我们写这本书的目的就是为了和大家分享这些，这样其他人就不用煎熬地重复接受同样的教训了。

Mouser ： 我们决定写这本书是因为在过去的几年里，在大型企业级开发团队里兴起了一股应用精益敏捷开发方法论的潮流。虽然对于大团队和小团队来说，这些方法当然都是富有成效的，但我们也发现其中许多工具和流程在被应用到大型组织之前需要进行修正，这样才能最大限度地发挥出它们的益处。举个例子，对于大型的、地理上分散的团队而言，他们所需要的管理持续集成（CI）活动的工具就和坐在同一个房间里的由6个工程师组成的小团队很不一样。我们在最初尝试将敏捷方法应用于企业级软件开发的时候，发现几乎获取不到什么可用的信息关于如何去处理好这部分问题，最终我们只有不停地去试验，从错误中学习。Gary的第一本书记录了我们所做和所学到的一切。这本书是这些教训经验的延续篇，面向那些在他们的组织里支持和支撑实施敏捷方法的企业管理者们。我们的目的是给他们提供路标，以帮助指引他们完成这一转变。这个路标基于我们的经验，我们希望可以给他们提供一些我们的教训心得，帮助他们在步入转型时拥有一个恰当的期望。

Mouser ： 我认为一个大型组织更常碰到的问题是，他们想将独立的开发团队和质量管理团队糅合进一个组织里，并应用敏捷，而不是让他们整个组织和流程变得敏捷。举个例子，很多大型开发组织设有程序管理办公室（PMO），在过去PMO和市场部门会参与到一个瀑布型流程，在这其中他们规划下一年的软件项目并筹得经费。作为规划的一部分，要求开发团队对项目进行量化，进而估算出项目经费。这一流程的结果是锁定了下一年的经费和高层级的需求。然后把项目交给开发团队，并希望他们既做到“敏捷”，又不要超出在工作实际开始之前就已经大致划定好的范围、时间表和预算。所有这一切的结果就是组织中的一部分使用了瀑布型流程而其他部分试图使用敏捷。正如你可能已经料想到的，这不可避免地导致了冲突，而这正是典型的管理者所要解决的问题。

凸显出诸如此类的情形，提醒管理者们应当整体地看待其所在的组织机构，在变革历程中对这类陷阱保持完全清醒的认识，是我们编写本书的目标之一。

Gruver ： 对每一个大变革来说，最大的挑战是组织变化管理以及变革人们的每天日常工作。另外，在大组织里一个典型的最低效之处在于协调不同团队的工作以向客户传递价值。而且大多数组织只在团队级别应用敏捷流程，而不是应用基本的敏捷准则，持续改进、优先级划分以及定期向客户提交代码以获得系统级的反馈信息。他们说服高级管理层向敏捷转变，在小部分原型团队中引入敏捷教练一起参与工作。一旦这些团队展现出了敏捷的有利之处并定义好了组织内的每个人该怎么开展工作，如何去正确实现它不过是一个培训就可以解决的问题。随着时光的推移，他们开始意识到他们仍然面临着跨团队协作的大问题，这时他们开始思考如何解决公司层面的问题。

这种方法容易忽视以下事实，即跨团队的协作问题通常是导致大组织低效的万恶之源，应当在一开始的时候就解决这个问题。同样被忽视的事实还包括，如果对新工作方法有一些投入参与和所有权，那么人们会更愿意迎接新工作方法带来的改变。尽可能地，应让人们在制定好的计划中留下自己的一笔，这样他们会有动力确保自己成功实现预定目标。这对最初数量较少的原型团队很适用，它们是为所在组织定义如何敏捷工作而存在的，但当这些方法向外全面推广时，这条原则和其它团队经常会脱钩。如果想让管理团队帮助自己成功达成规划，就要让管理团队也参与规划，这点的重要性也被忽视了。大多数变革从顶端管理者批准开始，然后由敏捷教练与团队一起开始执行。这种做法直接从中间跳过了管理层链，除了告诉他们团队将要做这做那，然后管理层的工作只是站在一旁表示支持就好了。这可能看上去很便利，不过随着时间的推移你将开始意识到这样做会引起明显的变革阻力。相反，我们会建议你从一开始就将整个管理团队都包含进来，与管理人员一起，协调所有重要的跨团队改进以及领导书本中描述的持续改进过程。在向外推广的时候，应给予其它团队在自身工作过程尽可能多的灵活性，这样他们会把成功当做是自己的事情。强制的共性只有在跨团队协作时才被要求，同时别忘了在其它每一处提供尽可能的灵活性。

Gruver ： 从我的观点来看，保持对持续改进流程的学习和调整是敏捷最为重要的准则。每一次变革、每一个开发过程以及每一个组织在迈向效率和效益的途中都会碰到独一无二的挑战和障碍。因此，需要不停地检查你的产品开发流程，识别出最大的改进机会点。一旦定出了问题的优先级并解决了它，你需要继续探寻和解决下一个最大的问题。如此持续不间断的改进过程将使得你采摘到在大规模变革中可能结出的业务果实。请一个敏捷教练，让你的团队实施scrum流程，这样做还不足以交出一份合格的成绩单，不如聚焦于你所在组织的具体挑战然后实施持续改进。

Mouser ： 将整个组织的工作置于持续集成流程下，有助于你对客户的反馈或竞争压力保持更为快速的反应，因为流程中的每一部分，从想法形成到传达给客户，都是扁平化的。使用CI流程还能让你快速找到并交付给客户一个最精简的可行方案，而不用把时间花在其它功能上，这些功能可以在后面晚些时候再交付。

Mouser ： 在大型企业组织内的确尤其如此。大型企业组织常会有许多在地理上分散的团队，团队之间的目标和目的也互不相同。这就是为什么开展和管理基于一系列易于理解且文档化的业务目标的持续改进项目是势在必行的。比如说，你也许想增加50%的特性产出能力，这样你就能为客户更快速地创造新特性和新功能。在这样的目标牵引下，各个团队可以衡量他们目前的产出能力并应用新流程和新工具来提升他们的产出能力。除此之外，作为组织内的高级管理者，将有一系列围绕着产出能力的指标可供其衡量。这将帮助高级管理者找出瓶颈所在，进而聚焦于瓶颈上。

关于这些指标的使用，Gary在他的两本书里都着重强调了一点，指标任何时候都不应成为“敲打”瓶颈团队的棍棒。相反，指标仅仅是一个指示器，指出哪些地方是你应当去了解情况的。你常会发现，处于瓶颈状态的团队在处理的问题远远超出它们的直接控制范围，他们需要你作为高级领导进入广阔的组织里去解决问题。

Gruver ： 你的经验让你觉得大组织的持续改进会很艰难，这挺有意思。在我的经验里，对一个领导着大组织的管理者来说，持续改进是相当明确和容易的事情。你只需写下你的月度优先项，分享给组织内的其他人，在该月里跟踪进度，在每个月的末尾设置检查环节，回顾一下哪些项已经做了，哪些项还没做，总结本月的工作并为下个月设置目标。如果你正在领导一个组织，将发现这是非常直接的事情，对我来说这些再正常不过了。

当我与越来越多的组织共事过后，我发现更困难的地方在于让一个跨组织的团队（开发、QA、运维、行政、业务）的管理者们参与到公共优先集的流程引导中来。我希望在这本书里能提供给他们一种通用的语言和方法，帮助他们走到一起来引领变革。如果这还不够，那我还将通过举行研讨会来对其管理者和组织，让管理人员开始引导持续改进流程，不过本书对大多数管理者而言已然够用。如果拥有在这个层次上对齐并参与的高管们，我确信持续改进会是相当自然直接的。让高管们支持、参与并开始投入是最难的部分。

Gruver ： 我们使用的流程方法如前所述，我的工作人员负责领导全球范围内的数以百计的工程师，并达成我们月度迭代中优先项的一致。这些优先事项将同时包括业务交付件和持续改进成果。一旦我们达成了目标的一致，我们的注意力就完全放在这些优先事项的执行上。工程师们都知道，如果他们手头有什么事情是在优先事项列表上的，或者其他人有活在列表上而他们又可以帮上忙的，那这就是他们排名最靠前的优先事项。如果他们自己已经没有待处理的优先事项了，他们可以在他们所属团队的优先事项上发力。自顶向下的变化协调和自底向上的努力在这里得到了一个很好的结合。

管理团队在我们迭代期间扮演调查记者的角色，设法弄明白为什么我们感觉已经把事情以及为什么我们的顶级优先事项没有完成。我们会花些时间去和组织的每个人进行沟通谈话，去更好的理解障碍因素。我们会和那些没有完成分配任务的工程师进行交谈，去弄明白其中的原因。我们这样做不是要去问责他们为什么没有完成任务。相反，我们会这么表达，我们都认同这件事情很重要而且可以做成，但是最后这事还是没有做成，那没有做成的原因是什么呢？其中发生了什么？通过这样的处理流程，我们首先弄清楚阻碍达成目标的最大问题，这样在下一个迭代我们优先清除障碍项。

老实说，作为一个管理着超过800名开发人员的管理者，当我和没有完成目标的工程师进行沟通时，起初几次是有些吓人的。过了段时间，他们开始意识到，我是在帮助他们确定阻碍问题的解决优先级，我们之间开始具备一定的信任度了。信任度带来了透明度，而透明度又进一步提高了解决问题的能力。很多人在谈论与DevOps相关的文化转变，但几乎给不出具体实在的例子。但愿这能成为一个开端，展示出管理者通过参与持续改进流程能在助力组织引领文化变革方面扮演一个积极的角色。

Mouser ： 当一个大型组织决定向敏捷开发方法转型时，大多数高级领导会有这样的倾向，即在做完决定后就脱离了各项日常活动。他们以为中层管理者和基层管理者这时对方向已经明了，然后自然而然就能达成目标。多数情况下，这导致组织的不同部门在做不同的事，但他们以为所做的事能让他们变得更敏捷。他们采用的各种不同的工具和流程，但彼此之间可能都不能兼容。

在这一转型过程中，高级管理者应更密切地参与进来。在每一个迭代规划和回顾环节，作为转型的掌舵人，他们应当围绕着组织已经对齐的原始业务目标去分析相关的指标。如果在这些目标上没有取得进展，高级管理者们应当去探求其中的原因，到底是什么阻碍了业务目标？这样做了，往往就会发现一些存在的问题，尽管从表面上看它们好像和敏捷转型丝毫不相干。比如说，也许团队需要更多的虚拟机，因为构建和测试的过程是同时进行的，而在等待测试结果的时候，开发们无所事事。

Gruver ： 我们一开始就非常清楚我们变革的业务目标。在过去的几十年里，固件部门一直是激光打印机业务的瓶颈，为了帮助企业在市场上实现差异化，我们一直挣扎于添加各种新功能。所以我们的业务目标就是保证公司能够往我们的产品线上添加新打印机，而不用担心固件是否支持，以释放创新能力。归根结底这取决于生产效率。我们审视了每一个占用制造周期或耗费的事情，如果对我们的业务目标而言不是关键所需，那么我们的处理方式就是，要么把它做成自动化，要么将它从系统中排除。这样做有助于我们聚焦在持续改进流程上，让大家都能为业务增添最有价值的东西。聚焦于业务目标以及不断地持续改进，最终给我们带来了巨大的进步。

Mouser ： 在每个月度迭代周期的末尾，就上一个迭代中大家做的怎么样，全体管理方面和技术方面的领导团队会碰头一起讨论。我们审视每一个我们设定的目标以及完成的情况。对任一个我们没能完全完成的目标，我们都会问为什么，其中的阻碍是什么。通过该流程，我们得以快速地找出安插在我们流程中的无用浪费以及低效活动。每个月我们都会识别出最严重的阻碍项，进而为下一个迭代的工作排出优先级，以求改进或消除阻碍项。几年下来，重复进行这样的月度处理，并且我们总会列出流程改进的待办项，就这样我们变得更优秀了。以上流程方法有效是因为技术组最高级别的管理者直接参与了上述讨论，并就解决问题设定优先事项当下做出决定。

Gruver ： 这个问题有点难回答，因为这取决于你如何定义DevOps。一开始我认为DevOps不过是和文化转变有关，让开发和运维能更棒地一块工作，持续交付就是创建一个自动部署的通道。随着时间的推移，DevOps在业界的势头已经变得越来越猛了，我又开始听到一种说法，DevOps被定义为以更快的节奏向客户发布代码为基础，包括了所有的技术上和文化上的转变，同时还要保持质量、安全性和性能的不变或是提升。我努力不让自己被那些名词给绕晕，哪个是哪个之类的，如果没有恰当的技术上和文化上的转变，那些难以理解的定义好的业务目标其实根本就无法完成。

如果你管理一个小型组织或者甚至一个拥有松散耦合体系结构的大型组织，在这类组织里，存在彼此隔离的小规模开发团队、质量团队和代码部署团队，只要你再给团队配置一名运营人员，并要求他们更紧密的联合工作，我猜你就能做到以更频繁的节奏提交有质量保证的代码。就我工作过的大多数大型组织而言，现实是他们有非常多群组的员工工作在紧耦合体系结构下，开发、质量和部署方面若发生任何变化，都需要去协调其它方面同事的工作。如果没有提供一个完好定义的、结构化的和严密完整的持续交付通道，协调工作是不可能做好的。另外，如果组织没有好好利用新系统，没从日常工作细节处进行改变，只定义一个完善的持续交付通道不会有太大用处。在一个有着紧耦合体系结构的大型组织里，仅有文化是不够的，如果文化上没有转向利用新系统的话，技术转变所带来的益处也将是有限的。因此，真的需要同时做好DevOps和持续交付，或者在你的定义里，DevOps应至少同时包含这两部分的内容。

Mouser ： 我认为管理者在推动转型到持续交付的过程中，能做的最重要的事情是保证他们的组织在整体上对齐，然后朝转型努力。只是简单地告诉开发团队，要做到分支代码可发布，这是不够的。所有相关的团队必须简化他们的流程。如果你的市场营销团队得花上6个月时间去做调研和客户调查，然后才能告诉你市场需要什么，那你永远也做不到真正意义上的持续交付。每个人必须在小规模的想法上对齐，然后通过持续集成这一过程，将引入的增量改变展现给客户，这样你就能获得实时反馈，并基于该反馈不断调整你的战略。

Gruver ： 他们应当先读这本书，书能赋予他们广阔的视野，尽览成功转型的全貌。他们还应当让尽可能多的同事也读这本书，以尽可能地为领导团队提供共同语言和共识。然后下一步是澄清转型的业务目标。如果当前的开发和交付流程已经能满足业务目标，就不应实施敏捷或者DevOps。变化与混乱已然太多，在需求能满足的情况下就不必再大动干戈了。对许多像激光打印机业务这样的公司来说，它们的问题在于，软件对业务的重要性在不断提高，而当前的开发过程已力不从心。如果正在读这篇评论的管理者恰好碰到的就是这样的问题的话，我会建议他们从理清转型的业务目标开始入手。在获取组织的支持、优先改进分析和持续进度展示上，这都用得上。

继之的下一步则取决于，在促使你的职员或者同事加入你，和你一起引领持续改进过程中你的角色定位。一旦你有了一个团队，管理及技术领导力联合起来，识别出第一个迭代的目标，然后持续不断的执行这个过程，往后就会越做越好。

Gruver ： 在我的工作内容中，我们强调，测试自动化将作为其中最大的目标之一。它对于我们的成功非常重要和关键，这点大家都同意。我们定期回顾状态和进度。总是向前看，想做更多的事情，想做得更好。开诚布公地说，每次我回顾那些我们曾经挣扎奋斗的时刻，我注意到就技术及管理领导力而言，我们积累的还不够。如果在开发和质量保障上没有一个强有力的领导力的话，是不可能搞出一个坚实稳定的、可维护的自动化测试框架的。也许一直以来我所面临的最大挑战就是将强大的开发技术天赋转化到创建测试自动化框架中去。看起来不好玩，也不妙，但如何将软件开发成功地转过去却又是极其重要的，需用采用可靠的方法，将手下优秀的开发和质量保障人员放到一起工作，在这一过程中，我不能认为你能避免上述问题。展望未来，我常感到我好像在测试自动化上投入了很多。回首过去，我却常意识到在面临的问题前面我马力不足。

Mouser ： 我认为在测试自动化上我学到的最重要的东西之一就是，在它正常工作时，才会带来了真正的价值，为了实现测试自动执行，你必须将流程上的每一步都自动化实现。给你相同的代码构建集，你必须得能精确地复制出你将要在测试时用到的环境。如果任意一个由你构建提供的，或者由你部署的过程还是手工完成的，那么首先你得解决这个问题。比如说，如果你在提供硬件过程时，有时候把你的软件部署在8 CPU的虚拟机上，有时候又把它部署在了4 CPU的虚拟机上，这时你的自动化测试结果可能会相差很大，而你又无法简单地解释清楚原因。在8 CPU系统上跑通过的测试用例在4 CPU系统上可能就超时了。你的团队要花很大的时间去定位分析这些跑失败的用例，但这些和刚签入的代码没有任何关系。

为了让自动化测试能正常工作，你必须有一个完全可重复和可信赖的构建、提交和部署流程。首先着眼于此，然后再去构建你的自动化测试套件。

Mouser ： 我给高级管理者的建议就是参与转型，并保持持续不间断地参与其中。你不用成为一个软件专家，但是你的业务管理技能对确保转型成功而言非常重要。不要忘记正在做的转型是为了达成某些具体的业务目标。你的技术团队可以指引和驱动那些需要完成的细节工作，但是你要让他们以及其他的业务合伙伙伴（运维、PMO、市场等）聚焦在他们想要达成的业务目标上，确保组织内的每一个人都在做出迎接成功的到来所需的改变。

Gruver ： 目前为止最大的挑战在于组织变革管理。要怎样才能使每一个人都参与进来并朝着一个共同方向前进？还有，要怎样才能获得业务侧的支持，将锯子磨得更锋利，而不是把你的资源都浪费在使用一把钝锯上面？在计划上取得每一个人的支持和参与非常重要，它能帮助你在后续中避开阻力。让工作变得尽可能的透明和包容需要一段时间，这是一段漫长的旅途。如果每个人都是团队的一份子，每个人都觉得他们有某种能力去影响方向，就凝聚人心和协力转型而言，将会是有帮助的。