带你读《SAFe 4.5参考指南:面向精益企业的规模化敏捷框架 》之一:SAFe基础-阿里云开发者社区

开发者社区> 华章出版社> 正文

带你读《SAFe 4.5参考指南:面向精益企业的规模化敏捷框架 》之一:SAFe基础

简介: SAFe精益–敏捷领导者是终身学习者和老师,他们通过理解和展示精益–敏捷思维、SAFe原则和系统思考,帮助团队构建更好的系统。本书提供了一套在企业的投资组合、价值流、项目群和团队各个层面的完整的工作指南,包括构成框架的各种角色、活动和工件,以及价值观、理念、原则和实践的各种基本要素,并针对SAFe 4.5和SAFe 4.6进行了更新。

敏捷开发技术丛书
点击查看第二章
点击查看第三章
SAFe 4.5参考指南:面向精益企业的规模化敏捷框架
SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises,Second Edition

image.png

[美]迪恩·莱芬韦尔(Dean Leffingwell)等著
李建昊 陆媛 译

第1章

SAFe基础

1.1 精益 – 敏捷领导者

管理层仅仅承诺质量和生产率是不够的,他们必须知道自己应该做些什么。这项责任是不能委派给其他人的。
—— W. 爱德华兹·戴明(W. Edwards Deming)
摘要
精益 – 敏捷领导者是终身学习者,他们担负着成功采纳 SAFe 并实现交付成果的责任。他们通过学习、展示、教授和辅导 SAFe 精益 – 敏捷原则与实践,授权和帮助团队构建更好的系统。
SAFe 的哲学理念很简单:作为团队的推进者,精益 – 敏捷开发方法的采纳、成功运用和持续改进的最终责任是由企业的经理、主管和高层管理者来承担的,只有他们可以改变和持续改进大家所使用的系统。因此,领导者必须接受培训,并成为培训师,用学习者的方式思考和处理问题。正如戴明所说:“这项责任是不能委派给其他人的”。许多采纳 SAFe 的企业需要采用一种新的领导风格,也就是真正的教导、授权和激发个体成员与团队发挥他们最大的潜能。
详述
SAFe 精益 – 敏捷领导者是终身学习者和老师,他们通过理解和展示精益 – 敏捷理念和 SAFe 原则,帮助团队构建更好的系统。这些领导者采取如下的行为。
#1——引领变革
引领一个组织向精益 – 敏捷的行为、习惯和成果进行变革的工作,是不能委派给他人的。然而,精益 – 敏捷领导者要表现出变革的紧迫性,与大家沟通这种紧迫性,为成功进行转型创建一份计划。领导者必须理解和管理变革的流程,当问题出现时及时进行处理和解决。采用原则#2——运用系统思考,是SAFe实施路线图成功的关键。
#2——知晓方法,强调终身学习
创造一个促进学习的环境,鼓励团队成员与客户和供应商建立关系,并给团队成员更多的展示空间。努力学习和理解新的开发方法,包括精益、敏捷和现代管理实践。建立和培养正式及非正式的学习与改进小组。博览群书,扩大阅读的广度,与他人分享阅读观点,并在相应的环境中发起读书俱乐部活动。
允许员工自己解决问题。帮助员工识别问题,理解根本原因,找到解决方案,并且提供组织支持。当员工和团队犯错误的时候,为他们提供必要的支持,只有这样才能做到持续学习。
#3——发展员工
采用精益的领导风格,专注于开发团队成员的技能和职业发展路线,而不仅仅是作为一个技术专家或任务协调员。创建一个对成功共同负责的团队。学习共同解决问题的方法,同时发展员工的能力,增强员工的参与和承诺。尊重员工和企业文化。
#4——鼓舞和遵循使命,最小化约束
通过最小化的、明确的工作需求,实现使命和愿景。去除那些消极的政策和流程。基于价值构建敏捷团队和版本发布火车。理解自组织、自管理的团队。创建一个安全的环境,让大家学习、成长和相互影响。为每个价值流构建一个经济视角的框架,并教导企业中的每一个员工。
#5——去中心化的决策
(更多信息可参考 3.9 节)
建立一个决策框架。通过设定使命、发展员工、教授问题解决等,对团队进行授权。领导者主要负责制定和传达战略层面的决策,这些战略决策通常不会经常发生,一经制定将会持续相当长一段时间,也会对经济收益产生重大的影响。除了这些战略层面的决策,可以把其他决策授权给团队利用去中心化的方式进行。
#6——释放知识工作者的内在动力
(更多信息可参考 3.8 节)
理解薪酬在激励知识工作者中的作用。创造一个相互影响的环境。消除任何可能导致内部竞争的基于目标管理(MBO)方法。改造人员评估体系以支持精益 – 敏捷原则和价值观。提供使命感和自主性,帮助员工实现对学习新技能和提升已有技能的掌握力。应用敏捷人力资源(HR)的原则和实践。
开发经理的角色
SAFe 与精益和敏捷开发的原则是一致的,所强调的价值观包括:尽可能自治、自组织、跨职能团队和敏捷发布火车(ART)。SAFe 支持一个学习型管理组织架构,它包括得到授权的个人和团队、快速和基层的决策。在这种环境下,以往在传统方式中对员工每天具体活动的指导就不再需要了。
然而,员工仍然需要有人帮助他们进行职业规划,设定和管理期望和薪酬,并提供积极的辅导,以提高自身的技术能力、业务能力、个人和团队协作能力,以及有效的职业目标。认识到所有的员工同样有权利成为高绩效团队中的一员。
自组织的 ART 并没有获得独立的财务预算,也不能独立定义自己的使命。因为它是实现战略的一个要素,所以这仍然是一项管理责任。在传统的方式中,以上大部分责任是由开发经理这种传统角色来承担的,在采用了精益 – 敏捷开发方法后,这些责任其实并没有消失。然而,在 SAFe 中,这些责任就落到了那些在新的环境中能够适应、调整和成长的人身上。
责任
开发经理(或是负责系统开发的工程经理)是一位管理者,他能够展现以上提及的精益–敏捷领导力的原则和实践。此外,管理者负有对其直接下属进行辅导和个人职业发展的责任,也应负责消除障碍,并积极地参与到员工的系统开发工作中。他们对于价值交付负有终极责任,以下是对于开发经理责任的总结。
人员和团队发展

  • 吸引、招聘和留住有能力的员工
  • 建立高绩效团队,为员工和团队建立使命与目标
  • 指导员工的个人职业发展
  • 倾听和支持团队进行问题识别、根本原因分析和决策
  • 参与制定和管理员工的福利、补贴和晋升制度
  • 消除障碍并参与系统开发和实践,支持精益 – 敏捷开发
  • 对于团队人员分配进行巧妙的控制,处理团队无法解决的问题,必要时引导个人的改变
  • 评估绩效,包括团队的输入;提供管理者的输入、指导和纠正措施
  • 作为团队的敏捷教练和顾问
  • 一方面保持与团队足够接近,从而可以为团队提供帮助,成为一名胜任的管理者;另一方面与团队保持适当的距离,为团队留出空间,让他们自己解决问题

项目群执行

  • 帮助建立敏捷里程碑和路线图,以及团队建设的计划
  • 帮助开发、实现和传达经济有效的框架
  • 参与检视和调整工作坊,通过帮助清除系统的障碍和实现持续改进待办事项条目以支持团队
  • 保护团队免受不相关和不必要的干扰
  • 协助发布火车工程师(RTE)和解决方案火车工程师(STE),进行项目群增量(PI)计划准备会议,以及 PI 计划前、后会议
  • 参与 PI 计划会议、系统演示和解决方案演示
  • 建立与供应商、分包商、咨询顾问、合作伙伴、内部和外部利益相关者的合作关系
  • 为团队和敏捷发布火车(ART)提供必要的资源,从而成功实现其愿景和路线图
  • 巩固和强化基本型 SAFe 的实践
  • 通过引导和参与价值流映射来识别系统中的延迟

协调一致

  • 与发布火车工程师、解决方案火车工程师和系统的利益相关者协作,确保战略主题的统一和有效执行
  • 与系统架构师/工程师、产品经理、产品负责人(PO)协作,建立清晰的内容权威性
  • 不断地协助多个团队,保持系统使命和愿景的协调一致
  • 帮助确保业务负责人(BO)、共享服务团队和其他利益相关者的参与

透明

  • 创造一个“事实友好性”的环境
  • 提供自由和安全,让员工个人和团队能够自由创新、实验,甚至偶尔失败
  • 与所有的利益相关者进行开放和坦诚的沟通
  • 确保待办事项列表和信息雷达对每个人都清晰可见
  • 赋予生产力、质量、透明度和开放性比内部政治更大的价值

内建质量

  • 针对软件、硬件和固件,增量式采纳内建质量的实践
  • 理解、教授或发起技术能力开发,从而支持高质量的代码、组件、系统和解决方案
  • 培养实践社区(CoP)
  • 理解、支持和应用敏捷架构及精益用户体验(UX)

参考资料
[1]Liker, Jeffrey and Gary L. Convis. The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence through Leadership Development. McGraw-Hill, 2011.

[2]Manifesto for Agile Software Development. http://agilemanifesto.org/.

[3]Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[4]Rother, Mike. Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results. McGraw-Hill, 2009.

1.2 核心价值观

寻找那些与你有相同价值观的人,大家一起去征服世界。
——约翰·拉岑贝格(John Ratzenberger)
摘要
SAFe的四大核心价值观是协调一致、内建质量、透明和项目群执行,它们是最基本的信念,也是SAFe有效实施的关键。这些指导原则可以帮助每一位参与到SAFe投资组合中的实践者规范自己的行为举止。
详述
SAFe是基于精益和敏捷原则的,兼具深度和广度。这就是SAFe的基础,但是它的理念是什么呢?
SAFe坚持四项核心价值观:协调一致、内建质量、透明和项目群执行。下文将分别描述每一项价值观的内容,如图1.2-1所示。

image.png

协调一致
运营企业就像驾驶汽车一样,如果不能保持协调一致,就可能会产生很多问题。比如,操控方向和根据方向变化进行响应就会变得困难(参考资料 [1])。即便是每个成员都清楚目的地,但由于缺乏协调一致,汽车也不可能把他们带到那里。
为了能够跟上快速变革的节奏、应对纷繁复杂的竞争、协调分布在不同地点的团队,企业都需要做到协调一致。尽管向敏捷团队进行授权的做法很好(甚至是最好的选择),但是无论敏捷团队有多么优秀,企业的战略和协调一致绝对不是每个团队情况的简单叠加。相反,协调一致必须要基于企业的业务目标。以下是 SAFe 支持的保持协调一致的一些方法。

  • 从投资组合的战略和投资决策出发,映射到战略主题和投资组合待办事项列表,然后传递到愿景、路线图和 SAFe 各层级的待办事项列表。“持续探索”从不同的利益相关者小组和多种信息来源收集信息和观点,确保待办事项列表中的条目进行了正确的优先级排序和梳理,并且可以交给团队进行实现。所有这些内容都是可视化的、可讨论的、可解决的、透明的。
  • SAFe 对于工作内容负责的授权角色有非常清晰的线路,从投资组合层出发,涉及主要的产品和解决方案管理者的角色,一直延伸到团队层产品负责人的角色。
  • 对交付的期望和承诺是通过 PI 目标和迭代目标进行协调同步的。
  • 通过确定的节奏和同步机制确保协调一致,或者仅在合理的财务状况和时间范围内,可以做适当的调整。
  • 项目群架构、用户体验指导和组织治理,有助于确保解决方案的技术性、健壮性和可扩展性。
  • 基于当前的环境和演进的状况,使用经济的优先级排定方法,可以保持利益相关者

持续地、认同地、滚动式地参与优先级排序。
但是,协调一致并不意味着或鼓励命令和控制。恰恰相反,事实上,协调一致支持自主性和去中心化的决策,它允许执行价值交付的实施者可以更好地做出本地化的决策。
内建质量
w.爱德华兹·戴明有一句名言:“检查既不会提升质量,也不会保证质量。检查进行得太迟了。质量,无论高低,都已经存在于产品中了。质量在产品和服务中是无法被检查的,只能内建进去。”
内建质量能确保解决方案中的每一个要素都符合质量标准,质量并不是“后来增加的”。内建质量是精益开发流的前提条件,如果没有质量,组织的运行可能伴随着大量的没有经过测试和验证的工作,这可能会导致过度的返工和更慢的交付速度,这都是不好的结果。毫无疑问,内建质量对于大型系统而言是至关重要的,质量是强制性的。
软件
简单地说,你不能扩展那些蹩脚的代码。敏捷宣言明确提出专注在质量上:“坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强”(参考资料 [2])。解决面对快速变化的软件质量问题,需要演进有效的实践,以及那些被极限编程(XP)强烈推荐的框架指导:

  • 测试先行:测试驱动开发(TDD)、接收测试驱动开发(ATDD)和行为驱动开发(BDD)
  • 持续集成和持续部署
  • 重构
  • 结对工作
  • 共同所有权

硬件
同样,没有人能够扩展蹩脚的组件和系统。硬件元素(如电子、电器、流体力学、光学、机械、包装、热学等)都很少涉及“软性”元素。硬件中的缺陷会带来更高代价的变更和返工成本。以下推荐做法可以避免这些缺陷:

  • 频繁的设计周期和集成(参考资料 [3])
  • 协同设计实践
  • 基于模型的系统工程(MBSE)
  • 基于集合的设计(SBD)
  • 对开发和测试基础设施进行投入

系统集成
最终,不同的组件和子系统(软件、固件、硬件和其他元素)必须共同协作,从而提供有效的解决方案级的行为。以下这些实践可以支持解决方案级的质量:

  • 频繁的系统和解决方案级的集成
  • 对于功能性和非功能性需求在解决方案级的测试
  • 系统和解决方案演示

合规
企业采用 SAFe 来构建那些世界上最大型和最重要的系统,很多这样的系统是无法承受失败所带来的社会和经济成本的。为了保护公众的利益,就需要应用额外的规则或者严格的合规需求。为此,构建高保障性系统的 SAFe 企业在精益质量管理系统(QMS)下,定义了自己的实践、规则和流程。这种系统需要确保开发和成果能够与相应的规则和合规标准相吻合,同时又能提供所需要的证明文档。
与之相反,大多数敏捷开发团队不需要创建这些正式的交付件。他们只需要使用团队待办事项列表、持续的测试用例,以及代码自身来描述系统行为即可。然而,在合规的环境下,很显然企业需要开发和维护一套软件需求规格说明书(SRS)来支持确认和验证。事实上,没有必要在最开始的时候大量地生成 SRS 文档。也就是说,只要有可能,这些所需要的文档和工件可以作为常规工作流动的一部分,由敏捷团队使用敏捷工具和自动化的形式增量式地进行构建。例如,敏捷工具可以用于生成 SRS 或者跟踪矩阵。
透明
解决方案的开发是很困难的,工作往往会出错或者无法按计划进行。如果没有开放性,就很难找到事实,而只能基于假设做出决策,也缺乏数据的支持。没有人能够解开这些谜团。
因此,就需要信任。因为如果没有信任,就无法建立高绩效的团队和项目群,也无法建立(或重建)信心以做出和履行合理的承诺。信任表现在,当进行集成的时候,一方完全信赖另一方的工作,尤其是在遇到困难的时候。如果没有信任,工作环境中就会缺少很多乐趣和激励。
建立信任是需要时间的,透明性是建立信任的推动因素,它提供了一些实践:

  • 企业高管、投资组合经理和其他利益相关者可以看到投资组合看板和项目群待办事项列表,他们对于每一个 ART 和解决方案火车的 PI 目标都有清楚的认识。
  • ART 可以清楚地看到团队待办事项列表,也可以看到其他项目群的待办事项列表。
  • 团队和项目群会做出短周期和可视化的承诺,并且兑现这些承诺。
  • 检视和调整工作坊可以邀请所有利益相关者共同从经验教训总结中创建改进待办事项列表。
  • 团队和敏捷发布火车(ART)可以清楚地看到投资组合业务和使能史诗,他们能够可视化地看到这些举措。
  • 进展是基于对于可工作解决方案的客观度量进行的。
  • 每一个人都能理解团队和项目群的速度及在制品(WIP),企业战略和执行能力是可视化和协调一致的。

项目群执行
当然,如果没有团队的执行力和持续的交付价值,SAFe 中其他要素所发挥的作用也就很有限了。因此,SAFe 非常重视聚焦在可工作的系统和所产出的业务成果上。历史经验告诉我们,当很多企业开始采用敏捷团队进行组织转型时,他们通常会在进行大型解决方案的交付过程中,处理可靠性和有效性问题时遭受挫败。
ART 的创建就是为了解决上述问题,而且 SAFe 将实施聚焦在项目群层级上。从另一个角度来看,价值流的交付能力又依赖于 ART 和解决方案火车的交付能力。
幸运的是,在团队方面,可以通过使用协调一致、透明性和内建质量,让团队有一种“风从背后吹来”的感觉,从而让团队专注在向前的工作执行中。通过团队的努力,解决那些复杂的难题,同时团队可以基于检视和调整工作坊形成闭环,在每一个PI 中执行得越来越好。
当然,项目群执行并不仅仅是基于团队、自下而上的。想要成功的扩展精益 – 敏捷的执行,不仅仅需要团队的参与,也需要精益 – 敏捷领导者的积极支持,领导者能够把内部领导力进行有效整合,使之面向客户结果。这样就可以为团队和利益相关者创建一个持续的、有意义的工作环境。
以上就是成功的团队和项目群的工作方式,这也是企业在员工参与、生产力、质量和上市时间等方面获得成功的原因,而且企业也愿意继续享受这个成功的过程!
参考资料
[1]Labovitz, George H., and Victor Rosansky. The Power of Alignment: How Great Companies Stay Centered and Accomplish Extraordinary Things. Wiley, 1997.

[2]Manifesto for Agile Software Development. http://AgileManifesto.org.

[3]Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

1.3 精益–敏捷理念

所有工作都始于精益-敏捷理念。
——SAFe作者
摘要
精益 – 敏捷理念是SAFe领导者和实践者在拥抱敏捷宣言和精益思想的过程中,所产生的信仰、假设和行动的融合。它是采纳和运用SAFe原则与实践的个人基础、知识基础和领导力基础。
SAFe基于三大知识体系:敏捷开发、系统思考、精益产品开发(参考资料 [1])。
敏捷开发提供了必要的工具,授权并鼓励团队达到前所未有的生产力水平、质量和参与程度。但是,想要扩展到整个企业层面,就需要一个更为广泛和深入的精益 – 敏捷理念来支持精益和敏捷开发的执行。因此,精益 – 敏捷理念包含以下两个主要方面:

  • 精益思想——精益思想在SAFe精益之屋中体现出来了(如图 1.3-1 所示)。在这幅图中,“屋顶”代表目标是交付价值;“支柱”通过尊重个人与文化、流动、创新和坚持不懈的改进,来支持目标得以实现;精益领导力则为其他一切奠定基础。
  • 拥抱敏捷——SAFe 是完全基于敏捷团队及其领导者的技能、资质和能力而构建起来的。敏捷宣言提供了一个价值体系和一系列原则,作为成功实施敏捷开发的基本理念。

理解和应用以上知识,有助于创建出精益–敏捷理念,它是新型管理方法和增强型文化的一部分,提供了驱动成功进行SAFe转型所需要的领导力,并有助于个人和企业实现其目标。
详述
精益的SAFe之屋
精益思想虽然最初起源于精益生产,精益思想的原则和实践同样可以应用于软件、产品和系统开发中,当今其应用范围是深远和广泛的(参考资料 [2])。例如,Ward(参考资料[3])、Reinertsen(参考资料 [4])、Poppendieck(参考资料 [5])和 Leffingwell(参考资料 [6])等人都描述了精益思想的各个方面,他们把精益的核心原则和实践付诸产品开发的环境中。综合所有这些要素,受到丰田公司的精益之屋的启发,我们提出了精益的SAFe之屋,如图1.3-1所示。
目标——价值
精益的目标是毋庸置疑的:在最短的可持续前置时间内交付最大的客户价值,同时向客户和社会提供所能达到的最佳质量。高昂的士气、安全的实施、客户的满意,这些都是更深远的目标和收益。
支柱1——尊重个人和文化
一种精益 – 敏捷的方法是无法自己实施或者开展实际运作的,而是由人来执行所有的工作。尊重个人和文化是基本的人类需要。当人们得到了尊重,就会得到授权演进自己的实践并进行改进提高。管理层激发团队成员做出改变,从而朝向更好的工作方法。同时,团队和个人也要学习问题解决和反思的技能,然后进行适当的改进提高(参考资料 [1])。

image.png

文化是这种新的行为背后的驱动力,这就需要企业及其领导者首先做出改变。尊重个人和文化这条原则,也应该扩展到与供应商、合作伙伴、客户,以及更广泛的社区关系,从而支持整个企业。
哪里有积极变革的紧迫性,哪里就会逐步实现文化的提升。首先,理解和实施 SAFe 的价值观和原则;其次,交付成功的成果;最后,文化的改变自然就会随之而来。
支柱2——流动
成功实施 SAFe 的关键是建立一个持续的工作流动,基于持续的反馈和调整,并支持增量的价值交付。持续的流动可以促进更快的价值交付、有效的内建质量实践、坚持不懈地改进,以及基于事实的有效组织治理。
流动的原则是精益–敏捷理念的最基础的部分。这些原则包括理解完整的价值流、可视化和限制在制品(WIP)、减小批次规模和管理队列长度。此外,精益会聚焦在识别和持续减少延迟成本和消除浪费(没有价值的活动)。
精益–敏捷原则提供了针对系统开发的流程、新的思维方式、工具和技术的更好的理解,使领导者和团队成员可以从基于“阶段–门限”的流程,转型成DevOps和持续交付流水线,从而可以扩展整个价值交付流程的流动性。
支柱3——创新
尽管“流动”支柱构建了价值交付的坚实基础,但是如果没有“创新”支柱,产品和流程都将会停滞不前。为了支持精益的 SAFe 之屋的关键组成部分,精益 – 敏捷领导者鼓励开展如下实践:

  • “走出办公室”,进入实际的工作环境中,到现场感受价值交付和产品创建与使用(所谓的“现场管理”(gemba))。正如大野耐一所说,“有用的改进不可能在桌子上发明”。
  • 为员工提供创新的时间和空间,促进有明确目标的创新。创新很少出现在对资源的 100% 利用或者持续的“救火”工作中。SAFe 的创新与计划(IP)迭代就提供了这样的创新机会。
  • 应用持续探索——是一个流程,可用于持续探索市场和用户需要,并定义愿景、路线图,以及一系列的特性,从而实现这些需要。
  • 应用创新核算方法(参考资料 [7])。建立非财务的、真实有效的度量指标,从而提供对于创新中重要元素的快速反馈。
  • 与客户一起验证创新,当收益假说需要改变时,不带任何怜悯和愧疚地转向。

支柱4——坚持不懈地改进
第4个支柱是“坚持不懈地改进”。通过持续反思和流程改进,鼓励学习和成长。持续的危机意识可以促使企业积极追求改进的机会。建议领导者和团队成员按照以下方法执行:

  • 对组织和开发流程的整体优化,而非局部优化。
  • 实事求是,快速行动。
  • 使用精益工具和技术,确定无效性的根源,快速应用有效的对策。
  • 在关键里程碑上进行反思,以开放的心态识别和处理所有层级流程中的不足。
    基础——领导力

精益的基础是领导力,这是团队成功的根本推动力。成功采纳实施精益–敏捷方法的终极责任,是由企业的经理、主管和高层管理者来承担的。正如戴明所说,“这项责任是不能委派给其他人的”(参考资料[8]),包括那些精益–敏捷倡导者、工作组、项目群管理办公室(PMO)、流程团队、外部咨询顾问或者其他第三方。因此,想要取得成功,领导者必须接受这些新型创新思维方式的培训,并展现出精益–敏捷领导力的原则和行为。
精益思想与敏捷类似,但是也有所不同。敏捷实践通常是引入一个基于团队的流程,而并不包含管理层。不幸的是,这种情况不太容易进行扩展。相反,在精益–敏捷开发中,管理者成了拥抱精益价值观的领导者,他们有能力参与一些基础实践,主动消除障碍,在驱动组织变革和促进坚持不懈地改进时扮演积极的推动者角色。
敏捷宣言
在20世纪90年代,为了应对瀑布式开发方法所面临的挑战,涌现出了很多更加轻量级的、更加考虑迭代执行的开发方法。在2001年,倡导这些方法的思想领袖们聚集在美国犹他州的雪鸟小镇,虽然大家所提出的方法各不相同,但是与会者一致认为这些不同方法所遵循的共同价值观和信仰,最终提出了《敏捷软件开发宣言》(参考资料[9])。这是一个转折点,它有助于统一方法,并开始在更大的范围之内推广这些创新方法的益处。敏捷宣言包含了一组价值观声明和一组原则,如图1.3-2和图1.3-3所示。

image.png

敏捷宣言通过各种各样的敏捷方法,为授权的、自组织的团队提供敏捷实施的基础。SAFe将这个实施的基础扩展到了大型团队的级别,并应用精益思想理解和持续提升系统,从而支持多团队的各项关键工作。
参考资料

[1]Knaster, Richard, and Dean Leffingwell. SAFe Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.

[2]Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World: The Story of Lean Production—Toyota’s Secret Weapon in the Global Car Wars That Is Revolutionizing World Industry. Free Press, 2007.

[3]Ward, Allen, and Durward Sobeck. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[4]Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.

[5]Poppendieck, Mary, and Tom Poppendieck. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

[6]Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[7]Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.

[8]Deming, W. Edwards. Out of the Crisis. MIT Center for Advanced Educational Services, 1982.

[9]Manifesto for Agile Software Development. http://agilemanifesto.org/.

1.4 SAFe 原则概述

人们常说:“我们的问题是不同的”,这其实是最常见的错误,它困扰着全世界的管理者。
这些问题确实各不相同,但有助于提升产品和服务质量的原则在本质上却是相同的。
——W. 爱德华兹·戴明(W. Edwards Deming )
摘要
SAFe基于九条恒定的、基本的精益和敏捷的原则(如图 1.4-1 所示)。这些基本信条和经济概念对于 SAFe 的角色和实践起到了鼓舞和描述的作用。
为什么聚焦在原则上
构建企业级软件和网络物理系统,是当今业界面临的最复杂的挑战之一。例如:

  • 构建具有数百万行代码的软件和系统

image.png

  • 融合复杂的硬件和软件交互
  • 跨越多个并发的平台
  • 满足需要和要求严格的非功能性需求(NFR)

当然,建立这些系统的企业也变得越来越复杂。他们比以往的规模更大,地域上也更加分散。合并和收购、分布式跨国(跨多国语言)研发、离岸外包,以及获得成功所需要的快速增长,这些因素都是解决方案的一部分,但同时也是问题的一部分。
幸运的是,我们有一个良好的和不断发展的知识体系,有助于我们应对这一挑战。这个体系包括敏捷原则和方法、精益和系统思考、产品开发流动的实践、精益流程和产品开发等。许多思想领袖已经率先走上了这条探索的道路,给我们提供了大量的书籍和参考资料。
SAFe的目标是综合一些相关的知识体系,并从数以百计的部署实施中收集经验教训。它创建了一个集成的、被验证过实践的系统,这些实践可以提高员工参与度、加快产品上市时间、提升解决方案质量和团队生产力。然而,前文也提到了行业挑战的复杂性,每一个企业面临的挑战都有所不同,也就不可能找到一个通用的适合所有情况的解决方案。这就意味着需要根据实际情况,对 SAFe 框架进行一些剪裁和定制化处理,SAFe 中所推荐的众多实践也不一定适用于所有情况。因此,我们一直致力于通过 SAFe 提供基础的实践、合理和恒定的原则。这样我们就能有信心让 SAFe 适用于各种常见的场景。
当这些实践遇到问题时,基本的原则可以指导团队确保他们继续朝着精益之屋的目标前进:“在最短的可持续前置时间内,为人类和社会提供最佳的质量和最优的价值。”这同样也是有价值的。
SAFe的实践以九个基本原则为基础,这些原则是从敏捷原则和方法、精益产品开发、系统思考,以及成功企业的观察不断演化而来的。针对每一条SAFe原则都有一篇具体的文章加以阐述。而且,这些原则也处处体现在整个规模化敏捷框架中。下面将简述每一条
SAFe原则。
原则 #1——采取经济视角
以可持续的最短前置时间为人类和社会交付最优的价值,需要对系统构建者所负使命的经济状况有最基本的理解。精益系统构建者努力确保每天的决定都是在一个适当的经济环境下做出的。主要包括开发和沟通增量价值流交付的战略和创建价值流的经济框架,他们定义了在风险、延误成本(CoD)、运营与开发成本之间的折中权衡,并且支持去中心化的决策方式。
原则 #2——运用系统思考
戴明观察到,在工作环境中所面临的问题需要了解工人所使用的系统。而且,系统是复杂的。系统中有许多已经定义的、共享目标的相互关联的组件(包括人员和流程)。为了能够改进提高,每个人都必须理解并致力于系统的目的;也就是说,优化一个组件并不能优化整个系统。在 SAFe 里,系统化思考被应用于构建整个系统的组织以及正在开发中的系统,同时也用于获悉该系统在其最终用户环境中如何运行。
原则 #3——假设变异性,保留可选项
传统的设计与生命周期实践使人们在整个开发过程的前期就选取单一需求并设计可能的实现选项。然而,如果起始点就错了,那将来的调整将会花费太长时间,并将导致一个未达最佳的长期设计。一个更好的方式是,在开发周期内更长时间地保留多个需求和设计选项。使用经验数据来收窄关注点,从而产生能够创造更好经济效益的设计方案。
原则 #4——通过快速集成学习环进行增量式构建
通过一系列短迭代的方式来增量地开发解决方案。每个迭代产生一个集成的可工作系统增量,后面的迭代都基于前一个迭代的工作成果进行构建。这些可工作增量可以快速获得客户反馈和降低风险,并且也可作为最小可行产品(MVP)或者原型用于市场测试和确认。此外,在早期,快速反馈的结果允许系统构建者在必要的时候“转移”到另一个行动方向。
原则 #5——基于对可工作系统的客观评估设立里程碑
业务负责人、开发人员和客户将共担责任,确保新的解决方案投资将带来经济效益。顺序式、阶段 – 门限式的开发模型设计,就是用来应对这种挑战的,但过往的经验表明,它并不能像期望的那样降低风险。在精益敏捷开发模型中,每个集成点都提供了一个客观的里程碑,从而可以频繁地进行评估并贯穿于整个开发生命周期中。这种客观评估提供了财务、技术,以及符合目标的治理,从而确保持续投资将产生与之相匹配的回报。
原则 #6——可视化和限制在制品,减少批次规模,管理队列长度
精益企业努力达到一种可持续流动的状态,从而,新的系统的能力可以从概念到盈利快速且可见地实现。实现这种流动的三个主要关键是:
1.可视化和限制在制品(WIP)的数量,从而限制对实际生产能力的要求

2.减少工作项的批次规模,以促进工件在系统中的可靠流动

3.管理队列长度,从而减少对系统新的能力的等待时间

原则 #7——应用节奏,通过跨领域计划进行同步
节奏为开发活动创建了可预测性,并提供了韵律节拍。同步能够促使人们同时理解、解决并集成多个视角。应用开发节奏和同步,加上定期的跨领域计划,提供了所需要的工具,可以在产品开发不确定性的情况下有效运作。
原则 #8——释放知识工作者的内在动力
精益–敏捷领导者都很清楚,知识工作者的构想、创新和敬业通常并不能被激励薪酬所激励。毕竟,个人目标会导致内部竞争,甚至有可能破坏必要的合作,乃至无法实现更宏伟的目标。提供自主性、使命感并尽可能减少约束,将会获得更高水平的员工敬业度,并为客户和企业产生更好的成果。
原则 #9——去中心化的决策
实现快速的价值交付要求快速的、去中心化的决策。这样做,可以减少延误、改善产品开发流动、促进更快反馈,并能根据具体的上下文信息产生更有创意的解决方案。然而,有些决策是战略性的、全局性的,并且这些决策具有足够的经济规模足以保证中心化决策的收益。由于这两种类型的决策(中心化集中决策、去中心化分散决策)都会发生,因此至关重要的一步是创建一个确定的决策框架,从而确保价值的快速流动。
第3章将对SAFe的九个原则进行详细的描述。
参考资料

[1]Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

1.5 SAFe 实施路线图

既能指明宏观方向又能摆脱细节,这是许多领导者引以为自豪的地方。但是仅有全景图,甩手掌柜的领导方式在变革环境中是行不通的,因为变革最难的部分,也是可能令其瘫痪的部分,就存在于细节之中。
所有成功的变革都需要将模糊的目标转化为具体的行为。简言之,为了转变,你需要制定关键行动。
——奇普·希思和丹·希思,《瞬变:如何让你的世界变好一些 》(Dan and Chip Heath, Switch: How to Change Things When Change Is Hard)

摘要
SAFe实施路线图包括一幅概览图和12个步骤,描述了一系列战略和有序的活动,这些活动是在成功实施SAFe中已经被证明的有效方式。
在规模化的环境中要达成精益–敏捷开发的业务收益,并不是一件简单的事情,因此SAFe也不是一个简单的框架。在实现SAFe的收益之前,组织必须接受精益 – 敏捷的理念,并理解和应用精益–敏捷的原则。组织必须识别价值流和敏捷发布火车(ART),实现精益–敏捷投资组合,内建质量,并建立持续价值交付和DevOps的机制。当然,文化也必须得到进化。
基于经过验证的组织变革管理战略,SAFe实施路线图和一系列指导文章描述了企业可以采取的步骤或“关键行动”,从而可以通过有序的、可靠的和成功的方式进行SAFe的实施。
详述
为了实现期望的组织变革,领导者必须编写“关键行动的脚本”,正如 Dan Health 和 Chip Heath 的描述(参考资料[1])。在确定采用SAFe的关键步骤时,数以百计的世界上最大的企业已经走上了这条道路,成功的采用模式已经变得越来越清晰。图1.5-1展示了一个相对标准的实施模式。

image.png

虽然实施方法各不相同,而且在企业中很少有能够完全按照顺序逐步进行实施的,但是我们知道,那些能够获得最佳成果的企业通常是遵循与SAFe实施路线图类似的路径得以实现的。SAFe实施路线图包括以下12个步骤:
1.达到引爆点
2.培训精益 – 敏捷变革代理人
3.培训企业高管、经理和主管
4.创建精益 – 敏捷卓越中心
5.识别价值流和 ART
6.创建实施计划
7.准备 ART 的启动
8.培训团队和启动 ART
9.辅导 ART 执行
10.启动更多的 ART 和价值流
11.扩展到投资组合
12.保持和提升
本节作为启动的概述,可以让你开始详细地探索这些步骤,并了解如何将其应用到自己的实施中。第2章将描述SAFe实现路线图的每个步骤。
参考资料
[1]Heath, Chip, and Dan Heath. Switch: How to Change Things When Change Is Hard. Crown Publishing Group, Kindle Edition.

[2]Knaster, Richard, and Dean Leffingwell. SAFe Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.

1.6 SAFe 咨询顾问

只有那些疯狂到以为自己能够改变世界的人,才能真正地改变世界。
——苹果电脑
摘要
SAFe咨询顾问(SPC)是变革代理人,他们把SAFe 的技术知识与提升公司软件及系统开发流程的内在动机结合起来。他们在成功实施SAFe的过程中起着至关重要的作用。SPC来自许多内部或外部角色,包括业务和技术领导、投资组合/项目群/项目经理、流程领导、架构师、分析师,以及咨询顾问。
详述
一种关键角色和一项关键需要
正如我们在实施路线图描述的一系列步骤,改变企业的开发实践和行为是一项重大的挑战。为了实现有意义的和持久的变革,约翰 • 科特指出,需要由利益相关者组成一个“足够强大的指导联盟”(参考资料 [1])。这样的联盟需要:

  • 具有能够为变革设定愿景,指引方向,并消除障碍的领导者
  • 具有能够实施具体流程变革的执行者、经理和变革代理人
  • 具有足以引起重视的组织信誉的员工
  • 具有能够做出快速、明智决策所必需的专业知识

在那些新引入SAFe的企业中,以上这些工作都需要经过培训的SPC来承担。
责任
SPC作为知识型的变革代理人,参与到SAFe实施路线图的绝大部分活动中。具体说来,他们的责任如下:

  • 达到引爆点——他们传达业务需要、紧迫感和变革愿景。
  • 培训企业高管、经理和主管——他们沟通新的概念,提供方向和宏观培训。SPCS 向领导者、管理者和利益相关者教授引领 SAFe 培训课程。
  • 创建精益 – 敏捷卓越中心(LACE)——SPC 协助 LACE 建立和执行变革待办事项列表。
  • 识别价值流和敏捷发布火车(ART)——SPC 与利益相关者一起合作,理解价值的流动,识别价值流和 ART,从而找到启动的最佳机会。
  • 创建实施计划——SPC 参与创建实施计划,沟通将要启动的变革,并建立度量。
  • 准备 ART 的启动——SPC 帮助 LACE 计划和准备 ART 启动。他们辅导领导者并帮助协调建立新的敏捷团队。他们自己开展培训或者找外部讲师进行培训,这些培训覆盖的角色包括:高层管理者、主管、开发团队、专业的角色(比如产品负责人、产品经理、Scrum Master、发布火车工程师(RTE))。他们也会参与到启动火车和待办事项列表准备的工作中。
  • 培训团队和启动 ART——SPC 通常会直接计划和执行 SAFe 快速启动活动或其他实施策略。他们针对团队自己开展培训或者找外部讲师进行培训,并参与初始的、关键的活动,如项目群增量(PI)计划会议,以及检视和调整(I & A)活动。SPC 帮助确立 ART 启动日期,以及 ART 和团队活动的日历。
  • 辅导 ART 执行——SPC 辅导领导者和利益相关者建立并维护愿景、路线图和项目群待办事项列表。他们辅导团队、产品负责人、产品经理、架构师和 RTE。他们也参加 Scrum of Scrums 和系统演示,引导 I&A 工作坊,并跟进后续的改进活动。最后,他们帮助团队建立 DevOps 文化和理念、持续交付流水线、基础设施,以及相关的敏捷技术实践。
  • 启动更多的 ART 和价值流——SPC 致力于使新的变更代理人能够增强组织能力以支持新的价值流,启动更多的 ART,并扩大 LACE 的影响范围。他们沟通进展,强调突出早期获得的成就。
  • 扩展到投资组合——一旦精益 – 敏捷实践获得了动力,SPC 就可以开始传递投资组合实践,并将其推动到公司的其他领域,包括精益预算、精益投资组合管理、更加精益的 CapEx 和 OpEx 方法,以及敏捷合同。他们还传达战略主题的价值。
  • 保持和提升——企业的精益实施永无止境。SPC一直保持着长远的视角,包括提高质量、培养精益– 敏捷的人力资源方法、通过继续教育支持增强的技能开发,以及建立实践的社区(CoP)。它们鼓励自我评估(参见6.1节的讨论),并帮助执行价值流映射。

需要多少SPC
乍一看,上面的清单似乎令人畏惧。没有一个SPC能够独自完成这一切。然而,从广义上看,SPC的知识和技能不能仅仅局限于选出的少数几个人身上。相反,许多新兴的精益–敏捷业务的领导者必须掌握这些独特的新能力。这意味着大多数公司将需要许多SPC (可能每100个开发人员就需要3~5个SPC)来驱动和保持实施工作。
培训SPC
SPC必须接受培训,以适应其新角色,并获得执行其责任所需的技能和工具,以及指导和教导其他人实施和支持变革。实现此目的的最佳方法是参加实施 SAFe4.0培训课程,并获得SPC4证书。这个为期4 天的课程可使SPC成为领导变革的变革代理人。参与者会学习如何有效地应用 SAFe 的原则和实践,以及组织、培训和教练敏捷团队。他们还会学习如何识别价值流、设计和启动 ART,以及帮助构建和管理精益投资组合。

image.png

在整个企业中扩展精益–敏捷还需要培训所有从事这项工作的人员。为了使之具备实用性和成本效益,SAI 公司支持培训师的培训、扇出模型、授权SPC教授 SAFe课程,以支持实施中的其他关键角色。这提供了负担得起的培训策略,并提供了培训师所需的完成公司范围内的变革任务。
我是 SPC,我现在该如何做
参加培训的人员通过考试后,就成了经过认证的SPC,他们可以获得各种有用的SPC资源(https://www.scaledagile.com/spc-resources/ )以方便采纳SAFe。他们也可以得到授权,教授 https://www.scaledagile.com/becoming-an-spc/#TrainingOthers 中列出的一组特定课程。
参考资料
[1] Kotter, John P. Leading Change. Harvard Business Review Press, 1996.

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接