您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
4个迭代,从批量交付到持续交付转型
 
作者:阿里云云效
  1224  次浏览      15 次
 2022-4-25
 
编辑推荐:
本文介绍通过4个迭代的持续改进,研发效率和质量取得了显著提升: 大幅缩短了需求开发时间,从一个月变为一周; 从无可用测试环境到具有稳定的测试环境; 从无自动化测试用例到50%的模块实现测试自动化 从手工部署到自动化部署。 这一切是如何做到的呢?通过本文来一一道来。
本文来自于51CTO,由火龙果软件Linda编辑推荐。

研发困境

首先我们了解了该团队的组织结构以及各人员的工作内容。如下图所示。

可以看到,产品、前端 、后台、测试属于不同的职能部门。这是一个非常普遍的组织形式——职能型组织。

在这样的组织形式中,通常会存在以下问题:

·工作之间相互依赖,彼此等待;

·职能团队之间的目标不一致;

·需求变动沟通不及时;

·工作完成标准不一致。

其次,集中批量集成发布,时间紧、效率低。团队的迭代周期一般是一个月,需求从准备开发到待测试的周期是4周,测试时间要花掉1天,发布一般都安排在周五晚上,大约第二天天亮才能发完,整个发布过程完全靠工程师手工完成。我们发现测试和发布的时间相对集中,时间紧,而且是完全手工操作,出错的可能性很高。

最后,测试守护薄弱,无法做到有信心发布。因为产品需要发布到公共云,目前集团没有相应的工具可以帮助公共云的发布;并且,产品的构建部署过程均无工具支持,需要手工打包和部署。在测试守护方面,有一些遗留的单元测试,但是这些单元测试根本就无法运行起来;而集成测试的运行的用例数基本为零,虽然有同学努力在加新的用例,但目前这些用例还无法运行,整个测试守护过程非常薄弱。

这么多的问题,该从哪里入手解决呢?下面分享一下我们的4个迭代措施。

迭代 1 :可视化研发工作,寻找问题的关键点

通过跟团队的沟通,我们发现团队同学其实已经或多或少地意识到了这些问题,并且他们也做了一些改进的尝试,但是因为各种原因没有继续下去,导致团队现在对改变没有什么信心。

在这样的情况下,需要在尽量少改变团队现状的情况下,去取得一个比较好的效果。

要解决问题,必须让大家能够站在全局的视角来分析现状,从而找到核心问题。因此,我们通过可视化物理板以及站会,把研发团队的工作进行了可视化。

1.1利用可视化物理板与站会,透明团队工作

初期的可视化板,主要是展现出团队当前迭代要做的工作以及每天出现的问题。过程中对物理板的规则并未做太多约束,主要起到可视化的作用。这样一方面降低了可视化工作的门槛,让大家愿意使用,另一方面,能把大家最真实的工作状况给反映出来,如下图所示:?

物理板展示的同时,配置了每日固定站会,时间控制15分钟,要求产品、前端、后端开发、测试一起参与。每人轮流对所有人透明每天完成的工作、接下来要完成的工作、遇到的问题。

1.2通过可视化物理板,暴露团队的测试瓶颈

物理板与每日站会,很清晰地展现了当前迭代需要完成的工作,团队在需要完成的目标基本上达成一致。并且在每日站会的过程中,因为每日不断需要沟通的需求,团队能及时调整并更明确研发流程规划。

同时我们发现,在项目初始阶段,几乎所有的需求在同一时期投入到了开发中;大约在中期时,有很多任务慢慢地移到了自测阶段,但并没有需求可以移到待测试阶段;直到临近发版前1-2天,大部份需求才一起移到了待测试。整个过程中,测试同学除了了解当前准备开始的工作以及准备测试用例外,一直在等待测试工作中。如下图所示。

为什么测试同学每天都在等待接受新的工作需求,但总没有需求可以提测呢?在离发版的前1天,研发才提测。对测试来说,测试时间很紧迫,验证出来的bug也来不及修,这就会造成上线后仍然需要有一周时间来修复bug。

通过可视化物理板,研发团队很快明白了测试瓶颈的原因——我们是不是可以尽快让测试参与工作呢?

迭代 2 :合理拆分需求,让需求变小、独立、可测试

如何让测试尽快参与工作呢?我们发现,需求之所以无法进行测试,是因为需求的各个子任务与其他需求之间的子任务相互依赖造成的,多个需求之间耦合在一起,相互等待。其结果就是,所有需求都得一起开发完成才能测试。为什么它们会耦合在一起呢?

我们发现,当前的需求拆分方式是以组件或模块来进行拆分的。例如,一个需求,首先从实现的角度,把它按模块拆分成多个需求,对模块的实现,再对该模块需求拆分成若干个任务。

但是,从测试的角度来看,需求应该是端到端可测的,这样拆分出来的模块需求不能独立测试,它仅局限在这个模块的范围。

那么如何有效地来拆分需求呢?

2.1从业务目标出发,由外而内逐步拆分需求

什么是有效的需求拆分呢?需求拆分完之后,它必须还是需求,它必须要:

·足够小:这样才能做到可持续交付;

·端到端:这样才能保证交付有意义的价值;

·独立性:便于持续集成和灵活安排;

·整体性:拆分完仍能看到整体的结构。

要做到有效的需求拆分,需要:

1.澄清目标:需求相关方要共同理解需求的背景,为什么要做需求的原因;

2.梳理需求上下文及用户的使用场景;

3.列出用户操作及操作步骤。

我们可以从一个具体的例子来了解整个拆分的过程。

需求描述:组件商业化

需求背景:某组件需要接入到E产品,以按量计费的形式提供服务,并通过阿里云统一按流量收费;组件接入到E产品后,用户通过访问产品页面开通/暂停/使用组件

如果我们按照上面描述的方法进行拆分的话,应该:

(1)澄清目标

组件要从免费的形式转变为按量计费的形式。组件要用统一的接入方式;用户在产品页面上可以看到已经接入的组件,在页面上开通/暂停组件,产生的费用,通过阿里云来进行计费并反馈给用户。当用户欠费时,该组件直接暂停使用,提示用户进行缴费。

(2)列出上下文及用户使用场景

系统上下文

用户使用场景(用例)

(3)列出用户操作及操作步骤

(4)按用户端到端的使用拆分为4个需求:

·组件成功接入到产品,能在产品上展示;

·用户能通过产品查看已经接入的组件;

·用户能使用组件功能,能根据使用数据提示已使用金额;

·用户如已欠费,无法使用组件功能。

其中,组件成功接入到产品需要依赖组件方技术改造,也是后续几个需求的依赖,因此这个需求为其他需求的依赖,需要最高优先级需求。

在整个拆分的过程,其实是需求从目标出发,逐层澄清分析的过程,需求拆分并不直接产生价值,产生价值的是需求分析本身,而需求拆分是需求分析的副产品。

当需求拆分完成之后,如何让需求顺畅流动起来,持续开发呢?

2.2完善看板规则,前后职能拉通,任务左右对齐

需求除了是交付的单元,同样也是沟通的载体。在整个端到端的交付过程中,经过有效拆分的需求,可以更便捷地进行协作,与此同时,看板的设计也需要做出相应的调整。

(1)明确需求准入规则

进入开发就绪前,必须进行需求拆分,并且明确验收标准,否则不能进入开发。每个需求拆分后的工作量大小不应超过1周,对应需求的每个任务工作量不应超过1天。

(2)前后职能拉通,任务左右对齐

通过看板,呈现需求端到端的交付过程,各职能以需求顺畅流动为共同目标,从需求层面拉通各职能之间的协作。同样,在需求的开发阶段,分解成不同的任务列,同一需求的各任务被安排在同一泳道(行)上,做到任务在需求层面的对齐。如下图所示。

采用新实践的团队,需求做到了有效拆分,提前一周完成了所有需求的开发以及测试验证工作,上线后缺陷比以往显著减少。而未做改变的团队,在发布前一天,仍然有代码未合并。

合理的需求拆分,使得持续测试成为可能。现在由于测试工作变得日常化,基本上迭代开始一周后就有需求进入提测,而这时,却没有一个与线上相一致的测试环境。那么环境就成为了当前团队的一个重要瓶颈。

迭代 3 :构建测试环境,恢复端到端持续测试

要做到持续测试,需要与之相匹配的测试环境。我们发现测试环境主要存在以下这些问题:

·测试环境中,服务组件之间的依赖多,准备一套环境让这些组件全部跑通不容易;

·某些外部依赖无法搭建线下环境;

·整个构建部署全由研发手动操作,缺少环境监控的有效手段;

·测试环境服务器部在售卖区,与阿里内部不能互通访问。?

问题很多,但解决的方法只有一个,即首先必须修复环境,让环境可用;其次,需要保证环境持续可用;最后,让集成测试的流程自动化,让规则自动化。

3.1提高优先级,修复环境,让环境可用

我们发现,环境的问题并不是技术上不可行,而是在研发过程中,环境修复缺少足够的优先级,不能得到足够的投入。当环境问题已经影响到持续测试后,我们在看板中设一个泳道(下图中的青岛VIP),由测试同学把当前测试环境中的问题在这个泳道展现出来,并作为最高优先级由研发同学来修复。并且在站会时,首先去关注环境是否可用。

3.2建立团队环境约定,保证环境持续可用

测试环境由测试同学来守护,做到有效监控、及时反馈、快速恢复(环境坏了要及时知道,知道了要及时将问题抛出来,大家进行修复)。在工具暂时还未支撑时:由开发打完包后,测试同学到固定的地方去取包进行部署,并做基础环境是否可用验证。考虑到验证的时间成本,先添加了一个端到端的用例来进行验证。待一个跑通并且持续稳定的前提下,再增加下一个用例。

部署后测试环境有问题的,测试需要判断是属于新提交代码提交导致的还是本身环境的问题,做到准确定位,新提交代码导致的,由代码合入人修复,本身环境问题指定对应人员修复。

整个环境管理的十六字规则就是:有效监控、及时反馈、准确定位、快速恢复。而这一切得到落地,一是测试的同学负责了环境的守护,二是团队有足够的优先级来响应环境的问题。

3.3有效利用云效自定义流水线,实现构建部署测试全自动化

为了让环境持续可用,整个流程可以不再依靠人力的管控,团队决定接入阿里一站式研发平台——云效来打通整个发布过程。因此,研发团队与云效团队一起,打通了从云效到售卖区的整个部署流程,形成一个从代码提交、构建、部署、测试和发布的完整流水线,该方案对后续上云的团队也可以借鉴。有了这样的测试环境和流水线,我们从新增一个完整端到端的测试用例开始,逐步完善测试自动化。

3.4研发流程规则工具化

经过前面几个迭代的改进,团队尝到了改进带来的好处,PD、测试及TL都要求其他研发团队也按照该研发模式进行协作。另外,如果其他团队仍然按照以前的模式进行工作的话,测试环境的稳定性也会难于维系,因此,整个大团队统一切换到新的研发模式中。

大团队的汇入,我们发现需要对原来的规则和模式做一些调整,才能适应大团队的运作,因此,我们将团队的研发过程规则进行了细化,补充和明确了完成标准和提测标准等。如下图所示。

?研发流程并非一成不变,应该是一个不断演进调整的过程。规则调整由团队共同商议决定,尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要,这是因为就绪规则是要控住入口,明确需求是否合理拆分;待测试规则是为了确定提测前是否做过自测,以保证不要一上去就把测试环境给弄趴下了;待发布是要保证发布质量。

当有了可用的测试环境之后,整个CI/CD的流水线打通,并且能够跑通30+自动化用例,该迭代准时发布,开发到测试的时间也缩短为1周。

似乎所有的问题得到了解决,但是,这个时候我们发现每一次部署都会block测试环境120分钟以上,如此长时间的block是什么原因导致的呢?有没有有效的方法可以解决??

迭代 4 :环境稳定并持续可用

测试环境被block120min以上,影响了每一次的验证工作。针对所有block的问题进行分析,发现问题有以下几类:

·新提交代码产生的问题,

·历史bug导致的

·测试环境本身未搭建好

·暂时无法判断原因的

分析原因主要是背后的理念,是先开始重要呢?还是先完成重要?我们从两方面进行了改进:

4.1明确优先级以及需求owner意识

目标是更早的交付价值。每个需求提交应该更早的去验证、集成,再去做下一个需求。

4.2 bug的修复流程

快速排查问题:

·测试环境问题,测试同学先做基本的排查;

·在云效发布工具上更多的展示发布单的反馈状态与信息,帮助排查;

缺陷消灭:

·新Feature引入的bug,研发同学默认高优先级解决,以加速单个需求的快速流转;

·整理一份当前测试环境功能点的Feature列表及其对应的Owner;

·遗留历史bug,版本owner组织review一遍,判断影响,影响度不大,修复成本高的,产品进行排期;

提前预防:

·提测前自动触发轻量级版本的自动化测试;

·代码强制codereview,代码合到测试分支的前提是自动化测试用例通过。

第四个迭代结束,测试环境已经明显不再有block的现象;团队研发流程也比较顺畅,迭代中也解决了异地站会同步问题。并且自动化测试用例已经覆盖主要核心业务。经团队评估,团队有能力在白天发布,发布熬夜已经不是团队的困扰了。

总结

通过4个迭代,研发团队达到了很多0到1的效果。从不被看好到大家都更有信心成为更高效的研发团队,最主要的原因是:大家能在同一高度来看到团队共同的问题,每次选择一个当前最迫切最重要的问题来改进,不贪多。

4个迭代后,通过数据我们来看整体的改进效果:

1.自动化测试释放人力的变化

以前每轮回归测试,需要7个开发*4小时的手动测试,通过自动化用例的添加,在回归测试人力上已经释放了2个研发人力。

2.研发周期时长明显缩短

从团队开始开发到提测从原来的4周缩短到了1周;测试的时间更充分了;限制了提测最后时间点,需求的发布时间也更充分,再没有通宵发布的情形。

3.软件质量也得到提升

从图中所示,由于需求的拆分、环境的稳定、让每个需求可以提前测试创造了有利的条件,测试时间更充分,缺陷在测试期间暴露得更多,因此遗留到线上的缺陷也就降低。

研发流程并非一成不变,应该是一个不断演进调整的过程。规则调整由团队共同商议决定,尤其对于就绪、待测试、待发布几个关键状态的规则定义显得尤为重要,这是因为就绪规则是要控住入口,明确需求是否合理拆分;待测试规则是为了确定提测前是否做过自测,以保证不要一上去就把测试环境给弄趴下了;待发布是要保证发布质量。

最后

4个迭代只是改进的开始,未来,仍然有许多的问题需要团队持续改进。但是,只要路走对了,就不怕远。

 

   
1224 次浏览       15
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
DevOps 道法术器,立体化实施框架
DevOps 中高效测试基础架构的最佳实践
DevOps 在公司项目中的实践落地
如何基于 Kubernetes 构建完整的 DevOps 流水线
阿里云Kubernetes实战
最新课程
DevOps体系实践、工具与平台
基于Kubernetes的DevOps实践
互联网运维与DevOps
基于Kubernetes构建企业容器云
企业级DevOps工作体系与平台
更多...   
成功案例
北京 DevOps体系实践、工具与平台
神龙汽车 DevOps体系实践、工具与平台
中国移动通信 网络规划与管理
某航空公司 IT规划与企业架构
某金融公司 IT服务管理(ITIL V3)
更多...