谁说只有小企业才能敏捷开发？这5招让大象也能跳舞

Posted 2021-04-25 BCG波士顿咨询

导读

如今敏捷开发已经成为初创企业的标配，如果运用得当，它能大幅提升企业的创新效率。然而在人数众多、层级复杂的大企业，敏捷开发能实现么？ 

许多行业的企业都在努力向敏捷开发（Agile）过渡，它是一种不断更迭的快速软件开发方法。很多企业看上去都像在运用敏捷开发，但大多数只停留在表面或形式中，比如他们都拥有色彩明朗的会议室，每天都要召开站立会议——但这些并没有为公司带来实质性的影响。

敏捷开发常用于初创的软件公司，开发团队是整个企业的核心，目标认同、坚持不懈的努力和协作也因此应运而生。但是，对于已经形成管理层级的大企业来说，接纳一个独立自主的跨职能敏捷团队并不是那么容易。

不过，有一部分大企业已经找到了使用敏捷的正确方法。他们并没有拘泥于具体的措施，而是充分领悟了敏捷的基本原则，尤其注重将敏捷团队融入整个企业组织当中。

企业一旦真正掌握了敏捷的精髓，将获得惊人的回报。生产力可以提升至过去的三倍。据定量调查的测评结果显示，员工参与度也有质的提高。此外，新的产品性能只需几周或者几个月就可以发布，而无需花费数个季度甚至年度。创新率提升，产品缺陷和返工的情况减少。采用敏捷开发的第一年，一家银行的开发团队将每花费一美元所产生的价值增加了50%，同时研发时间减半，员工参与度增加了三分之一。

为什么用敏捷开发？

传统软件开发的弊病催生了敏捷原则。过去，软件开发一般都是按顺序进行，瀑布式开发（waterfall serving）是其写照。构思、设计、编码、测试、运营、维护都归独立的小组负责，每个小组要等上游小组完成工作后才能开工。这种思路比较低效。很多情况下，员工将大量的时间用于参加会议和克服部门间的障碍完成工作交接，而不是编写或测试代码。根据经常被援引的《混乱报告》（The Chaos Report），只有不到10%的大规模软件开发项目能够按时完成任务且不超预算。

瀑布式理念源于工程学。但是，编写不同类型的软件和造桥可不是一回事。河流不会突然改道，可软件用户却经常改变，而且需求不可预测。因此，敏捷依靠的是整合众多不同的观点以及支持软件开发者和企业管理人员之间反复沟通。

敏捷衍生出许多形式，但最核心的还是一套理念：迭代、实证、跨职能、专注和持续完善。

• 迭代。敏捷的基础是不断更迭，直到做对为止。短时间的更迭意味着团队可以迅速改变方向并且做出反应。发展是可见并且可以预测的，因为是短期冲刺的结果。移交的风险也大大降低。
  

• 实证。敏捷团队不怎么依赖于瀑布式理念常见的规划、估测和假设，而是更看重A/B测试和其他来自于终端用户的实时度量标准。冲刺的好处之一是可以快速给出实证反馈，令团队可以自我修正。敏捷团队也会测量并密切跟踪自身的活动。
  

• 跨职能。敏捷团队的成员来自各相关部门，比如交易、营销、开发，在一些行业还会有风险管理部门，来自不同部门的团队成员密切合作，目的是为了能经常从企业管理者和消费者那里获得一手反馈。团队里每一个人都有明确的分工和责任。
  

• 专注。敏捷团队要完全负起责任。他们不会同时接好几个项目。也不会在尽责后迅速离开这个项目。在持久性上，他们会产生一种责任感。
  

• 持续完善。敏捷软件开发是一个持续的工作过程，为了满足客户的需求会不断更新和试验。
  

在大企业，要想将敏捷的这套理念付诸于实践不是一件易事，因为大企业内部层级较多，比如人力资源、财务和法律部门。企业不要将敏捷视为一种全新的工作形式，而是要将其核心价值理念与现有的软件开发部门以及企业文化融为一体，必要时可做适当调整。有几个最佳的实践方法能够帮助大企业激活敏捷的理念体系。这些方法——充分融合了迭代、实证、跨职能、专注和持续完善的特性——符合大企业的现实情况，同时遵循了敏捷的根本原则。

• 迭代。敏捷团队在固定的时间内完成大量可控的工作，同时创造一个模板。基于对模板的反馈，团队继续开始新一轮任务。大企业的技术环境可能无法满足团队在两周时间内完成冲刺的要求，因此许多企业会把冲刺周期延长为四到六周。
  

• 实证。测试是敏捷模式的基石，可以确保软件的高质量以及开发活动的高效。大企业，特别是那些初次接触敏捷的企业可能没有对测试工具进行大力投入。但是，他们开始为这部分投资建立商业案例时，可以酌情放弃一部分真正的敏捷企业要执行的严格测试。
  

• 跨职能。理想情况下，团队不应该违反“披萨盒规定”——团队人数应控制在每个人都能分得一块披萨。这是为了限制人数，团队需要的是具备关键和互补技能的人才，这样才能顺利完成工作任务。但是，这个规定也可能会让大企业无法把所有需要的专家囊括到一个团队里。因此，这条规定可能会放宽，让所有实际做贡献的成员——兼职人员不算在内——都能加入团队。
  

• 专注。正常运行的敏捷团队最重要的一个元素就是“产品负责人”，作为唯一的管理者，产品负责人有权决定范围、时机、预算分配和产品特性。在纯敏捷形式中，负责人需要咨询指导小组或者管控委员会。但是在大企业中，这部分管理职责可能由两到三位高管负责，比如一位产品经理、一位商业分析师或专家、可能还有一位“产品主管”。
  

• 持续完善。敏捷团队依靠的是回顾、消除障碍和迭代，通过调整和协调工作环境及方法，继续发掘机遇提高生产力。坚信软件开发是一项持续（而非固定）进行，没有终点的工作，这份认同感比具体操作方法更重要。
  

五个秘诀帮助大企业向敏捷转变

从顶层开始

改革离不开企业顶层领导者的支持。高层管理者需要积极参与基础决策，这些决策事关向敏捷转变的企业目标以及可能阻碍成功的文化障碍和思维定式。没有这份决心，原有资金分配、人力资源和资产管理等方法将导致企业追求敏捷的计划一败涂地。这就是为什么企业领导者——而不只是技术人员——必须要负起责任。

敏捷不同于其他转变：领导者必须调动管理层向一个完全不熟悉的新方向前进。敏捷的快节奏和跨职能特色会把许多高管推出安乐窝。没有顶层领导者强有力的稳定支持，许多高管和团队将退回原位。欧洲一家大银行的CEO告诉我们，他想让自己的企业像提供金融服务产品的科技公司一样运转。

要想飞，你需要试点

在大企业中，敏捷试点项目十分有必要，因为需要通过试点才能决定敏捷是否奏效，企业能否接受敏捷理念。在企业为适应敏捷做出必要调整时，试点发挥了关键作用。

例如，在开发过程中，产品负责人需要管理开发者和消费者之间的关系和互动。这个角色既要懂技术又要懂业务。企业里可能需要两到三个人一起担任这个角色，直到培养出具备多种能力的复合型人才为止。

同样，要在一切情况下都充分进行迭代开发可能比较困难，但开发者和企业管理层之间频繁的互动和反馈应该成为常态。

通过培养相应的能力，分期开展的数轮行动可以帮助企业创造动力并确保敏捷原则和文化已经渗入企业的方方面面。

管理临界点

试点阶段结束后，下一个阶段需要更精细地操作来避免不必要的矛盾：企业虽然口头上愿意采纳敏捷，但实际操作起来依旧充满挑战。

人力资源的那一套方法，如绩效管理或许不适用于管理重在冲刺的跨职能团队，因为团队里面的个体不是最重要的，团队打拼的结果才是。即便最终的整体开销比传统的方案小，敏捷的灵活性也肯定会给预算带来压力。因为所需的准备时间长，企业可能还没有建好相应的IT基础设施来满足持续的整合和部署。而且，传统的开发团队会心怀怨恨，一部分活动会被外包出去，导致员工失去工作。

这些技术和组织层面的担忧都是现实存在，而且靠自己的力量无法解决。高层管理者们必须积极促进整合，企业几乎必然要在培训和开发上进行投资，以鼓励正确的文化和行为。

在企业内部推行敏捷有几个成功的方法。其中有一个极端的例子，媒体音乐流服务提供商Spotify为推动敏捷转型，从根本上改变了自己的组织结构。该公司的产品传送组织包括分队（squad）、部落（tribe）、分部（chapter）和公会（guild）。最基本的单位是分队——由产品负责人领导的多元化团队，为共同的目标奋斗。部落由多个相关的分队组成。分部则由多支人马组成，这些人来自不同的分队，但拥有相似的知识和经验，他们形成了直线组织。公会则是面向所有人的兴趣小组，只要感兴趣就可以加入。（见下图）其他企业则只是简单地在原有的等级结构中覆盖跨职能的小组。

只衡量对的东西

敏捷的最终目的是促进业务发展。因此，终极的衡量标准应该与企业的业绩相关。如果银行的敏捷项目目标是降低信用卡申请的撤销率，那么撤销率就应该是最重要的指标。但是为了促进业务发展，企业还需要跟踪软件可靠性、安全性、复杂性和规模。

于是，软件衡量工具登场了。企业可以用这些工具来实际验证敏捷的生产力和质量提升效果，以及Aigle团队的整体表现。

永不停止

敏捷是一个不断提高的活动。这不是一次性的行为。敏捷需要不断监测和调整，才能确保正常运行。企业需要将敏捷原则融于组织。有许多方法能够令敏捷保持下去。比如，许多企业打造起一个由敏捷项目负责人组成的团队，可以分享彼此的最佳实践经验。

敏捷的本质是创造正确的氛围，让你的员工——特别是开发人员——能够全力以赴。人们通常认为敏捷只适用于编写软件，但它最终可以成为改善企业运营，推动企业不断发展的有力工具。

关于大中华区技术优势专项的专家：

廖天舒（Carol Liao）是波士顿咨询公司大中华区董事总经理、资深合伙人。

殷伯昌（William Yin）是波士顿咨询公司资深合伙人兼董事总经理、大中华区技术优势专项领导人。