DevOps 是什么，想必大家都知道。但这个概念，并没有停止进化，而是根据开发实践的不停深入而产生了不同变种。其中，BizDevOps 便是其中最注重与业务结合的一个。

BizDevOps，也称为 DevOps  2.0，Business（业务） + Dev（开发）+ Ops（运营），是一种软件开发方法， 它鼓励开发人员、运营人员和业务团队一起工作，以使组织可以更快地开发软件，对用户需求做出更快的响应并最终实现收入最大化。

01 BizDevOps 势在必行

DevOps 为何诞生？就是为了打破开发与运营之间的部门墙。同理，BizDevOps 则更为进阶。

尽管 DevOps 弥合了开发和运维部门之间的鸿沟，但大约 30％到 35％的 IT 项目都失败了。原因通常是业务利益相关者和技术部门之间缺乏协作，这导致团队开发和业务需求之间出现差距。

据 IDC 分析师 Stephen Elliot 估计，有 30％到 35％的 IT 项目在业务价值上来说都是失败的，其他的研究则出现更高的分析结果，甚至接近 50％。许多项目都出现大规模的滞后、不断返工最后才让业务方满意。主要原因是需求定义不明确和开发人员、用户和其他利益相关者之间缺乏沟通。

为了解决这一问题，DevOps 流程演变为包括业务（Business）利益相关者。BizDevOps 是一种软件开发方法，它将非技术业务用户、开发人员和运营团队召集在一起，以快速交付符合业务和市场需求的定制解决方案。

开发团队创建代码，运营团队在代码发布后对其进行管理，管理团队审查业务关键绩效指标 ( KPI ) 的数据并为未来的开发项目设定要求。

BizDevOps 致力于从根本上改变软件的开发方式。在这种方法中，业务团队不仅设定要求，他们还直接与开发人员合作，为敏捷软件开发冲刺和积压的工作设定优先级。他们成为业务方的合作伙伴，与管理人员一起解决问题，实现业务目标。

当下，越来越多的开发团队认识到，需要与其业务方紧密协同以确保软件开发带来更好的业务成果，DevOps 帮忙实现应用程序交付、投产的高速度和高可靠性，但这远远不够，如果一个项目不能给业务提供价值，那能称之为成功吗？所以，DevOps 正在演变为 BizDevOps。

在 DevOps 的基础上，BizDevOps 需要更多的包容性。当然，想要从文化层面去根治，几乎是不可能的，而是必须从技术层给予支持。

有了低代码后，这一状况将得到根本改善：上述各角色都可以在同一个低代码开发平台上紧密协作（甚至可以是同一个人）。这种全新的协作模式不仅打破了部门墙，还能通过统一的可视化语言和单一的应用表示（页面 / 数据 / 逻辑），轻松对齐项目各方对应用形态和项目进度的理解，实现 BizDevOps。

自从 Forrester 于 2014 年首次提出 “Low-Code（低代码）” 这一概念，这几年，低代码发展迅速，在国外已经有相对成熟的商业模式了，而国内也在 2018 年左右开始热议，不少 DevOps 平台多多少少都有涉及到此概念。

02 实现 BizDevOps，我们该怎么做？

Gartner 预测，到 2021 年应用开发需求的市场增长将至少超过企业 IT 交付能力的 5 倍。面对如此巨大的 IT 缺口，如果没有一种革命性的 “新生产力” 体系，很难想象仅凭现有传统技术体系的发展延续就能彻底解决问题。

低代码 + BizDevOps 的实践，渐成大势所趋。而想要一个低代码 + BizDevOps 项目走上正轨，两个角色必须关注：

• 业务代表 – BizDevOps 流程中的关键角色。业务用户（即产品负责人）负责通过对应用程序提出需求或反馈来提供业务方面的见解，然后将其转换为用户案例。

• 开发人员 – 支持业务分析师构建应用程序，提供实际成果。开发人员专注于集成、数据模型、安全、性能等技术方面的工作。

一、开发团队方面：好的 DevOps 工具链，可以保障前端与后端之间的良性循环

开发人员之间有一个很经典的开发者循环，也就是开发人员最常见的任务，充分利用他们的技能：编码、运行、验证和调试。这也构成了一个开发团队之间的 “内循环”。

要形成良好的 “内循环”，一个好的 DevOps 工具链是必不可少的。

所有工具连接成一条链，保证了前端和后端开发人员、质量分析人员和客户之间的盈利循环。从而达到自动化开发和部署流程，以确保快速、可靠和预算友好地交付创新解决方案的目标。

这绝非易事，需要进行不断的实验和改进，以确保基本流程完全自动化。关于 DevOps 工具的推荐，可以点击查看之前的文章：《推荐！DevOps 工具正越来越自动化》。

除此之外，在工具层面我们也要擅用 AI。比如 AIOps 这个概念，AIOps 将人工智能 (AI)、分析和机器学习 (ML) 结合在一起，以自动识别和修复 IT 运营问题。通常，我们可以将 AIOps 系统作为 CI/CD 工具链的一部分并跨混合开发、测试和生产系统运行。

二、业务团队方面：让不写代码的人也参与进来

但在 BizDevOps 中，仅仅关注开发者之间的 “内循环” 是不够的。让其他部门参与进来并打破孤岛，在整个组织中建立 BizDevOps 文化，形成更大的 “外循环” 才是关键。

BizDevOps 可以帮助消除业务部门开发之间的隔阂。比如，支持新产品发布的销售和营销团队需要持续了解开发项目的进度；同时，开发人员利益相关者也需要了解业务活动。

在 BizDevOps 文化中，业务部门可以将客户反馈和要求传达到开发周期中，以便增量版本可以包含客户请求的功能。让业务部门等不写代码的人参与进来的办法有两个：

第一，允许业务部门访问文档、接受演示甚至使用测试版本等非技术办法。第二则是通过低代码和自动化等技术办法来教育业务团队。

三、最后却也是最重要的：选对平台

在目前国内的 DevOps 工具平台的选项中，飞算 SoFlu 软件机器人应该是功能较为齐全的那一类。尤其，飞算 SoFlu 软件机器人最近线的 “前端全自动开发平台”，十分有利于 BizDevOps 的实施。相关网址：https://www.feisuanyz.com/webv/

这个新上线的平台其实是一个前端开发客户端，它可以提供可视化开发模式和丰富的页面控件，实现快速开发前端界面交互和页面自定义开发，且无业务场景限制，能够简化后端接口数据联调，其生成的前端部署包还能实现应用项目私有化部署。

这一层能力的完善，也使得飞算 SoFlu 软件机器人功能更加全面且更有竞争力。如下图所示，从能力维度上对比，飞算 SoFlu 软件机器人比国内同类型产品更加全能：

同时，飞算 SoFlu 软件机器人的解决方案能够在可视化搭建、降低开发成本、提供选择模版、多终端兼容等方面实现突破，为其应用维度方面的对比带来竞争力：

依托飞算 SoFlu 软件机器人开发、测试、运维一体化的设计和可视化的低门槛开发方式，一方面可以打破开发、测试、运维之间的部门墙；另一方面可以让业务人员全程参与软件开发，从而使得 BizDevOps 能够得到真正落地。