第3章
SAFe原则
3.1 原则＃ 1——采取经济视角
你可能会忽略经济，但经济不会忽略你。
—— Donald Reinertsen，《产品开发流的原则》
摘要
精益的目标是在最短的可持续前置时间内，为人类和社会提供最佳的质量和最优的价值。为了实现这个目标，需要对经济效益有基本的了解。如果没有这样的认识，即使是一个技术成熟的系统也可能需要很高的研发成本、很长的交付时间，或者由于生产和运营成本太高以至于无法在经济上支持有效的价值。
为此，整个产业链中的领导者、管理层和知识工作者就必须完全了解他们所做出决策的经济影响。传统的观点是，只有那些了解业务、市场和客户经济情况的决策者和当局者，才有必要了解这些活动与经济之间的关系。
然而，如果这些对经济相关的理解只是集中在领导者那里，就会造成基层员工在处理日常工作问题时要么缺乏相关信息，要么将问题升级到掌握信息的管理层。其中第一个选择会直接破坏经济成果，而第二个选择会导致延迟价值交付，这都会带来不好的影响。
详述
SAFe十分强调经济效益在成功的解决方案开发过程中所发挥的重要作用。因此，SAFe的第一个精益-敏捷原则就是采取经济视角。之所以是排名首位的原则，是因为如果不能满足客户或解决方案提供者的经济目标，那么解决方案能否长期存在就令人怀疑了。解决方案失败的原因有很多，其中不能满足经济要求是一个主要的原因。本章介绍了通过精益-敏捷方法达到优化经济成果所需的两个基本方面：
- 尽早和经常交付
- 理解每一个项目群和价值流的经济平衡参数
这两个方面在下文中都有概述。此外，SAFe将这些原则在各种实践中进行了实例化，例如 7.5 节所阐述的主题。
尽早和经常交付
一般来说，企业决定拥抱精益-敏捷开发，是由于当前流程不能满足生产的需要，或者是他们认为当前流程将来会被取代。在选择精益-敏捷的道路上，通常选择基于增量式的模型，尽早和持续交付价值，如图3.1-1所示。
这样的决策将会带来显著的，或许是最基础的经济效益，如图3.1-2所示。
图3.1-2展示了精益-敏捷方法在这种流程中可以尽早地给客户交付价值。而且，这些价值随着时间不断累积，客户持有时间越久，得到的价值就越大。相比之下，在瀑布模型中，价值只能按照计划在开发周期结束时得到交付。
这种差异也展示了使用SAFe的经济效益。此外，该图并没有考虑尽快得到解决方案相关反馈的好处；同时也忽略了瀑布交付模式最终可能无法按时交付，或是无法证明可用性。而且，还有第3个也是最后一个因素，如图3.1-3所示。
图3.1-3展示了一个关键的差异化优势：只要质量满足要求，产品和服务越早投入市场，价值就越高。毕竟，如果能早于竞争对手提供相应产品，客户无法从其他厂商那里获得产品和服务，就愿意花更多的钱来购买。随着时间的推移，产品就会趋于同质化和陷入价格战，也就没有了价值差异化，这就是产品发展规律。这就意味着即使是在早期提供给客户最小可行产品（MVP），也比在后期提供全面的功能更有价值。
所以产生的净效应是累积总利润会更高。这是精益-敏捷开发的基本前提——它固化在精益-敏捷理念中，更是在最短的可持续前置时间内完成解决方案开发的驱动力量。
理解经济平衡的参数
此前讨论的基本原理是采用更有效的经济模型来更快速交付的驱动力。然而，在执行项目群时仍然有很多工作要做。毕竟，解决方案生命周期中的经济决策也将最终决定交付的成果。因此，有必要更深入地讨论多种经济参数的平衡。Reinertsen（参考资料 [1]）描述了五种基本因素，可以用于站在经济角度评估特定的投资情况，如图3.1-4所示。
对于五种参数的解释如下：
- 开发费用：为了实现某种能力所需要的人力和物料成本。
- 周期时间：为了实现某种能力的时间
- 产品成本：（销售商品的）制造成本和/或部署及运营的成本
- 价值：所实现的能力对于业务和客户的经济价值。
- 风险：解决方案的技术或业务成功与否的不确定性。
理解经济平衡的参数，有助于优化生命周期的收益——这也是解锁开发中最佳经济价值的关键。然而与此同时，这需要对项目有更深刻的理解，以下是两个例子：
- 一个团队正在构建家庭自动化系统，据估计将更多功能转为软件实现可以减少100美元的电子部件的成本，但是这么做可能会延迟发布前置时间3个月。那么团队应该执行这个项目吗？答案显然是“视情况而定”。它取决于产品预期的销售量和如果推迟3个月发布产品的延迟成本（CoD）之间的对比。在做出决策之前，还需要做进一步的分析。
- 一个大型软件系统，如果有大量的技术债务，是很难进行维护的。而且开发费用是严格固定的。如果专注于现在的技术债务，在短期内将会减缓价值交付，但是从长期来看，会有利于减少未来特性交付的前置时间。那么团队应该采取这种措施吗？答案同样是“视情况而定”。在做决策之前需要更多的定量分析。
除了经济平衡的参数，Reinertsen 还介绍了一些关键的原则，有助于团队从经济的角度出发做出明智的决策。
- 量化延迟成本（CoD）的原则——如果你只对一件事进行量化分析，那就是 CoD。
- 持续经济平衡的原则——经济有效的选择必须在整个过程中持续不断地进行。
- 最佳决策时间的原则——每一个决策都有它的最佳经济时间。
- 沉没成本的原则——不要考虑已经花费的成本。
- 第一决策规则的原则——使用去中心化经济控制的决策规则。
以上最后一个原则与SAFe紧密相关，可以推导出SAFe的原则＃ 9——去中心化的决策，该原则将在 7.5 节中进一步描述。
参考资料
[1]Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
3.2 原则＃ 2——运用系统思考
系统是必须被管理的，它不会进行自我管理。如果让其自我管理，各个组件就会变得自私、相互竞争，成为彼此独立的利润中心，从而破坏整个系统。系统管理的奥秘就是面向组织目标，协调各个组件之间的合作。
——W. 爱德华兹·戴明
摘要
SAFe来源于三个基础知识体系：系统思考、敏捷开发和精益产品开发。系统思考采用全方位思考来进行解决方案开发，将系统及其环境的所有方面整合到系统本身的设计、开发、部署和维护中。
了解这些概念有助于领导者和团队掌控解决方案开发和组织的复杂性，以及总上市时间的全局视图。下面将会一一进行介绍。
解决方案就是一个系统
SAFe指导复杂软件和网络物理系统的开发和部署。它们由SAFe解决方案体现，该解决方案是有形的，可以提供最终用户价值，是每一个价值流的主题（例如，应用程序、卫星、医疗设备或网站等）。当涉及这些有形的系统时，戴明的评论“系统是必须被管理的”，会引导我们做出批判性的洞察：
- 团队成员必须清晰理解系统的边界是什么，系统自身是什么，系统如何与周围的环境及其他系统进行交互。
- 仅仅优化一个组件是无法达到系统优化的，组件反而会变得自私，并独占其他组件所需的资源（比如计算能力、内存、电力供应等）。
- 为了让系统的行为表现良好，就必须理解其预期的行为，并对其架构有更深入的了解（组件如何协同工作以实现系统的目标）。意图设计是系统思考的基础。
- 一个系统的价值会通过其连接部件进行传递，比如接口和接口之间的依赖关系，这些连接部件是提供最终价值的关键要素。持续关注这些接口及其交互至关重要。
- 一个系统的进化速度取决于系统中最慢的集成点。完整系统的集成和评估越快，系统掌握的实际知识的增长速度就越快。
构建系统的企业也是一个系统
系统思考还有第二个方面：构建系统的组织中所包含的人员、管理和流程也是一个系统。“系统必须被管理”的理念也适用于此。否则，构建系统的组织的各个组件将只做局部优化并变得自私，从而限制了价值交付的速度和质量。这也会引导我们做出另一组对于系统思考的洞察：
- 建立复杂系统是一种社会性工作。因此，领导者必须创造一种环境，使人们可以通过最优的合作方式构建最好的系统。
- 供应商和客户都是价值流不可或缺的组成部分。他们必须被视为合作伙伴，建立长久的信任基础。
- 在这种情况下，仅优化一个组件是无法对整个系统进行优化的。同样，仅优化本地团队或职能部门，也并不一定能提高企业的价值流动。
- 价值跨越组织边界。想要加快价值传递，就需要消除职能筒仓，或者创建跨职能组织，比如敏捷发布火车（ART）。
理解并优化完整的价值流
价值流是SAFe的基础。SAFe投资组合本质上是价值流的集合，每个价值流向市场交付一种或多种解决方案。如图3.2-2 所示，每个价值流包含了一系列的步骤，可以通过新系统或现有系统来集成和部署一个新的概念。
系统思考的第三个方面是理解和优化完整的价值流，这是减少从概念到现金所需的总时间的唯一方法（参考资料[2]）。系统思考要求领导者和员工掌握完整的价值流，并对其不断进行优化，特别是当价值流跨越技术和组织边界时。
一个基本的流程是价值流映射，它是一种系统的方法，用来查看产生价值所需的所有步骤。价值流映射让领导者迅速认识到实际的增值工作步骤（创建代码和组件、部署、验证等）仅仅消耗了总上市时间的一小部分。这种认知促使领导者不断关注步骤间的延迟。图3.2-3 提供了价值流映射的示例。请注意，图中从提出特性到部署之间的时间几乎全都是等待时间，从而导致一个非常低效的过程。
只有管理能够改变系统
每个人都已经尽了最大努力；问题存在于系统之中……只有管理能够改变系统。
——W. 爱德华兹·戴明
戴明的这段话为我们提供了对系统思考最后一个方面的理解——系统思考需要采取一种新的管理方式，也就是说管理者是问题解决者，他们具备长远的系统视角，并且积极清除障碍。这些精益敏捷领导者：
- 展示和教授系统思考和精益-敏捷的价值观、原则和实践。
- 参与问题解决，消除障碍和无效的内部系统。
- 使用和教授根本原因分析和纠正措施技术。
- 与团队合作，共同实现关键里程碑，帮助团队识别和解决问题。
- 具备长远眼光，投资于基础设施、实践工具和培训等支持能力，从而实现更快的价值交付，更高的质量和生产力。
总结
理解系统思考的方方面面，有助于领导者和团队真正明白他们所做工作的目的和内容，以及对周围的影响。反过来，这也会形成一个更加精益、更加智慧的企业，可以更好地处理组织结构和解决方案研发的复杂性。相应地，这也会带来更好的业务成果。
参考资料
[1]Deming, W. Edwards. The New Economics. MIT Press, 1994.
[2]Poppendieck, Mary, and Tom Poppendieck. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
3.3 原则＃ 3——假设变异性，保留可选项
创造系统级设计和子系统概念的多种可选方案；而不是过早地选择一个胜出方案，然后消除与之不同的其他可选项。只有那些存活下来的设计选项，才是最强大的可选方案。
——艾伦 C. 沃德，《精益产品和流程开发》
摘要
系统开发人员都会倾向于减少变异性，这是人的本性。表面上看起来，你认为自己经过深思熟虑并且已经做出了相应的决策，应该能走得更远。但是，现实情况往往并非如此。
虽然变异性会导致糟糕的结果，但有些时候也不尽然。
变异性的自身无所谓好与坏。相反，是时间的经济效应和变异性的类型决定了最终的结果。如果过早地专注于消除变异性，可能会导致企业萌生厌恶风险的文化，这样员工也就不能通过试错和学习来获取经验。
精益知识工作者们认识到，在项目的早期除了一些基本的系统目标之外，对项目的实际情况往往知之甚少（确实，如果能掌握所有信息，那么系统早就构建成功了）。然而，传统的设计方法往往让开发人员迅速地开始实现单一的方案，而这个方案仅仅是众多潜在解决方案中被认可的一个，然后再通过修改推荐的设计，直到最终满足系统的目标。
这也许是一个很有效的方法——当然，前提条件就是团队最初所选择的单一方案不能有误。然后再通过后续的迭代进行细化，但是最终可能需要浪费许多时间才能得到一个并不是最佳设计的解决方案（参考资料[1]）。不幸的是，如果最初选择的单一方案不是最优的，那么后果就是：系统越大越需要技术创新，所带来的损失也会越大。
一个更好的方法是，可以参考使用基于集合的设计（SBD，即多个设计构成一组）或者基于集合的并行工程（SBCE，即多个并行工程构成一组）（参考资料 [2]），如图 3.3-1 所示。
在基于集合的设计中，开发人员最初会考虑非常广泛的设计思路，提出多种设计选项。接下来，他们持续地评估经济效益和技术难度之间的平衡，在集成的学习点上，可以演示与目标的匹配情况。然后，基于演示的结果和所获取的经验，去除那些不太好的选项，收敛到一个最终的设计。
采取这种流程，可以让设计选项的持续时间尽可能延长，在必要的时候进行收敛，并最终产生更优的技术实现和经济效益。
参考资料
[1]Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review, 38. 1995.
[2]Ward, Allan C., and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.
3.4 原则＃ 4——通过快速集成学习环进行增量式构建
产品的集成点，是控制产品开发和提升系统的关键支点（杠杆点）。如果没有处理好集成点的时间，项目就会陷入困境。
——Dantar P. Oosterwal
摘要
在传统的方法中，根据“阶段 – 门限”进行开发，项目一开始就立刻投入成本，随后成本逐渐累积直到最终方案得以交付。通常，在项目执行期间极少交付实际价值，而是直到所有功能完成后才在最后一次性交付价值，有时候项目也会面临时间延期或者成本超支的问题。在开发过程中，一般很难收集到有意义的反馈，因为流程就不是为收集反馈而设计的。更重要的是，开发流程本身也并不是按照允许客户评估需求和能力的增量式提升来设计和实现的。因此，风险在项目执行中会一直存在，直到项目结束，有时候甚至会进入到部署和客户最初使用环节。
毫无疑问，这种典型的“阶段–门限”流程容易导致错误和问题，经常导致失去客户的信任。为了调整这些问题，合作双方会在项目早期进行需求定义，并选择“最好的”设计，他们也会执行更加严格的“阶段–门限”评审。不幸的是，这些补救办法实际上都存在一些潜在的问题。这是开发流程中存在的一个系统级别的问题，所以必须从系统化的角度去解决这个问题。
集成点可以从不确定性中获取知识
精益原则与实践解决问题的方式与上述方法有所不同，并不是在项目早期选择单一的需求和设计方案，也并不假设这些方案是完全可行和满足要求的，而是基于一定范围的需求和多种设计选项（原则＃ 3）进行一系列短周期（时间盒）的增量式解决方案构建。每一个基于时间盒的活动都会产出一个可工作系统的增量，这个增量是可以交付的。后续的时间盒会在之前增量的基础上，逐渐交付演进的解决方案，直至最后的发布。在集成点上，获取经验知识不仅仅是为了技术可行性研究，也可以得到最小可行解决方案或者原型，供市场验证、建立可用性、获取客户反馈等。在必要的地方，这些快速反馈点允许团队转向另一个有效的解决措施，从而可以更好地服务于目标客户的需要。
根据意图设置集成点
在一定程度上，开发流程和解决方案的设计聚焦在基于节奏的集成点。每一个集成点都会创建一个“拉动事件”，拉动各种方案要素进行整体集成，即使只解决了系统的一部分目标也会进行集成。集成点也会将利益相关者拉动到一起，创建定期的同步有助于确保方案的演进，从而解决真正的问题和当前的业务需要，而不是仅仅依赖于在流程开始的时候建立起来的假设。每一个集成点都会通过将不确定性转化成经验知识的方式交付价值，这些经验知识包括：
- 当前设计选项的技术可行性的相关经验知识
- 基于客观度量的解决方案的潜在可持续性经验知识（原则＃ 5）
通过更快的周期进行更快的学习
集成点是休哈特（Shewhart）的PDCA（计划–执行–检查–调整）循环（如图3.4-1所示）的一个示例，是控制解决方案开发中变异性的机制（参考资料[3]）。
集成点越频繁，学习速度就越快。在复杂系统开发中，本地集成点用于确保系统中的每个元素和能力都能够履行其职责，为整体解决方案意图做出 图3.4-1 PDCA循环贡献。然后，这些本地集成点也必须集成到更高的系统级别中。系统规模越大，集成的层级就越多。解决方案设计者意识到：最高层级的、发生频率最低的集成点，提供了度量系统进展的唯一标准，他们也在努力尽可能频繁地创造这些集成点。所有的利益相关者也明白：如果集成点的时间没有控制好，项目就会陷入困境。但是即便是这样，这些经验知识也会有助于激发对范围、技术方法、成本和交付时间的必要调整，以重新定向项目来满足调整后的期望。
参考资料
[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, 2014.
[3]Deming, W. Edwards. Out of the Crisis. MIT Press, 2000.
3.5 原则＃ 5——基于对可工作系统的客观评估设立里程碑
实际上，按时进行“阶段–门限”交付与项目的成功并无关系。但有些数据表明，反过来却是相关的，即成功的项目都是按时进行阶段交付的。
——Dantar P. Oosterwal，《精益机器》
“阶段–门限”里程碑的问题
现在，对于大型系统的开发需要大量资源——投资总额可以达到数百万、上千万，甚者过亿美元。开发人员和客户有义务共同确保对于新的解决方案的投资可以提供必要的经济收益。否则，何必要进行投资呢？
显然，利益相关者必须进行协作，从而帮助确保在整个开发过程中实现预期经济效益的潜力，而不仅仅是“一厢情愿”地认为最终可以得到美好的结果。为了应对这一挑战，业界引入了“阶段 – 门限”（瀑布式）的开发流程，这种流程会对一系列确定的里程碑进行度量和进度控制。
这些“阶段–门限”里程碑也不是任意设置的，它们遵循一定的逻辑性和一系列的流程——发现、需求、设计、实现、测试和交付。当然，这种里程碑的设置方法并不总能获得好的收效，如图3.5-1所示。
导致这个问题的根本原因是没有认识到在假设“阶段–门限”显示真实进展情况，从而消除风险的过程中，犯了四个关键的错误：
1.将需求集中起来，同时进行职能筒仓式的设计决策，导致了后续的解决方案缺乏完整性。
2.过早的设计决策和“虚假的可行性”（参考资料 [1]）：
- 一个早期的选择是在当时做出的最佳选择
- 随后的开发流程就假设一切按照计划进行
- 直到最后才发现最初的选择是不切实际的（原则＃ 3）
3.假设存在一个确定的解决方案，而且只进行一次尝试就可以构建成功。这样就忽视了流程中固有的变异性，并且没有提供有效的处理方法。改变将是迟早的事。变异性迟早是要表现出来的。
4.在前期就进行决策，创建了大批量的需求、代码和测试，形成了很长的队列。这也导致了大批量的工作交接和延迟的反馈（原则＃ 6）。
基于客观事实设立里程碑
显然，“阶段–门限”模型并没有像预期的那样降低风险，所以就需要一种不同的方法。
原则＃ 4 提供了解决这一困境的一些要素。
在整个开发过程中，系统进行增量式的构建，每一次构建都是一个集成点，在集成点上可以演示一些已经实现的内容，以验证当前解决方案的可行性。与“阶段–门限”开发方法不同，基于客观事件所设立的每一个里程碑都包含研发的所有步骤——需求、设计、开发、测试），从而达到增量式的价值交付，如图3.5-2所示。
此外，这种里程碑会基于的节奏进行（原则＃ 7），一个固定的节奏可以形成一种纪律，确保定期提供可用性和评估，同时能提前确定时间边界，也可以用来去除那些不太理想的选择。在关键的集成点上要对哪些要素进行有效的度量呢？这取决于所要构建系统的类型，关键点在于利益相关者可以在整个解决方案开发周期内频繁地对系统进行度量、评价和评估。这样可以提供财务、技术和符合目标的组织治理，从而确保持续的投资可以产生与之相匹配的回报。
参考资料
[1]Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
3.6 原则＃ 6——可视化和限制在制品，减少批次规模，管理队列长度
接近满负荷地使用产品开发流程是一场经济灾难。
——Donald Reinertsen
摘要
为了实现最短的可持续前置时间，精益企业努力实现持续流动的状态，即新的系统可以迅速地从概念到盈利。实现持续流动需要消除传统方法中的基于“开始－完成－开始”的项目启动和开发流程，也要消除阻碍流动的现行“阶段–门限”的方法（原则＃ 5）。
实现流动的三个关键点是：
- 可视化和限制在制品。
- 减少工作项的批次规模。
- 管理队列长度。
可视化和限制在制品
团队和项目群的工作过载，任务量超出了他们所能承担的范围，这是一个常见且有害的做法。过多的在制品（WIP）会影响优先级，导致频繁地在不同工作场景之间进行切换，并增加开销。这种情况会使员工作过载，将注意力集中在即时任务上，降低了生产力和吞吐量，并增加了交付新功能的等待时间。
纠正问题的第一步是让当前的 WIP 对所有的利益相关者清晰可见（如图 3.6-1 所示）。这个看板说明了每一个步骤的工作总量，也作为对初始过程的诊断，并显示出当前的瓶颈。通常，仅需简单地可视化当前的工作量就可以唤醒团队成员，让他们开始意识到要解决同时开展工作太多而没有形成流动的问题。
下一步就是处理在制品数量和可用开发容量平衡的问题。如果在执行过程中，达到了WIP的上限，就不再承接新的工作任务。
然而，限制在制品（WIP）是需要有知识、有纪律和有承诺的。甚至有些时候看起来是反直觉的，比如以前有些人认为放入系统的工作越多，完成的就越多。这种关系在接近满负荷之前是成立的，但是如果超出了一定的限度，系统就会变得动荡，也会降低吞吐量。这说明，有效的WIP管理是不可取代的。
减少批次规模
减少在制品和提高流动性的另一种方法是减少工作的批次规模，这些工作包括需求、设计、编码、测试和其他相关工作。小批量通过系统的速度更快，变异性更小，并能够促进快速学习。速度更快的原因是显而易见的。变异性减少是由于批次中事项数量的减少。因为每个事项都会有一些变异性，所以大量的事项会累积成更多的变异性。
从经济的角度上来看，最优的批次规模依赖于持有成本（延迟反馈、库存损坏和延迟价值交付带来的成本）和交易成本（准备和实施该批次的成本）。如图3.6-2所示，说明了“U型曲线”是批次规模的最优曲线（参考资料[1]）。
为了提高处理小批量的经济效益，从而增加吞吐量，团队必须聚焦在减少批次的交易成本上。通常包括增加在基础设施和自动化上的关注和投资，包括考虑比如持续集成和构建环境、DevOps自动化，以及系统测试的配置时间。以上这些关注都是与系统思考的融合（原则＃ 2），也是进行长期优化的关键要素。
管理队列长度
实现流动性的第三个措施是管理队列长度并减少队列长度。利特尔法则（基于排队论的法则）告诉我们，系统提供服务的等待时间等于队列的长度除以平均的处理效率（虽然这可能听起来很复杂，可是在星巴克排队买咖啡的时候也会证明利特尔法则的有效性）。因此，假设平均的处理效率一定，队列越长，等待时间越长。
对于解决方案开发来说，这意味着无论团队多么有效地处理工作任务，只要团队实现的工作任务队列越长，那么等待时间就越长。因此，要实现更快的服务，就必须减少队列的长度或者提高处理效率。虽然提高处理效率是一个有价值的目标，但是减少等待时间最简单的方式是减少队列长度。在工作中，可以通过保持较短的待办事项列表和并不过多进行承诺来做到这一点。同时，可视化工作有助于确定简化流程的方法，同时缩短队列长度以减少延迟，减少浪费并增进对于成果的可预测性。
实现流动的三种主要方式是：可视化和限制在制品、减少批次规模和管理队列长度，这三种方式对于提高吞吐量非常有效。通过采取这些方式，可以触发在客户满意度和员工参与度方面的快速和可衡量的改进，对敏捷团队及其客户也可以带来收益。
参考资料
[1]Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
3.7 原则＃ 7——应用节奏，通过跨领域计划进行同步
节奏和同步可以限制变异性的累积。
—— Donald Reinertsen，《产品开发流的原则》
摘要
解决方案开发在本质上是一个内在不确定的过程。否则，解决方案早就已经存在了，下一代解决方案的创新也就没有空间了。这种内在的不确定性风险与企业活动是相互冲突的，比如企业活动需要管理投资、跟踪进展、对于未来成果有足够的信心，从而制定计划和承诺一个合理的行动实施。
精益-敏捷团队在“安全地带”中工作，这个“安全地带”有足够的不确定性提供创新的自由，同时也让企业有充足的信心来保证运营。实现这种平衡的主要方式是了解当前所处的状态。而应用节奏、同步和跨领域计划有助于对当前状态的了解。
节奏
节奏是流程中稳定的心跳，可以提供一种优雅的节拍模式。节奏让日常工作有规律进行，从而使知识工作者可以管理解决方案开发过程中那些可变的部分。通过将不可预测的事情变得可预测，节奏带来了很多额外的益处：
- 等待时间可预测，如果你所需要的工作交付物不在当前的这个项目群增量（PI）时间盒内，那么可能就会在下一个时间盒内。
- 通过引导计划活动，使人员和资源的使用更加有效。
- 降低了关键活动的交易成本，这些活动包括计划、集成、演示、反馈和回顾等。
同步
同步允许在同一时刻从不同的角度出发，进行工作任务的理解、解决和集成（如图3.7-1所示）。其结果是：
- 将系统中不同的资产进行整合，以评估解决方案的可行性。
- 将开发团队和业务团队的共同使命协调一致。
- 将客户融合到开发的流程中。
总之，尽管有前面描述的风险，节奏和同步——更为重要的是相关的其他活动，仍然可以共同帮助团队充满自信地开展工作。
通过跨领域计划进行同步
在SAFe的所有活动中最关键的一环是：所有的利益相关者定期聚集在一起进行跨领域的计划和同步。这项活动被称为PI计划，它是所有其他活动的支撑，它也使团队有机会展示和评审当前的真实状态。
PI计划活动的三个主要目的是：
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.
3.8 原则＃ 8——释放知识工作者的内在动力
看起来，任务的绩效提供了内在的奖励……这种驱动力……可能与其他元素一样，都是基础……
——丹尼尔·平克，《驱动力》
摘要
精益-敏捷领导者必须接受一个相对较新的、改变游戏规则的事实：对于知识工作者的管理其实是一个自相矛盾的说法。正如彼得·德鲁克指出的：“知识工作者比他们的老板更了解自己所从事的工作”（参考资料 [2]）。在这种情况下，员工完全更有能力自己定义必要的工作以达成他们的目标，那么经理们如何试图细致地监督，甚至亲自协调这些员工的技术活动呢？
事实上，经理们做不到。经理们能做的是释放知识工作者的内在动力。下面将介绍一些实施指导。
利用系统视图
在深入了解其他的激励机制之前，我们必须注意到一个重要的见解，即SAFe的精益-敏捷原则本身也是一个系统。此外，这个系统的元素相互协作，创建了一个新的授权模式。通过 SAFe，知识工作者现在能够：
- 跨越职能的边界进行沟通
- 基于对经济效益的理解进行决策
- 获得有关解决方案有效性的快速反馈
- 参与持续和增量式的学习并提高掌控能力
- 参与更高效、更充实的解决方案开发过程——这就是最强大的动力之一
了解薪酬的作用
许多组织的运作仍然基于那些已经过时的、对人员潜力和员工绩效的假设，而且大多基于传统观念而不是科学。这些组织继续追求的做法是，短期激励计划和按照证据的绩效工资支付方式，但实际上这种度量方式并不奏效，甚至会带来危害。
——丹尼尔·平克，《驱动力》
丹尼尔·平克和彼得·德鲁克，以及其他一些学者指出了知识工作者的薪酬激励因素的一个基本悖论（参考资料[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 Ikurijo Nonaka. “The New New Product Development Game.” Harvard Business Review, January 1986.
3.9 原则＃ 9——去中心化的决策
由知识工作者自己来决定如何开展自己的工作，这是最佳的方式。
——彼得·德鲁克
摘要
在最短的可持续前置时间内交付价值需要去中心化的决策。任何需要上升到领导层进行的决策都会带来延迟，也会导致决策的质量降低，这是因为缺乏对具体环境的考虑，再加上在等待时间内会发生的各种变更。
相反，去中心化的决策可以减少延迟，提升产品开发的流动和吞吐量，并能更快反馈和做出更多创新性的解决方案。
战略性决策中心化进行
当然，并不是所有的决策都是去中心化分散进行的。有些决策是战略性的，其影响深远，超出了团队的范围、知识或职责。此外，领导依然对成果负责。他们还拥有市场知识、长远视角，并了解引导企业所需的业务和财务状况。
那么，这些决策应该是集中进行的，它们具有以下特征：
- 发生频度不高——这些决策通常是不紧急的，并且适合做更深入的思考（例如，产品战略、国际扩张）。
- 长期有效——一旦做出决策就不大可能改变，至少在短期内不会改变（例如，对标准技术平台的承诺、围绕价值流进行组织调整的承诺）。
- 对于经济效益有重大影响——这些选择会带来巨大而广泛的经济效益（例如，常用的工作方式、标准开发语言、标准工具、离岸外包）。
领导层负责制定这些类型的决策，并得到受决策结果影响的利益相关者的支持。
其他类型的决策去中心化进行
绝大多数的决策并没有达到需要进行战略性决策的高度。这些决策都可以授权给团队分散进行。这些类型的决策包括以下特征：
- 发生频度高——分散决策所要解决的问题是反复发生和常见的（例如，团队和项目群待办事项列表的优先级设定，实时界定敏捷发布火车范围，对缺陷和紧急问题的回应）。
- 时间上很紧急——这些类型决策的延迟会带来高昂的延迟成本（例如，单点发布，客户紧急事件，与其他团队的依赖关系）。
- 需要本地信息——这些决策需要考虑特定的具体环境，无论是技术、组织，还是特定的客户或市场影响（例如，向特定客户发布版本，解决重大设计问题，个人和团队的自组织以应对新出现的挑战）。
去中心化的决策应由那些了解具体环境，并详细了解当前情况的技术复杂性的工作人员决定。
一个轻量级思考的决策工具
了解决策的制定方式有助于知识工作者更加清晰地了解决策过程。领导层的责任是建立决策规则（例如，包括经济框架），然后授权其他人进行决策。图3.9-1展示了一个简单的工具或练习，用于考虑决策是中心化进行还是去中心化进行。
