写点什么

《大规模 Scrum:More with LeSS》访谈

2017 年 4 月 24 日

关键结论

  • 大规模敏捷需要组织机构减少自身的复杂性。
  • 需要一个恰到好处的框架来支持大规模敏捷。
  • 所创建的环境鼓励自然涌现的非正式协作。
  • 这使得团队开发人员能和客户直接沟通。
  • 共同迭代和不断学习才能构建优秀的产品。

在 Craig Larman 和 Bas Vodde 所著的《More with LeSS》一书中,介绍了多团队合作生产一个产品时,如何采用 Scrum 来创建更加简单灵活的组织结构。《More with LeSS》是 LeSS 系列的第三本书(参见 LeSS 的其他书籍),是学习 LeSS 最具体也最基础的入门书籍。这本书还包含了有关采用 LeSS 的经验和见解。

现在可以在线阅读《More with LeSS》第二章

InfoQ 采访了 Craig Larman 和 Bas Vodde,探讨了如下内容:LeSS 的定义、第三本书如何搭配之前出版的大规模 Scrum 方面的书籍、组织应该如何采用 LeSS、与功能团队合作、为了实现协作顺畅和整体性要怎么做、LeSS 如何看待经理的角色,以及对多站点组织采用 LeSS 的建议。

InfoQ: 可以为不熟悉 LeSS 的人简单介绍下吗

Craig Larman 和 Bas Vodde:LeSS 是什么?简单地说,LeSS 是合作研发同一个产品的多个团队要使用的 Scrum 原则。

分别介绍如下:

LeSS 仍是 Scrum,是大规模的 Scrum(Large-Scale Scrum)。LeSS 不是新事物或 Scrum 的改进,也不是团队底层或者建立在团队之上的 Scrum。相反,它是关于在多团队场景下,如何实践 Scrum 的价值观、原则、意图、元素和优雅。同 Scrum 和其他按照敏捷定义的框架一样,LeSS 遵循“够用论”。

规模化 Scrum 并不是仅仅用于团队级别的、恰好包含了 Scrum 的特殊规模化框架。真正的规模化 Scrum 是让 Scrum 规模化。

应用于多个团队。这些团队跨功能、跨组件,由 3-9 名热衷于学习的成员组成,每个成员都为完成任务和产品交付而无往不前。

共同创造。 团队成员要一起工作,他们要有共同的目标,在公共 Sprint 里完成一个可交付的产品,以后还可能要持续交付,每个团队都很重视这一点,因为功能团队要负责产品的整体,而不是一部分。

同一个产品。什么产品?一个宽广完整的端到端的以客户为中心的解决方案,使用者是真真实实的客户。产品不是组件、平台、层或软件库。

LeSS 包含以下内容:

规则。即构成基础的一些规则。规则定义了 LeSS 框架的本质,这些规则是能够支持经验过程控制和以整体产品为中心的最低要求。例如,要在每一次 Sprint 时都进行总体回顾。

指南。一套适当的指南,阐明了组织在采用 LeSS 规则时会产生的影响。均基于多年的 LeSS 经验,值得尝试。例如,“采用三原则”。

实验。很多实验有情景要求,甚至不值得尝试。例如,尝试在团队间进行翻译转述。

原则。位于核心的是一套从采用 LeSS 的经验中总结出来的原则,包含了规则、指南和实验的有关信息。例如,要以整体产品为中心。

InfoQ: 在最新的关于 LeSS 的第三本书中,想传达 LeSS 什么样的差异化思想

Larman 和 Vodde:我们想传达两种不同的思想。(1)自己做主。(2)LeSS 的目的是降低组织的复杂性,而不仅仅是 LeSS 本身。

自己做主

回到敏捷开发的早年,思想领袖们试图传达一个重要理论:够用论。让框架必需的元素集保持极简、刚好够用,这样组织内的人员就能自己做主。他们拥有、在乎和改进自己的想法,而不是借鉴、使用和跟从。团队将学习并创造性地解决问题,创建和发展符合情景的流程和实践。这就像丰田精益精神中挑战每一件事的心态和文化,工人们自己实践形成了自己的组织系统并不断地去完善。

当然,这并不意味着不必再像其他团队学习,他们应该!主要区别在于:传统方式看重流程,有顾问来指导团队并培训应遵循怎样的最佳实践方案。而现在更看重持续发展,团队通过阅读指南来学习早期值得关注的想法,同样也会通过实验来进行革新。

这便是为何 LeSS 被称作 LeSS(除了是 Large-Scale Scrum 的简写):它更少。或者说,对于在一个产品线上合作的多个团队来说,它简单且够用。

不仅仅是 LeSS

很多人问:“大型复杂组织中要怎样应用敏捷?”

我认为这是一个错误的问题。为什么?

因为传统大型组织的复杂性并非必需的,它们的组织设计造成了这种假象,是一种不必要的复杂性。

这是至关重要的!很多大型群体是由一个个独立的功能团体和组件团队构成的,这就导致了协调混乱的问题。随后人们便会问,现存的这种组织设计,要如何应用“敏捷方法”呢。

这些大型群体是如何变复杂的?一个主要原因是,传统手段通过添加角色、流程、工件来解决问题。每当一个新的想法或一个需要解决的问题出现,就要做加法。添加角色、流程、工件这种传统方法看上去无害,但其实不然。更多的角色会导致更少的责任(和更多的协调沟通工作),流程减少了话语权和改进的空间,工件则拉大了团队和客户的距离。

因此,在 LeSS 中,我们会这样问:“如何简化不必要的大而复杂的组织设计,让组织自身敏捷,而不是去变得敏捷?” 所以,LeSS 能够去除组织的复杂度,对复杂组织的不必要的解决方案进行简化,用简单的方式解决问题。

因此,可以说,LeSS 的作用是降低规模,而不是增大规模。

如果在学习 LeSS 后有人说:“好吧,这里的角色、流程和实践还不够。我们想要一个更大的框架,里边有更多超好的实践。”… 那么他们真是理解错了重点。

InfoQ:为什么决定写这本书

Larman 和 Vodde:在对 LeSS 前两本书( LeSS 第一本书 LeSS 第二本书)的意见反馈进行思考时,我们发现虽然给出了很多观点,却鲜少提及如何着手实施,于是决定写第三本《 Large-Scale Scrum: More with LeSS 》, 最初是打算为前两本 LeSS 写一本入门书, 期望能帮助到新手团体。但是最终我们写出的不仅是一本入门书,它包含了不同的内容并且更有趣。当然它仍然是开始学习 LeSS 的最具体最基础的书籍。

InfoQ:这本书的目标读者是谁

Larman 和 Vodde:这本书适用于在产品开发中希望创建一个自身敏捷的组织(而不是实施敏捷)的任何成员。采用 LeSS 意味着现有的组织设计将发生改变,包括结构、团体、角色、流程以及政策。所以,本书与能够决策组织变动的高级管理层相关…但也与团队成员、教练、Scrum 主管、产品负责人相关,也适合所有想了解 Scrum、LeSS 以及组织的人。

InfoQ:这本书如何与以前出版的 LeSS 书搭配阅读呢

Larman 和 Vodde:我们原本打算写一本关于前两本 LeSS 的入门书。

最后却写了本不同的书。因为在研究具体如何开始采用 LeSS 时,引发了我们对规模化的最小要素的思考。然后?就有了 LeSS 规则、LeSS 指南以及这本书。书中也包含了 10 年来采用 LeSS 的经验和重要见解,对最重要的部分做了整合、阐明和强调。例如,我们意识到(至少阐明了) 产品定义范围对于规模化和系统优化的重要性,书中包括了关于产品范围的一套重要指南,而这些在前两本书中都没有提到过。

尽管这本书最后同我们原本打算的非常不一样(其实更好!),我们仍强烈推荐它作为学习 LeSS 的入门书。将来,前两本也许会进行修改,加入本书的概念。

InfoQ:如何在组织中采用 LeSS

Larman and Vodde:首先,采用 LeSS 有一个采用三原则。

  1. 专注原则。深入专注,需要把大量精力放在训练、管理支持等方面,从经验中学习,推测未来的变化。
  2. 自顶向下、自底向上。自顶向下、自底向上意思是,由于 LeSS 要对组织设计(群组、角色、政策等)做深入的改变,则一定会包括高层管理人员的参与,来实施这些变化。而让成员被动去服从上级发出的命令也许没有效果,这时需要在团队中引进深入学习,激发团队的能量。
  3. 自愿原则。 自愿原则,是指成员自愿参与变革,以此带来团队归属感和正能量。

实际操作上采用的方法取决于产品群组的规模。LeSS 中有 2 个框架。简化版 LeSS 框架,适用于 2-8 个团队的产品群体(例如 50 人左右)。大型 LeSS 框架,适用于单个产品超过百人或千人规模的产品群体。
为何提到这点?重申一下,这是因为具体方案会因为采用框架的不同而不同。事实上,两者正相反。

2-8 个团队采用 LeSS

小型群体部署简化版 LeSS 框架,规则是“一次性搞定”,“从一开始”就建立完整的 LeSS 结构。

为什么对于小型 LeSS 框架,要一次性完成呢?有几个原因,但或许最简单的概括是,LeSS 的组织模型在结构、角色、责任、流程、政策和实践等方面均与传统(现存)模型截然不同。不更改结构会造成无数深层次的冲突,其中大部分正是因为只改了名字而未做其他变更引起的。我们曾在《 Larman’s Laws of Organizational Behavior 》(《组织行为的拉尔曼法则》)一文中介绍过这种行为。

因为“仅有”50 人左右,他们可以在“一次性搞定”还没开始前的几个月组织起来准备,这是可以切实去做到的。准备过程包括了解 LeSS 的结构,系统性的思考,深入了解现存问题,让环境和团队为 LeSS 的第一次 Sprint 做好准备。在这本新书的入门指南中,我们讲述了采用 LeSS 的典型步骤。

  1. 培训
  2. 定义“产品”
  3. 定义“完成”
  4. 组建合适的结构化团队
  5. 由产品负责人进行分工
  6. 让项目经理远离团队

在这次的简单介绍中我们就不对细节进行展开了,我们只想强调,第一步“定义产品”是关键。很多事情都以合适的产品定义为前提,LeSS 的基本要求是产品定义要尽可能丰富、以实际的最终客户为中心。在实践中,很多公司都发现他们的产品和原本以为的并不相同。

大型 LeSS 采用

在对 500 人左右规模的多站点组织中采用大型 LeSS,“一次性搞定”的方法不再适用,这种过多更改带来的影响,会让组织无法吸收、学习和适应。因为有模型冲突的问题,我们也乐意看到能一次性完成,但这是不可行的。如果有人有办法,欢迎赐教。

采用大型 LeSS 时最经常被推荐(但不是唯一)的推荐方法是创建一个并行组织,这样能避免模型冲突带来的大多数问题,并同时遵守了三原则中的深入并专注。首先要整理好产品积压需求,然后选择一个以客户为中心的部分来采用 LeSS。这个以客户为中心的部分(在大型 LeSS 中被称作需求范围)基本上由 2-8 个团队构成,可部署小型 LeSS 框架。组织的其余部分仍能像以前一样运作,当然,如果理想,也要持续改进,尤其是在技术方面。

最后我们想给出的采用指南是:工作安全,而非角色安全。如果因为改变观念而失去工作,这对人们是极度不尊重和不公平的。事实上在变革管理方面,你不可能成功实施一个伴随着恐惧的变更,原因是不言而喻的。LeSS 意味着结构、角色和责任会发生深刻变化,自然无法确保一个人的角色安全。

InfoQ:实现新功能时,功能团队可能需要升级很多组件。这是否意味着开发人员需要了解整个系统

Larman 和 Vodde:对于 2-8 个团队的 LeSS 采用,或许有必要这样。但是对于大型 LeSS 采用,就不太可能了。

不过,首先让我们定义一个术语:功能团队(在 LeSS 中或常见用法中),是一个跨职能以及“跨组件”的团队,为了了解和交付以客户为中心的功能,无所不作。可能包括 UX 调研、分析、设计、架构、组件整合、视频、图片、音频等。为了完成功能,要对所需的任何和全部组件(微服务、应用、层、模块、类…)进行编码。

这是否意味着,对于功能团队的每个产品,开发人员都要了解全部内容呢?答案是否定的。这种“不是…就是…”的看法是软件行业的常见模式,所以计算机从业者通常具有二元思维,是有原因的。因此,我们在几年前第一本关于 LeSS 的书中写了一章《假两难推理》。

假两难推理是说,个人或团队要么只了解某一件事,要么了解所有的一切,但实际上,很有可能不同的团队成员具有不同程度的专业知识,了解不同的模块。因此,为了完成一个功能,团队作为一个整体,需要拥有必要组件的相关知识,但不是每个人都需要了解全部。如果某个组件没有任何人了解,那么学习的时间就到了,学习是 LeSS 组织中一个关键和主导的行为。这并不新鲜,早在 1986 年 HBR(Harvard Business Review)的一篇描述 Scrum 起源的论文中已经定义过“多重学习”是 Scrum 的一个重要特性,意思是学习多层次技能和功能。

另外,一想到要处理不熟悉的代码,非程序员以及经常同垃圾代码打交道的程序员,会觉得这很可怕,令人生畏。但如果使用了 LeSS 在“技术卓越”中建议的 TDD 重要实践,来开发整洁的代码,就不是什么大问题。我们俩(Bas 和 Craig)除了作为 LeSS 的组织设计咨询师和高级管理者一起工作,也依然在亲自作为专业的程序员和其他开发者一起工作(这是一种对跨越职能架构的尝试)。因此,有了多年在开发整洁代码和 TDD 方面的直接经验,我们才敢说出“这不是什么大问题”这样的话。而对于要在遗留有大量垃圾代码的情况下采用 LeSS 这一常见问题,有一套补救指南和实验,包含分组的导师制度、现行架构学习研讨会等。

对于小规模 2-5 个团队采用 LeSS,有人了解代码库中的大部分或全部内容,是相对常见的。产品规模越大,则越不可能。Bas 正参与一个千人规模的大型 LeSS 采用,让一个人去了解每一部分代码是几乎不可能的。不过在这种规模下,也无需如此。为什么?大型 LeSS 由众多以用户为中心的部分构成,相互间有功能相关性,例如“交易处理”和“监管报告”。这些都被称作需求范围。团队倾向于在单个需求上花费更长时间。要注意,这些是客户需求的范围,而不是架构上的组件。即使这些需求不是基于架构组件的,专注在某个需求上(例如监管报告)的 4-8 个功能团队只需关心整个代码库的部分可预测子集也是可能的。这样,他们需要了解的代码便少于整个代码库。

InfoQ:为了让团队之间的协调和整合更加流畅,要做些什么

Larman 和 Vodde:团队的协调和整合在 LeSS 中非常重要,但 LeSS 的观点通常让人吃惊,因为人们期待的是协作行为(big room planning)、会议(Scrum 的 Scrum)或角色(项目经理、集成型团队)。但是在 LeSS 中完全没有这些,事实上,LeSS 的建议正相反。为什么。两个原因:(1)专门的协调角色会减少大家的协作责任感。(2)我们发现,正式的协作通道常会减少团队发起的、自然涌现的、自组织的、分散的协作,而我们认为这些原本更能提高效率。

如何鼓励团队间的分散式的信息协作方式?基础如下:

  • 团队自己决定如何协作
  • 功能团队要有共同的目标
  • 以产品的整体为中心
  • 友好的物理环境和技术环境

我想重点介绍下共同目标。在传统的组织结构中,协作往往是一种令人讨厌的打扰。测试团队发现 bug 时会打扰开发团队。后端团队需要前端进行修改,就要去打扰他们,中断了本来在做的其他事情。而如果沟通协作没那么正式,而是自然地发生,也许就不会令人讨厌,反而让人感到有用和及时。或者,像 Yves Morieux 在关于简化组织结构的 TED 演讲中说的那样,“我们创建的组织结构应该有助于其中每个部分的合作。” LeSS 通过对功能团队的结构重组来创建这样的组织,这些团队无所不做,他们共享代码,并将在 Sprint 结束时交付产品作为共同目标。团队间的协调合作基于他们共同关心的任务,这一切同时发生,为所有参与其中的团队带来了好处,而且与它们直接相关。

具体说下集成:LeSS 提倡先进的开发实践,例如,对主线不断更新进行持续集成,以保证产品在任何阶段的可交付,甚至在任意时刻的可持续交付。在采用大型 LeSS 时,通常首先要做的便是自动化测试、快速构建和自动化部署。

再从宏观上看:协作和集成是紧密相关的,传统上大多数协作都和集成有关。当两个团队想整合他们的工作,他们就需要协作。但是当使用持续集成时,可以将事情反过来。通过持续集成,能轻易地知道有哪些人在同时开发某一部分系统。因为可以共享工作成果,互相协作对双方都有好处。这样,取替用协作来支持集成,我们有了能够实现协作的集成。我们将这种实践称作“用代码交流”。 当然,这样一来,建分支变得比以前更讨厌了。

还有更多的关于加强这种非正式、松散式协作的 LeSS 指南,例如社区、多团队活动、开放空间、出差、分组导师、侦查员。就不在此一一细说了。

InfoQ:LeSS 如何看待经理这一角色

Larman 和 Vodde:大多公司都有众多不同的经理,我们只关注两种:项目经理和开发经理。

项目管理

在 LeSS 的组织中,项目经理这一角色在产品开发过程中近乎消失了。一部分是因为自我管理型的团队接过了大部分职责,一部分是因为避免在产品开发中使用项目模式。

LeSS 遵循传统的组织理论。如果想增加组织的弹性(敏捷性),可以进行职责委派,从而不会让决策减慢响应。这使组织更扁平,经理的数目也更少。

当然,我们不是在建议辞退所有的项目经理,因为这样做违背了 LeSS 指南中提到的“工作安全而非角色安全”的原则。相反,因为这些人通常都很聪明,可以在组织中找到不同的角色定位或融入团队。

在大型 LeSS 的产品群组中,特别是涉及硬件制造的情况下,可能仍会有最后一个关于产品发布的项目,以及和产品发布活动(如制造物流)相关的管理角色 。在采用 LeSS 时,这些现存的项目角色不会立即改变,不过,越是深入实施持续交付的组织,对项目管理的需求就越少。

开发管理

传统上,这些经理要参与产品从开始决策到生产的过程。在 Scrum 和大规模 Scrum 中,决策移交给了团队,尤其是产品负责人(来自商业部门,他们并不是开发人员或项目经理),生产完全移交给了这些自我管理型的团队。有了自我管理,团队的职责得到扩大,引用哈佛大学杰出的团队研究员 Richard Hackman 的说法,职责中包含了“对流程和进展的管理与跟进”。

在 LeSS 组织中有管理者的角色吗?如果从来不存在管理者(是的,真有这样的公司),那在采用 LeSS 时不需要去增加这样的角色。但是如果已经存在管理者,他们可是很有价值的,不过他们的角色可能会改变。他们不专注在每日的产品生产中,而是注重提高产品开发体系中的价值传递能力。通过实践去发现、鼓励暂停和修复以及对一致性的实验,管理者这一角色要对产品开发体系做出改进。

InfoQ:对多站点组织采用 LeSS 有什么建议

Larman 和 Vodde:我们为客户采用 LeSS 的大部分经验都来自超大型或多站点的产品群组(分布地点通常包含亚洲、欧洲和美洲),因此这对我们来说是一个熟悉的领域。我们的首要建议是尽量避免这种情况。人们常认为这在当今世界是不可能的,但这仍是一个选择。许多非常优秀的产品都是同地点开发,这是有道理的。

也就是说,多站点产品是可以采用 LeSS 的。重要的是,一个功能团队应在同一地点办公。为什么?一提到这种成员在不同地点办公的分布式团队,几乎无一例外地会感觉这并不算真正的团队,而像各自忙着自己事的一群人。好的团队不是这样工作的,好的团队是有高度凝聚力的社交单元,有共同目标,互相学习,时刻都在一起工作,会在白板上进行团队设计研讨,结众编程,无序结对编程等。因此同地点办公有巨大的好处。

现在如果整个开发部门要分布在 7 个城市,只有 7 个人,我们便只能接受分散这个事实。但是考虑一个典型的大规模多站点情形,也许有 200 人共同开发一个产品,50 人负责站点 1,50 人负责站点 2,以此类推。这种情况,没有理由再让一个 7 人左右的团队不在同一地点,因为每个地点都有超过 7 个人。

所以 LeSS 中多站点开发的基础是:每个功能团队要在同一地点。如果站点 1 有 3 个团队,站点 2 有 5 个团队,也是完全可以的。这种情况下,剩下的关键问题便是如何围绕不同站点的团队展开协作。不幸的是,没有魔法能够消除团队分散的痛处,减少痛苦的方法也已有共识,包括视频会议、存储共享,Slack 这样的工具,频繁出差等。

InfoQ: LeSS 如何支持组织的持续改进

Larman 和 Vodde:持续改进应该由谁来做?传统上讲,改进的行为是独立于团队,由专门的改进人员推动的。质量人员、安全人员、程序顾问、自由人,无论怎么称呼他们吧。这几乎无法带来真正的改善,因为他们没有足够重视,也看不到工作中的真正痛点。

显然,答案应该是“每个人”。但如何让组织中的每个人都进行持续改进呢?他们需要关心自己如何工作,他们要能够掌控自己的工作方式。这样我们就回到了开头讨论的“自己做主”这个话题了。当员工掌控了自己的工作,对工作效果做出快速反馈,被鼓励并被赋予了做这件事的权利,那么就能做到持续改进。

为了实现这些,框架应避免给出所有情况下的答案,以防产品部门只会照做。相反,产品部门应该边实验边改进。因此,框架只给出了一个最小的结构,允许有透明度、允许反馈和做实验。因此…

More with LeSS,不仅仅是 LeSS。

关于《More with LeSS》的作者

在结束了失败的街头音乐家职业生涯之后,Craig Larman转行学习计算机科学,主攻人工智能领域(并有了一点自己的成就)。他与好朋友兼同事 Bas Vodde 一起创立了 LeSS 并合著了三本 LeSS 的书籍:《Large-Scale Scrum: More with LeSS》、《Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum》、《Practices for Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Product Development with Large-Scale Scrum》。

在意识到不喜欢湿冷的气候之后,Bas Vodde独自一人从荷兰旅行到了新加坡,在那里他一边练习 uitbuiken(荷兰语,字面意思为超越,类似于冥想,指在人吃饱之后坐下来放松身心,以利于食物的消化)艺术,一边以教练、程序员、培训师和作者的身份帮助人们进行产品的敏捷和精益开发。他是 LeSS 和教练组织的联合创始人,分别在组织、团队、个人 / 技术实践三个方面有所建树。十多年来,他为软件开发、Scrum 和现代敏捷实践培训了数千人。

查看英文原文: Q&A on Large-Scale Scrum: More with LeSS


感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2017 年 4 月 24 日 18:543747
用户头像

发布了 62 篇内容, 共 16.4 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

第八周作业

方堃

AI大有可为:NAIE平台助力垃圾分类

华为云开发者社区

AI 模型训练 垃圾回收机制 数据集 华为云

抢占5G大市场 众盟科技助力企业跑赢短视频营销新赛道

人称T客

架构师训练营 - 学习总结 第 8 周

铁血杰克

架构师第8周练习

小蚂蚁

CompletableFuture运行流程源码详解

编号94530

Java 并发编程 多线程 CompletableFuture

单向链表合并节点

chenzt

37岁程序员被裁,想用6月工资跪舔领导划掉被裁名额,结果蒙了!

程序员生活志

程序员 职场 程序员生活

【API进阶之路】高考要考口语?我用多模态评测API做了一场10w+刷屏活动

华为云开发者社区

人工智能 学习 评测 API 华为云

如何在微服务团队中高效使用 Git 管理代码?

看山

git 微服务 高效

第八周·命题作业

刘璐

总结

chenzt

华青融天战略拓展总监王旭详解IT运维的九阳神功

DT极客

Spring系列:请问各位大佬为何要学spring?

简爱W

架构师第8周学习总结

小蚂蚁

week8

不在调上

最新硬件虚拟化检测技术,让攻击者逃不出“楚门的世界”

百度安全

云计算 安全 虚拟化

教培行业工程师面临着什么挑战?研发面板全栈式解决工程师的痛点

Deepexi

DevOps 运维 敏捷开发 研发管理 单元测试

云图说 | 快速创建一个kubernetes集群

华为云开发者社区

Kubernetes 虚拟机 集群容错 华为云 容器化

实现DevOps的三步工作法

看山

DevOps 凤凰项目

作业一

Kiroro

作业二

Kiroro

区块链+国防安全,科技是核心战斗力

CECBC区块链专委会

架构训练营第八周感悟

张锐

各类SQL中日期时间那些事

大唐小生

sql 大数据 SQL语法

PC人脸识别登录,出乎意料的简单

程序员内点事

Java 人脸识别

TNFE-Weekly[第六十六周已更新]

莹姐🙈

小程序 前端 周报

面试官问:如何设计一个安全的对外接口?

Java小咖秀

Java 面试 经验

架构师训练营第八周作业

sunnywhy

极客大学架构师训练营

作业

不在调上

第八周·总结·数据结构预算法

刘璐

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

《大规模Scrum:More with LeSS》访谈-InfoQ