普元DevOps 5.3 产品研发发布

引言：

普元DevOps5．3新增64个功能特性、优化了26项体验，其中，大型项目群管理能力、全新报表能力、动态任务看板、部署能力增强、第三方工具升级、平台性能优化6大关键特性，使普元DevOps平台性能实现了较大提升。

目录：

一、5．3版本的主要特性

二、对研发过程的思考

三、下一版本的想法

一、5．3版本的主要特性

首先说说我们的产品发展，每个版本在定义之初会有一个核心目标，围绕核心目标再去对特性分解和制定优先级。

1．0版本，我们是追着热点概念来，容器云、微服务、DevOps同时开展，投入很大，但种种原因，效果并没有达到预期。

5．0版本，更像是一个重构版本，经过1．0版本的市场尝试，我们知道什么是重要的，什么是紧急的，什么是普元所在的企业市场所需要的。

5．1／5．2版本，是一个敏态与稳态共同支撑的双模版本，正值很多企业的数字化转型阶段，所以版本里既有敏捷的项目管理、也有瀑布的推进模式，能力上相对则更偏敏捷一些。

5．3版本，则在一次次实施过程中，充分认知了企业DevOps市场的特点与难点，进而形成了以企业级中间件支持、企业级项目管控模式等为重心的平台建设。

如果这里有产品经理，可能会问，如何来考虑新版本的需求范围？

如果这里有DevOps产品经理，可能会问，DevOps很多时候被诟病实施效果不明显，因为什么？

如何把握版本范围？

基础软件市场向来是竞争激烈的，但是合理运用好这个市场氛围，会是产品经理的一大利器。对于一个发展中的产品版本，需要的来源一般包括四块：

售前交流的建议： 来自这方面的需求很多，对团队来讲，则需要很好的鉴别能力

项目实施的积累： 这个一般没有疑问，是必须纳入到后续版本的一部分需求

核心特性的巩固： 这个取决于产品定位，就像我们的定位是企业级生产线，那就必须满足企业的常见流程、中间件要求，并不断升级优化，要在这些特性上做到行业领先

竞争对手的压力： 尤其一些pk时的丢分项，或者对手的加分项，会是我们重点斟酌是否要纳入的需求来源

为什么很多企业DevOps建设效果不明显？

DevOps在实施后，很多人会觉得效果不明显，产生这个的原因同样有这么几点：

单职能部门承建，缺少高层推动。因涉及角色较多，如果只是为某个部门服务，平台是很难形成规模效应的

工具堆积，缺少流程与规范。单纯的工具链打通只是解决了统一工作台的问题，但是工件之间的关系并不能有效关联，进而很难做整体的分析优化

一味追求快，对安全、质量考虑较少。企业IT系统的交付，安全是重中之重，单纯的自动化驱动只能解决部分问题，对于最卡壳的并没有实质解决。

技术有限，平台级设计不足。DevOps是一个持续的建设过程，周期也相对较长，如果只是短暂的考虑眼前的工具、管控，很可能在后续的发展中成为瓶颈。

回到标题，在这里和大家分享我们在5．3版本里的六个特性：

一、大型项目群管理

项目群是为了实现更高战略目标，对一组项目进行统一协调管理，日常工作则仍在各个项目内进行。

比如最近普元来了一个支持IPv6的需求，全线产品都需要做，此时就需要一个项目群来统一协调，制定大里程碑，组织驱动所有子产品按目标执行。在金融、电信等行业此类组织特征尤其显性。

所以在项目群的特性里，需要提供对多个项目统一协调，通过主项目与配合项目的设置，以及里程碑的跟踪，有效协同。