您真的需要复杂的企业规模敏捷框架吗？
所以您正在运行一个大型复杂的企业规模运营。您正在团队层面进行敏捷工作，现在您已经准备好解决企业规模的敏捷性了。您像企业规模敏捷框架迈向了第一步。哎呀！您可能刚刚犯了一个大错误。（文章来源：ADT MAG）
敏捷最初是作为软件开发人员如何更好合作以制作优秀软件的哲学而引入的。敏捷宣言隐含着一种理解，即这需要个人作为一个团队一起工作。随着大公司采用敏捷性，他们认识到他们的团队还需要共同努力，创建一个更大的集成整体。
例如，智能恒温器公司可能需要将其新恒温器（硬件和固件）的发布与利用这些新功能的后端服务和移动应用程序的发布进行协调。医疗保健公司可能需要在支持其电子病历、实践管理系统和患者门户网站的团队之间进行协调。一家大型在线游戏公司可能需要协调其计费系统的更改，并发布新的游戏，该版本现在具有应用程序内购买功能。
这些都是似乎需要执行不同任务的多个团队进行大规模协调的举措的例子。但他们真的吗？
你真的需要企业规模的敏捷吗？
在我们深入之前，让我们首先确保我们都对我们正在讨论的内容有一个共同的理解。我故意使用“企业规模的敏捷”一词，而不是“企业敏捷”。当然，您应该努力让您的整个组织灵活：您希望您的整个组织能够交付价值并拥抱变革。通过使用“企业规模的敏捷”一词，我指的是大型组织试图管理大量负责交付不同软件、固件和基础设施的团队之间的依赖性，可能在组织的不同部门内，以便作为一个整体，他们可以同时提供大量协调价值块，但有一项谅解，即如果缺少任何部分，它将否定正在交付的大部分或全部业务价值。
在上述三个例子中，唯一可能需要大规模、复杂、相互依存和协调努力的例子是智能恒温器。硬件的规则与软件截然不同。需要建立供应链和订购零件。恒温器发货后，就发货了。硬件无法更新。除非制造商愿意通过支付无线更新功能来增加制造成本，否则固件也很可能无法更新。
但还是...我们应该努力打破依赖关系，增加简单性。
从这个方向看：你宁愿努力实现某种形式的企业规模的敏捷性，以增加交付价值的日常负担；或者，你宁愿通过寻找减少或消除团队间依赖性的新方法来努力降低复杂性，从而减轻交付价值的日常负担？
我们怎么做？
现在，我从未声称这很容易。不是。这需要时间、努力和实验。与其大爆炸性地解决这个问题，不如采取有影响力的小步骤，不断走向更好的状态。
这里有一些想法需要考虑。
概念1：通过将部署与发布脱钩来消除发布依赖
我之前讨论了抽象的功能切换和分支。也许其中最强大的方面是能够在尚未启用功能的情况下将代码部署到生产中。
考虑一种情况，即多个团队必须发布新功能，以便为用户提供新的跨团队功能。按照传统方法，每个团队将协调其时间表，试图按时发布。如果一个团队错过了截止日期，他们会将其他团队扣为人质，从而难以或不可能构建和发布其他功能。为什么？发布跨团队功能后开发的新功能也会发布跨团队功能的一部分，并可能破坏系统。
通过使用功能切换，每个团队继续独立部署。如果一个团队在截止日期前还没有准备好，则功能切换没有启用，但每个团队都可以部署跨团队功能的一部分，同时继续发布其他功能。当所有团队都准备就绪时，功能切换将启用，用户将看到新功能。
概念2：利用云计算
云计算，无论您使用公共云还是私有云，都会改变我们对构建和发布软件的看法。随着计算能力按需提供，在开发期间支持高峰使用时间的成本大幅降低。云计算方法对企业规模的敏捷性很重要，它使调试新的基础设施和服务器配置与软件的开发和部署脱钩。
使用云原生或云就绪的软件，旋转新环境要容易得多。这意味着单个团队有能力旋转一个全面或部分生产式环境，以独立于其他团队进行测试。如果他们还无法访问其他一些团队构建的软件，也许因为这些团队落后于计划，团队可以在此期间构建模拟。团队可以持续集成，而不是以预先定义的企业范围节奏进行集成。
利用云计算的另一种方法是使用蓝绿色部署和金丝雀部署来降低风险。新版本部署到新的生产环境中。新的生产系统可以根据需要进行测试。完成最终测试后，少数用户将被重定向到新环境以收集反馈，然后再移动到所有用户。
将蓝绿色和金丝雀部署与功能切换相结合，可以实现强大的回滚功能，使每个团队能够独立部署软件，同时安全地发布跨多个团队的功能。
概念3：通过减少每个团队的代码所有权来消除代码更改依赖性
通过允许团队间依赖项修改彼此的代码来删除它们。我们宣扬全团队代码所有权，但随着开发人员和技术数量的增加，这变得非常困难。考虑采用类似于开源模型的东西，其中团队可能拥有软件模块的最终所有权，但允许其他团队提交补丁。这有助于能力管理。拥有代码的团队可以继续处理他们的优先事项，而需要更改的团队可以在尊重另一个团队的边界和责任的情况下进行更改。
概念#4：通过轻触式架构治理消除架构依赖性
架构治理经常受到不好的批评。没错。严格的自上而下的治理的高压架构会导致笨拙的解决方案，这些解决方案在纸面上看起来不错，但在实践中行不通。高压、整体架构很少工作良好，并导致团队之间不必要的耦合。
当架构治理从执行工作的团队中冒出来时，它的工作效果更好，取决于团队之间的实际协调需求，而不是架构纯粹主义。
尽管如此，在实现企业规模的敏捷性方面，架构治理是有一席之地。团队在界面点的一致性越强，他们就越容易集成软件。架构和设计的一致性降低了集成不正确和不必要的复杂性的风险。
例如，考虑采用微服务架构的案例。这是一个众所周知的解决方案，用于支持多个自给自足的团队，它们之间耦合松散。基于服务的体系结构，无论微观与否，都允许对可以同时继续支持传统功能和新功能的接口进行版本管理。应用全局版本策略使团队在准备就绪后更容易知道如何访问新功能。API网关等工具可以帮助促进自助式集成方法，每个可用的API/服务版本都有很好的文档记录和易于访问。
概念5：通过改变组织架构消除组织依赖性
确定团队、部门和部门之间的依赖关系。在可能的情况下，进行重组，以减少依赖性。这可能也意味着团队之间的责任转移。将您的组织映射到您的价值流。如果他们位置不对齐，请更改它们。
最后的想法...
整个企业的敏捷性不需要锁定步骤的全公司协调。从以用户为中心的方法驱动您的价值流。根据需要进行调整。转移人员和资源以保持平衡。这并不是要提前做所有聪明的思考和计划，而是要让每个人都保持协调。这是关于给自己工具、可见性和灵活性，以便能够推动业务，并每天思考协调挑战。
那么，您需要企业规模的敏捷框架吗？也许吧。但我会先做上面的所有事情，甚至更多。
关于作者
博士Mark Balbes担任WWT应用服务架构副总裁，并领导政府和财富500强公司的多个敏捷项目。1992年，他在杜克大学获得了核物理博士学位，然后在俄亥俄州立大学继续研究核天体物理学。博士Balbes自1995年以来一直在工业部门工作，将他的科学专业知识应用于软件开发学科。他带领了像少数软件开发人员一样小的团队，以及在美国、加拿大和印度设有开发中心的多国工程部门。无论是担任产品经理、首席科学家还是首席架构师，他都围绕敏捷开发、敏捷架构和敏捷项目管理原则提供技术和思想领导。
声明：发表于The Open Group APAC雷达栏目的文章不一定代表官方观点。文内对出版物、产品或服务的评论和分享并不构成对购买的认可或建议。
限量速领
新年兴「书」礼！官方数字化转型发布物礼盒装等您遇见！限量速领！
