SAFe?原则
2.1 原则#1——采取经济视角
你可能会忽略经济，但经济不会忽略你。——Donald Reinertsen，《产品开发流的原则》
摘要
精益系统构建者的目标是：持续地在最短前置时间内，对人类和社会提供最佳的质量和最优的价值。为了实现这个目标，需要系统构建者对经济效益有一个基本的了解。如果没有这样的认识，即使是一个技术成熟的系统也可能需要很高的研发成本，很长的交付时间，或者由于生产和运营成本太高以至于无法支持经济有效的价值。
为此，系统构建者们（比如整个产业链中的领导者、管理层和知识工作者）就必须完全了解他们所做出决策的经济影响。传统的观点是，只有那些了解业务、市场和客户经济情况的决策者与当局者们，才有必要了解系统构建者的活动与经济之间的关系。然而，如果这些对经济相关的理解只是集中在领导者那里，就会造成基层员工在处理日常工作问题时做出两个选择：（1）不理解经济关系就进行决策，（2）不做任何决策，而将这些问题升级到管理层。其中第一个选择会导致仅仅是对经济成果的局部优化，而第二个选择会导致延迟价值交付，这都会带来不好的影响。
详述
SAFe十分强调经济效益在成功的解决方案开发过程中所发挥的重要作用。因此，SAFe的第一个精益–敏捷原则就是：采取经济视角。之所以是排名首位的原则，是因为如果不能满足客户或系统构建者的经济目标，那么解决方案就无法长期存在。解决方案失败的原因有很多，其中最主要的原因就是不能满足经济要求。本节介绍了通过精益–敏捷方法达到优化经济成果的两个主要方面：一是尽早和经常交付，二是理解每一个项目群和价值流的经济平衡参数。这两个方面在下文中有详细描述，此外，SAFe将这些原则在各种实践中进行了实例化，这也是6.3节所阐述的主题。
尽早和经常交付
一般来说，企业做出精益–敏捷转型的重大决策，是由于当前流程不能满足生产的需要，或者是他们认为当前流程将来会被取代。在选择精益–敏捷的道路上，通常是使用基于增量式的模型，尽早和持续交付价值，如图2.1-1所示。
这样的决策将会产生显著的，或许是最基础的经济效益，如图2.1-2所示。
图2.1-2展示了在这种流程中价值可以尽早交付给客户。而且，这些价值可以多次集成，客户持有时间越久，得到的价值就越大。
在瀑布模型中，价值无法在项目早期交付，而只能按照计划在开发周期结束时得到交付。这种差异也展示了使用SAFe的经济效益。此外，图2.1-2还展示了在瀑布模型中，并没有考虑解决方案构建者快速得到反馈的收益，而且最终能够按时交付并满足要求的概率也会比较低。最后，还有第3个因素最为重要，如图2.1-3所示。
图2.1-1 尽早和持续交付
图2.1-2 增量开发和交付能尽早产生价值
图2.1-3 早期价值更高，可以在更长的时间内产生更大的收益
图2.1-3展示了一个关键的差异化优势：只要质量满足要求，产品越早投入市场，价值就越高。毕竟，如果足够早的话，竞争对手还没有提供相应的产品，因此客户就愿意花更多的钱来购买。随着时间的推移，产品就会进入同质化和价格竞争，也就没有了价值差异化，这就是产品发展规律。这就意味着即使是在早期提供给客户最小可行产品（MVP），也比在后期提供全面的功能更有价值。所以产生的效果是，方案构建者的累积总利润就会更高。这是精益–敏捷开发的基本前提，也是精益–敏捷思维实施的坚实基础，更是解决方案构建者争取最短的可持续前置时间的驱动力量。
理解经济平衡的参数
上述讨论的主要问题，驱动着解决方案构建者使用这种更加经济有效的模型更快速地交付价值。然而，当执行项目群时仍然有很多工作要做，而且在解决方案生命周期中的经济决策也将最终决定交付的成果。因此，有必要更深入地讨论多种经济参数的平衡。Reinertsen（参考资料[1]）描述了5种基本参数，可以用于站在经济角度考虑特定的投资情况，如图2.1-4所示。
对5种参数的解释如下。
开发费用：是指为了实现某种能力所需要的人力和物料成本
周期时间：是指为了实现某种能力的时间（前置时间）
产品成本：是指制造（销售成本）、部署和运营的成本
价值：是指所实现的能力对业务和客户的经济价值
风险：是指解决方案中技术或业务可行性的不确定性
理解经济平衡的参数，有助于优化生命周期的收益——这也是处理开发中最佳经济价值的关键。但是，这需要对项目有更深刻的理解，以下是两个例子：
1.一个团队正在构建一个家庭自动化系统，据估计可以通过增加更多的软件功能减少100美元的电子部件的成本，但是可能会延迟发布前置时间3个月。那么团队应该执行这个项目吗？显然无法简单给出答案。这取决于产品预期的销售量和如果推迟3个月发布产品的延迟成本之间的对比。在做出决策之前，还需要做进一步的分析。
2.一个大型软件系统，如果有大量的技术债务，是很难进行维护的。而且开发费用是严格固定的。如果专注于现在的技术债务，在短期内将会减慢价值交付，但是从长期来看，会有利于减少将来的特性交付的前置时间。那么团队应该采取这种措施吗？同样，也无法简单给出答案，它取决于定量地分析更多的要素，再做出决策。
除了经济平衡的参数，Reinertsen还介绍了一些关键的原则，有助于团队从经济的角度出发做出坚实的决策。这些原则如下所述：
量化延迟成本的原则——如果你只对一件事进行量化分析，那就是延迟成本
持续经济平衡的原则——经济有效的选择必须持续不断地进行
最佳决策时间的原则——每一个决策都有它的最佳经济时间
沉没成本的原则——不要考虑已经花费的成本
第一决策规则的原则——使用去中心化经济控制的决策规则
以上最后一个原则与SAFe紧密相关，可以推导出SAFe的原则#9——去中心化的决策，该原则将在6.3节进一步描述。
参考资料
[1] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
2.2 原则#2——运用系统思考
系统是必须被管理的，它不会进行自我管理。如果让其自我管理，各个组件就会变得自私、相互竞争，成为彼此独立的利润中心，从而破坏整个系统。系统管理的奥秘就是面向组织目标，协调各个组件之间的合作。
——W.爱德华兹·戴明
戴明是世界上最著名的系统思想家之一，他一直专注于研究人们构建和部署各类系统时所面临的问题和挑战，这些系统包括：制造系统、社会系统、管理系统，甚至政府系统。一个核心的结论是，在员工开展工作的系统中所面临的问题，是由一系列复杂的相互作用的因素驱动的，而这种复杂性往往是被低估的。从更大的系统视角切入，是解锁系统奥秘的关键，并能提高开发流程和产品与服务质量，这也是系统的目标。
解决方案就是一个系统
SAFe的目的就是帮助系统构建者实现最短的可持续前置时间，以及对人类和社会交付最好的质量和价值。因此，主要的焦点就是系统——大型、炫酷、新奇的事情。在这里，系统是必须被管理的，以下是一些关键点：
系统构建者必须清晰理解系统的边界是什么，系统自身是什么，系统如何与周围的环境和其他系统进行交互，以及系统内的组件如何进行交互从而达成系统的目标，最终服务于客户的需要。
仅仅优化一个组件是无法优化系统的，相反，系统必须进行整体优化。系统构建者们必须确保组件不能只顾及自己的利益，也不能独占所需要的资源（比如计算能力、内存、电力供应等）和其他要素。
为了让系统的行为表现良好，就必须在实施之前对其有清晰的了解，比如意图架构和非功能性的系统行为。
一个系统的价值会通过其连接部件进行传递，比如接口和接口之间的依赖关系，这些连接部件是提供最终价值的关键要素。
一个系统的进化速度取决于系统中最慢的集成点。完整系统的集成和评估越快，系统掌握的实际知识的增长速度就越快。
构建系统的企业也是一个系统
运用系统思考带给我们的重要的、必然的结果是：构建系统的企业也是一个系统。企业的员工、管理层和职能行政部门，组成了构建系统的系统。
同样，系统思考的警示在企业系统中也适用，否则也会造成研发和产品系统的各个组件只考虑自己的利益，互相干扰价值交付和经济效益。这也产生了另外一组对系统思考的关键理解：
价值跨越组织边界。想要加快价值传递，就需要消除职能筒仓，或者创建可以更好交付价值的虚拟组织。
建立复杂系统是一种社会性工作。系统构建者们必须创造一种环境，使人们可以通过最优的合作方式构建最好的系统。
供应商和客户都是价值流不可或缺的组成部分。他们必须被视为合作伙伴，建立长久的信任基础。
领导者必须具备长远眼光，今天做出的决策会影响未来的结果。为提升能力进行投资，比如基础设施、实践、工具和培训，为未来的价值交付和质量与生产力的进步奠定基础。
只有管理能够改变系统
戴明曾提出过一些相关结论（参考资料[1]）：“每个人都已经尽了最大努力，问题存在于系统之中”“只有管理能够改变系统”。
这也为我们提供了最终的理解：系统思考需要采取一种新的管理方式，即经理是问题解决者，他们具备长远的系统视角，并且积极清除障碍。精益–敏捷管理者同时也是老师，他们的工作如下：
展示和教授精益、敏捷和系统思考的价值观、原则和实践。
消除职能筒仓，清除障碍，促进流动。
建立长期有效的供应商和客户关系。
持续不断地致力于问题解决和清除障碍。
使用和教授根本原因分析与纠正措施技术。
授权知识工作者，释放其内在动力（原则#8）和去中心化的决策（原则#9）。
成为团队的伙伴，共同实现关键里程碑，帮助团队识别和解决问题。
理解系统思考的方方面面，有助于领导者和员工真正明白他们所做工作的目的和内容，以及对周围的影响。反过来，这也会形成一个更加智慧的企业，可以更好地处理组织结构和解决方案研发的复杂性，从而提升经济效益。
参考资料
[1] Deming, W. Edwards. The New Economics. MIT Press, 1994.
2.3 原则#3——接受变异性，保留可选项
创造系统级设计和子系统概念的多种可选方案；而不是过早地选择一个胜出方案，然后消除与之不同的其他可选项。只有那些存活下来的设计选项，才是最强大的可选方案。
——艾伦 C.沃德，《精益产品和流程开发》
系统构建者们都会倾向于减少变异性。表面上看起来，你认为自己知道的越多并且已经做出相应的决策，你就会走得更远。但事实往往并非如此。虽然变异性会导致糟糕的结果，但有些时候也不尽然。变异性的自身无所谓好与坏。相反，是由于时间的经济效应和变异性的类型决定了最终的结果。如果过早地专注于消除变异性，可能会导致企业萌生厌恶风险的文化，这样员工也就不能通过试错和学习来获取经验。
精益系统构建者们认识到，在项目的早期除了一些基本的系统目标之外，对项目的实际情况知之甚少。确实，如果能掌握所有信息，那么系统早就构建成功了。然而，传统的设计方法往往让开发人员迅速地开始实现一个单一的方案——而这个方案仅仅是众多潜在解决方案中的一个——然后再通过修改设计，直到最终满足系统的目标。这也许是一个很有效的方法——当然，前提条件就是最初所选择的单一方案不能有误——然后再通过后续的迭代进行细化，但是最终可能需要花费很长时间才能得到一个并不是最佳设计的解决方案（参考资料[1]）。
如果最初选择的单一方案不是最优的，那么后果就是：系统越大、越需要技术创新，所带来的损失也会越大。一个更好的方法是，可以参考使用基于集合的设计（多个设计构成一组）或者基于集合的并行工程（多个并行工程构成一组）（参考资料[2]），如下图所示。
在基于集合的设计中，系统构建者们最初会考虑非常广泛，提出多种设计选项。接下来，他们持续地评估经济效益和技术难度之间的平衡，在集成的学习点上，可以演示与目标的匹配情况。然后，基于演示的结果和所获取的经验，去除那些不太好的选项，收敛到一个最终的设计。
采取这种流程，可以让设计选项的持续时间尽可能延长，在必要的时候进行收敛，并最终产生更优的技术实现和经济效益。
参考资料
[1] Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review 38 (1995): 37–58.
[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.
2.4 原则#4——通过快速集成学习环，进行增量式构建
产品的集成点，是控制产品开发和提升系统的关键支点（杠杆点）。如果没有处理好集成点的时间，项目就会陷入困境。
——Dantar P. Oosterwal
增量式构建系统
在传统的方法中，根据“阶段–门限”进行开发，项目一开始就立刻投入成本，随后成本逐渐累积直到最终方案得以交付。通常，在项目执行期间极少交付实际价值，而是直到所有功能完成后才在最后一次性交付价值，有时候项目也会面临时间延期或者成本超支的问题。在开发过程中，一般很难收集到有意义的反馈，因为流程并不支持反馈收集；而且系统也并没有按照客户需求和能力的逐步提升进行相应的增量式设计和实现。风险在项目执行中会一直存在，直到项目结束，有时候甚至会进入到部署和客户最初使用环节。这种流程所导致的错误和问题，往往会破坏系统构建者和客户之间的信任关系。其实，系统构建者和客户也在努力调整这些问题，他们会在项目早期进行需求定义，并选择“最好的”设计，他们也会执行更加严格的“阶段–门限”评审。但是，使用这种流程所生成的解决方案，总会产生一些潜在的问题。这是开发流程中存在的一个系统级别的问题，所以必须从系统化的角度去解决这个问题。
集成点可以从不确定性中获取知识
精益系统构建者解决问题的方式与上述方法有所不同，他们并不是在项目早期选择单一的需求和设计方案，也并不假设这些设计是完全可行和满足要求的，相反，他们会基于一定范围的需求和多种设计选项（原则#3）进行一系列短周期（时间盒）的增量式解决方案构建。每一个时间盒都会产出一个可工作系统的增量，可以交给系统构建者和客户进行评审。后续的时间盒会在之前增量的基础上，逐渐交付演进的解决方案，直至最后发布。在集成点上，获取经验知识不仅仅是为了技术可行性研究，也可以得到最小可行解决方案或者原型，供市场验证、建立可用性、获取客户反馈等。在必要的地方，这些快速反馈点允许系统构建者找到一个采取下一步方案的“支点”，从而可以更好地服务于目标客户的需要。
根据意图设置集成点
基于节奏的集成点逐渐成为系统构建者的主要关注焦点，它可以根据特定的目标设计相应的开发流程和解决方案架构。每一个集成点都会创建一个“拉动事件”，拉动各种方案要素进行整体集成，即使只解决了系统的一部分目标也会进行集成。集成点也会将利益相关者拉动到一起，定期的同步有助于确保方案的演进，从而解决真正的问题和当前的业务需要，而不是仅仅依赖于在项目开始时建立起来的假设。每一个集成点都会根据技术可行性和当前的设计选项，将不确定性转化成经验知识，进而交付一定的价值，而且对于解决方案潜在可行性的经验知识，都是基于目标进行度量的（原则#5）。
通过更快的周期进行更快的学习
集成点是休哈特（shewhart）PDCA（Plan-Do-Check-Adjust）循环（参考资料[3]）的一个实例，因此它可以作为控制解决方案开发中变异性的主要机制。
集成点越频繁，学习速度就越快。在复杂系统开发中，本地集成点用于确保系统中的每个元素和能力都能够服务于满足整体解决方案的目标，它也必须进一步集成到更高的系统级别中。系统规模越大，集成的层级就越多。系统构建者们明白：最高层级的、发生频率最低的集成点，提供了度量系统进展的唯一标准，他们也在努力尽可能多地实现这些集成点。所有的利益相关者也明白：如果集成点的时间没有控制好，项目就会陷入困境。但是即便是这样，及时获取经验知识也会有助于促进对范围、技术方法和成本的必要调整，也有助于更新交付时间让项目可跟踪，从而调整客户的预期。
参考资料
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.
[3] Deming, W. Edwards. Out of the Crisis. MIT Press, 2000.
2.5 原则#5——基于对可工作系统的客观评价设立里程碑
实际上，按时进行“阶段–门限”交付与项目的成功并无关系。但有些数据表明，反过来却是相关的，即成功的项目都是按时进行阶段交付的。
——Dantar P. Oosterwal，《精益机器》
“阶段–门限”里程碑的问题
现在，对于大系统的开发需要进行大量投资，可以达到数百万、上千万，甚者过亿美元的投入。系统构建者和客户有义务共同确保对于新的解决方案的投资可以提供必要的经济收益。否则，就没有理由进行相应的投资。
显然，利益相关者必须进行协作，帮助确保预期的经济效益贯穿在整个开发过程中，而不仅仅是“一厢情愿”地认为在最终可以达到美好的结果。为了应对这一挑战，工业界引入了“阶段–门限”（瀑布式）的开发流程，这种流程会通过对一系列确定的里程碑进行度量和控制。而且这些里程碑也不是任意设置的，它们遵循一定的逻辑性和一系列的流程（发现、需求、设计、实现、测试和交付）。当然，这种里程碑的设置方法并没有获得好的收效，如图2.5-1所示。
图2.5-1 “阶段–门限”里程碑的问题
导致这个问题的根本原因是没有认识到在“阶段–门限”显示的真实进展情况和消除风险的过程中，犯了四个关键的错误：
1.将需求集中起来，同时进行职能筒仓式的设计决策，导致了在后续的解决方案构建过程中缺乏完整性。
2.过早的设计决策和“虚假的可行性”（参考资料[1]）：一个早期的选择是在当时做出的最佳选择，随后开发流程就假设一切按照计划进行，直到最后才发现最初的选择是不切实际的（原则#3）。
3.假设存在一个确定的解决方案，而且只进行一次尝试就可以构建成功。这样就忽视了流程中固有的变异性，并且没有提供有效的处理方法。改变将是迟早的事。变异性迟早是要表现出来的。
4.在前期就进行决策，创建了大批量的需求、代码和测试，形成了很长的队列。这也导致了大量的工作交接和延迟的反馈（原则#6）。
基于客观事实设立里程碑
显然，“阶段–门限”模型并没有像预期的那样降低风险，所以就需要一种不同的方法。原则#4（通过快速集成学习环，进行增量式构建）提供了解决这一困境的一些要素。
在整个开发过程中，系统进行增量式的构建，每一次构建都是一个集成点，在集成点上可以演示一些已经实现的内容，以验证当前解决方案的可行性。与“阶段–门限”开发方法不同，基于客观事件所设立的每一个里程碑都包含研发的所有步骤（需求、设计、开发、测试），从而达到增量式的价值交付，如图2.5-2所示。此外，这种里程碑会基于节奏进行（原则#7），一个固定的节奏可以形成一种纪律，确保定期提供可用性和评估，同时能提前确定时间边界，也可以用来去除那些不太理想的选择。
图2.5-2 基于对可工作系统的客观评价设立里程碑
在关键的集成点上要对哪些要素进行有效的度量呢？这取决于所要构建系统的类型，但是利益相关者可以在整个解决方案开发周期内，频繁地对系统进行度量、评价和评估。这样可以提供财务、技术和符合目标的组织治理，从而确保持续的投资可以产生与之相匹配的回报。
参考资料
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
2.6 原则#6——可视化和限制在制品，减少批次规模，管理队列长度
接近满负荷地使用产品开发流程是一场经济灾难。
——Donald Reinertsen
为了实现可持续的最短前置时间，精益系统构建者们努力实现持续流动的状态，即新的系统可以迅速地从概念到盈利。实现持续流动需要消除传统方法中的基于“开始–完成–开始”的项目启动和开发流程，也要消除阻碍流动的现行“阶段–门限”的方法（原则#5）。
实现流动的三个关键点是：可视化和限制在制品，减少工作项的批次规模，以及管理队列长度。
可视化和限制在制品
团队和项目群的工作过载，任务量超出了他们所能承担的范围，这是一个常见且有害的问题。系统中如果在制品（Work in Process，WIP）过多，就会导致人员复用和频繁地在不同工作场景之间进行切换。这种情况会使员工工作过载，减少了对正在执行任务的专注度，降低了生产力和吞吐量，并增加了交付新功能的等待时间。
第一步是让当前的在制品对所有利益相关者清晰可见。这个可视化说明了在每一个步骤的工作总量，也作为对初始过程的诊断，并显示出当前的瓶颈。在某些情况下，仅需简单地可视化当前的工作，就可以唤醒开发人员，让他们开始意识到要解决同时开展工作太多而没有形成流动的问题。下一步就是处理在制品数量和可用开发容量平衡的问题。如果在执行过程中达到了在制品的上限，就不再承接新的工作任务。
然而，限制在制品是需要有知识、有纪律和有承诺的。甚至有些时候是看起来是反直觉的，比如以前有些人认为放入系统的工作越多，完成得就越多。在一定程度上这是正确的，但是如果超出了一定的限度，系统就会变得动荡，也会降低流动性。这说明，有效的在制品管理是不可取代的。
减少批次规模
减少在制品和提高流动性的另一种方法是减少工作的批次规模，这些工作包括需求、设计、编码、测试和其他相关工作。简单地说，小批量通过系统的速度更快，变异性更小，并能够促进快速学习。显而易见，因为随着批次规模的增加变异性是累积增加的，所以批量越小速度越快。
从经济的角度上来看，最优的批次规模依赖于持有成本（延迟反馈和价值交付带来的成本）和交易成本（实现和测试的成本）。如图所示，说明了“U型曲线”是批次规模的最优曲线（参考资
料[1]）。
为了提高处理小批量的经济效益，从而增加吞吐量，主要的工作重点需要聚焦在减少批次的交易成本上。通常包括更加关注在基础设施和自动化上的投资，比如持续集成和构建环境、DevOps自动化，以及系统测试的配置时间。以上这些都是与系统思考的融合（原则#2），也是进行长期优化的关键要素。
管理队列长度
实现流动性的第三个措施是管理队列长度（一般来说是减少队列长度）。利特尔法则（基于排队论的法则）告诉我们，系统提供服务的等待时间等于队列的长度除以平均的处理效率（这可能看起来很复杂，可是在星巴克排队买咖啡的时候也会用到这个公式）。因此，假设平均的处理效率一定，队列越长，等待时间越长。
对于解决方案开发来说，这意味着无论团队多么有效地处理工作任务，只要团队实现的工作任务队列越长，那么等待时间就越长。如果你需要更快地完成，就必须减少队列的长度或者提高处理效率。虽然提高处理效率是我们都希望达到的共同目标，但是减少等待时间最快的方式是减少队列长度。在工作中，可以通过保持较短的待办事项列表和并不过多进行承诺来做到这一点。同时，可视化工作可以极大地帮助过程改进。
减少队列长度可以减少延迟、减少浪费，增进对于成果的可预测性。可视化和限制在制品，减少批次规模和管理队列长度，这三种方式对于提高吞吐量非常有效。通过采取这些方式，可以在客户满意度和员工参与度方面达到快速和可衡量的改进，对系统构建者及其客户也可以带来全面的经济效益。
参考资料
[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
2.7 原则#7——应用节奏，通过跨领域计划进行同步
节奏和同步可以限制变异性的累积。
——Donald Reinertsen，《产品开发流的原则》
解决方案开发在本质上是一个内在不确定的过程。否则，解决方案早就已经存在了，下一代解决方案的创新也就没有空间了。这种内在的不确定性与企业活动是相互冲突的，比如企业活动需要管理投资、跟踪进展、对于未来成果有足够的把握，从而制订计划和承诺一个合理的行动实施。解决方案开发总是处在一个十字路口，它有自己的难题，即交付成果的不确定性和企业需要业务的确定性之间的冲突。这或许正是它的魅力所在。
精益系统构建者需要在安全的环境中工作，这种环境需要有足够的不确定性提供创新的自由，同时也有足够的确定性保证企业运营。实现以上结果的主要方式是，真正了解当前所处的状态。而应用节奏、同步和跨领域计划，恰恰有助于对当前状态的了解。
节奏
节奏是流程中可靠的心跳，可以提供一种优雅的节拍模式。节奏让常规工作有规律地进行，从而使系统构建者可以利用其知识能力管理那些可变的要素。节奏能使不可预测的要素变得可预测，并带来了很多益处：
使等待时间可预测，如果你所需要的工作交付物不在当前的这个时间盒内，那么可能就会在下一个时间盒内。
引导计划活动，使资源使用更加有效。
提供了一个强制函数，同时降低了关键活动的交易成本，这些活动包括计划、集成、演示、反馈和回顾等。
同步
同步可以在同一时刻从不同的角度出发，进行工作任务的理解、解决和集成。
同步用于如下内容：
将系统中的不同资产进行整合，以评估解决方案层级的可行性。
将开发团队和业务团队的共同使命协调一致。
将客户融合到开发的流程中。
总之，节奏和同步，以及其他重要的相关活动，共同帮助系统构建者在不确定的安全环境中可靠地开展工作。
通过跨领域计划进行同步
在SAFe的所有活动中最关键的一环是：所有的利益相关者定期聚集在一起进行跨领域的计划和同步。这项活动（即SAFe中的发布计划会议）是所有其他活动的支撑，它也是一个全员会议，用于展示当前的真实状态。发布计划会议的三个主要目的是：
1.评估解决方案的当前状态——通过集成和解决方案级别的演示与评估，确定当前状态的目标。这项活动通常是在计划会议之前进行。
2.再次对齐所有利益相关者的共同技术和业务愿景——基于当前状态，业务领导和技术领导一起重新设定使命，考虑最小可能的限制条件（原则#8和原则#9）。这项活动用于对齐所有利益相关者的近期和远期愿景。
3.对下一个项目群增量进行计划和承诺——基于达成的新共识，团队对于在接下来的时间盒内要完成的工作进行计划。计划和控制的分布式进行，可以授权团队在给定的约束条件下，为达到最佳可能的解决方案创建出最佳可能的计划。
大型系统的开发从根本上来讲是一种社交活动，这种计划活动为建立和完善社交网络提供了一个持续的机会。
解决方案开发的内在不确定性是无法治愈的。如果可以治愈，那么治愈的结果可能比原来的疾病更糟糕。然而，应用节奏和同步，定期地进行跨领域计划，为精益系统构建者提供了在安全环境中开展工作所需要的各种工具。
参考资料
[1] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
[2] Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
2.8 原则#8——释放知识工作者的内在动力
看起来，任务的绩效提供了内在的奖励……这种驱动力……可能与其他元素一样，都是基础……
——丹尼尔·平克，《驱动力》
精益–敏捷领导者工作在一个相对较新的环境中，对于知识工作者的“管理”其实是一个自相矛盾的说法。正如德鲁克指出的：“知识工作者比他们的老板更了解自己所从事的工作”（参考资料[2]）。在这种情况下，员工完全有能力自己定义必要的活动以达成他们的目标，那么经理们如何进行管理，并协调技术活动呢？
事实上，经理们无法进行管理。相反，经理们能做的是释放知识工作者的内在动力。下面将介绍一些实施指导。
利用系统视图
在进一步了解相关的激励元素之前，我们需要注意存在一个重要的理解，那就是需要理解SAFe的精益–敏捷原则本身也是一个系统。这个系统的元素相互协作，创建了一个新的授权模式，知识工作者可以跨越职能的边界进行沟通，基于对经济效益的理解进行决策，对于有效的解决方案实现快速反馈，参与持续和增量式的学习并提高掌控能力，更多地参与解决方案开发的过程。这就是最强有力的激励因素之一。
了解薪酬的作用
许多组织的运作仍然基于那些已经过时的、对人员潜力和员工绩效的假设，而且大多基于传统观念而不是科学。这些组织继续追求的做法是，短期激励计划和按照证据的绩效工资支付方式，但实际上这种度量方式并不奏效，甚至会带来危害（参考资料[1]）。
丹尼尔·平克（参考资料[1]）和彼得·德鲁克（参考资料[2]）以及其他一些学者，指出了知识工作者的薪酬激励因素的一个基本悖论：
如果企业不能支付足够的工资，员工就不能被激励。低薪酬是致使动力下降的主要原因。
但是，如果达到了一个临界点，工资就不再是一个长期的激励因素了。这个临界点就是知识自由和自我实现。也就是说，知识工作者可以无偿地专注在工作上，而不是金钱上。
如果达到了这个临界点，增加薪酬反而会变成一个致使动力下降的原因。这可能会成为对知识完整性的一种亵渎，从而让员工把注意力只是放在金钱而不是工作上。
精益–敏捷领导者都很清楚，知识工作者的构想、创新和在工作场所中深入参与工作，是无法用金钱来激励的，也不会被威胁、恐吓和恐惧所胁迫。那种基于激励的报酬，往往体现在个人的目标管理上（MBO），会导致内部竞争，甚至有可能破坏必要的合作，乃至无法实现更宏伟的目标。如果这样的话，企业就会在竞争中失败。
提供目标、使命和最小可能约束的自主性
《驱动力》（参考资料[1]）同样也“驱动了”一个不争的事实，即知识工作者需要具备自主性——也就是他们与生俱来的自我指导和自我管理的能力。提供自主性，同时把它作为大型企业发展的目标，这一点是领导者的重要职责所在。
经理们和员工们也都知道，自我指导的动力必须存在于更大的目标中。所以，领导者们需要提供一些更大的使命——把员工的日常工作和企业的发展目标联系起来。
在构建系统时，知识工作者作为团队的一部分参与其中，所以，成为高绩效团队的一员同样也是激励的另一个维度。领导者可以通过以下方式鼓励团队做到最好（参考资料[4]）。
确立使命感：要有一个概要的目标和战略方向，同时也是一个强烈的愿景。
对于具体工作和项目计划，仅给出少量的、最小化的指导，甚至没有任务说明和计划。
对于需求和最小可能的约束条件进行检查，由团队决定如何实现这些需求
营造一个平等互助的环境
“如果要做到有效地领导，就必须尊重员工并倾听他们的声音”（参考资料[2]），而且是在相互平等的环境中（参考资料[4]）。领导者可以营造一个良好的环境，他们可以对员工给予及时的反馈、放下自己的职权影响力，并鼓励员工按照如下的方式开展工作：
在恰当的地方提出不同意见。
鼓励员工坚持自己的立场。
让员工清晰自己的目标并努力达成。
促进管理者和员工共同解决问题。
协商、共识、同意和承诺。
当前的系统构建者生活在一个崭新的时代，这个时代的特点是员工更加智慧，在具体的工作中比管理者具备更多的知识。释放这种潜力是改善员工活力的一个重要因素，同时也可以为客户和企业达成更好的成果。
参考资料
[1] Pink, Daniel. Drive: The Surprising Truth About What Motivates Us. Riverhead Books, 2011.
[2] Drucker, Peter F. The Essential Drucker. Harper-Collins, 2001.
[3] Bradford, David L. and Allen Cohen. Managing for Excellence: The Leadership Guide to Developing High Performance in Contemporary Organizations. John Wiley and Sons, 1997.
[4] Takeuchi, Hirotaka and Ikujiro Nonaka. “The New, New Product Development Game.” Harvard Business Review. January 1986.
2.9 原则#9——去中心化的决策
由知识工作者自己来决定如何开展自己的工作，这是最佳的方式。
——彼得·德鲁克
正如我们在精益之屋中所指出的，目标很简单：在可持续的最短前置时间内交付价值。如果要实现这个目标，就需要快速的、去中心化的决策。任何需要上升到领导层进行的决策，都会带来延迟，也会导致决策的保真度降低，这是因为缺乏对具体环境的考虑，再加上在等待时间内会发生各种变更。去中心化的决策可以减少延迟，提升产品开发的流动，并能更快反馈和做出更多创新性的解决方案。
然而，这也并不是说所有的决策都是去中心化分散进行的。有一些决策是战略性的、至关重要的、长期有效的，这些决策最好是集中进行，而且应该被进行管理。由于这两种决策（中心化集中决策、去中心化分散决策）都是存在的，所以要确保价值可以顺利地流动到客户那里，建立一个明确的决策框架是至关重要的一步。
战略性决策集中进行
虽然员工作为知识工作者获得了授权进行决策，但是这并不能替代管理层对战略决策和最终成果所担负的责任。经理之所以能够处于管理岗位上，是因为他们具有资深的市场经验，他们具有更长远的技术视野，他们被委以重任并理解财务状况，从而能够引导企业获得正确的业务成果。所以，经理们可以也应该有权做出这些高层次的决策。
这些集中进行的决策特点是：发生频度不高、长期有效、对于经济效益有重大影响。
其他非战略性决策分散进行
然而，绝大多数的决策并没有达到需要进行战略性决策的高度。这些决策发生的频度很高，通常时间上很紧急，但是没有重大的经济效益的影响。
这些决策就可以授权团队分散进行，因为团队更加了解具体的执行情况和环境，也具备解决技术复杂度的详细知识，而且他们的日常工作就是在一线解决这些具体问题和交付价值。
建立决策框架
领导者授权团队进行决策，并不意味着他们对于决策的成败可以袖手旁观。为此，企业应该建立一个可以在不同层级上进行决策的框架。决策框架基于并属于经济框架（原则#1）
的一部分，是考虑了决策背后的逻辑性和经济合理性而建立起来的，决策框架可以授权包括个人和团队内的各种角色，进行决策的制订和实施。
一个有效的决策框架可以为企业带来许多益处，比如更快的上市时间、更高质量的产品和服务。有效的决策框架还有助于释放知识工作者的内在动力（原则#8），从而带来更高的员工参与度和更好的员工满意度，进而有助于带来企业绩效和企业文化非常显著的提升。
参考资料
[1] Drucker, Peter F. The Essential Drucker. Harper Collins, 2001.
[2] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
