DevOps已向业务进阶,如何实现项目研发效率的提升?
DevOps = Dev(开发)+ Ops(运营),是一种软件开发方法。随着企业业务对软件系统日益依赖,IT管理与研发模式也随之对“敏态”模式产生了需求,也就是今天时常提起的DevOps。提升效率和软件的质量,是DevOps实践的核心内容之一。
一、DevOps之“作业流”分析
软件工程将软件的生命周期定义为问题定义、需求分析、软件设计、程序编码、软件测试、运行维护等过程,无论是对于传统模式、敏捷模式还是DevOps模式,软件生命周期过程是基本一致的。
软件生命周期各个过程也组成了软件工程的“业务流”,而在不同团队采用相应地开发模式中,具体执行的开发及相关的活动,我们则成为“作业流”。
DevOps实践中,最主要改进的内容,就是对于这些 “作业流”的活动进行“关停并转”,从而实现整体与局部上对于效率的提升。完成这些作业需要开展的活动,可以分为以下3类:
1、人与人的互动
这类活动交互的双方均为自然人,如业务需求收集,活动的特点是具备高度的不规则与不规律性。
2、人与机的互动
这类活动交互的一方为自然人,一方为依托于计算机的程序,如编码作业、人工审核/审批等,活动的特点是人的活动必须依循计算机相关主题的规则,部分活动可以抽取为规范化的过程。
3、机与机的互动
这类活动的特点是交互的双方都是依托于计算机的程序,如编译构建、自动化测试,活动的过程高度规范化。
不同的作业类型,在效率提升的优化中,需要采用的方法各有不同。
二、DevOps效率提升之协作
协作的本质是在不同的主体之间进行快速、有效的信息共享,从而进一步协调各主体进行步调一致、有序的工作执行,实现整体上的一致性与顺畅性,协作是DevOps实践中效率提升的重要方向和内容之一。DevOps实践中的协作更多需要是从软件生命周期整体系统化考虑与设计,协作设计上面主要包括以下两个方面。
1、信息共享
传统的模式中,相关业务信息仅共享于各阶段内部,而在DevOps实践中,则更强调信息的跨阶段共享,面向产品的全生命周期,共享信息包括:
业务类信息:即业务目标、业务背景、业务需求、业务限制等信息。
执行类信息:即软件开发、编译、测试、部署等执行的相关信息,如开始时间、结束时间、执行时长、执行操作记录等。
反馈类信息:即各步骤、阶段执行的信息反馈,如需求拆分反馈、任务执行反馈、代码扫描结果、测试结果、发布验证结果等。
DevOps时间的信息共享,需为以上信息提供统一的信息管理与分析平台。对于代码编写之前的阶段提供如敏捷协同的工作协同管理模块,以记录需求、任务分配、需求完成进展等信息,对于代码编写之后的阶段,则提供相对完整的执行记录信息以及必要的通知信息,以构建及时的反馈。
2、协作调度
协作调度是DevOps协作实践中另外一项关键内容。通过工具平台的驱动,实现对于“机与机的活动”全自动协作调度,对于“人与机的活动”简化协作调度,对于“人与人的活动”事件驱动协作调度,进而实现优化协作调度的效率,提升协作效果。
全自动协作调度
全自动的协作调度主要是通过DevOps平台的流水线引擎实现,通过流水线编排的实现指定作业流自动执行,执行过程中自动完成不同阶段的信息交互,过程无需人工参与。
简化的协作调度
简化的协作调度也是通过DevOps平台的流水线引擎实现,在流水线作业流中编排需要人工干预的节点,但仅需要人工给出通过/终止等简单的指令型信息即可。
基于事件的协作调度
基于事件驱动的协作调度,主要是用于“人与人的活动”,也可以用于“人与机的活动”,其通过通知、待办等事件方式,实现精准的信息共享与推送,驱动协作的下游方快速接受和推进事务工作。
DevOps实践中的协作调度的效果可以通过研发效能来进行初步的评估与衡量,通过衡量,我们可以较为清晰的获知哪个阶段的协调调度是关键阻碍点或可以进一步优化。
三、DevOps效率提升之持续优化
持续优化,是DevOps效率提升的第三个主要方面,也是践行DevOps理念的重要实践。持续优化需要解决优化什么、如何优化等问题。这些问题的解决,需要应用DevOps精益分析的理念实践。精益分析,本质就是对数据的统计、分析与挖掘。
1、数据获取
精益分析所涉及的数据应从需求提出到用户访问形成一个端到端闭环。数据的获取需要从业务系统本身以及支撑业务系统的DevOps平台两个方向获取。早期可以以DevOps平台相关数据的获取为主要来源,后续可持续集成非DevOps平台以及来自业务系统埋点获取的数据。在整个过程中,需要做到数据的及时性、准确性与完整性。
2、数据分析
数据分析需要有明确的目标和针对性,如针对业务需求提出到上线的平均周期、开发返工趋势等,通过数据分析,可以快速找到当前影响效率的关键点,从而实现针对性的改善。
3、数据呈现
数据呈现即为数据应用,数据呈现可以采用两种方式进行。
协同管理
将数据获取/分析的结果,在DevOps的协同管理平台实时的反馈和呈现,从而推动PO/开发团队/干系人等根据反馈信息快速推进效率优化,通过量变引发质变,通过团队内自我优化的方式实现效率的提升。
度量分析
针对于与效率相关的重点指标,通过可视化大屏等方式,进行专项的度量分析,并在管理与项目团队共享指标信息以及指标的变化趋势,通过全局监督的方式推进效率的提升。
四、BizDevOps
文化上的协同打破了流程与部门的屏障,共享了信息,协作了调度;过程中的自动化消除了重复性的工作,降低人为风险;业务系统与DevOps平台的数据支持精准提供优化的方向。DevOps之所以能为企业提升效率在于DevOps的实践实现软件生命周期的业务流与作业流的一致与顺畅。
BizDevOps,也称为 DevOps2.0,Business(业务) + Dev(开发)+ Ops(运营),它鼓励开发人员、运营人员和业务团队一起工作,以使组织可以更快地开发软件,对用户需求做出更快的响应并最终实现收入最大化。
1、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。
2、实现 BizDevOps,我们该怎么做?
Gartner 预测,到 2021 年应用开发需求的市场增长将至少超过企业 IT 交付能力的 5 倍。面对如此巨大的 IT 缺口,如果没有一种革命性的 “新生产力” 体系,很难想象仅凭现有传统技术体系的发展延续就能彻底解决问题。
低代码 + BizDevOps 的实践,渐成大势所趋。而想要一个低代码 + BizDevOps 项目走上正轨,两个角色必须关注:
业务代表 – BizDevOps 流程中的关键角色。业务用户(即产品负责人)负责通过对应用程序提出需求或反馈来提供业务方面的见解,然后将其转换为用户案例。
开发人员 – 支持业务分析师构建应用程序,提供实际成果。开发人员专注于集成、数据模型、安全、性能等技术方面的工作。
一、开发团队方面:好的 DevOps 工具链,可以保障前端与后端之间的良性循环
开发人员之间有一个很经典的开发者循环,也就是开发人员最常见的任务,充分利用他们的技能:编码、运行、验证和调试。这也构成了一个开发团队之间的 “内循环”。
要形成良好的 “内循环”,一个好的 DevOps 工具链是必不可少的。
所有工具连接成一条链,保证了前端和后端开发人员、质量分析人员和客户之间的盈利循环。从而达到自动化开发和部署流程,以确保快速、可靠和预算友好地交付创新解决方案的目标。
这绝非易事,需要进行不断的实验和改进,以确保基本流程完全自动化。关于 DevOps 工具的推荐,可以点击查看之前的文章:《推荐!DevOps 工具正越来越自动化》。
二、业务团队方面:让不写代码的人也参与进来
但在 BizDevOps 中,仅仅关注开发者之间的 “内循环” 是不够的。让其他部门参与进来并打破孤岛,在整个组织中建立 BizDevOps 文化,形成更大的 “外循环” 才是关键。
BizDevOps 可以帮助消除业务部门开发之间的隔阂。比如,支持新产品发布的销售和营销团队需要持续了解开发项目的进度;同时,开发人员利益相关者也需要了解业务活动。
在 BizDevOps 文化中,业务部门可以将客户反馈和要求传达到开发周期中,以便增量版本可以包含客户请求的功能。让业务部门等不写代码的人参与进来的办法有两个:
第一,允许业务部门访问文档、接受演示甚至使用测试版本等非技术办法。第二则是通过低代码和自动化等技术办法来教育业务团队。
三、最后却也是最重要的:选对平台
在目前国内的 DevOps 工具平台的选项中,勾股DEV应该是功能较为齐全的了。
工具相关网址:https://gitee.com/gouguopen/dev
勾股DEV结合 「管理」+「协作」设计理念 ,管理团队的工作、项目和任务,贯穿“从需求提出到研发完成上线”整个产品研发全生命周期,促进产品、研发、测试、运维等产品研发过程中各角色的良好协作。
勾股DEV:通过“项目(Project)”的形式把成员、需求、任务、缺陷(BUG)、文档、互动讨论以及各种形式的资源组织在一起,团队成员参与更新任务、文档等内容来推动项目的进度,同时系统利用时间线索和各种动态的报表的形式来自动给成员汇报项目进度。
使用勾股DEV管理研发项目,一方面可以打破产品、开发、测试、运维之间的部门墙;另一方面可以让业务人员全程参与软件开发,从而使得 BizDevOps 能够得到真正落地。