后台做网站的题,照片组合拼图,sem营销推广,福州网站建设多少钱【以下内容为分享实录#xff0c;有删节】
如何解决在家办公时 “团队沟通”和“研发流程”问题 软件研发团队在家办公时#xff0c;会遇到的两个核心问题#xff1a;团队沟通和研发流程。因为云效团队原本就分布在多个城市#xff0c;平时的沟通方式也经常采用“在线会议…
【以下内容为分享实录有删节】
如何解决在家办公时 “团队沟通”和“研发流程”问题 软件研发团队在家办公时会遇到的两个核心问题团队沟通和研发流程。因为云效团队原本就分布在多个城市平时的沟通方式也经常采用“在线会议”所以“在家办公”期间大团队之间的沟通协调受到的冲击较小。 但是小团队之间的沟通还是遇到一些问题平时大家坐在一起有事情“吼一声”就解决了远程办公肯定无法做到。经过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平台源于阿里巴巴先进的研发理念和工程实践致力于成为数字企业的研发效能引擎云效提供从“需求 -开发-测试-发布-运维-运营”端到端的在线协同服务和研发工具通过人工智能、云原生技术的应用助力开发者提升研发效能持续交付有效价值。 原文链接 本文为云栖社区原创内容未经允许不得转载。
