在企业里，业务与 IT 之间的合作或许是个问题，而人们正在寻找解决它的方法。例如形成使用业务 -IT 融合的单一实体，以增进 IT 的业务价值。或是借助 DevOps 来增进开发和运营之间的协作，让它们携手支持业务需求。又或是通过使用“全民政治”（注：代议制的对称，指使用基于个体的共识决策法，自上世纪末开始被引入到企业管理中）来让组织机构中的沟通渠道显现，从而连接敏捷团队与业务的利益相关者。
David Ramel 撰写一篇有关应用开发趋势的文章，题为 Forrester 的研究显示，业务及软件开发脱节：
阻碍软件开发项目更加成功的主要因素之一，是这样一种导致业务与 IT 之间缺乏协作的企业文化：业务领导将 IT 部门看作“执行命令者”，而 IT 领导则持有相反意见。
对于实际上二者之间协作得怎么样，业务和 IT 双方的看法有很大差异：
43% 的业务决策者表示，两个部门共同决定将要交付的业务服务或产品。
59% 的 IT/ 工程领导表示，他们与业务部门的同事协作；而 57% 的 IT/ 工程领导表示，IT 作为合作伙伴与业务利益相关者联合决策。
今年早些时候，InfoQ 在持续交付加速了创新的步伐中涵盖了 Forrester 的这份研究。读者在注册后可以下载关于持续交付的 Forrester 研究报告的完整版。该报告提出的主要建议之一是“业务领导和 IT 领导需要提高他们的协作”。
（……）传统企业需要转变其组织机构模型，改变将软件开发提供方视作执行命令者的思路，更多地将其视作交付业务技术（BT）的合作者。IT 部门则需要重新设计其组织机构以聚焦于端到端的服务交付，而不是围绕着功能性卓越中心（CoE）进行组织。
在博客文章业务 -IT 融合需要真正的协作中，Michael Maurer 探讨了业务 -IT 协作：
融合是将两个或更多事物结合以形成单一实体的结果。那么我们是否曾经目睹过业务和 IT 结合以形成单一实体？
IT 往往作为独立部门来组织，而不是“与业务融合”。这样的组织方式让协作难以实现：
但因为 IT 往往被视作业务的支持部门，所以它常被当作供应商，而不是业务合作伙伴，或者甚而是业务整体的一份子。业务管理者扮演着客户的角色，IT 则被当作供应商对待；而对于充当这一角色，IT 既不踌躇，也不抗拒。
Michael 建议组织机构应该改进协作并努力促进业务和 IT 的融合：
首先要承认 IT 是业务的一部分，而不是一个独立的功能性专业团队。每个业务管理者也即是 IT 管理者，同时 IT 需要聚焦于深度理解用户。这就要求真正理解业务驱动因素，以及 IT 如何做出积极影响。业务和 IT 应该共同肩负实现良好 IT 的责任。
Kevin Parker 在博客文章如何使用敏捷来打下基础中分享了他对敏捷和协作的观点。他阐述了所了解的敏捷实践的问题——覆盖了小部分流程：
敏捷的设计初衷是为了让价值更快地回流到组织机构。然而，每个敏捷项目都不是孤立存在的。如果 IT 的其他部分无法跟上正在进行的开发工作，或是业务无法理解应该如何参与，那么最优解将永远无法实现。
Kevin 举了这样一个例子：由敏捷开发团队来交付软件时，如果他们还不能应对频繁发布的话，IT 生产会受到影响；而如果他们不能及时理解新的功能，服务台则会面临挑战。而 DevOps 支持开发和运营之间协作，它将有助于为业务需求进行服务：
解决类似发布管理这样的挑战是以下二者之间的区别：敏捷成为开发团队可以利用的良好方法，或是成为业务上不断变更的竞争优势。DevOps 运动正在解决敏捷现有的问题，并正在探寻如何让文化和理解带来更大的业务价值。
Derwyn Harris 在她的博客文章采用全民政治将敏捷扩展到整个组织中表示，“拥有更大、更复杂项目的组织机构正在努力采用敏捷”。当组织机构构建孤立作业的敏捷团队时，业务和 IT 之间的联系就断开了。全民政治的理念有助于寻找这一问题的解决方案：
全民政治让组织机构能够通过创建交叠的“圈子”和“双重链接”来精简沟通渠道。圈子是独立负责某个目标（例如一个 Sprint）的若干团队。双重链接确保每个交叠圈子中的代表们的出席。这并不是简单地让某位管理者在一个圈子中出席并倾听。双重链接则确保能够快速传递沟通和决策能够，而不会丢失信息或导致混淆。
Derwyn 解释了如何使用全民政治来让组织中的沟通渠道变得可视化：
一项很好的演练是记录下来在组织机构中观察到的每个圈子。（……）接下来，按它们如何沟通来连接，并确定谁代表了双重链接。这样就有机会发现某个人在许多圈子中扮演了单一链接的角色，或是发现圈子间完全没有直接交叠。沟通的破坏由此而生，而这也正是敏捷失败的主要原因。
暂无签名
中国开源发展研究分析 2022
本次报告为开发者，技术管理者，开源社区运营、市场，开源办公室工作人员带来信息上的增量以及对开源趋势、...
评论