今天是吴言老师的专访，他给我们详细的讲述了项目管理中的规模化敏捷，几个规模化敏捷模式在使用中的对比，以及和ACP的区分，ACP学习的适用方向，非常的干货，我们一起往下看。
吴言老师
北京航空航天大学项目管理工程硕士；
10余年IT相关从业经验；
曾供职于大唐电信、中国石油、中国电信等顶级企业IT线、经验覆盖了**、*队、能源、影视、工控、物流等不同行业，有大型系统产品的运营和维护性需求、实施交付、运行维护经验，有管理型产品的专家顾问经验，初创产品的策划和设计经验，以及软件产品的交付组织管理经验；
作为内部顾问，主导了隆正信息内部的SAFe转型并完成了案例梳理；
作为演讲嘉宾参与TiD大会、中国软件技术大会、TiD大会、PMI中国大会。
01.初始敏捷
Q：吴言您好，非常感谢您百忙之中抽出时间来参加我们《敏捷人CLUB》的专访，您是敏捷进中国后的第一批践行者，对于敏捷的理解和实践肯定都非常的丰富，今天主要想和您聊聊这几大块，第一、您是什么时候接触到敏捷的；第二、谈谈关于规模化敏捷和ACP之间的一些看法，包括您现在的一些实践情况等？
吴言老师：大家好，我是吴言，很高兴有机会给大家分享我对于敏捷的理解，希望对于你们有用。
其实我们现在谈起敏捷，还是有很多场景会谈到敏捷项目管理的交叉场景，我在念项目管理工程硕士的时候，当时就已经看到这个领域了，但是，当时我自己不知道后面会不会用到这个地方。然后16年的时候，学组织级项目管理，机缘巧合，一并去进修了一下敏捷方向的课程，这样的话，从那时候，就从纯粹的项目管理方向变成了敏捷项目管理双方向。
紧跟着就被朋友问到了一个问题，敏捷下我们怎么做项目群管理，就这样17年就参加了国内首批SAFe敏捷框架本土培训，这样，我就彻底走上敏捷这条路了。
敏捷这个事，对于在中国的实践水平来说，我当时应该算起步比较晚的。因为真正的敏捷软件的开发实践，像我们经常说的极限编程、结对编程、做个持续集成，做小批次交付，最早实现这些东西的人，国内圈子早到03、04年，就已经有人在接触了。
敏捷宣言是01年提出来的，在03、04年，就有人以“敏捷”的概念来接触敏捷了，而不是单纯的做一些有效的做法。相比起那些前辈来说，我是非常晚的学习者，但我非常有幸，赶上大规模敏捷框架进中国的契机，然后成为了首批国内的参与学员，通过努力完成了国内的第一个官方发布的案例，所以，在这个角度上来说，我在这些跟我同批的敏捷的这个学习者来说，我是幸运的。
Q：那后来加入之后，您对这个东西是怎么产生兴趣，并且一直坚持到现在，一直在这一领域的？
吴言老师：因为敏捷本身跟我们“传统”的项目管理的做法和思路是完全不一样的，因为在敏捷里边，我们不谈人和人之间怎么设立层级，怎么通过管控的手段去管理，不谈怎么去运用权术，相反的，它是我们大家共同营造一种团队共赢的气氛，由团队氛围的打造者营造一种向上的氛围，然后让大家产生一种工作的热情，它是这样去工作的。
在这种环境下，我们又能经常看到我们的产出，能经常看到产出的改善，团队士气因此进一步提升，这种做法，会给人一种由衷的喜悦感。我接触敏捷之后，就觉得这个是比我之前研究的项目管理这套东西，更适合我去追寻的方向，就这么坚持下来了。02.规模化敏捷与ACP
Q：那您这边跟我们谈一下，规模化敏捷，包括ACP，这两块东西的运用，以及实际工作当中的一些好处吧。
吴言老师：ACP这个认证本身，对敏捷一线实践者来说，就是为我们去打造一个非常良好的知识基础。因为ACP他不是一门单一的知识认证，它是一个知识合集的认可，它包括的是什么？它包括的是在那些经典所提出的年代，也就是敏捷宣言诞生的年代，高效的软件工程实践者们所遵循的一些良好实践。那些良好实践，放到现在，有可能我们国内没用过，或者说我们已经不这么用了，或者我们有更好的做法。
认证里的知识集不是为了让我们照搬的，但是ACP给大家最大的帮助是，你理解有敏捷的存在，你理解敏捷它最初提出的时候是什么样子。你能在一个非常广泛的范围之内，去建立对敏捷认识。
相比起市面上另一个流行的敏捷的基础认证，CertifiedScrumMaster认证，ACP的特点是，它把知识讲的比较全，就是你不会局限的认为，敏捷就是我在做Scrum或者是Scrumban，或者是Scrumban极限编程。（CSM认证本身并不给人这样的认知，但是面试官面试那些只认证CSM的纯Scrum实践者的时候可能会导致这样的误解。）你不会有这样一个先入为主的认知。
你会了解到，敏捷是一种思维方式，在这种思维方式之下，我们有一系列可用的工作模式，那这些工作模式有些是实践，有些是框架，实践性的，比如说极限编程，包含12种或者13种做法，然后再比方说Scrum，它是一种指导框架，你可以按照他的这个框架，参考这个去运行。
ACP会给大家一个非常全面，稳固的一个基础，学完后你对敏捷的基础是非常牢固的，但是有一点，ACP的考试跟实践之间的鸿沟，比PMP考试跟国内项目管理实践之间的鸿沟，其实还要稍微大一些。
这里面有几方面的原因，一方面，ACP因为要兼顾大量不同的敏捷实践，所以他并不特定聚焦在哪1到2种实践方式上，但实际上我们在企业里落地的时候，我们其实是要选择我们需要的实践集合的，所有为什么国内一说敏捷，大家做的要么是Scrum，要么是看板，用户故事，然后极限编程里边的少数实践，比如说小批次交付，还有条件允许的话大部分人会推持续集成。
那为什么大家都这么在推，因为这个东西可以“做”，这个东西比较明确，这个东西你能做出看的见的改变，但实际上这不是敏捷的全部。这个东西靠什么去弥补呢，这个东西靠另外一个东西，就是机构给大家讲解，每个机构的老师，他发现ACP的这个知识框架本身，存在着这种零散不够结构化的遗憾，所以培训机构的讲义上，会帮助学员去弥补，就是帮你把整个的这件事梳理成一个完整的，你能理解的，跟项目管理更加接近的这样一个状态。
这样比较好类比嘛，跟据原有的实践，然后从ACP到Scrum，团队级Agile到SAFe框架，当然我不只擅长SAFe一个框架，我至少还擅长Scrum
Scale框架，并且我对所有的国内市场上提到的框架，都或多或少有些了解，那在这个广泛的知识之上我对大规模敏捷跟我们在ACP里面讲的敏捷的认知，我的理解是什么呢？我理解说，ACP就是带你进入这么一个状态，告诉你，敏捷可以是怎么样，告诉你团队可以是怎么样。这是最初的敏捷能带给我们的。然后，我们现在在谈的大规模敏捷，尤其是我擅长SAFe框架。SAFe框架的立足点在于，如果你的小团队敏捷了，那你的企业将如何运作？这是两个完全不同层级的东西，这两个层级差的真的比较多。中间你至少跨越了几个层次。我们敏捷在课程上，一般会学到5到11人的小团队，然后中间会有一个稍大一点的团队，以往的课程里边会讲，scrumofscrums。你用这种方法，把多支小团队组成一个大团队。
但是当多支小团队组成的大团队，比如说我们建立待办事项列表，具体的待办事件跨层级的时候该怎么处理，Scrum上没有特别说明，它只是告诉你，你可以这么去跑，但是，具体怎么跑，原版Scrum上面说，它依然是Scrum，就没有了，那你需要自己去为它做填补。
SAFe跟它形成的鲜明对比就是，它的里面有一个非常完整的操作手册，在外企里边叫Playbook的东西。它会有一个完整的玩法说明书，包括什么层级的人，做什么样的事情，然后什么的人在哪方面统筹，帮助大家去建立一致性消除分歧。
5到11只小团队组成一个敏捷发布列车，我认为比较大型点的团队，完成一个稍大一点儿的产品，他就是这种交付。但这个在我们ACP的课程里面，我们是建立不起来这么清晰的一个概念的，而且从ACP的课程到内部的应用过程，除了团队的规模不一样以外，他其实还有一个内在的跃迁。
在ACP里面，5到11人小团队，然后如果你有能力的话，你的团队自组织做的好的话，你可以组成稍大一点的团队，可以对它进行扩展，一切依赖于你自己的能力和理解。SAFe里就会简单很多，你5到11人，然后10到人，然后多团队，搭一层级出来需要怎么样的沟通、人员延伸、联动机制，照着操作手册，结合一些关键指导就扩展出去了，可以直接按照价值流，把不同的业务方向组织起来了。
所以，我们在ACP里边，我们看到的是一些面向交付的东西，有点像PMP，指导“项目”交付。（当然这可能是我自己的一些认知的局限）我认识的ACP带给大家的东西，更多的是一些我们怎么用敏捷的的方式，达成更好的交付，但实际上我现在在讲的已经不只是怎么达成更好的交付的问题了。
围绕价值达成更好的交付本身，很好，但还不够，我们要企业从这种敏捷的方式的交付，从单点的改善里面，形成企业整体获益的局面，这个是我们在SAFe里面，最为关键的作用。
对SAFe在市面上充满了各种非议。批评者认为，SAFe把它做得太复杂了，失去了简约性，失去了优雅，而且，这个东西看起来太自上而下了。实际上，我自己，学习和践行这么多年SAFe之后，知道SAFe其实根本不是这样说的，SAFe也没有说，你就定在大图的那个样式；或者说如果你做到大图了，你就SAFe了。其实这个不是它的本意。它只是说，如果要成为一家精益经营的企业，你要借由这样的一种组织形式，你要找到自己如何去实现业务的敏捷性。
这点我们在小团队的敏捷里边其实是解决不了的问题，因为，最初提出的敏捷是解决什么问题的？最初提出的敏捷是因为，当时最早签敏捷宣言的那17个人里面，有人对轻量级软件开发方法这件事，感觉到心中不安，觉得应该避免直接使用轻量级这样的词，所以他们选了一个词叫敏捷。
所以，以往的敏捷，或者说在软件开发行业者里面，那个比较纯粹的敏捷，它是一种基于轻量级的思想，更好地去交付、更好地去围绕价值去进行交付的这么一种心智模式、思维模式，然后遵循这种心智模式有一系列的这种交付实践。
但我们现在社会需要的，不止是你怎么去解决软件交付的问题，你还要确保这种交付是真正有商业价值的。什么叫商业价值，你不止要上线，你上线之后，还要让你上线这个成果能卖钱。你不光这次能卖钱，而且我还希望你能持续的卖更多钱。我希望你的商业模式构建在你的敏捷的这个成果之上。
那这时候，你该怎么去持续的创新、持续的改善收益，这是我们从SAFe框架里面获得的更有价值的东西。有批评者认为他不够纯粹，但对于企业来说，去拥抱这样的思想其实更加务实。
03.SAFe、LeSS、DAD的对比Q：那您觉得他跟LeSS比起来，有什么区别呢？这方面的话，因为很多学员对这方面其实不懂，因为现在产品好多个，不只是SAFe一个。
吴言老师：你问了一个很好的问题，因为所有的框架里面，就属LeSS和SAFe打的时间最长了，其实这就是对一个问题的不同解，LeSS的宗旨是什么，它的宗旨是我们要尽可能的去解耦，我们要尽可能地去降低系统之间层级的复杂性，我们尽可能地去减少这种依赖关系，围绕着价值做精简的这种设计，然后在这种精简的组织设计的思想之下，提升你的交付价值，优化你的价值实现过程。
LeSS当然也可以不止局限于技术环节上，但是系统工程的这种思考方式，确实是开发等类似工作者会比业务工作者更容易理解它的设计理念。
那相比SAFe就完全是我们在大型的企业里面，我们要怎么样把它的层级结构转化成一种柔性的治理结构。对于经营者来说，他若是到治理这一步了，其实把企业的层级瞬间打散是个很危险的行为。经营者看SAFe和LeSS，就是两者在解决完全不同的问题。
LeSS在执着地降低复杂度；而SAFe应用的点在于，对于很多企业来说，一下子消除复杂度是不可能的，那我怎么样在容许复杂度存在的基础之上。我给你一种方式，让你不用去正骨（根本性地打破组织设计）也能享受到一定程度上敏捷带给你的改善。这两者基于的思想，还有他们涉及的范围是不一样的。LeSS有直接支撑的更多的还是产品交付，而这个SAFe它已经将手触及到企业经营的方方面面。
Q：我们不能说它谁好谁坏，两个东西其实都有各自的特色。
吴言老师：没错，有些地方我们该瀑布的还得瀑布，比如说我修万里长城，我敏捷一下，可能不会有什么特别的收益，再比如，我们有10万亩的树林要栽，它可能也不会有特别的收益。所以SAFe里讲过这么一个问题，说我们企业里边有两种决策类型，一种可能是很长时间才决策一次的，或者是这个决策一旦下了之后，我们可以几年不去大幅度的调整的，又或者是，做这个决定的时候，你的规模越大，越合算，比方说你是集中采购还是零散采购，像这几种情况下，我们不一定要去做那种所谓的去中心化举措，因为这个时候有非常明显的规模效应。
所以没有一个解决方案是完美的，没有一个解决方案说用我这个解决方案，你就能解决所有问题，这是肯定的。在行业里面传得最广的就是，诺基亚的“敏捷之路”，诺基亚是LeSS诞生的地方。但是就是这样，诺基亚在有一段时间之内，他发现LeSS在它的有些条件上，解决不了它的问题了，他们也（局部地）转向过SAFe，后来又走了SAFe几年之后，他们发现规模继续扩大的时候，SAFe也不能特别好的解决它的问题了，于是他们又转向了一个自研的一个方法。
所以，在大规模敏捷这个路上，就跟我们聊所有的管理话题一样，管理有对错之分吗？管理从来没有对错之分，管理只有适用不适用，框架有好坏吗，没有绝对的优劣，它只有谁适应这种场景之分。
Q：那吴老师还有一个DAD（DisciplinedAgileDevelopment）您了解吗?这东西跟前面差别在哪里，也希望您帮我们科普一下。
吴言老师：我们一般把它翻译成规范敏捷，然后规范敏捷开发这个内容，我跟那边也有联系，他们从SAFe的阵营里面，拉了一员大将过去，美国有一个非常著名的人，叫AlanShallowy。他们把这个人从SAFe的阵营，拉到DA的阵营。Al早年间，在SAFe上也做了不少贡献，作为两边都有比较深度了解的意见领袖，他对DA跟SAFe做了很多的对比。
然后我们从现在的这个局面上看，现在对DA的了解和对SAFE的理解上看，SAFE是给企业画了一个完整运行的蓝图，相对来说一种模式化的蓝图，而DA说我就干脆不给你预设，我不跟你预设你的运行框架是怎么样，我就纯粹给你提供一个工具箱，我保持敏捷本身的纯粹性，我不做过多的假设，我也不用那么强烈的跟Scrum强绑定的这种角色称呼，那DA要解决什么问题？它的这个理念就是想要更加务实的去解决问题。
我们发现其他框架都有偏差，我们发现其他框架的实施结果的适用性都有局限。作为DisciplinedAgile来说，我们希望回避这些局限，我们希望大家不要掉到一个非此即彼的状态中去，大家不要被一个特定的东西套住。
与此相反，我给你提供一系列的能力——也就是我们这几年在项目管理或者敏捷上都特别爱说的赋能——我去赋能你，我给你提供一系列的工具箱，提供一系列的路线图，我通过这个来赋能。我让你有能力去规划，我们的敏捷应该是什么样，我们的敏捷运行秩序是什么样子，我们的敏捷开发里边应该注意哪些关键点等。
Q：它其实是整合了一些模型、模式这些东西，然后精减一下，然后让你根据这块地方模型去套用，然后再把它改变成自己的模式，它其实是这个意思，包括很多工具，它等于是一个BOX感觉，这个直接给你一个案例加BOX，是吗？
吴言老师：据我所知，以前的DA首页也有个大图，然后现在的DA已经不去强调它那个全景图，不去强调它那个模型了。我们知道，SAFe有一张大图，然后LeSS有一全景图，Nexus有自己的一个全景图，然后Scrum
Scale有一个双环图。相应DA以前有一个多层级的图，但是现在DA已经不把这个东西放在