DevOps 向业务进阶，BizDevOps 要如何实现？

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 的实施。

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

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

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

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