企业敏捷的三层结构：研发、业务、战略敏捷的增强回路

很多人（包括不少IT人员）误以为敏捷只是研发阶段的事——只要研发人员响应业务需求足够快，敏捷就能在企业里成功落地。两个反例足以推翻这种理解：研发能快速交付需求，但测试人员验收拖拖拉拉，功能开发完也无法上线；业务人员对需求实现和验收都很积极，但最终交付给客户的产品或服务达不到预期——这两种情况都算不上真正实现了敏捷。实际上企业中的敏捷是分层的、是一个体系化工作，从下到上分三层：研发敏捷——传统意义上的敏捷，职责是接收业务需求、输出业务能力，创新点在于把业务需求按优先级分散到持续的多个小迭代中，提升业务能力与需求的匹配度；但研发敏捷要真正达成，需要业务敏捷的支持。业务敏捷——有两个职责，向下与研发敏捷对接（业务人员要能持续提出高质量需求，同时准确判别研发提交的业务能力）、向上与战略敏捷对接（高质量需求来自业务人员对企业战略的准确理解，业务能力有时还需要组合包装后再向上输出产品/服务）——业务敏捷同时依赖研发敏捷和战略敏捷的支持。战略敏捷——企业内最高层级的敏捷，职责是根据外部环境变化不断制定调整企业战略规划，并及时向外部客户提供所需产品或服务。这三层敏捷之间的关系正是[[自顶向下与自底向上融合产生的能量：增强回路|自顶向下与自底向上融合的增强回路]]——上层敏捷依赖下层敏捷去实现，下层敏捷的目标实现又是为了支撑更上层的目标达成，只有三层协同配合、结合自顶向下和自底向上两条路线，才能持续推动企业敏捷能力的改进。可迁移启发：诊断一个团队”敏捷推行了却没见效”，先检查问题出在哪一层——如果研发迭代很快但业务需求本身质量差、或者业务需求很清晰但企业战略本身摇摆不定，问题根本不在研发敏捷这一层，而在于三层之间没有形成真正的增强回路。

结构图：

flowchart TB
  S["战略敏捷<br/>(应对外部环境变化,制定/调整企业战略)"]
  B["业务敏捷<br/>(向下接研发,向上接战略)"]
  R["研发敏捷<br/>(接收需求,分散到小迭代,输出业务能力)"]
  S <-->|支撑与依赖| B
  B <-->|支撑与依赖| R
  R -.三层协同形成增强回路.-> S