不知不觉中，敏捷已经成为传统行业的流行语，虽然敏捷这个词在软件行业，尤其是互联网行业已经流行了十几年。在朋友圈里，人们不断听到敏捷，敏捷这个，敏捷那个。似乎敏捷是能解决所有问题的银弹。如果不用敏捷这个词，再厉害的管理实践方法，也不够抢眼，不够酷。随着互联网公司借助资本的力量进入传统车企，高敏捷的大旗增加了车企员工的焦虑。频繁走访各大敏捷课堂、敏捷社区，高大上的抽象词汇和“中国田园敏捷”让人摸不着头脑，进一步加剧了焦虑。事实上，如果我们研究敏捷的背景，我们发现这个敏捷不是敏捷。或者敏捷软件开发的价值可以被严格地应用到业务中。或者，认为推进SCRUM或DevOPS工具链是业务敏捷性。一个又一个“乱花渐欲迷人眼”。 　　

　　总结一下，敏捷这个词出现在三个地方：软件敏捷(产品敏捷开发属于这一类)、业务敏捷和组织敏捷。读者不禁要问，三者有什么区别和相似之处？如果我们看英文原文，会发现软件开发敏捷中用到的英文单词是Agile——敏捷开发。而业务敏捷性和组织敏捷性使用敏捷性——业务敏捷性和组织敏捷性。在英语中，敏捷和敏捷都表示“总是计划和做工作，在这种情况下，需要做出改变是工作的重要部分”。敏捷和敏捷的区别只是在词性上。目前看来，敏捷应用在商业或组织中的本源已经失传(欢迎有线索的读者留言)。然而，大胆的猜测来了。敏捷应用之所以要区别于软件敏捷，是为了避免生搬硬套，闹出“抄袭别人”的笑话。 　　

　　追根溯源，可以总结出软件敏捷性、业务敏捷性、组织敏捷性的共性(客户价值是商业活动永恒的主题。这里就不描述了，以免啰嗦。): 　　

　　一种工作管理的哲学 　　

　　无论是软件敏捷、业务敏捷还是组织敏捷，都是一种方法。它是一种哲学思想，可以指导我们制定相应的计划，并在实地实施(见图3)。对于作者来说，敏捷这个词其实是一个伞字，代表一种快速灵活的工作管理思想。因此，当实施的对象不同时，具体的方法和做法也会有所不同。比如敏捷在软件开发中的应用，体现了如何快速、高质量地开发软件产品；如果将敏捷应用到业务中，就是如何灵活响应客户需求，高质量快速交付产品或服务，实现业务的最终目标。如果总结敏捷工作方法的特点，我觉得有两点非常重要。第一，速度，尽可能减少不产生客户价值的浪费(速度的潜台词隐含着对高质量的要求。从精益和敏捷的角度来看，低质量的产品也属于浪费)，缩短产品或服务的交付时间；二是柔性，需要不断改进以适应多变的VUCA(波动性、不确定性、复杂性、模糊性)商业环境，与时俱进。 　　

　　拥抱变化 　　

　　我们目前的环境是VUCA的。随着人们获取信息的速度越来越快，获取信息的方式越来越方便，人类商业活动同步加速，企业的商业环境变得复杂多变。正如我们常说的，变化成为常态。唯一不变的是变化。于是，我们之前所依赖并运作良好的战略、计划、控制和预测开始出现了无法应对VUCA的复杂局面。同样，我们在经历了值得骄傲的事情后，也开始出现无法应对新事物的情况。因此，当今复杂多变的商业环境迫使我们需要一种拥抱变化并快速应对变化的方式。一种 　　

以人为本

敏捷（Agile）一词最初来自于应用软件开发行业，是在2001年，仅有17位软件大牛参加的软件开发敏捷会议上，由参与者，Martin Fowler ，取自他正在研读的一本书《Agile Competitors and Virtual Organizations: Strategies forEnriching the Customer》，之后敏捷一词逐渐被泛化。但无论是软件敏捷还是业务或组织敏捷，以人为本是确保敏捷工作方法得以落地实施的根本。从图一的软件开发敏捷宣言中，我们可以看到最初倡导的软件开发价值观，“个体和互动”，“客户合作”都与人及团队密切相关。而“工作的软件”和“响应变化”都需要有经验和技能，并保持开放心态的知识员工来确保。同样，在业务或组织敏捷中所倡导的实践方法，尤其强调对个体技能，领导力重视，以及组织文化转变，产品或服务创新和企业家精神的培养，而这一切，都离不开对人和团队的激励与尊重。

图一

我们讨论了软件敏捷，业务敏捷和组织敏捷的共性。那么，他们之间有啥区别呢？

首先，三者的应用范围不同

如同精益一样，敏捷是一个Umbrella词汇。如果我们将其作为修饰词去掉，软件敏捷，业务敏捷和组织敏捷的工作范围将定位于软件，业务和组织。三者之间的关系可以用下图二描述。

图二

具体来讲，

软件敏捷是基于敏捷宣言定义的价值观和原则的一系列框架、方法和实践的总称（见图三）。这些方法的共性标志是强调开发团队与产品所有者之间的密切配合，不断评估开发需求、计划和结果，频繁交付小的、可用的价值“增量”。敏捷软件开发是跨职能协作的自组织团队，团队成员之间的信任和开放式的沟通、协作是敏捷核心。软件敏捷在具体的落地实施过程中，也可能是分步，分阶段进行的。例如，可能是开发团队先落地实施SCRUM 团队，然后逐步扩展为系统工程团队，系统测试团队，实现了软件产品从需求到验证、确认的全链路敏捷交付。软件敏捷逐渐泛化，与精益产品开发模式逐步融合，形成了精益产品开发方法论（也有人称之为敏捷产品开发）。典型的敏捷开发实践方法有SCRUM，FDD，XP，DSDM等。而大规模敏捷，如LeSS，SAFe等，是对软件开发敏捷的进一步扩充，横跨了软件敏捷和业务敏捷，并囊括了软件敏捷与部分业务敏捷的实践方法。

图三

业务敏捷是指公司确保其主营业务具备竞争优势的能力或行为。敏捷的业务能力可以使公司，在VUCA商业环境下，具备灵活，快速交付客户及利益相关者价值的能力（Flexible）。当公司运营碰到瓶颈或者困难时，具备能够快速恢复的能力（Resilience）。业务敏捷的范围要远超单纯的软件开发，它涵盖了组织的主营业务流程，从客户来，到客户去（见图四）。业务敏捷覆盖了业务价值流程中涉及的多个或者全部部门，如销售，产品，技术，开发，测试，交付，运维等。

业务敏捷包括了4个维度：

1. 快速交付（与软件敏捷是一致的。但是，涉及的价值流程可能更长，涵盖的部门更多。）
2. 产品创新
3. 自适应组织
4. 企业家思维

业务敏捷的详细描述可以参阅公众号视频：业务敏捷。典型的业务敏捷方法框架如DevOPS，就是实现了从产品开发及运维的端到端业务交付。其他的业务敏捷方法框架包括，例如来自IT业界的IT4IT，来自PMI的DAD（Discipline Agile Development）, Full SAFe等。

图四

组织敏捷 - 组织有大有小。所以，很多时候，组织敏捷与业务敏捷可以互换。当我们把组织视作企业整体，如此一来，因为企业可能运营多种业务 （如图五展示的不同公司的组织业务架构），相应地，组织的范围将超越了业务范围本身。这里，组织敏捷是指企业能够快速应对多变，复杂，混沌，动荡的商业境况，能够成功地做到或重生，或掉转经营方向。

典型的企业，包括了总经办，销售，市场，技术，研发，采购，制造，财务，人力资源，行政管理，法务，IT和售后服务等职能组织。所以，组织敏捷是对企业的一场全方位，多维度的变革。这个变革范围，要远超主营业务的敏捷变革。变革的深度也进入到深水区，变革的阻力也会越来越大。

注：业务敏捷与组织敏捷，除工作范围有所区别，其实践方法基本一致。为简单起见，在后述的段落中，我们使用组织敏捷统一称呼。

图五

其次，三者的实践方法不同

软件敏捷的开发方法非常多，包括了敏捷宣言的12原则，包括了诸如结对编程，CICD，测试驱动，等不同的软件开发实践方法。敏捷软件开发也包括了如何构建、激励自组织团队及团队沟通的实践，如团队看板，每日站会等。这些实践方法相对具体，容易落地实施。相对应的是，业务或组织敏捷，其实践方法却相对偏“软”，更“务虚”一些。业务或组织敏捷的实践方法，除去核心产品或服务的开发，更多关注在这6个方面（REGCLS），涉及到：

• 组织弹性（Resilience）
• 组织员工（Employee）
• 组织管理（Governance）
• 组织文化（Culture）
• 组织领导者（Leadership）
• 组织策略（Strategy）

在业务或组织敏捷的REGCLS的任一维度，有大量的不同实践方法指导组织的运作。不同的咨询公司，也推出不同的方法论。在此，作为管中窥豹，上传图六（From AgileCenter）及图七（From AgileBusiness），与大家共鉴。

图六

图七

第三，三者实施的周期及重要性不同

如图八，我们分别列出了典型的软件开发敏捷框架及其实践方法，同时也列出了组织或业务敏捷的实践方法。整体看起来，软件敏捷的方法部署时间相对更短一些，效果显现更快一些（很容易在软件开发团队实施落地。当然，开发人员规模不同，落地实施效果的显现时长也会各不相同。）。反观业务或组织敏捷的实践方法，其效果显现却是长期的，需要在日常工作中不断地践行，规范员工行为，养成良好的习惯，最终形成公司文化的转变。这个过程可能是几年，甚至更长的时间。软件开发敏捷也涉及员工技能及团队管理的“软技能”。这些技能域跟组织或业务敏捷的要求也是不谋而合，其落地实施的时长也会相对较长。作为组织敏捷的重要一环，创新是永恒的话题，企业需要时刻反思自己的产品及商业模式，积极应对市场的变化。具体的方法可以参阅公众号文章– 商业模式创新和颠覆式创新

图八

结论：

综上所述，从软件敏捷，业务敏捷到组织敏捷，他们的工作范围一个比一个大；实施的实践方法一个比一个务“虚”(后者更侧重于软实力的培养)；但对于企业业绩的影响，其重要性一个比一个重要；实施效果的显现周期，也是一个比一个长。

组织在引进敏捷时，需要参考几个原则：

第一， 要牢记 “罗马不是一天建成的”；同样，组织的文化建设也不是一天就可以完成转变。尤其需要注意的是，在重构业务或组织，引进敏捷时，需要清楚组织自身短板 - 战略，技术，管理，人员还是领导力（企业家精神），根据不同的问题，选择合理的方法及落地框架。

第二， 组织如果是单纯的软件研发团队，可以考虑软件敏捷的引进。分阶段或者一步到位，实施变革，涵盖软件开发的各个主要职责部门。具体的敏捷框架可以是SCRUM，XP，FDD或者LeSS，SAFe等。

第三， 组织如果是嵌入式产品开发团队，可以考虑软件敏捷中的精益产品开发的方法引进，对软硬件产品实施不同的敏捷精益方案；当然，SAFe和LeSS也提供了类似的借鉴方案。

第四， 组织如果是云端SaaS软件开发团队，那么，需要的可能是业务敏捷，如DevOPS方法，打破开发与运维的壁垒，实现持续交付，持续部署的目的。

第五， 组织如果是事业部的编制，独立核算，拥有独立的业务及战略决策权，可以考虑业务或组织敏捷的引进。SAFe或者LeSS或者DAD框架，提供了一定的参考。但是，敏捷不是万能的银弹。是Revolution还是Evolution，需要组织的慎重决策。组织可能需要的只是PMO管理方法，可能只是OKR或者KPI的绩效管理，也可能只是规范化的开发流程，或者需要的是产品创新与创意管理。“只选对的，不选贵的”

第六， 组织如果决策在整个公司级引进组织敏捷。那恭喜你，你开始走向了一条不归路- 可能是光明的未来，也可能是万丈深渊。所以，组织需要清醒地认识到：

1. 公司的规模多大 - 如果是10~30人的创业公司，需要的可能是Lean Start Up之类的方法；
2. 公司要解决的问题是什么？
3. 全面走向敏捷的考量有哪些？

如果不能清楚回答上述问题，这已经证明组织领导者没有精益敏捷思想的基因组织转型失败的概率将大大升高。

写在最后：敏捷是一个Umbrella词汇。任何不经调研，泛化软件敏捷适用范围的做法，必定有其背后的原因-“Promote Something To Sell”。