《SAFe Distilled》作者访谈

敏捷 SAFe

摘要

《SAFe Distilled》一书将复杂的框架分解成易于理解的解释和可操作的指南，从中我们可以深入理解及学习如何实现“大规模敏捷框架（Scaled Agile Framework）”。

正文

本文要点

• 《SAFe Distilled》一书面向的是所有参与SAFe或重大精益-敏捷转型的从业者、领导者和高层管理人员。
• 敏捷宣言在大规模敏捷和SAFe领域蓬勃发展，在构建大型系统时，其价值和原则重新体现出了重要性。
• SAFe的基础是获得授权的自组织敏捷团队和“敏捷团队的团队（teams-of-agile-teams）”。
• SAFe是一个可以满足所有企业需求的可配置框架。它为积极参与解决方案开发的各级别组织提供指导——团队、项目、价值流、项目组合。
• 领导人员是精益-敏捷转型的主要角色。他们还要借助专门为此设计的理念和活动，引领规模化持续改进过程。

《SAFe Distilled》一书将复杂的框架分解成易于理解的解释和可操作的指南，从中我们可以深入理解及学习如何实现“大规模敏捷框架（Scaled Agile Framework）”。

InfoQ读者可以下载《SAFe Distilled》的样书。

InfoQ采访了Richard Knaster和Dean Leffingwell，了解从SAFe的视角如何看待敏捷扩展，企业如何应用SAFe，敏捷宣言在大规模应用时是个什么样子，如何为团队授权及提供局部决策支持，如何预测和估算大型的复杂系统，如何实现敏捷转型，如何支持企业的持续改进。

InfoQ：你们为什么要写这本书？

Richard Knaster：Ben，这个问题很好，而且很有趣，人们经常会问我们这个问题。我们写这本书是为了帮助人们和企业在一个变化从未如此之快的世界里取得成功。事情的发展如此之快，人们都来不及反应、改善并快速响应，以便通过技术的进步成为现如今数字化经济的真正玩家。即使他们做到了，他们经常还是不知道什么需要改革以及如何改革。SAFe的网站很棒，但它是供人们根据需要随机访问的，面向的是那些为了完成工作需要即时获得信息的人。为了了解SAFe，得阅读我们知识库里的许多文章，一篇又另一篇。这本书将复杂的框架分解，编排成了一个完整的故事，并提供了易于理解的说明和实践指南。但是，我们都知道，组织变革很难，需要采用新的行为方式、领导风格、实践和文化。《SAFe Distilled》提出了新的实施路线图，可以加速精益-敏捷转型，为转型的每一个阶段提供指导。由于SAFe是一个大型框架，我们决定用一整个章节概括介绍获得大多数好处的十个基本要素。

Dean Leffingwell：对于那些构建世界上最重要的系统的人而言，SAFe是一个广泛的在线知识库。它不是一个小框架，因为人们使用SAFe构建的系统也不是小系统。但是，知识库仅仅是知识库，因此，它没有讲述一个故事或者自我总结。为了让人们可以全方位地深入理解SAFe，我们希望提供一份更简短易读的指南，对那些知识进行总结，从而使从业者可以更好地理解SAFe是什么，它建立在什么原则之上，它提供了什么实践方法，以及最终如何实现SAFe。

InfoQ：这本书面向哪些人？

Leffingwell：技术高管、负责人、项目经理、从业者，即那些希望可以更快地构建出更大更好的系统的人，那些想要把最新最现代的方法应用于解决方案开发的人——现如今，人们在企业范围内应用的精益敏捷实践就是这样的方法。

Knaster：这本书面向多类读者。它帮助负责人和高管了解SAFe业务场景：它的优势、它解决的问题以及如何推动大规模的精益敏捷转型。它帮助项目经理理解自己作为精益敏捷负责人的新角色，让团队通过学习和培训了解SAFe的精益敏捷原则、理念和系统思维，从而能够构建出更好的系统。它帮助敏捷团队学习如何更快地交付价值，内建质量，改进工作流，取得更好的业务成果。最重要的是，它帮助所有读者了解什么是SAFe，为什么企业需要它以及如何利用它的原则、方法和价值。

InfoQ：从SAFe的视角如何看待敏捷扩展？

Knaster：SAFe将敏捷、精益产品开发及系统思维融合在一起实现了扩展。它实现了策略和执行的一致，从项目组合到敏捷团队，反之亦然。SAFe可扩展性的基础是敏捷发布序列（ART）。本质上，ART是一个敏捷项目，它包含5到12个敏捷团队，他们全都在一起协作，像一个团队，有共同的使命、愿景和项目待办事项。

如果你正在构建的方案需要成千上万的人作出贡献，你只要发起更多的培训，协调他们遵循相同的模式和类似的角色，从而协调多个敏捷团队。当面制定计划及完整的系统演示程序有助于保证协作、一致性和快速适应。ART构建并维护着一个持续交付管道，用于定期开发和发布增量较小的价值。借助精益UX原则和实践，ART提供了常用的、一致的用户体验方法。ART使用了面向新特性开发的、构建-检测-学习假说驱动的方法，它被设计成了一个持续创新引擎。可扩展性的另外一个方面是SAFe的DevOps方法CALMR（文化、自动化、精益流、管理和恢复）。毕竟，只有解决方案发布到市场或生产环境时价值才得以实现。DevOps是实现可扩展性及提升价值流速度的重要助推器。

Leffingwell：作为敏捷实践者，我坚信，“没有什么胜过敏捷团队”，除了向着共同的使命努力工作的“敏捷团队的团队”。SAFe是在自组织和跨职能敏捷团队的基本范式下提出来的。参与过的人都知道那些好处。但是，团队敏捷不会自己扩展。我们开始的时候不是要“扩展敏捷”或“构建一个框架”，我们只是希望帮助人们构建更大的系统，尽享敏捷开发的好处。只是它演化成了一个功能齐全的框架。

InfoQ：SAFe有多少层级？敏捷企业通常如何运用？

Leffingwell：嗯，3个或4个，这要看你怎么数了。团队和项目层实际上只有一层，一个敏捷团队的团队，被称为“敏捷发布序列”。但是，我们还是要把它们构造为两个层，团队和项目，因为关注点多少有些不一样，而且，那样会让指南更容易组织和理解。那些层构成了我们所谓的“基础SAFe”，四个开箱即用的配置之一。

• 项目组合层关注的是策略、资金投入、项目组合流、精益创业思维、敏捷项目指南和精益治理。
• 大型解决方案层为真正构建大系统的人提供指导。

Knaster：对于积极从事解决方案开发的企业，SAFe在所有的层级上提供了指导——团队、项目、价值流和项目组合——同时，它还提供了“基础支撑要素”和“广度面板（spanning palette）”。SAFe的可配置框架提供了足够的指导，可以满足产品、服务或组织的需求。简单起见，企业可以从Essential SAFe开始，随着时间推移，终有一天会具备随需求发展演化的能力，如增加Dean前面说过的项目组合和大型解决方案层级。

InfoQ：敏捷宣言在大规模应用时是个什么样子？

Knaster：“敏捷软件开发”宣言为软件开发人员提供了一种激动人心的全新思维和工作方法。不过，大多数原则也可以运用到软硬件兼有的大型综合解决方案的开发上。在实施SAFe及教授SAFe课程中，我们了解到，敏捷宣言实际上是可扩展的。举例来说：敏捷原则#11的表述为“最好的架构、需求和设计来自于自组织团队”。虽然大多数人都同意这个原则，但它依赖于你对团队及决策议题和范围的定义。通常，局部决策最好。毕竟，那是SAFe原则#9的一部分——去中心化决策。不过，它也提供了什么时候集中化决策最高效的经济学原理。最重要的是，今天，敏捷宣言的重要性还和它被定义出来时一样。我们很幸运有这样一个宣言，它在随SAFe扩展时发挥了关键的作用。

Leffingwell：那是我们在每堂课上都会做的有趣练习。几乎每个团队都认定，敏捷宣言的价值和原则在构建大型系统时更有用。例如，谁会在构建大型的任务关键系统时对“可工作的软件”、“可持续的开发节奏”、“面对面交流”、“简单性”和“良好的设计”等持有异议呢？实际上，它们甚至更重要了。是的，围绕“欢迎需求变化”（例如，设想一下，在卫星发射之前数天）或者“……胜过文档”（设想一下，如果没有提交规范的文档，是你要去坐牢）总是有些细微的差别。但是，SAFe依赖敏捷宣言的大量实践方法和它们所带来的各种好处。我们是2001年那份文件的重度粉丝。如果你不相信敏捷宣言的价值系统，那么你就无法实现SAFe。

InfoQ：怎么给团队授权及提供局部决策支持？

Leffingwell：可以归结为一种新的精益敏捷领导力理念。这包括了解精益和产品开发流程，恪守敏捷宣言。没有什么灵丹妙药，那是一次旅行，而不是一个目的地。自学精益和敏捷开发，致力于终身学习，这是唯一的方法。SAFe总是从领导力训练开始，因为，如Deming所言，“只有管理能改变系统”。

Knaster：以可支撑的最短提前期交付价值需要去中心化决策。任何决策都必须上报到更高层级的管理部门会降低交付速度。此外，决策升级会降低决策的效果，因为缺少局部信息，而且情况可能在等待期间发生变化。SAFe的原则#9是促成去中心化决策的关键。其方法是集中化频率低、持续时间长、提供显著规模经济的决策。其他所有的决策通常应该去中心化。另一方面，每个人都应该成为充分发挥人们能力的领导者。David Marquet是一名退役的潜艇艇长和作家，他在著作《Turn the Ship Around》中做了很好的总结，“领导力不是选择少数几个高层。在高效的组织中，每个层级都有领导者”，我最喜欢的一句话是，“控制，收获随从；放权，收获领导者。”

InfoQ：如何预测和评估大型的复杂系统？

Leffingwell：敏捷评估和规划的基础是历史，而不是工作分解结构。不过，大型系统必须分解成较大的部分，以便于工作评估。在SAFe中，团队使用史诗、特性和故事，而它们都使用故事点作为唯一的计量单位。那不是非常精确；只是总体上更符合实际。人们在学习如何在大规模敏捷场景中做出更好地评估和规划时有一个重大的发现，就是他们可以使用传统的方法。

Knaster：没有可以用于大型复杂系统的水晶球。评估就是猜测，我们不应该因为制定过分详细的计划而陷入困境，自己欺骗自己，误以为计划越精确就越符合实际。Dean在前面说过，SAFe提供的评估和规划机制已经证明，它们比历史上使用的那些传统的方法更可靠。

InfoQ：你们有什么实现敏捷转型的建议吗？

Leffingwell：像这样的转型，要想成功就只有领导者真得发挥领导作用。就像Deming所说的那样，“他们必须知道自己必须做的事情是什么。”

Knaster：我非常赞同Dean对于领导者在敏捷转型中的角色的表述。根据我的经验，领导者是成功转型的最重要的决定因素。实行转型变革，如转而采用精益敏捷的工作新方法，对任何企业而言，都需要付出巨大的努力，承担巨大的风险。我们有一句简单的真言，如果照办常常会成功：“培训每个人，启动多个敏捷发布序列（Train everyone and launch trains）。”也许，这句话十分精炼，很容易让人记住，它是这本书中首次引入的“实施路线图”的基础。该路线图描述了12个步骤或者“关键动作”，企业可以按照这些步骤实现有序、可靠的SAFe滚动。该路线图完善了John P. Kotter的开创性工作，论述了他所提出的引领变革的8个步骤。

InfoQ：在企业里，为了支持持续改进，可以做些什么？

Knaster：持续改进始于理念的变革，组织里的每一个人都要致力于持续改进，争取更好的结果。持续改进是SAFe精益屋的支柱，精益敏捷领导者可以不断地制造变革改进的紧迫感。团队各自回顾，检查调整ART活动及价值流，这些是持续改进的基石。此外，针对SAFe的每个层级，SAFe提供了多种可用的精益指标以及自我评价工作表。SAFe还有许多其他支持持续改进的方法。例如面向Scrum管理员和发布序列工程师的高级培训，采用内建质量实践，实现精益敏捷卓越中心和实践社区，建立精益敏捷项目组合管理、敏捷HR和价值流映射，等等。

Leffingwell：“持续改进”是SAFe精益屋的支柱，因此，这在每个人的理念中都是必不可少的。这一点，具体的实践可以说明。例如，除了团队的迭代回顾，我们还会在每次项目增量完成后召开SAFe的检查调整研讨会。这是按计划举办的意义重大的活动，团队和项目经理聚在一起，分析根本原因，采取纠正措施，针对他们当前面临的问题制定计划。每次会议结束，他们都会得到一个行动清单，该清单直接加到了项目的待办事项列表中下一天的计划活动里。这样，在某种程度上，持续改进是有计划性的。检查调整就像是加强版的团队冲刺回顾。

关于作者

Richard Knaster是一名作家、SAFe研究员兼Scaled Agile公司首席顾问。他有30年的软件开发经验，做过开发，也当过高管，至今，他已经从事精益敏捷开发将近20年了。

Dean Leffingwell是一名作家、连续创业者兼软件开发方法学家，他获得了广泛的认可，被公认为是软件开发的权威。他是大规模敏捷框架的创建者，出版了许多关于软件开发的著作。

查看英文原文：Q&A on the Book SAFe Distilled