【以下内容为分享实录，有删节】
如何解决在家办公时 “团队沟通”和“研发流程”问题 软件研发团队在家办公时，会遇到的两个核心问题：团队沟通和研发流程。因为云效团队原本就分布在多个城市，平时的沟通方式也经常采用“在线会议”，所以“在家办公”期间大团队之间的沟通协调受到的冲击较小。 但是小团队之间的沟通还是遇到一些问题，平时大家坐在一起，有事情“吼一声”就解决了，远程办公肯定无法做到。经过10多天的磨合，我们逐渐解决了这个问题，提升了沟通效率。下面以云效团队为例，简单介绍下在公司办公和在家办公之间的差异。
“晨会”和“周会”上沟通的内容基本没有变化，主要是会议形式不同。在公司我们都是面对面交流，而在家办公，会采用电话会议和视频会议的形式。同时为了提升沟通效率，我们在会前需要同步个人工作项、明确会议主题。在家办公期间，除“周报”外，我们增加了“日报”，主要是为了在每天下班前披露个人工作进度和可能存在的风险。
在“研发流程”方面，如果你的团队不是采用“在线化”“白屏化”这种标准流程的话会遇到比较大的挑战。一旦在发布过程中遇到问题或故障，在家办公时，不像在公司可以很方便的找到人，这会造成问题的放大。阿里巴巴在研发流程方面一直是做得比较好的，我们主要通过“Aone”（云效是阿里巴巴自研的DevOps平台，内部名称为Aone）这个研发工具来承载整个研发流程的，包含了开发、构建、部署和安全生产等流程。
在家办公期间，我们主要是通过“敏捷研发”和“持续交付”来解决的“团队沟通”和“研发流程”这两个问题，接下来，会详细介绍一下我们是怎么做的。
以迭代为核心的敏捷研发 “敏捷研发”其实是一套非常成熟的方法论，但是所谓“一千个人心中有一千个哈姆雷特”，每个研发团队都应该“理论结合实际”磨合出一套符合自己团队的方法和机制。通过云效团队的实践，我们认为：敏捷研发应该以迭代为核心，其中的关键是要进行“异步沟通”。
为什么这么说呢？因为“迭代”是长期或者最终目标的拆解，当大的目标变成小的目标之后，我们的团队会对这些“小目标”更有感知。当以迭代为中心后，我们会将这些“小目标”再拆解成“工作项”或者“看板”上的“卡片”，并落实到每个人身上，这也就形成了“异步沟通”的基础。
“异步沟通”相对于“同步沟通”，优势在哪里呢？首先，能够积累“上下文”。异步沟通时，我们沟通的内容都会记录到工作项上；而同步沟通，更多的是以口头传达。其次，这也让每个人能明确自己的目标，让大家保持专注，减少打扰，从而提高效率。
云效团队会将“工作项”分成三类：日常缺陷、项目需求、产品需求。“日常缺陷”很好理解，主要是对已上线产品的维护性工作，缺陷来自用户反馈或自测。“项目需求”一般比较复杂，交付周期较长，有明确的交付时间，来自企业客户或者企业自身内部需求。“产品需求”更多是面向大众，需要持续演进。接下来，我们介绍针对这三种不同的工作项，云效团队是如何进行实践的。
如何处理“日常缺陷”。首先，云效团队会将“日常缺陷”分成四个类别：紧急缺陷立刻修复；一周内修复缺陷；两周内修复缺陷；不修复缺陷。为什么这么做呢？因为“缺陷”相比于“需求”来说，是更加“明确”的，变化比较少，大家在认领的时候，基本可以确认什么时间可以完成。
第二，缺陷不会占用“故事点”。背后的含义是，不会把修复缺陷的时间计算到你正常的工作时间里，要求大家利用空闲时间去完成。这其实建立了一套正向激励的机制，因为“任务”和“需求”的工作项会带来一定的缺陷，当你的工作项完成的质量越高的时候，相应的，你的缺陷就会越少。反之亦然。这个机制就鼓励大家尽可能的把自己的工作项做到最好。
第三，晨会不过缺陷，而是在周会核查上周缺陷进度，确认新增缺陷分类和指派人。 这套机制非常简单，而简单的机制其实更利于执行。云效在践行这套机制处理日常缺陷后，我们自己的产品质量也得到了很大的提升和保障。
如何处理“项目需求”。 项目需求一般有确定的完成时间点，且需求明确。我们会根据确定完成时间点，倒推关键时间，明确里程碑。这样做主要是为了更好的把控风险。需要注意的是，里程碑的内容一定是可量化的、可观测的。然后我们会根据里程碑形成迭代，每个迭代开始前做需求澄清和故事点评估。这样做跟敏捷研发方法论实际上是一致的。需要注意的是，在团队培养方面，每个人的技能应该是尽可能均衡的。这样我们从迭代拆解出来的“工作项”或“卡片”， 任意一个开发者都可以做，而不会和特定的人绑定。这样就不会因为某一位开发者技能的不足而形成瓶颈。
如何处理“产品需求”。 产品需求和项目需求工作项上的处理比较类似，都需要做需求澄清、故事点评估，然后在“站会”上进行“卡片”认领，风险预警等工作。主要的差异点是产品需求的迭代周期相对固定，这有益于保持产品稳健的延续性。如果迭代周期有时长有时短，这意味着在同样的研发周期中开发者处理的“卡片”数量是有稀疏的，这就可能造成交付质量的差异。另外一个不同点是，产品需求的迭代目标一般是根据用户、市场和数据的反馈而产生的，存在一定的不确定性。这就要做一些“需求澄清”，在需求评审上也会更细致一些。
云效在践行敏捷研发的过程中取得了很好的效果，团队成员也比较有成就感。我们的一个心得体会就是：找到团队的节奏非常重要。希望大家也能够在敏捷研发的实践中，找到自己团队的节奏，探索出一套适合自己团队的敏捷研发机制。
如何通过“持续交付”实现研发流程标准化 下面给大家介绍一下云效团队如何通过如何通过“持续交付”实现研发流程标准化。我们常见的持续集成、继续交付都是通过“流水线”去完成的，今天主要给大家介绍一下云效除流水线外，比较有特色的一些实践，包括测试环境：微服务架构下，开发测试环境隔离方案，实现云端开发； 分支管理：多人研发协同下代码分支和静态配置项流程化管理；安全生产：软件交付保障，过程标准化，交付可追溯。
测试环境。先介绍一下我们做这个解决方案的背景，之前我们开发的都是“巨型应用”，随着微服务架构的演进，巨型应用开始拆分成很多小的应用。微服务架构带来益处的同时，对开发过程也带来新的挑战。首先，应用越来越多，应用链路就会变得很长，整体的开发资源有限，并且不稳定，导致整个开发调试过程比较困难。而在开发过程中，你又需要一套独占的环境。用什么方法能够解决这个问题呢？
第一种方法，当我需要一套独占的环境时， 就把整个环境全部的应用都拉起来。这个方案有一些弊端，第一，随着应用越来越多，如果每个应用的开发者都希望把整个环境的全部应用拉起来，在开发资源有限的条件下，是无法实现的；第二，随着应用的增多，整个微服务架构就已经变得“难以描述”了，即使是一次完整的拉起也很难实现。
第二种方法是目前大家采用比较多的，我们首先建立一些公共的基础环境，比如测试环境、预发环境等。当我需要开发的时候，我在本地起一个服务或应用，跟公共基础环境进行联调。这个方案也存在一些弊端，首先，在开发一个功能的时候，你要改动的应用可能不止一个，你需要把这些应用都部署到公共基础环境中。但是开发过程中的服务或应用又是不稳定的，进而会造成公共基础环境的不稳定。此外，这样操作也会形成一种对公共基础环境的抢占。这种“抢占”使公共基础环境成为了开发过程中的瓶颈，非常影响开发效率。
通过对以上经验的总结和实践的积累，阿里巴巴设计出一套“隔离环境”的解决方案。如上图中所示，当你需要做一些有特性的开发时，你不需要把应用或服务部署到公共基础环境中，而是单拉出来一部分资源为你的特性开发做部署，同时把这个“特性环境”和“公共基础环境”做一个打通并且隔离。大家可以共用一套资源，但是相互的请求又是隔离开的。这样操作的好处是，第一你不会占用大量的开发资源；第二，不会影响公共基础环境的稳定性。
“特性环境”其实是一套虚拟的环境，从表面上看，每个特性环境都是一套独立完整的测试环境，由一系列服务组成集群；而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。
这套测试技术在阿里巴巴内部已经经过几代的演进，最开始是对要使用到的中间件（微服务中间件、消息队列中间件等）进行改造，使中间件支持这样的隔离机制。随着云原生技术的发展，我已经在使用Service Mesh的能力进行隔离。同时，我们也开发了一款产品KT Virtual Environment，目前已经开源，欢迎大家在上面提缺陷。
分支管理。云效团队以及阿里巴巴内部研发团队基本都是采用“AoneFlow”这种分支管理模式。这个分支管理模式是经过多年实践积累而产生的，它通过变更模型，管理了Feature分支和静态配置项；代码分支和静态配置项合并、冲突解决都是通过白屏化来处理的；它和我们常见的固定分支管理模式不同，它的发布分支是动态的，可以实现Feature灵活组合，快上快下。为什么要用“动态发布分支”？第一，我们发现相比于传统的“巨型应用”，在微服务架构下，整个集成验证会变得非常困难。因为你需要在公共环境中与其它应用一起进行集成验证，即使在单体验证时你的代码是OK的，也很难确保与其它应用一起集成验证时你的Ferture分支是可靠的，一旦出现问题就需要从发布分支中退下来。第二，当多人协作共同开发一段代码分支时，你很难确保跟其他人集成时不出现问题， 而且发布频率越高，这种不稳定性就越大。特别是我们的互联网企业，整个迭代速度非常快，开发频率也非常快，相应的出现冲突的可能性也会非常大。在这种情况下，你就很难确保在集成验证时你的代码分支是可靠的。这两种情况，都要求代码分支要“快上快下”。
安全生产。刚才我们提到的“测试环境”和“分支管理”主要是从效率的角度考虑如何让持续交付做得更好，其实还有更重要的一点是怎样让交付质量得到保障，做到发布过程0故障。
首先，我们要建立起一系列安全机制，比如安全扫描、Code Review等， 让“测试左移”，在开发阶段就发现问题。第二，这些机制不能仅仅是口头约定，我们需要有效的工具来管理这些机制。云效团队将这些机制变成“卡点”“红线”集成到研发流程中，通过“云效流水线”来承载。同时为了平衡“效率”问题，云效团队更多的是对“增量”进行质量要求，对“增量”设置单元测试、代码静态扫描、集成测试、覆盖率等质量红线卡点。第三，是要做到人工审核和变更封网的全局维度管控，通过人工的方式与前面介绍的技术手段相结合，形成互补，来确保安全生产。
全新云效即将上市 敬请期待
近期，阿里云·云效会有一个全新的版本上线，带来全新的产品功能和使用体验。这是我们聆听了来自各个渠道开发者的反馈，和众多中小企业开发者共创，用心打磨的一款产品。大家可以加入云效开发者交流群（钉钉群号：23362009）进行内测申请和讨论。
【下期预告】
【直播日期】4月15日 16:00 【直播主题】阿里的Kubernetes测试环境开源工具箱 【直播讲师】林帆 阿里巴巴技术专家 【观看方式】云效开发者交流群直播（钉钉群号：群号：23362009）
【直播预告】https://yq.aliyun.com/live/2618
【关于云效】 云效，企业级一站式DevOps平台，源于阿里巴巴先进的研发理念和工程实践，致力于成为数字企业的研发效能引擎！云效提供从“需求 ->开发->测试->发布->运维->运营”端到端的在线协同服务和研发工具，通过人工智能、云原生技术的应用助力开发者提升研发效能，持续交付有效价值。
上云就看云栖号：更多云资讯，上云案例，最佳实践，产品入门，访问：https://yqh.aliyun.com/
本文为阿里云原创内容，未经允许不得转载。
