企业正以越来越多地使用敏捷，这是因为正式的敏捷做法以及类似方法（例如DevOps）会给企业带来很多好处。然而，企业在更广泛地拥抱敏捷业务合作伙伴关系方面，仍然存在障碍。

在2019年发布的第13期全球敏捷状态报告中，我们看到了部署和扩展敏捷的11个常见挑战。此外，该报告发现三个最大的障碍在组织层面：最常被提及的挑战是组织文化与敏捷价值不符（52%），其次是组织对变革的抵制（48%）以及管理支持和赞助不足（44%）。

在这个问答文章中，屡获殊荣的研究人员、作家（他的最新著作是《独角兽计划》）兼IT Revolution的创始人Gene Kim讨论了CIO和其他企业技术领导者应该如何扩展敏捷到IT之外。下面让我们看看他对部署敏捷业务合作伙伴关系的观点，以及在利益相关者抵制的情况下应采取哪些措施。

对于敏捷流程（从正式的敏捷方法学到DevOps）意味着什么以及如何定义， IT与业务部门之间仍然存在脱节吗？

Gene Kim: 我们可以通过使用敏捷来解决问题，DevOps专家Jonathan Smart对DevOps的定义是：更快更安全更快乐地获得更好的价值。对于这个定义，我们很难争辩，谁不想要更开心、花更少时间来获得更多的价值呢？敏捷可消除问题和异议，并且，这是开始富有成效对话的好方法。

我们知道，敏捷是一种截然不同的工作方式，在这种方式中，我们与利益相关者建立更加协作的关系，从而带来更好的结果。因此，我们可以说：‘我希望更快更安全更快乐地提供更好的价值。’而不是争论我们如何定义特定术语，这并不会推动讨论或使我们朝着想要的方向发展。

IT似乎知道，在敏捷方面，他们是否做得很好。对于整个企业来说，成功的敏捷业务伙伴关系是什么样？

Kim：在IT Revolution主办的DevOps企业峰会中，我最喜欢看到的是技术领导者与他们的业务部门同事共同的展示。这些业务领导者不只是在舞台上与技术领导者很亲近，他们还会说：‘这是我最大的目标、梦想和抱负，如果没有这个技术人员的支持，一切都不可能实现，这种协作是我们在市场上获胜的方式。’

我喜欢看到这种画面是因为，这就是我们所有人都想要的关系-相互协作、相互支持，拥有共同目标和共同信誉。这就是目标。并且，我们看到技术领导者得到重视，他们得到升职、得到更多预算并被要求采取更大举措。

随着CIO将敏捷推向整个企业，以建立敏捷业务合作伙伴关系，他们通常会遇到哪些障碍？

Kim：每当技术专家从业务同事那里听到，‘我们无法在市场上取胜是因为，我们无法以我们想要的质量足够快地满足客户需求，’对此我们应该高度关注。技术人员有责任让其业务同事了解敏捷。

但是，业务人员可能会做些事情危害敏捷目标，例如不清还技术债务，不让工程师有时间修复缺陷，不让工程师有时间改善系统—业务部门日常依赖的系统。当发生这种情况时，就会导致恶性循环。

对工作的完成方式，也可能存在误解。他们的想法是，他们可以划分所有工作，然后将其外包到全球各地，以期获得更好的结果。但是编码是知识工作，而不是工厂工作。编码是一种对话和探索性的工作。

当你剥夺了工程师进行这项工作的能力和自由时，很多事情都会出错，例如编写40页的需求文档，以及过早地让他们对成本、范围和日期负责，而他们还不了解他们视图解决的问题。

此问题是由业务和技术领导者共同造成，因此解决方案必须由业务和技术领导者共同提出。DevOps企业峰会的演讲者们正在共同努力，消除障碍，并且对问题有共同的理解。如果你听取他们的谈话，我相​​信每个技术领导者都会羡慕，几乎每个技术领导者都渴望拥有这样一种可信赖的工作关系。

CIO经常听到关于建立信任的说法，那么，如何做到这一点？

Kim：当我们听到‘我了解问题所在，我有能力部署资源来解决该问题，并以实现这些目标的方式来完成，’时，就会建立信任。

我认为常见的障碍是，技术人员表示无法获得权限自动化或改善系统，或重新分配人员进行实验。通常，我的回答是‘你从何时需要权限？’每个领导者都有责任改善他们在日常工作中使用的程序和流程。这样做可以赢得我们的信任。

您能否列举成功建立敏捷业务合作伙伴关系的关键步骤？

Kim：安排专门的团队专门研究这些功能、特性和所需的结果。他们并没有像很多团队那样分散-他们没有在进行8、9或10个不同的项目。当他们变得有效时，他们并没有被分开和改组。你应将工作带到团队，而不是将团队带到工作。

间隔要短。检查点之间的间隔时间不超过六个月；业务利益相关者需要每周审查一次创建的内容并提供快速反馈。等待太久的反馈没有意义。

项目所有者。一个优秀的项目所有者每天将与团队互动10次，工程师每天将向产品所有者询问10次，这表明让业务利益相关者参与至关重要。

而且，还需要有正确的技术部分：自动化测试，并且，理想情况下，还需要经常对所有内容进行测试的环境。在这个环境中，他们会经常合并其代码，以便可以随时对其进行演示和使用。如果很少进行测试和部署，则可能导致灾难性结果。你不会希望在产品交由客户使用之前才进行测试和部署。

如果业务部门仍然不接受敏捷呢？

Kim：让我生气的一件事是，技术部门构建了功能，然后提供演示以获取反馈，而业务利益相关者却没有露面。这对于同事们来说，这是很糟糕的事情，这对于公司中最重要的人才，也是一种不尊重。

有时，当企业主不露面时意味着‘不要使用这些功能，因为它对业务部门并不重要。’在我看来，很明显，如果业务利益相关者不参加会议，那么意味着他们不在意。你希望你的团队致力于最重要的问题，因此，如果业务部门同事继续不露面，那么，你应该转向业务部门同事愿意参与的工作中，与他们共同创建解决方案。

你需要一支热心的敬业的团队，利用其工程技术来解决问题，并且你希望软件工程师能够提高工作效率。同时，考虑到他们的薪资水平，你不可能让开发人员不进行开发。

显然，你希望每个人都参与其中，协同工作，成为很好的合作伙伴，但不幸的是，你只有有限的控​​制权。你可以向同事展示业务领袖和技术人员共同努力在市场中取胜的例子，并询问你的业务部门同事：‘我们能做些什么来实现这一目标？你是否想为公司的未来共同创建一些解决方案？’如果他们回答‘是’，那么你就有进行良好对话的基础。如果他们拒绝，那么你可以试一试去寻找其他合作点。