在一般的大中型规模企业，一个产品的创意从无到有，再到上市为止，可能需要经历几个阶段（如图3-2所示）。

图3-2价值创造过程

这个过程跨越了市场、产品、研发、设计、生产、销售、运营等多个部门。对于那些由软件和硬件集成的产品，还需要将软件项目（或软件项目群）与硬件团队拉通，对齐交付节奏才能确保整个产品的成功。

精益软件大师玛丽·帕彭迪克提出了八个精益软件开发原则，其中之一是全局优化原则：只有将整个价值的创造过程进行改革，消除浪费环节，优化全价值流 ，提升整体价值流动的效率，才能最大化地提升组织的效率。因此，只有从团队级敏捷上升到产品级敏捷，才能够从客户的视角来观察：如何加速从提出一个创意或者反馈开始，到交付给客户为止的整个循环的过程。

产品级敏捷，是以整个产品的价值流为单位开展敏捷转型。产品级敏捷与团队级敏捷关注的视角有很大不同。团队级敏捷关注单个团队的效率、质量和士气等。而产品级敏捷所关注的是一个产品或产品每个版本的TTM，旨在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里，在需要的情况下调整组织结构，让价值流上的每个团队协同交付，最大限度地减少交接、等待，去除价值流动过程中的浪费，从而达到缩短TTM，并通过缩短产品的质量反馈时间来快速提高产品质量，最终提升客户满意度。

通信企业B在开展产品级敏捷后，应用规模化敏捷框架SAFe，将底层协议团队打散，与上层单板团队重新整合，成立真正的特性团队，从而最大化地去除彼此之间的依赖。然后，该通信企业应用SAFe的敏捷发布火车（AgileReleaseTrain，简称ART）机制，将各Scrum团队纳入ART敏捷活动，Scrum团队协同计划、对齐节奏、密切协作，再也不是每个Scrum团队孤军奋战了。

团队级敏捷的基本实践为产品级敏捷打下了良好的基础。进入产品级敏捷后，团队级敏捷的实践仍然需要继续夯实。除此之外，在整个产品范围内，团队一般会尝试一些规模化敏捷和精益实践，以及工程技术实践。

规模化敏捷和精益实践包括：

• 价值流映射（ValueStreamMapping，简称VSM）；
• 精益看板方法（LeanKanban）；
• 投资组合规划和管理（PortfolioPlanningandManagement）；
• ART的组织架构及其流程；
• ScrumofScrums。
  

工程技术实践包括：

• 主干开发；
• 微服务；
• 持续交付流水线；
• DevOps。
  

在很多企业里，更严重的浪费不是制造产品所产生的浪费，而是大量产品或其特性本身就没有价值或是价值很低。也就是说，这些产品或特性压根就不该走到图3-2中的第二步“形成需求”，而应在创意阶段就被杀死。但是，很多企业做产品的方式仍然是秉承着功能“越多越好”的思想，导致大量低价值的产品和无价值的需求产生。因此，产品部和市场部的工作方式也需要拥抱精益的思想，向“更少的需求，更大的价值”的方向转型。本书第8章专门介绍这个话题。

需要说明的是，不是每个企业都需要经过团队级敏捷→产品级敏捷这两个阶段。在很多初创企业，一个Scrum团队就可以涵盖价值创造的整个过程，这样的企业就不需要经过这两个阶段。但是对于那些几百人、上千人甚至上万人的大型产品线，完成一个产品的价值创造过程需要多个部门或多个团队的配合，这时一般都需要经历团队级敏捷→产品级敏捷阶段。

即使对于非初创公司，也可以采用另一种转型策略：不经过团队级敏捷，直接从产品级敏捷开始自上而下转型。具体来说，企业以整个产品为单位试点转型，需要从转型的第一天开始，将产品价值流涉及的上下游团队都纳入敏捷转型范围，调整组织结构，组建Scrum团队，导入敏捷思想和实践。这样做的优点是速度快。从产品级敏捷直接切入，涉及范围广，能够让管理层看到立竿见影的变化。但是采取这样的策略，需要保证的先决条件是：领导需要有足够的魄力决定在整个产品级组织范围内转型。此外，企业要配备足够的敏捷教练，教练既要深入每一个试点团队辅导，又要对整个产品级团队进行辅导和推动，否则整个产品级的所有团队在不知道如何做的情况下，全部同时启动敏捷，那么将会导致混乱的局面，且混乱波及的范围大、时间长，难以产生效果。

在一般的大中型规模企业，一个产品的创意从无到有，再到上市为止，可能需要经历几个阶段（如图3-2所示）。

图3-2价值创造过程

这个过程跨越了市场、产品、研发、设计、生产、销售、运营等多个部门。对于那些由软件和硬件集成的产品，还需要将软件项目（或软件项目群）与硬件团队拉通，对齐交付节奏才能确保整个产品的成功。

精益软件大师玛丽·帕彭迪克提出了八个精益软件开发原则，其中之一是全局优化原则：只有将整个价值的创造过程进行改革，消除浪费环节，优化全价值流 ，提升整体价值流动的效率，才能最大化地提升组织的效率。因此，只有从团队级敏捷上升到产品级敏捷，才能够从客户的视角来观察：如何加速从提出一个创意或者反馈开始，到交付给客户为止的整个循环的过程。

产品级敏捷，是以整个产品的价值流为单位开展敏捷转型。产品级敏捷与团队级敏捷关注的视角有很大不同。团队级敏捷关注单个团队的效率、质量和士气等。而产品级敏捷所关注的是一个产品或产品每个版本的TTM，旨在拉通产品价值流的上下游，将相互依赖的团队纳入同一个敏捷框架里，在需要的情况下调整组织结构，让价值流上的每个团队协同交付，最大限度地减少交接、等待，去除价值流动过程中的浪费，从而达到缩短TTM，并通过缩短产品的质量反馈时间来快速提高产品质量，最终提升客户满意度。

通信企业B在开展产品级敏捷后，应用规模化敏捷框架SAFe，将底层协议团队打散，与上层单板团队重新整合，成立真正的特性团队，从而最大化地去除彼此之间的依赖。然后，该通信企业应用SAFe的敏捷发布火车（AgileReleaseTrain，简称ART）机制，将各Scrum团队纳入ART敏捷活动，Scrum团队协同计划、对齐节奏、密切协作，再也不是每个Scrum团队孤军奋战了。

团队级敏捷的基本实践为产品级敏捷打下了良好的基础。进入产品级敏捷后，团队级敏捷的实践仍然需要继续夯实。除此之外，在整个产品范围内，团队一般会尝试一些规模化敏捷和精益实践，以及工程技术实践。

规模化敏捷和精益实践包括：

• 价值流映射（ValueStreamMapping，简称VSM）；
• 精益看板方法（LeanKanban）；
• 投资组合规划和管理（PortfolioPlanningandManagement）；
• ART的组织架构及其流程；
• ScrumofScrums。
  

工程技术实践包括：

• 主干开发；
• 微服务；
• 持续交付流水线；
• DevOps。
  

在很多企业里，更严重的浪费不是制造产品所产生的浪费，而是大量产品或其特性本身就没有价值或是价值很低。也就是说，这些产品或特性压根就不该走到图3-2中的第二步“形成需求”，而应在创意阶段就被杀死。但是，很多企业做产品的方式仍然是秉承着功能“越多越好”的思想，导致大量低价值的产品和无价值的需求产生。因此，产品部和市场部的工作方式也需要拥抱精益的思想，向“更少的需求，更大的价值”的方向转型。本书第8章专门介绍这个话题。

需要说明的是，不是每个企业都需要经过团队级敏捷→产品级敏捷这两个阶段。在很多初创企业，一个Scrum团队就可以涵盖价值创造的整个过程，这样的企业就不需要经过这两个阶段。但是对于那些几百人、上千人甚至上万人的大型产品线，完成一个产品的价值创造过程需要多个部门或多个团队的配合，这时一般都需要经历团队级敏捷→产品级敏捷阶段。

即使对于非初创公司，也可以采用另一种转型策略：不经过团队级敏捷，直接从产品级敏捷开始自上而下转型。具体来说，企业以整个产品为单位试点转型，需要从转型的第一天开始，将产品价值流涉及的上下游团队都纳入敏捷转型范围，调整组织结构，组建Scrum团队，导入敏捷思想和实践。这样做的优点是速度快。从产品级敏捷直接切入，涉及范围广，能够让管理层看到立竿见影的变化。但是采取这样的策略，需要保证的先决条件是：领导需要有足够的魄力决定在整个产品级组织范围内转型。此外，企业要配备足够的敏捷教练，教练既要深入每一个试点团队辅导，又要对整个产品级团队进行辅导和推动，否则整个产品级的所有团队在不知道如何做的情况下，全部同时启动敏捷，那么将会导致混乱的局面，且混乱波及的范围大、时间长，难以产生效果。