分享实录 | 中小企业如何在家高效研发软件-阿里云开发者社区

开发者社区> 阿里巴巴云研发> 正文

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

简介: 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

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

云效,企业级一站式DevOps平台,源于阿里巴巴先进的研发理念和工程实践,致力于成为数字企业的研发效能引擎!云效提供从“需求→开发→测试-→发布→运维→运营”端到端的协同服务和研发工具,支持公共云、专有云和混合云多种部署形态,通过人工智能、自动化技术的应用提升开发者的研发效能,持续交付有效价值。

官方博客
【产品与服务】
【友情链接】