分享实录 | 中小企业如何在家高效研发软件

简介: 4月伊始,开发者们终于可以告别在家办公的煎熬,云效团队也同样经历了一段在家研发软件的历程。本期《云效说码》,阿里巴巴高级技术专家李帅(焦霸)将会介绍云效团队在家办公时的一些心得,并分享他在持续交付、敏捷研发方面的实践和经验。

01-分享要点.png

【以下内容为分享实录,有删节】

如何解决在家办公时 “团队沟通”和“研发流程”问题
软件研发团队在家办公时,会遇到的两个核心问题:团队沟通和研发流程。因为云效团队原本就分布在多个城市,平时的沟通方式也经常采用“在线会议”,所以“在家办公”期间大团队之间的沟通协调受到的冲击较小。 但是小团队之间的沟通还是遇到一些问题,平时大家坐在一起,有事情“吼一声”就解决了,远程办公肯定无法做到。经过10多天的磨合,我们逐渐解决了这个问题,提升了沟通效率。下面以云效团队为例,简单介绍下在公司办公和在家办公之间的差异。

02.png

“晨会”和“周会”上沟通的内容基本没有变化,主要是会议形式不同。在公司我们都是面对面交流,而在家办公,会采用电话会议和视频会议的形式。同时为了提升沟通效率,我们在会前需要同步个人工作项、明确会议主题。在家办公期间,除“周报”外,我们增加了“日报”,主要是为了在每天下班前披露个人工作进度和可能存在的风险。

03.png

在“研发流程”方面,如果你的团队不是采用“在线化”“白屏化”这种标准流程的话会遇到比较大的挑战。一旦在发布过程中遇到问题或故障,在家办公时,不像在公司可以很方便的找到人,这会造成问题的放大。阿里巴巴在研发流程方面一直是做得比较好的,我们主要通过“Aone”(云效是阿里巴巴自研的DevOps平台,内部名称为Aone)这个研发工具来承载整个研发流程的,包含了开发、构建、部署和安全生产等流程。

在家办公期间,我们主要是通过“敏捷研发”和“持续交付”来解决的“团队沟通”和“研发流程”这两个问题,接下来,会详细介绍一下我们是怎么做的。

以迭代为核心的敏捷研发
“敏捷研发”其实是一套非常成熟的方法论,但是所谓“一千个人心中有一千个哈姆雷特”,每个研发团队都应该“理论结合实际”磨合出一套符合自己团队的方法和机制。通过云效团队的实践,我们认为:敏捷研发应该以迭代为核心,其中的关键是要进行“异步沟通”。

04.png

为什么这么说呢?因为“迭代”是长期或者最终目标的拆解,当大的目标变成小的目标之后,我们的团队会对这些“小目标”更有感知。当以迭代为中心后,我们会将这些“小目标”再拆解成“工作项”或者“看板”上的“卡片”,并落实到每个人身上,这也就形成了“异步沟通”的基础。

“异步沟通”相对于“同步沟通”,优势在哪里呢?首先,能够积累“上下文”。异步沟通时,我们沟通的内容都会记录到工作项上;而同步沟通,更多的是以口头传达。其次,这也让每个人能明确自己的目标,让大家保持专注,减少打扰,从而提高效率。

云效团队会将“工作项”分成三类:日常缺陷、项目需求、产品需求。“日常缺陷”很好理解,主要是对已上线产品的维护性工作,缺陷来自用户反馈或自测。“项目需求”一般比较复杂,交付周期较长,有明确的交付时间,来自企业客户或者企业自身内部需求。“产品需求”更多是面向大众,需要持续演进。接下来,我们介绍针对这三种不同的工作项,云效团队是如何进行实践的。

如何处理“日常缺陷”。首先,云效团队会将“日常缺陷”分成四个类别:紧急缺陷立刻修复;一周内修复缺陷;两周内修复缺陷;不修复缺陷。为什么这么做呢?因为“缺陷”相比于“需求”来说,是更加“明确”的,变化比较少,大家在认领的时候,基本可以确认什么时间可以完成。

第二,缺陷不会占用“故事点”。背后的含义是,不会把修复缺陷的时间计算到你正常的工作时间里,要求大家利用空闲时间去完成。这其实建立了一套正向激励的机制,因为“任务”和“需求”的工作项会带来一定的缺陷,当你的工作项完成的质量越高的时候,相应的,你的缺陷就会越少。反之亦然。这个机制就鼓励大家尽可能的把自己的工作项做到最好。

第三,晨会不过缺陷,而是在周会核查上周缺陷进度,确认新增缺陷分类和指派人。
这套机制非常简单,而简单的机制其实更利于执行。云效在践行这套机制处理日常缺陷后,我们自己的产品质量也得到了很大的提升和保障。

如何处理“项目需求”。 项目需求一般有确定的完成时间点,且需求明确。我们会根据确定完成时间点,倒推关键时间,明确里程碑。这样做主要是为了更好的把控风险。需要注意的是,里程碑的内容一定是可量化的、可观测的。然后我们会根据里程碑形成迭代,每个迭代开始前做需求澄清和故事点评估。这样做跟敏捷研发方法论实际上是一致的。需要注意的是,在团队培养方面,每个人的技能应该是尽可能均衡的。这样我们从迭代拆解出来的“工作项”或“卡片”, 任意一个开发者都可以做,而不会和特定的人绑定。这样就不会因为某一位开发者技能的不足而形成瓶颈。

如何处理“产品需求”。 产品需求和项目需求工作项上的处理比较类似,都需要做需求澄清、故事点评估,然后在“站会”上进行“卡片”认领,风险预警等工作。主要的差异点是产品需求的迭代周期相对固定,这有益于保持产品稳健的延续性。如果迭代周期有时长有时短,这意味着在同样的研发周期中开发者处理的“卡片”数量是有稀疏的,这就可能造成交付质量的差异。另外一个不同点是,产品需求的迭代目标一般是根据用户、市场和数据的反馈而产生的,存在一定的不确定性。这就要做一些“需求澄清”,在需求评审上也会更细致一些。

云效在践行敏捷研发的过程中取得了很好的效果,团队成员也比较有成就感。我们的一个心得体会就是:找到团队的节奏非常重要。希望大家也能够在敏捷研发的实践中,找到自己团队的节奏,探索出一套适合自己团队的敏捷研发机制。

如何通过“持续交付”实现研发流程标准化
下面给大家介绍一下云效团队如何通过如何通过“持续交付”实现研发流程标准化。我们常见的持续集成、继续交付都是通过“流水线”去完成的,今天主要给大家介绍一下云效除流水线外,比较有特色的一些实践,包括测试环境:微服务架构下,开发测试环境隔离方案,实现云端开发; 分支管理:多人研发协同下代码分支和静态配置项流程化管理;安全生产:软件交付保障,过程标准化,交付可追溯。

05.png

测试环境。先介绍一下我们做这个解决方案的背景,之前我们开发的都是“巨型应用”,随着微服务架构的演进,巨型应用开始拆分成很多小的应用。微服务架构带来益处的同时,对开发过程也带来新的挑战。首先,应用越来越多,应用链路就会变得很长,整体的开发资源有限,并且不稳定,导致整个开发调试过程比较困难。而在开发过程中,你又需要一套独占的环境。用什么方法能够解决这个问题呢?

第一种方法,当我需要一套独占的环境时, 就把整个环境全部的应用都拉起来。这个方案有一些弊端,第一,随着应用越来越多,如果每个应用的开发者都希望把整个环境的全部应用拉起来,在开发资源有限的条件下,是无法实现的;第二,随着应用的增多,整个微服务架构就已经变得“难以描述”了,即使是一次完整的拉起也很难实现。

第二种方法是目前大家采用比较多的,我们首先建立一些公共的基础环境,比如测试环境、预发环境等。当我需要开发的时候,我在本地起一个服务或应用,跟公共基础环境进行联调。这个方案也存在一些弊端,首先,在开发一个功能的时候,你要改动的应用可能不止一个,你需要把这些应用都部署到公共基础环境中。但是开发过程中的服务或应用又是不稳定的,进而会造成公共基础环境的不稳定。此外,这样操作也会形成一种对公共基础环境的抢占。这种“抢占”使公共基础环境成为了开发过程中的瓶颈,非常影响开发效率。

06.png

通过对以上经验的总结和实践的积累,阿里巴巴设计出一套“隔离环境”的解决方案。如上图中所示,当你需要做一些有特性的开发时,你不需要把应用或服务部署到公共基础环境中,而是单拉出来一部分资源为你的特性开发做部署,同时把这个“特性环境”和“公共基础环境”做一个打通并且隔离。大家可以共用一套资源,但是相互的请求又是隔离开的。这样操作的好处是,第一你不会占用大量的开发资源;第二,不会影响公共基础环境的稳定性。

“特性环境”其实是一套虚拟的环境,从表面上看,每个特性环境都是一套独立完整的测试环境,由一系列服务组成集群;而实际上,除了个别当前使用者想要测试的服务,其余服务都是通过路由系统和消息中间件虚拟出来的,指向公共基础环境的相应服务。

这套测试技术在阿里巴巴内部已经经过几代的演进,最开始是对要使用到的中间件(微服务中间件、消息队列中间件等)进行改造,使中间件支持这样的隔离机制。随着云原生技术的发展,我已经在使用Service Mesh的能力进行隔离。同时,我们也开发了一款产品KT Virtual Environment,目前已经开源,欢迎大家在上面提缺陷。

07.png

分支管理。云效团队以及阿里巴巴内部研发团队基本都是采用“AoneFlow”这种分支管理模式。这个分支管理模式是经过多年实践积累而产生的,它通过变更模型,管理了Feature分支和静态配置项;代码分支和静态配置项合并、冲突解决都是通过白屏化来处理的;它和我们常见的固定分支管理模式不同,它的发布分支是动态的,可以实现Feature灵活组合,快上快下。为什么要用“动态发布分支”?第一,我们发现相比于传统的“巨型应用”,在微服务架构下,整个集成验证会变得非常困难。因为你需要在公共环境中与其它应用一起进行集成验证,即使在单体验证时你的代码是OK的,也很难确保与其它应用一起集成验证时你的Ferture分支是可靠的,一旦出现问题就需要从发布分支中退下来。第二,当多人协作共同开发一段代码分支时,你很难确保跟其他人集成时不出现问题, 而且发布频率越高,这种不稳定性就越大。特别是我们的互联网企业,整个迭代速度非常快,开发频率也非常快,相应的出现冲突的可能性也会非常大。在这种情况下,你就很难确保在集成验证时你的代码分支是可靠的。这两种情况,都要求代码分支要“快上快下”。

安全生产。刚才我们提到的“测试环境”和“分支管理”主要是从效率的角度考虑如何让持续交付做得更好,其实还有更重要的一点是怎样让交付质量得到保障,做到发布过程0故障。

08.png

首先,我们要建立起一系列安全机制,比如安全扫描、Code Review等, 让“测试左移”,在开发阶段就发现问题。第二,这些机制不能仅仅是口头约定,我们需要有效的工具来管理这些机制。云效团队将这些机制变成“卡点”“红线”集成到研发流程中,通过“云效流水线”来承载。同时为了平衡“效率”问题,云效团队更多的是对“增量”进行质量要求,对“增量”设置单元测试、代码静态扫描、集成测试、覆盖率等质量红线卡点。第三,是要做到人工审核和变更封网的全局维度管控,通过人工的方式与前面介绍的技术手段相结合,形成互补,来确保安全生产。

全新云效即将上市 敬请期待

09.jpg

近期,阿里云·云效会有一个全新的版本上线,带来全新的产品功能和使用体验。这是我们聆听了来自各个渠道开发者的反馈,和众多中小企业开发者共创,用心打磨的一款产品。大家可以加入云效开发者交流群(钉钉群号:23362009)进行内测申请和讨论。


【下期预告】

【直播日期】4月15日 16:00
【直播主题】阿里的Kubernetes测试环境开源工具箱
【直播讲师】林帆 阿里巴巴技术专家
【观看方式】云效开发者交流群直播(钉钉群号:群号:23362009)

【直播预告】https://yq.aliyun.com/live/2618

【关于云效】
云效,企业级一站式DevOps平台,源于阿里巴巴先进的研发理念和工程实践,致力于成为数字企业的研发效能引擎!云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具,通过人工智能、云原生技术的应用助力开发者提升研发效能,持续交付有效价值。

94faac411c85ba36d7dc12689f03f5189c26546b

相关实践学习
基于函数计算一键部署掌上游戏机
本场景介绍如何使用阿里云计算服务命令快速搭建一个掌上游戏机。
相关文章
|
7月前
|
移动开发 小程序 JavaScript
太卷了,某公司把自家运营多年的核心系统(智慧系统)完全开源了
推荐一款开源的智慧物业开源系统。实现了微信公众号、小程序、PC、H5、智能硬件多端打通,旨在提升物业公司效率、规范物业服务流程、提升物业服务满意度、加强小区智慧化建设、便捷业主服务。
68 0
太卷了,某公司把自家运营多年的核心系统(智慧系统)完全开源了
|
11月前
|
数据中心 云计算
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.1 历史背景
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.1 历史背景
130 0
|
11月前
|
存储 云计算 数据中心
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.3 上云之路
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.3 上云之路
187 0
|
11月前
|
数据中心 云计算 UED
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.2 上云优势
《云上大型赛事保障白皮书》——第一章 大型赛事云上数字化转型——1.2 上云优势
146 0
|
11月前
|
监控
《云上大型赛事保障白皮书》——第二章 云上大型赛事保障体系——2.1 云上大型赛事业务架构
《云上大型赛事保障白皮书》——第二章 云上大型赛事保障体系——2.1 云上大型赛事业务架构
168 0
|
11月前
|
人工智能 达摩院 供应链
新书导读 |《数智化敏捷组织:云钉一体驱动组织转型》即将发布,敬请期待!
新书导读 |《数智化敏捷组织:云钉一体驱动组织转型》即将发布,敬请期待!
181 0
|
运维 Cloud Native 容灾
金山办公 2022 年技术开放日:文档云原生时代的规模之道
金山办公 2022 年技术开放日:文档云原生时代的规模之道
205 0
金山办公 2022 年技术开放日:文档云原生时代的规模之道
|
移动开发 开发框架 监控
杭州银行:坚定投入移动化战略,借助EMAS研发平台迈入移动开发3.0时代
可以想见,未来银行的绝大部分业务、渠道、连接点,都不免与手机银行打通,以实现线上、线下服务的无缝连接,并以此构建起新的银行形态。未来的手机银行将是银行产品创新、业务拓展和战略转型的重要平台,EMAS移动研发平台已经为杭州银行打下了基础。
杭州银行:坚定投入移动化战略,借助EMAS研发平台迈入移动开发3.0时代
|
敏捷开发 人工智能 运维
直播预告 | 中小企业如何在家高效研发软件
4月10日19点,云效开发者交流群见!
823 0
直播预告 | 中小企业如何在家高效研发软件
|
机器学习/深度学习 弹性计算 运维
上下求索,白“云”苍狗(三):2015到2019,从5到70,从0到100万,技术推动业务的云实践,我创业的这4年
从2015年到2019年,业务DAU从0到100万,团队从5人到70人,讲述技术人的创业之路,解读如何从技术推动业务,分享作为CTO的心路历程,一同感受创业的五味杂陈。

热门文章

最新文章