很多企业已经走在敏捷转型的路上，首先始于电信和互联网公司，然后是金融行业，现在连零售这样的传统行业都在尝试转向敏捷。 

从2001年敏捷宣言宣布到现在，已经有将近十五年的历史。十五年，在我们这个变化迅速的软件工程行业已经是一个非常悠久的时期了。敏捷并不是什么新玩意，但它已经成为我们行业主流的管理运营体系。 

如果一个企业还没开始拥抱敏捷思想并付诸实践，那它很快就要out了！原因很简单，为了快速响应市场需求的变化，企业采用和拥抱一些敏捷的方法和思维是必须的。  

走向敏捷并不表示完全放弃目前的工作方式。很多企业可能会觉得目前的运营有敏捷所不具备的优势，但在这个快速变化的时代中，持续改进已经成为必然，敏捷有很多成熟可操作、可落地的改进方法是完全可以被拿来借鉴的。如果一个企业对现有的工作方式太执着，结果必然是逐渐边缘化，直到被市场淘汰。  

十年前，很多企业对敏捷有所怀疑，说敏捷不成熟。但如今形势恰恰相反，一个还没有拥抱敏捷的企业会怀疑自己到底出了什么问题，为何不愿意敏捷、为何敏捷不起来。

在2007年，每当我介绍敏捷，都一定会跟瀑布模式做个比较，解释敏捷的好处。眼下我再给企业介绍敏捷时，已经不谈瀑布了，大家都知道敏捷的好处，解释也变得多余。现在我遇到的问题大多是如何让敏捷落地，如何把敏捷带给整个企业。 

即使敏捷已经是主流了，一个企业也不应该为了敏捷而敏捷。敏捷是要解决具体问题的。企业具体问题在哪？有哪些痛点？涉及哪些方面？这些问题应该从组织结构开始梳理。  

图1展示了一个典型的企业组织结构。上层负责指定方向，规划、预算、决策、治理和激励。在执行层面会有业务部门直接与用户对口。用户的请求和期望由业务代表来收集。如果组织有复杂的系统应用组合，往往会有一个解决方案部门，负责整理需求传达给开发和测试。开发测试交付的软件系统由运维部门来运营和支撑。  

我咨询过的很多企业，从互联网企业、传统企业、到嵌入式产品厂商等，他们的组织结构大概就如图1。 

图1 典型企业组织结构  

虽然图1是一个高度抽象的组织结构展示，但它有益于让我们在讨论企业痛点时找到具体聚焦的主体：是业务侧，还是解决方案侧；是开发测试侧，还是运维侧，亦或是决策层的问题？  

企业的痛点一般是如何让各部门端到端的更好协作，那么具体痛点在哪？瓶颈在哪？具体哪些部门必须更加敏捷灵活的运作来响应市场变化？

很多企业在尝试敏捷的初期往往都会从一个小范围开启，大部分会从开发测试小团队开始。小团队的敏捷方法和理论非常成熟，比方说Scrum的小团队迭代运作，极限编程（Extreme Programming）的用户故事（User Story），持续集成（Continuous Integration），看板（Kanban）等。  

图2 小范围的尝试，小范围的效果  

小团队敏捷运作的方法和理论是很成熟的。有能力让小团队敏捷落地的教练和资源也很多。  

• 如果企业的应用都是十人以下小团队能够完成的，那么实施Scrum和XP就会获得一些效果。但如果只停留在小范围的尝试，必然只有小范围的效果。

• 如果企业有比较复杂的系统，开发团队上百人的话，那Scrum和XP就远远不够了。

不管企业团队大小，如果企业敏捷落地只限于开发测试这一侧，没有执行层端到端的考虑，以及和企业上下对齐的思维，就不能发挥敏捷的潜能，就失去了获取更大效益的可能。  

没有组织层面的支持，小团队的良好效果也不容易持续，反而很容易倒退。组织一旦想踏上敏捷的道路，就必须要有决心，必须要有长远的目标，必须考虑企业的整体敏捷转型。 

除了小团队必须敏捷之外，一个拥有大型开发团队的企业还必须解决一系列的问题。我与许多上千人企业的管理者和工作者交流他们面临的挑战，做了一个总结（看图3）： 

图3 大型企业的挑战 

这些企业面临的挑战包括：  

• 端到端的敏捷：如何让执行层端到端的运作更加顺畅稳定？包括前端的需求管理和后端的运维协同。前端的业务代表往往非常希望需求能够快速上线，而后端运维则希望系统稳定，能不变是最好的。在这样的矛盾中，大型组织必须思考如何建立一个快速又稳定的开发通道。

• 跨团队协作敏捷：团队之间和项目之间如何协作得更好？每个小团队都有他们的目标和工作量，团队之间的工作计划如何更好的对齐，减少协作的成本和不必要的等待或者冲突？我经常观察到由于团队之间冲突导致工作中不必要的拖延，浪费了时间非常可惜。

• 用户互动敏捷：如何更好得贴近用户聆听他们的需求？业界调查显示，大部份开发后的功能都没人关注，甚至没人用。用户对这些功能觉得无所谓，没太大的感觉。如何更有效的理解“用户真正想要什么”是一个挑战，企业要考虑如何让整个组织具备这样的共情能力。

• 人力敏捷：个人能力是非常重要的。在一个大的企业里，人员能力参差不齐，如何提高各个层面人员的能力，让他们学会自我管理，是企业必须解决的问题。如果能够达到这一点，就会减少很多的管理成本。

• 战略治理敏捷：执行层面运作如何有效的与决策层面结合？决策层的举措如何有效的落地到执行层面？执行层面遇到市场机会时如何有效反馈到规划层面从而指导方向调整？

• 文化敏捷：敏捷以人为本。一个大型企业由于人数众多，很容易忽略个人特别是基层的战士。我们这个行业有“屌丝”和“码农”这种说法，说明对基层不够重视的情况长期存在。事实上他们也很有想法，有改进的意愿。如何激励他们，发挥他们的价值和协助他们成长是企业文化建设中必须考虑的。

当企业在考虑以上的挑战时，会发现小团队敏捷运作的实践，已经不是企业敏捷转型所关注的重点了。小团队有效的运作仅仅是个基础，而企业需要的是整个组织的战略和布局。就像一名将军或总司令，看的是整个战场，不只是一兵一卒，看问题需要更加宏观。 

要解决一个大型组织面临的挑战，办法不是没有的。敏捷方法也在持续的演进中，从开始仅仅解决开发侧的问题，到如今已经延伸到整个组织的运营体系中。目前，业界所强调的已经不是团队的敏捷（Team Agility），而是产品端到端的敏捷（Product Agility），以及整个企业的敏捷（Enterprise Agility）。

图4 大型组织的敏捷实践 

敏捷方法和理论有丰富的实践（Practice）和经验总结。这几年来，我花了不少时间总结这实践。在企业内，除了小团队敏捷Scrum和XP之外，还必须引入许多方法和实践（见图 4）。 

• Super Scrum：不仅小团队需要Scrum，Super Scrum拔高了一个层次，指导跨团队和项目的运作。

• 前端协同和后端协同：当然也必须有前端和后端的敏捷。前端敏捷包括敏捷的需求管理，有效的概念过滤，需求的ROI排序，尊重开发侧的能力和容量而不强压需求。后端除了稳定上线之外，避免上线的风险，提供运营的反馈。

• 一个产品的演进是经过很多市场需求积累的。如果需求的实现没有标准化，代码和架构很快就会腐烂。标准化不仅仅能够提高软件本身的质量，也能够提高开发的效率。有了标准，各职责都知道要做什么，实现起来简单，评估也简单。

• 贴近客户包括与客户进行有效的接触和快速反馈。借鉴用户行为分析，构建用户的同理心，有效挖掘客户和用户的痛点，形成明确的产品定位。

• 质量不仅仅需要后端的测试和验证，更重要的是如何进行更有效的设计。这包括产品设计、业务设计、系统设计和不可缺少的代码设计。这些设计能力，必须融入到各成员的习惯中。

• 大型企业必须要有针对每个个体的回顾和反馈体系。这不是一件容易的事，企业不仅仅需要时刻聆听用户，也必须有效地聆听每个成员的心声。一个团队开心就会积极，一个团队积极，什么问题都能解决。

• 以上的实践必须有一个改进工作组来落地。这个工作组必须具备分析、说服、探索、尝试、总结等能力，改进也必须有章法。

每个实践是解决企业运营上某个问题的一种方案。每个实践（Practice）有具体的操作指导，还有交付对象、交付物、职责、活动、模式等定义，这样能够方便学习和落地。建立实践的架构也应该有方法。 

一个大型企业不是说变就变的，需要一步一步来，首先选择一些基础的实践来落地，然后逐渐延伸到整个企业的运营。

图5 显示了一个可参考的大型企业的敏捷转型路标  

图5 大型企业敏捷转型路标（共参考） 图5的横轴代表时间。从企业当前的运营来看，可以首先让开发测试团队内部运作，通过Scrum或XP的实践，让团队先养成敏捷运作的习惯，然后是整个执行层端到端的敏捷运作，再延伸到上层的战略治理和基层的大规模回顾与激励，确保改进能够持续。  

有一个敏捷转型路标非常重要，这是企业踏上敏捷转型的关键步骤！在这条走向敏捷的道路上，企业必须一开始就明确改进工作组，来协商制定这个路标。有了路标，就能给各参与者一个统一的方针，管理他们的期望，从而推动企业敏捷实践落地的方向和计划，进而有助于衡量进展和效果。 

敏捷就是响应变化。敏捷的落地也必须敏捷，也必须按照实际情况而演进，所以企业必须明确自己的步伐和节奏。经过以上的实践积木化，就能够有一个相对灵活的路标。希望通过以上的积木识别，协助你的企业走向敏捷。

作者介绍 黄邦伟（微信：huangyaoshiboshi）

• 黄博士从2000年开始辅导团队和组织，协助团队和组织走向敏捷，精益，优化架构，梳理需求管理流程，以加强团队协作，设计更好的产品。

• 《基于用例的面向方面软件开发》和《软件工程的本质：运用软件工程方法与理论内核》作者。