如何将团队与业务对齐并构建可组合企业？

探讨敏捷开发中的依赖关系与业务架构

• 你说，好的，如果我们要采用敏捷开发，那么采用敏捷开发的必要前提是什么？你说好，我必须有完整的团队，最小化的依赖关系，我必须有待办事项，必须能够生产出可工作测试的增量软件，对吧，这是敏捷开发的基本前提。那么，我需要做什么来逐步创造这些条件呢？这实际上是你正在问自己的根本问题，因为没有快速解决的办法，你必须拆解这个系统，然后以不同方式重建它。我该怎么样将我的团队与业务对齐，将技术与人员及业务对齐，减少依赖关系，使人员可以更具当地自治权，并代表客户做出明智决策，因为这实际上是我们想要做的。我要探讨我经常谈到的一个概念，那就是敏捷开发中的依赖关系。我们的行业正在围绕一个非常有趣的话题打转。如果我们只讨论Scrum，我们有团队、待办事项、可工作的软件类型。在敏捷开发中，团队是指6至8人，他们在技术堆栈、他们之间以及其他团队之间拥有一定程度的自治权，他们可以根据待办事项展开工作，每个迭代大约可以生产出一个可工作测试的增量软件。关于依赖关系的概念，每当团队之间存在依赖关系时，我们必须以某种方式协调这些依赖关系。在最简单的层面上，如果我有偶尔的依赖关系，我可能会走到对面向别人寻求帮助来解决这个依赖关系，在迭代过程中如果他们有空闲时间，他们可能会帮助我。如果依赖关系是严重的设计依赖关系，那么在迭代过程中解决这些依赖关系通常是非常困难的。当组织的不同部分、技术堆栈、需求之间存在许多依赖关系时，就需要某种协调机制。我们最近谈了很多关于SAFe，我想说的是，SAFe实际上是一种协调团队之间依赖关系的方法，因为如果团队之间没有依赖关系，你就不需要它们。所以，行业正在探寻的主题是关于...上次我谈到了敏捷开放数字化的概念，这是我们遇到过的美国国防部规范中的一部分，与Joe Justice谈到的特斯拉和SpaceX正在构建汽车和火箭的方式非常相似。我最近从我的一些技术团队那里得到了一些关于领域驱动设计的内容，15年前我们第一次见面时，Dennis Stevens非常频繁地谈到的一个概念是业务架构的概念。我推测上次提到的方式可能是思考组织的业务架构、组织的能力模型以及它们的交集。

探讨敏捷开发中的依赖关系与业务架构

构建可组合企业：培养敏捷文化的关键

• 我们最终希望业务、技术和人员能够保持一致。我们想要业务与技术和员工保持一致，确实有Scrum团队、封装的发布列车、封装的价值流。如果可以做到这一点，甚至可以更进一步。如今一个非常流行的概念是产品驱动型组织是什么呢？如果我想要一个产品驱动型组织而不是一个项目驱动型组织，基本上是在说同样的事情。产品就是价值所在，这就是与业务保持一致，产品就是技术和建设它的人员所在的地方。可组合企业是什么呢？这是一个敏捷开放数字化的企业，组织实际上是由可重复使用的组件构建而成。这是一个非常有趣的想法，它本质上是敏捷社区一直在追寻的东西。我们正在谈论如何创造敏捷文化，讨论团队策略、backlogs来源、企业治理以及我们衡量和控制的内容。我们需要让团队与业务保持一致，让他们对技术栈拥有一定的自主权，这样我们就不需要在企业不同部分之间进行疯狂的协调。思考起来有点意思，因为我们是变革业务，开始自问为什么如此困难。我认为目前的挑战之一就是非常难以突破目前的限制，如果组织无法超越目前的限制，那么我们可利用的空间是多么有限呢？

构建可组合企业：培养敏捷文化的关键

重塑企业架构：理解封装和编排的关键性

• 我们常常会说，好吧，我们要购买一些新的软件包，我们要实施和设计一些新技术，我们要叠加一些新流程，但为什么我们总是会陷入这样一个境地，就好像流程不断变化，时髦词汇不断更新，攻击角度不断改变，我们所提供的产品和软件不断更替？就好像我们不断试图寻找这个圣杯，知道一切归结到封装和编排对吧？这是一直不变的基础，我认为我们作为一个社区、市场或者敏捷社区的一部分，需要思考的一个问题是，如果我们不能弄清楚如何帮助公司建立这种团队、以产品为导向的组织、可组合的企业、敏捷开放数字化等等，无论你如何看待它，如果我们不能真正地抛开当前的局限，真正地做到这一点，你知道我不想说这种戴珊的话，但这就是我们现在所做的，这是相当迷人的，我认为挑战的一部分，挑战的一部分，即使我们这些实践者意识到了，我们也不知道该怎么做，我们不知道如何编排变革，如果我是一个高级领导者，我可能会把事情委托给我的下属，我并不确切地知道，需要改变的基本模式是什么，我有些许信任我的下属会做到，但其中有一个元素，就像如何让高管们理解，要做到以产品为导向的组织、可组合的企业、做一些敏捷开放数字化的事情，我们必须从根本上重新思考我们系统的架构，我们必须从根本上重新思考主驱动设计，必须重新思考我们的业务能力建模，必须从根本上重新思考我们如何编排价值，如何滋养这个系统，如果我们想要敏捷开放数字化、可组合的企业、以产品为导向的组织的好处，它们本质上都在说同样的事情，这本质上是一个封装和编排的问题，这就是公司面对的问题，试图将传统的主机转变为面向服务的架构，这可能是一个有趣的模式可以探讨，因为这就是我们在转型的世界所做的事情，如果你要把一个传统系统重构成为一个微服务、容器化、基于云的生态系统，带有测试，那么你会在软件上做什么，你实际上也在对组织做同样的事情，这非常有趣，我认为这是原则，我认为这是事情的核心真相，你要摆脱咨询顾问，摆脱流程，摆脱技术，摆脱对变革的抵制，存在着一个模式，存在着一个基础的东西，就是我们试图做的事情的核心，在如何创建封装的自主实体上有一件事

重塑企业架构：理解封装和编排的关键性

领先敏捷：改变组织和数字化转型

• 我要再次向所有人提出挑战，我认为发生的事情是，我们听到这一点并且我们同意，然后我们看着我们的组织现状，我们无法突破当前的限制，无法看到如何以有意义的方式改变组织，无法看到如何以有条理和有纪律的方式启动一项改变程序。你知道，冒险自说可能有点自私，但你知道为什么要做所有这些视频，这就是我们的工作，对吧？所以我认为领先敏捷非常像我们是一把寻找钉子的锤子，而钉子到处都有。但当有人走到我们面前，说一些像‘嘿，我们想采用敏捷’这样的话，那通常是我们开始的地方，并且我们会说，好的，如果我们要采用敏捷，采用敏捷需要哪些先决条件呢？你会说，嗯，我必须拥有完整的团队，尽量减少依赖性，我必须拥有待办事项，必须能够生成可工作的、增量式软件，很酷，这是敏捷的基本先决条件。然后你会自问，如果我无法创造这些条件，那么我不会得到我想要的业务收益，那么我需要做些什么才能随着时间创造这些条件呢？这实际上是你在自问的根本问题，因为没有简单的按钮可按，你必须拆卸这个系统，然后以不同的方式重新构建它。所以如果这是一个敏捷的问题，你必须从这个基本先决条件开始。如果我把这种隐喻应用于系统方面，我可能会这样考虑，我手上有一个我想要移至云端的传统单块系统，我有一些传统软件想要移到云端，那么你必须问自己，需要什么才能将这些软件移至不同的平台呢？你可以通过几种不同的方式做到这一点，你可以将这个传统平台移到云端，我想他们称之为云启用或类似的名称，但云启用与云就绪或原生云之间是有区别的。因此，如果要真正成为原生云，你必须将其拆分，使其更注重服务，使其更容器化，必须包裹在API中，并进行测试，以便能够充分利用云服务的优势。如果有人对我说，我想采用敏捷，你必须逐步回到这种封装和编排的问题，如果你想进行云迁移，你从根本上必须以相同的方式思考。另一个一直频繁出现在我意识中的词是数字化转型，我们正在开始看到，在行业中数字化转型被大多数视为技术问题，现在我们开始看到有关为什么数字化转型失败的文章被撰写。我认为失败的原因是因为它被视为技术问题，而不是作为一个涉及人和的问题。

领先敏捷：改变组织和数字化转型

数字转型中的困境与解决之道

• 数字转型问题并不是作为一种组织设计来看待的治理问题，就好像倾向要么是要引入新技术，要么是将现有组织包装在一套新的流程或工作方式中。但是在一天结束时，你会发现它无处不在，你无法忽视。你需要做的是，将新的数字技术融入人员当中，为他们提供更灵活的治理框架，以便进行实验。这就像一旦你看到这一模式，你就无处不见它。这实质上是一个团队战略问题，是一个协作问题，是一个依赖性问题。而我只是认为最根本的原因是，我认为这并不难理解，而且我认为大多数人都不会反对，但挑战在于看到超越当前限制的可能性。如何让组织中的人们明白这是一个质量问题，然后如何取得高层支持来进行变革，一旦获得支持，又如何管理和成本证明这种变化。在过去几年中，我们一直在进行越来越大规模的敏捷转型工作，我们的转型工作是非常有趣的，不仅仅是安装Scrum，很大程度上是数字转型、云迁移、技术升级这个领域。因此，我们称之为敏捷转型，但所有这些都是同一个领域，即如何让我的人员与业务对齐，将技术与人员业务对齐，减少依赖性，以便人员能够更具地方自治权，代表客户做出正确决策。如果我们不能克服当前的限制并制定计划，真正创造条件，那么我们将继续投入资金、技术，投入新流程、新标签。但归根结底，它仍然是同一回事，人员、流程、技术的协调。这似乎是咨询的基础，但是它意味着什么？封装、协调、减少依赖性，如果你不能封装，你必须协调，不能打破依赖性，你必须管理它们，这就是问题所在。因此，我们真正需要的是真正做到这一点的组织，这就是为什么我一直倾向于这个词“可组合企业”，因为可组合企业的概念似乎真正将系统视图、技术视图和人员视图融合成一个整体。我一直在使用这个词，试图借此更有趣、有深度。期待您的想法，欢迎留言讨论，我会定期查看并回复。

数字转型中的困境与解决之道

Conclusion:

通过深入探讨敏捷开发中的依赖关系与业务架构，可以帮助组织更好地将团队与业务保持一致，实现构建可组合企业的目标。重要的是要理解敏捷开发中的团队自治权和依赖管理，从而推动数字化转型的成功。

Q & A