大规模敏捷：敏捷扩展到传统管理领域

2001年敏捷宣言的诞生，标志着敏捷方法在软件产业酝酿多年后的诞生，并逐渐成为软件行业的事实标准，其中的追求真实价值、快速反馈、消除浪费的价值观，结合TDD、全程自动化、持续重构的工程方法，逐渐发展成为今日的DevOps,确实大大提升了软件产业的生产效率。

但是敏捷方法在推广应用中，永远面临着一个问题，就是在纯软件、小规模团队产品很有效的敏捷方法一旦移植到结合硬件、大规模团队的产品，就发现很多东西失去了魔力，再也无效了。因为在敏捷扩展方面，开发并不是最大的难题。要想运行的更快，需要在很多方面做出改变，比如产品规划、财务、采购、产品管理、数据管理和后期运维等。这些改变需要花费很长的时间。在这些涉及到传统管理的领域，现有的敏捷方法就显得小儿科，传统的很多管理方法都产生在工业时代，例如大企业往往在多年前就会进行战略规划，有三到五年的规划，也有年度规划，这个似乎天生就会拥抱变化的敏捷抵触，看起来过时，但并不能简单的说这种规划就是错的，大规模企业不做中长期规划是不可想象的，动辄几万人的企业，总不能说大量员工不知道我们的目标在何方，到公司上班了才知道今天的工作是什么，这样会造成巨大的混乱和浪费，重点在于说这种战略规划也要有快速反应的能力，去适应这个改变速度越来越快的世界，如果不能快速响应，倒下的Motorola、诺基亚等公司就是实例。

大体量的公司如何在战略级别快速的响应市场，引入敏捷快速响应的思想？业界大牛们进行了多年的探索，慢慢诞生了SAFe、Less、DAD等多种适合大规模项目的规模敏捷框架，其核心思想，就是在敏捷开发的基础上，增加了管理协调的机制，把一个公司从市场分析，到研发实现，以及后期运维的流程整个覆盖，其过程首先是分而治之，把大团队划小，各个小团队按照快速敏捷的方法运作，在各个团队之间加协调层，其二是敏捷框架脱离研发层，逐渐向上扩展到业务和战略层。在一个框架内，公司战略和产品规划都可以快速调整，适应市场变化，结合底层的实施团队层实敏捷开发，以及中上层进行各个团队的协调和组合，最后达成公司的商业战略目标。下面就是几种典型的大规模敏捷框架：

SAFe框架

提供了三层管理模型，分别由战略层、产品组合、实施团队构成。具体详见下图。

战略层：进行企业级业务、架构等战略决策的集中处理，主要视角是价值和投资，通过Epic进行跟踪和呈现。

产品层：关注某一个基本产品、解决方案或价值主题目标的产品，规划Release Train中，，通过这层的协调，多个团队在进度、范围方面产生对齐，帮助管理风险，并与组织价值流保持一致，实现战略；

团队级别：各实施团队利用现有的SCRUM、XP实践，进行交付。

LeSS (LeSSLarge-Scale Scrum)，把多个Scrum团队组合在一起，共用一个Product Backlog。LeSS一般能支持8个Scrum团队。依靠一个统一产品负责人协调不同团队，进行定期的Sprint评审，其中各团队的代表会一起分享他们的进度跟潜在的整合风险。LeSS Huge框架支持在一个产品中投入几千人。

DAD（Disciplined Agile 2.0)，这个框架有三个阶段，前期是概念期-团队规划项目，构建期-不断增多的产品目标，和移交期-团队保证方案满足客户需求并能交付。