企业已死，敏捷万岁！

引言

在企业中，“企业”一词常常会让人联想到重要性、复杂性、成本和规模。同样，高预算、高知名度的项目往往会导致技术部门以面向企业的软件解决方案和基础设施作为响应。

这意味着需要进行广泛的规划、评估、采购，并且通常需要数年的时间才能“做对”。以这种方式构建面向企业的解决方案的成本通常是数百万。失败的风险是极大的。

当然，面向企业的解决方案不应该意味着高成本、高风险和长周期。这通常是传统思维模式和组织结构的产物。有时也反映了企业无法或不愿意转型并拥抱变革。

本文探讨了传统企业需要具备哪些条件才能从这种思维模式转型并实现敏捷。

什么是企业？

在本篇文章的语境下，企业是指大规模复杂解决方案的规模化交付。它通常会产生面向企业的软件解决方案，这些解决方案包含专门的应用程序，可以解决组织内的特定业务需求。

“企业”一词还暗含了解决业务需求的规模、成本和复杂性，并且通常因此驱动了一种传统的部署和规划方法。它通常意味着本地部署的解决方案或第三方应用程序的管理。

传统的企业项目可能包含以下内容：

• 专门的精锐团队
• 可行性研究
• 风险评估和缓解策略
• 预先确定所有功能性和非功能性需求
• 文档和项目规划
• 与其他系统和团队的集成策略
• 迁移策略
• 成本估算
• 评估和采购流程
• 实现
• 操作指南和检查点
• 灾难恢复计划
• 部署和发布规划
• 一次性大规模发布
• 对问题发生的调查

为什么选择企业？

讽刺的是，传统的企业方法旨在降低风险、确保长期性、可维护性，并为整个业务提供最大价值。

几十年前，这样做是有道理的。部署软件和维护服务器是一个复杂的过程，需要专业的团队和专业的应用程序。它需要专门的团队来保证正常运行时间、可用性并提供 24/7 支持。部署、监控、保护和管理这些企业系统是一项全面而复杂的挑战，需要很长的周期才能实现新功能。企业围绕这些依赖性发展起来，并形成了支持它的组织结构。

随着技术和现代实践的进步，这些挑战中的许多不再存在，而且通过相对低成本的基于订阅的云提供商，可以轻松获得更优越、更具扩展性和性能的解决方案。这使得初创公司和拥抱精益原则的公司能够迅速获得竞争优势。尽管他们在产品开发方面面临同样的挑战，但他们能够更快、更便宜、更大规模地交付。

Monzo 等挑战者银行是这方面的良好实践范例，它们现在正在与巨头们争夺规模。毫无疑问，这是一个企业级的产品，但该产品是基于敏捷原则构建的，并利用了现代架构。它能够快速推出新功能，并快速适应客户的需求。

实际上，采取传统企业方法的公司在市场上的竞争力较弱。他们对风险和变革的规避反而增加了实际的风险和成本。许多项目失败，遗留系统被建立在他们本应替换的系统之上或与之集成。

这很大程度上源于传统的组织结构，这些结构导致了 IT 优先的方法，并与业务脱节。一旦识别出业务需求，IT 就会构建庞大的企业解决方案，而业务还未能从中获得任何价值。在这段时间里，市场或业务需求可能已经改变，或者对客户需求的假设可能是错误的。

在传统企业中，项目被水平地切分成孤立的团队。IT/运维团队提供企业软件解决方案来服务业务。结果是在整个项目生命周期中存在大量的沟通开销和交接点。

孤立的团队导致需要支持组织内许多需求的单体系统。这增加了部署、升级和项目管理的复杂性。由于推出这些系统需要大量投资，这也阻碍了变革。

什么是敏捷？

敏捷是一种基于简单宣言的方法论。

• 个体和互动胜过流程和工具
• 工作的软件胜过详尽的文档
• 客户协作胜过合同谈判
• 响应变化胜过遵循计划

它基于十二项原则，这些原则将最终用户的需求置于首位，这是一种重要而强大的策略。它还涉及频繁发布，并从自组织团队内部驱动架构决策，同时与业务紧密合作。

敏捷方法论实际上是促进团队协作和沟通以及自我改进和学习的框架和仪式。它有助于快速实验和迭代开发。

精益原则与测试和学习相结合，补充了敏捷的工作方式，并进一步增强了以低成本验证整个项目中的用户价值和假设的能力。这使得团队专注于完成最少的工作来实现业务目标并满足客户。这与传统的企业模式相反，后者则致力于规划和预测业务的未来需求。

为敏捷而组织

为了使公司转型并拥抱敏捷，它需要进行重组，摆脱孤立的团队。要成功做到这一点，需要打破组织中的横向切分，并重组为小型、纵向切分的“产品团队”。

敏捷产品团队应具备：

• 自组织
• 交付用户价值并验证用户价值
• 由实现产品所需的所有技能组成
• 在所有决策中拥有自主权
• 负责产品数据集和产品基础设施
• 能够独立、快速、频繁地部署
• 通过产品服务与其他产品团队松散耦合

对于转型为敏捷原则的传统公司来说，由于产品之间遗留系统的强耦合，这些往往难以实现。随着时间的推移，应消除这些交叉依赖性，并将新系统迁移到拥有它们的一个团队的控制之下。

当然，其他挑战还包括在过渡期间保持运营、知识转移和抵制变革。

选择正确的产品团队划分方式很重要，以确保产品的适当粒度，并最大限度地减少交叉依赖性和约束。这些团队应专注于特定的业务能力。

为敏捷而架构

这里我们真正指的是为持续交付而架构，以变得更加敏捷。这支持产品团队实现其业务目标。持续交付是敏捷的 12 项原则之一。持续交付本身包含一套原则和实践，以最小的风险、成本和开销来实现这一目标。

拥有完全自主权的产品团队可以自由地随着时间的推移来调整和改进其产品的架构，以满足其业务目标，而不会受到孤立的运营团队的约束和复杂性。这本身就消除了需要接触公司多个部门的企业软件的需求。它允许每个团队重新架构并简化产品路径，以满足业务需求。

绞杀企业

在转型过程中，遗留系统和产品之间的高度耦合会阻碍重新架构和发展的需求。“绞杀者模式”是解决此问题的一种方法，它允许业务在整个转型过程中继续运行。

通过“绞杀者模式”，可以一次用小增量更改替换现有系统的一小部分。它只需要最少的初始投资和风险。每一部分都在新的架构上重建，并允许逐渐蚕食遗留部分，直到完全替换。新部分可能包含新功能，并在过渡期间继续提供价值。

通常使用反向代理来使此过程对最终用户透明，并保持用户体验的无缝性。

这种方法避免了另一种选择，即对现有系统进行大规模重构、潜在的代码冻结和大规模迁移。此类项目将与敏捷原则相冲突，因为它在重写期间不会为用户提供直接价值。

英国 TSB 银行在一个大规模的一次性迁移项目中公开失败，该项目适得其反，瘫痪了其产品线。这导致客户无法访问他们的账户或资金。

摘要

为了在不断发展的市场中保持竞争力，传统公司必须拥抱整个组织的变革，并打破企业的传统。这需要大规模的业务转型，而转型始于组织结构。这包括建立专门的跨职能产品团队，并消除孤岛。

产品团队必须获得自主权和信任，以完全管理其拥有的产品，而无需外部治理或架构约束。

为了在既有的产品系列中实现必要的转型，“绞杀者模式”可以帮助团队在持续为客户提供价值的同时发展产品。这是通过现代云架构重构和新成立的产品团队中的迭代来实现的。这可能需要简化和/或替换大规模的企业系统，以重新聚焦于业务目标。

衡量这些团队的 KPI 应包括上市速度和客户满意度。一个好的团队应该能够一天部署多次。他们应该通过快速实验和用户测试不断改进。这使得团队能够快速创新，真正了解他们的客户，并在必要时进行调整。

历史

• 2018年10月7日：初始版本