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 能够得到真正落地。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
