从 Etsy 团队看敏捷架构的设计(2)

简介: 从 Etsy 团队看敏捷架构的设计(2)


我们知道经验、技能和关系的多样性,有助于更好地解决问题—架构功能、场景、解决方案、错误修复或提供产品。
最好的解决方案来自于包括多个领域代表的团队,他们利用各自不同的观点和经验来解决这个问题。


如果请软件工程师设计一个门,他或她会马上开始思考门的工作原理,铰链如何运作,门把手如何转动,等等。如果请产品经理设计门,他或她可能开始考虑门应达到的效益,其他竞争对手的门都有什么功能,最后一轮用户测试的结果。如果请系统管理员设计门,他或她会开始思考如何确保安全,如果插销或锁出现常见的故障应该如何恢复。当我们把这些不同的观点都集中起来,就可以设计出一个更强大、更具可扩展性以及更高可用性的产品。


关系的多样性用来衡量团队成员的个人或专业关系网络。这对创新很重要,因为几乎所有的项目都会遇到不同的阻碍。关系广泛的团队能够在项目早期更好地识别潜在的障碍或可能遇到的问题,因为他们可以咨询各种各样团队以外的人。当团队确实遇到了障碍,这种多样化的关系使他们的易于发现和取得资源并绕过障碍。



有限的资源


 

当一个灵活的团队有多样化的技能、广泛的人脉关系以及各种各样的经验借鉴后,团队成员设计、研发、部署和支持高度可靠和可扩展的产品的能力会更强。如果公司不能为每个团队配备一位架构师,或者六个敏捷团队只有两个DevOps工程师会怎么样?


这个问题的不仅出现在资金有限的初创公司,也同样存在于现金充沛的高增长型公司。在第一种情况下,公司无法雇用很多架构师、DevOps工程师和其他想要的专业技术人员。在第二种情况下,公司可能无法如愿吸引和留住许多架构师或DevOps工程师。团队的成长常常是非同步的,先招聘软件开发人员、然后是产品经理、再后是质量保证工程师、DevOps工程师,最后是架构师。填补团队的周期可能花费一年到18个月的时间。没有一家公司会让软件开发人员闲下来等待架构师的加入。但是在这种情况下,团队该怎么做呢?


image.png



当面对有限的人员和资源时,团队通常会试图以现有的有限资源来对付。这种方法可能会为公司带来相当大的风险。试想一下没有足够的产品经理的情景。结果可能是仓促编写的用户场景描述和调度很差的项目优先级,结果导致严重的错误。


敏捷团队的第一步是确保他们有必要的资源来完成项目。


一旦关键资源缺失,这个团队就会处于危险之中。争取必要资源的办法是使用看板来直观地显示研发过程中的资源瓶颈,说明需要资源的业务理由。另一种方法是跨团队共享资源。有限的资源,如DevOps工程师,可以在整个团队共享。这些人应该被分配给多个团队,但不是所有的团队。就像有多个房客但不是所有的房客。例如,如果你有两个DevOps工程师和六个敏捷团队,把DevOps工程师1分配给敏捷团队A、B和C,把DevOps工程师2分配给敏捷团队D、E、F。这样,团队会感到与DevOps工程师有某种程度的关联性。他们开始思考“DevOps工程师1是和我一起配合的人”而不是“我们有两个DevOps工程师的资源池,要找他们帮忙就要提交请求来排队”。看到区别了吗?一方面我们打破了壁垒,另一方面可以确保他们和团队一起成长。

 

标准



在多个团队情况下,如何保持标准,是一个不变的主题。如果我们允许每个敏捷团队自主决定哪种模式、基础库、框架甚至技术,公司如何受益于规模的扩展?工程师如何在团队之间调动的过程中共享知识?在很多情况下,这些问题的答案是“那要看情况”。


这取决于组织、领导和团队成员。让我们看一些不同的方法。


image.png



“规模经济”一词是指企业因其经营的规模而实现的成本优势。基本的概念是,因为固定成本分散在更多的输出单位,每单位的输出成本随规模的增加而减少。这种思想可以追溯到亚当·斯密(1723~1790)和通过分工获取更大的生产效益的概念。


对于工程团队,规模经济来自于诸如有关技术或经营方式的知识共享。如果从项目的角度把软件研发服务的成本分解成固定成本的和可变成本两个部分,我们可以得到如下的结果。固定成本包括软件开发人员的知识和技能。我们在每个迭代为此付出,无论是为一个场景写代码还是为50个场景写代码,成本都一样。每个迭代的代码完成量越多,固定成本的分摊就越小。如果只完成一个场景的代码,这个场景就消耗固定成本的100%,如果我们的写20个场景的代码,每个场景就只负担5%的固定成本。如果每个软件开发团队(敏捷团队)必须是不同的语言、技术或过程的专家,这个知识的固定成本只由负责那些场景的单一代码团队负担。如果所有的团队都可以利用彼此的知识,那么成本就可以由所有的团队来分担。


一些组织认为应该允许团队对所有的事情独立做决定,最好的想法就会渗透到整个团队。其他组织采取不同的方法,把团队成员集中在一起制订出大家要共同遵守的标准。我们先来看看Spotify的数字音乐服务是如何解决敏捷团队的架构设计问题的。然后我们将以此方法与Wooga作对比,Wooga是一个社交游戏公司,其采用的方法稍有不同。


目录
打赏
0
0
0
0
367
分享
相关文章
超越Transformer,全面升级!MIT等华人团队发布通用时序TimeMixer++架构,8项任务全面领先
一支由麻省理工学院、香港科技大学(广州)、浙江大学和格里菲斯大学的华人研究团队,开发了名为TimeMixer++的时间序列分析模型。该模型在8项任务中超越现有技术,通过多尺度时间图像转换、双轴注意力机制和多尺度多分辨率混合等技术,实现了性能的显著提升。论文已发布于arXiv。
221 84
一阶优化算法启发,北大林宙辰团队提出具有万有逼近性质的神经网络架构的设计方法
【4月更文挑战第19天】北京大学林宙辰团队在深度学习领域取得突破,提出基于一阶优化算法的神经网络设计方法,构建具有万有逼近性质的模型,提升训练速度和泛化能力。该方法利用一阶导数信息,高效处理大规模问题。虽然面临非光滑优化和收敛速度挑战,但团队通过正则化和自适应学习率等策略进行改进,相关研究在多个标准数据集上表现出色。
124 1
|
9月前
|
微信团队分享:来看看微信十年前的IM消息收发架构,你做到了吗
好的架构是迭代出来的,却也少不了良好的设计,本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构,愿各位读者能从中获得启发。
318 1
字节跳动基础架构编排调度团队论文入选云计算领域顶会 SoCC 2023
2023 年 10 月 30 日至 11 月 1 日, SoCC 2023 将在美国加州 Santa Cruz 举行。 字节跳动基础架构 - 编排调度团队的研究成果被 S o CC 2023 接收,并受邀进行现场报告。 SoCC 会议全称 Annual ACM Symposium on Cloud Computing,是 云计算领域顶级会议之一,同时也是 ACM 所有会议当中唯一一个同时被 SIGMOD 和 SIGOPS 赞助的顶会。代表了当前云计算领域在学术界、工业界和开源社区的前沿水平。SoCC 会议伴随着云计算的兴起而成立,至今已经举办到第 14 届。该会议每年吸引全球顶级研究机构和知名
531 0
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
84 3
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等