GMTC深圳站本周日开幕,14大专题全部上线,完整日程>> 了解详情
写点什么

解析精益产品开发(一)—— 看板开发方法

  • 2013 年 4 月 26 日
  • 本文字数:6487 字

    阅读完需:约 21 分钟

看板(Kanban)开发方法是近年来最热门的敏捷和精益开发方法。越来越多的案例表明,它能够改善协作、优化管理,显著提高交付速度、质量和灵活性。看板开发方法的规则简单,但其有效实施依赖于对原理的理解、对原则的坚持和实践的应变。本文将整体介绍看板的原理、原则和基本实践。

1. 看板的原始含义

看板源自精益制造。尽管具体实践不同,看板开发方法和精益制造中的看板原理是一致的。从精益制造出发,可以帮助我们更好地理解看板的本质。

1.1 看板源自精益制造

精益制造是上世纪 50 年代起,从丰田公司实践中演化出来的,又被称为“丰田生产方式”。1990 年麻省理工的 James P. Womack 等几位教授提炼总结了丰田的实践,出版《精益生产方式——改变世界的机器》一书,精益制造的概念开始为世人所认识和效仿,直至今日,它仍然是最先进的制造方式,是制造业共同追求的目标。

丰田生产方式之父,大野耐一说:“丰田生产方式的两大支柱是‘准时化’和‘自働化’,看板是运营这一系统的工具看板是丰田生产方式的核心工具(如图 ㈠)。

图 ㈠ 丰田屋——丰田生产方式

看板(Kanban)一词来自日文,本义是可视化卡片。如 图 ㈡,看板工具的实质是:后道工序在需要时,通过看板向前道工序发出信号——请给我需要数量的输入,前道工序只有得到看板后,才按需生产。看板信号由下游向上游传递,拉动上游的生产活动,使产品向下游流动。拉动的源头是最下游的客户价值,也就是客户订单或需求。

图 ㈡ 看板拉动制造过程

图 ㈢ 是一个典型的看板——装在塑料套里的一枚卡片,包含的信息是“什么地方,需要什么产品,多少数量”

图 ㈢ 生产中的看板

1.2 基于看板的拉动系统实现准时化

准时化又叫即时生产(Just in time - JIT)是丰田生产方式的一个支柱。看板形成拉动系统,各环节根据看板信息,仅在在需要的时间,生产需要数量的必要产品。这将带来生产库存的降低,甚至实现生产过程零库存。库存又被称为“在制品(WIP ——work in progress)”,是已经开始但没有完成的工作,它们堆积在工序间或临时仓库中。库存降低带来的直接收益是:

1) 降低成本:库存减少增加了运营现金的使用率,同时降低管理和仓储开销。

2) 缩短交付周期:消除或缩短产品在工序间的库存等待时间,缩短了从开始制造到交付的周期时间。

3) 提高制造过程的灵活性:在低库存水平下,调整生产的计划更加容易。

降低库存更重要的作用是暴露制造系统中的问题。图 ㈣中的湖水岩石是一个经典隐喻,水位代表库存多少,岩石代表问题。水位高,岩石就会被隐藏。生产系统中库存多时,设备不良、停工等待、质量不佳、瓶颈过载等问题都会被掩盖。库存降低后,这些问题都会显现出来。没有了临时库存的缓冲,设备运转不良或停工等待立即会凸显出来;没有了库存等待时间,上一环节输出的质量问题也能即时得到反馈。这就是所谓“水落石出”,暴露问题是解决问题先决条件,不断暴露和解决问题,带来生产率、质量以及灵活性的提高。

图 ㈣ 湖水岩石效应

1.3 自働化

自働化是丰田生产方式的另一支柱,它的准确含义是自动停机(Auto-No-Mation),指出现问题时(如某个环节有次品),机器能够自动感知异常,并立刻停机或停下整个生产线。丰田认为,这相当于把人的智慧赋予了机器,称其为“人字旁的自动化”,所以用“働”而非 “动”字。图(三)比较了自动化与自働化在概念和实践上的不同。

图 ㈤ 自动化和自働化

自働化把质量内建于每一个制造环节,出现异常时,杜绝继续产出不合格产品,并且不把不合格产品输入到下一环节。这就是 “内建质量”(build quality in),而不是让质量依赖于最后的检测环节。

其次,自働化带来“停止并修正”(Stop and Fix)的文化,发生异常时,立刻停止生产,分析根本原因,并加以解决,防止问题的再次发生。“停止并修正”是持续改善的基础。

2. 精益产品开发的发展

以上我们简要介绍了精益制造(丰田生产方式)的框架和其中的看板实践,它既带来直接经济结果,又带来深层次的文化和思想变革。精益是制造业的革命,是既大规模生产之后的全新范式。精益思想的影响早已超越制造领域,精益服务、精益医疗,甚至精益行政都被广泛实践,产品开发也不例外。然而,开发和制造特点不同,决定无法照搬精益制造的实践。产品开发需要从自身特点出发,发展完备的实践体系。

产品制造

产品开发

影响

工作对象

具体、可见的物理产品

抽象、不可见的信息

产品开发的价值、价值流动不可见,管理价值流更加困难。有必要采取适当的措施,可视化价值和价值流动。

完成单个任务的时长

固定——完成前后两个加工任务的时间相同,且可以精确预测。

不固定——每一个开发任务都是全新的,完成的时长不同,且不能完全预测。

在生产中可以追求或逼近零库存。产品开发中,由于任务时长的不确定性,零库存可能会导致开发步骤间的等待。

不同任务的延期成本

相同

差别很大

在生产中一般采取先入先出(FIFO)的队列管理方式;开发中用需要应用比先入先出更灵活的队列管理方式,以优化经济结果。

对可变性和错误的态度

制造是重复的过程,消除可变性能够提高质量。

不确定性 (可变性) 是产品开发价值的一部分,完全消除差异是不可能的

产品开发必须接受不确定性,并通过必要的试错来验证它们,以增加价值。可变性不能完全消除,需要在考虑开发过程的可变性。

精益产品开发概念出现于上世纪 90 年代,2000 年后逐步成熟。这中间起到推动作用的代表人物有 Mary Poppendieck,Don Reinertsen 和 David J. Anderson 等。他们促进了精益思想和产品开发特征的结合。

Mary Poppendieck 是精益软件开发的早期推动者,她的思想在敏捷软件开发社区被广泛引用,2003 年到 2010 年,Mary 和他的丈夫 Tom Poppendieck 先后在三本书中总结了这些思想,并提出了操作建议。Don Reinertsen 致力揭示产品开发流的本质,并提出相匹配的原则方法。在 2010 年出版的“ The Principles of Product Development Flow ”一书中,Don 提炼了精益产品开发的 175 条原则,这可能是迄今为止对产品开发最本质和深入全面的阐述。但面对 175 条原则,从哪里开始是一个问题。

2006 年在 Don Reinertsen 的启发和鼓励下,David J. Anderson 最早在软件开发中应用看板实践,其后不断完善,形成了看板开发方法,这是精益产品开发走向适用和普及的重要里程碑。看板的推广速度超过任何其它敏捷开发方法,Version one 的调查报告显示看板是增长最快的敏捷实践,2011 年使用了看板的敏捷团队占24%,2010 年这个数据是18%。

2010 年 David 在他的著作”kanban – Successful Evolutionary Change for Your Technology Business”一书中,详细介绍了看板的价值、原则和实践。书中总结了看板开发方法的五个核心实践,它们是:可视化工作流、过程规则显式化、限制在制品数量、度量和管理流动、以及协同改进。接下来,我们将以这五个实践为线索,介绍看板开发方法的概貌。

3. 看板的五个核心实践

3.1 核心实践 1:可视化工作(价值)流

产品开发的加工对象——信息——是抽象和不可见的,这提高了价值流的管理难度。看板开发方法把可视化工作流作为基础实践,先让价值和价值流动具体可见,然后才是管理和优化。图 ㈥是看板开发方法中的一个典型可视化案例,被称为看板墙(Kanban wall)。

图 ㈥ 可视化工作流

图中的每个卡片代表一个价值项,如:功能需求、缺陷、技术概念验证等。它们所在的列,表示其所处的阶段。这些价值项,每经过一个阶段(图中的列)都会产生新信息,价值得以增加。例如,需求经过分析阶段,注入了新信息,价值更高。价值流是价值项从左至右的流动过程,是信息的产出过程,也是价值增加的过程。

价值流动可能会被阻碍。比如,编码因对第三方接口错误而无法进展;测试因没有设备而停滞。图中,红色卡片是对问题和阻碍因素的可视化。标识阻碍因素并推动其解决,促进价值流动。

最终限制系统端到端流量的是系统瓶颈处的流量,改善端到端的价值流,必须从解决瓶颈问题开始。发现看板墙上的瓶颈并不困难,找到最长的队列就可以了,这就和交通系统的瓶颈处,总是出现长长的等待车队是一个道理。上图中的队列出现在测试处,不难看出,测试是价值流动的瓶颈。

价值、价值流,以及问题和瓶颈的可视化,是改善价值的起始,也是其它看板实践的基础。

3.2 核心实践 2:显式化流程规则

显式化流程规则,是指明确定义和沟通团队所遵循的流程规则。价值项的“流转规则”是看板开发方法中最典型流程规则,它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。图 ㈦中,给出了某团队其中一项流转规则的实例,定义了从分析阶段进入开发阶段所必须达到的条件。

“流转规则”的显式化,让质量内建于各个阶段——这与精益制造中内建质量的思想是一致的。除各个“流转规则”外,其它重要的流程规则也可以或者需要被显式化,如,团队的协作规则、优先级的定义规则等。

图 ㈦ 显程化流程规则

流程规则显式化更重要的意义在于,它是“持续改进”的出发点和结果的载体。没有显式化的规则作为依据,讨论改进就没有基础,而变得主观和随意。改进的结果通常也需要落实到显式的流程规则当中,让改进稳步进行,避免低效的反复。显式化规则不是为了限定团队的工作方式,而是为了帮助团队更好的改进。这就像,丰田的生产现场必须有明确操作规程,但如果这个操作过程长时间没有变化也同样是一个问题,因为,持续改进是精益思想的核心之一。

3.3 核心实践 3:限制在制品数量

限制在制品数量是看板开发方法的核心机制。如 图 ㈧所示,列标题右面的数字标识了该阶段允许的在制品的最大数目(进行中和完成的价值项的和)。在制品数目小于这个数字时,才可以从前一阶段拉入新的工作。图中,分析阶段的在制品限制数目是 3,而实际在制品数目是 2,可以拉入新的工作。测试阶段的在制品数是 3,达到了上限,就不允许拉入新工作。

图 ㈧ 限制在制品数目

限制在制品数量形成一个与精益制造类似的拉动机制。一个环节有空余的能力(在制品数目未达上限)时,从上游拉入新的工作,拉动的源头是最下游的交付或客户需求。与产品制造类似,通过拉动系统可以:

1) 加速价值流动:限制在制品数量,减少了价值项在阶段间的排队等待,缩短了价值从进入系统到交付的时间,加速了端到端的价值流动。

2) 暴露问题:限制在制品数量,让湖水岩石效应产生作用。它让过去被隐藏的问题,如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。

许多号称使用“看板”的团队,并没有限制在制品数量,他们当然也不会得到上述收益。精益制造通过看板向上游传信号,拉动生产。而看板开发方法通过限制在制品数量形成拉动系统,缺乏这一核心机制就不成其为看板,对此, Corey Ladas 这样描述 “复印的美元不再具备货币的内涵,因此不再是钱;同样,缺少在制品数量限制的看板墙,也不能叫看板”。在制品数量的限制值及其演化,将在以后的文章中讨论。

3.4 核心实践 4:度量和管理流动

快速、顺畅的价值流动是看板开发方法的目标。快速流动带来快速的价值产出和快速反馈,它对业务成功至关重要;顺畅流动,意味着稳定和可预测的价值交付能力,这与流动的绝对速度同等重要。

度量为改善价值流动提供方向参考,同时为改善的结果提供反馈。看板开发方法没有定义特定的度量方法,累积流量图是实际应用较为普遍的一种。图 ㈨是一个典型的累积流量图,左面的斜线是累积已经开始的价值项(如用户需求)数目,右面斜线是累积完成价值项的数目。两条斜线的垂直距离表示某个时刻已经开始但还没有完成的价值项数目,也就是在制品的总计数量。两条斜线的水平间距表示价值项从开始到完成的周期时间,也就是从概念到交付的响应时间,它是价值流动效率的一个重要衡量。斜线的斜率反应的是价值交付的速率,也就是每周可以交付的价值项数量。

图 ㈨ 流量累积图

累积流量是一个综合的价值流度量方法,可以通过它得到不同维度的信息。例如,我们设想限制在制品的数目,可以缩短周期时间、而对交付速率影响有限。但实际效果如何还要通过事实来检验,通过实验和度量,图中的数据基本验证了这一假设,让改进更有方向,结果更可衡量。同样的数据有不同的呈现方式,图 ㈩基于相同的数据,它突出了在制品数目和周期时间的变化趋势,以及两者的关系。从图中可以看出,周期时间的降低略滞后于在制品数量的降低,这符合精益理论,因为只有在积累的队列被处理完后,对交付周期的改进才能够显现出来。而图 11 反应的是系统流量(每周交付价值的数量)的变化趋势,为改进提供了信心。

图 ㈩ 在制品数目和周期时间

图 11 周流量图

以上只是一个度量实例。度量不是目的,而是管理和优化价值流的手段。对于特定的组织,度量什么应该由目标和现状决定。

3.5 核心实践 5:协同改进(Improve Collaboratively)

应用可视化、限制在制品数量、以及价值流度量,能够暴露产品开发中的问题和瓶颈。但发现问题还不够,重要的是如何去解决它们,对此看板开发方法给出了两个建议——团队协作和应用科学方法和模型。限制在制品数目本身就能够激发协作,例如在前面图 ㈧的看板墙,可能会出现以下的顺序场景

1) 测试遇到问题 (如输入质量太差) 而被阻塞 ,在制品数量达到上限

2) 因在制品数量达到上限,根据规则,测试不能从上游(实现)拉入更多的工作

3) 实现阶段已完成的工作无法进入下游测试环节,实现阶段的在制品数量很快也达到上限

4) 实现要想开始更多的工作,就必须关注下游的问题,并做出反应,如提高本环节的输出质量,或者是给予帮助

5) 实现和测试的协作使价值流动更加顺畅

图 12 协同改进

图 12 是”kanban – Successful Evolutionary Change for Your Technology Business”一书的封面插图,它反映了发生在看板墙前面的协同改进。看板开发方法的基本假设是:产品开发的目标不是单个环节效率的最大化,而是端到端价值流的提升。看板通过拉动机制暴露了限制价值流动的瓶颈,并激发团队协作,改善价值流动。

解决瓶颈问题的方案可能在瓶颈处,如临时加班、分配更多资源、或相邻环节的支持等。但很多时候解决瓶颈问题的方案在别处,例如提高瓶颈之前环节的输出质量,调整职责分配,甚至是重新设计工作流。

对于偶然出现的问题,只需要临时性解决方案。如突发性高负荷,可以通过暂时的相互支持解决。而对于系统性问题,如持续的负荷不均衡,则需要长期的方案和更加系统和科学的模型指导,如系统思考、精益思想、排队理论等,这些模型本身不属于看板方法的一部分,但它们让长期的改进有章可循,以后的文章,我将中深入地探讨其中的一些模型。

4. 总结:看板是变革方法

David J. Anderson 这样定义看板开发方法

“看板定义了我增量、渐进地改变技术开发和组织运营的方法。它的核心机制是限制在制品数量的拉动系统,通过它暴露系统运作(或流程)的问题,并激发协作以改进系统。”

这当中的核心是,看板并不是一个开发框架或流程,而是引领变革的方法。每个组织有自己特点,所面对的市场,使用的技术不同,经历和所处的阶段不同,他们值得也应该拥有适合自身特点的方法流程。

看板的实施正是从组织流程现状出发,首先可视化实际工作流并显式化流程;在此基础上,限制在制品数量形成拉动系统以暴露系统问题和瓶颈,度量价值流动以发现改进机会;并通过团队的协作,不断改进和演化出合适的流程、方法,实现一个高效、顺畅的产品开发价值流。

适应组织的具体情况,和发现合适的变革路径,这两点是敏捷实施的最大困难,看板给出了被证明可行的方案。这可能是看板能够在国外社区迅速推广并成功运用的原因,而在国内,看板这方面的价值还远未被认识和发掘。这篇文章之后,我们还会从不同的方面,更加深入地介绍精益产品开发。它们是:

- 价值篇:解析产品开发中的价值和价值发现过程

- 价值流篇:解析产品开发中流动的本质,和价值流的管理

- 可视化篇:探讨面向价值和价值流的整体可视化方案

- 看板实施篇:通过案例介绍看板的实施步骤和实践细节

- 变革篇:从组织变革的视角讨论精益的实施、看板应用和持续改进

- ……


感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2013 年 4 月 26 日 03:4914222

评论

发布
暂无评论
  • 软件开发中的准时化生产

    准时化生产(Just In Time,JIT)是精益生产(Lean Production)中的重要概念,它来源于丰田汽车公司,强调在合适的时间生产合适数量的满足客户需求的产品。由于制造业和软件开发行业都面临着一些类似的问题,软件开发组织从一开始就借鉴着制造业中不同的生产和管理方式,并形成了不同的软件开发方法。敏捷开发与准时化生产中的很多观点和实践是一致的,精益思想作为准时化生产的指导思想也正在积极地影响着软件开发的方式,向其中注入着创新与活力。

  • OPTM 框架:怎么使用 CLAP 模型?

    这一讲,我详细讲解了OPTM框架,并且以烘焙公司为例介绍了CLAP模型和AAR模型的使用方法。

    2021 年 2 月 3 日

  • 价值流图适用于软件开发吗?

    价值流图是精益制造中用于分析物流和信息流的方法,为客户提供产品或服务时这是必须的。丰田成功地在制造业中实现了这个过程,同时价值流图也已经映射到软件开发中。软件开发与制造业使用的是相同方法吗?

  • M 三兄弟-精益三人组

    关于软件开发中应用精益原则的讨论,大部分集中在识别和消除浪费(浪费在日语中叫作:muda)。同样,精益思考的目标是消除过重的负担(过重的负担在日语中叫作:muri)和不必要的变化(不必要的变化在日语中叫作:mura)。Roman Pichler对“M三兄弟”之间的关系进行了讨论,并建议将消除过重的负担作为走上精益之路的第一步。

  • 看板方法:科技企业渐进变革成功之道

    看板在软件开发领域已获得越来越多的应用,而大卫·安德森是这个领域当之无愧的领导者,《看板方法:科技企业渐进变革成功之道》是他系统深入阐述看板方法的重要著作,是了解和实践看板的必备读物。

  • 精益看板(上):精益驱动的敏捷开发方法

    企业的敏捷转型并没有一条通用的路径,所用的方法也没有一定之规。今天,我就跟你分享一种主流的敏捷开发方法:精益看板。

    2019 年 10 月 29 日

  • 从把事做对到做对的事

    ING Netherlands首席信息官Peter Jacobs在Agile 2018印度大会上作了一场演讲。他在演讲中说明了如何提倡并践行敏捷方法,帮助组织把事做对,以便应对他们目前面临的挑战,保证他们真正做对的事。

  • 第 85 讲 | 游舒帆:敏捷力,拥抱不确定性,与 VUCA 共舞

    当所有部门都正确理解了敏捷,而非把敏捷视为研发团队的责任,企业才可能真正敏捷,面对多变且不确定的环境时,才能同舟共济,以达成目标为首要。

    2018 年 9 月 11 日

  • 大厂都在用哪些敏捷方法?(上)

    大厂做项目采用常见的“分而治之”的策略:大项目拆成小项目,大服务拆成小服务,大团队拆成小团队。

    2019 年 3 月 7 日

  • 看板如何奏效

    最近,越来越多的人开始对看板产生兴趣,因为它是管理软件开发简单有效的方法。但是看板如何奏效?本文依据排队理论深入细节,试图去理解看板的动态性。Amr Noaman Abdel-Hamid在本文中提供了三个案例分析,对于看板如何奏效,他揭示了一些基本的、精辟的思想。

  • 研发效能度量核心方法与实践:实践框架和指标体系设计

    本篇文章,我会介绍名为“研发效能度量的五项精进”的度量实践框架,详细展开根据这几年经验总结出来的研发效能度量指标集设计、关键指标定义,并会对指标设计过程中的常见疑问进行解答。

  • 应用看板的是是非非

    看板(Kanban)试图通过确保上游阶段只生产下游阶段所需的零件,以达到在不同阶段之间最小化WIP(未完成任务),或者存货清单的目的。最近以来,精益和看板变得越发流行。越来越多的公司开始创建看板,以限制WIP和终止浪费(Muda)。Michael Dubakov撰文探讨了应用看板的是是非非。

  • 都 996 了,需求还是没法按时交付,怎么办?

    在产品开发中,很多管理者往往关注的是各环节的产出以及工程师的忙碌程度,阿里资深技术专家何勉认为,这些局部的优化往往是研发效能改进过程中最大的坑。产品开发的核心问题从来不是停滞的资源(工程师),而是停滞的价值项(用户需求)。如果仅仅关注“停滞的工程师”,我们总有办法让各个资源环节忙起来,至少看上去忙起来,但它往往只是掩盖了问题。停滞的需求才是影响研发效能的关键所在。

  • Ultimate Kanban:Ultimate Software 不使用框架实现规模化敏捷

    Ultimate Software结合Kanban作为其规模化方式,与公司的自主文化相结合。团队定义了自己的流程,并根据自己的情况使用规则。通过创新使用流实践和原则,Ultimate从精益敏捷中受益匪浅,公司也不再使用重量级框架。

  • 将看板应用于软件开发:从敏捷到精益

    许多团队仅对软件价值流(software value stream)的一部分做了优化,但是Kenji Hiranabe向我们展示了如何将精益生产中的看板跟踪系统嫁接到软件开发中,以便与更多的组织结构进行沟通。

  • “一问一答”第 1 期 | 30 个软件开发常见问题解决策略

    软件开发中的很多问题,都是可以通过软件工程的知识来解决的。

    2019 年 3 月 16 日

  • 效能度量:效果不好甚至有副作用,怎么回事?

    我分析了度量难题的几个原因,并列举了三个失败案例,希望能对你有所启发,并避免再犯类似的错误。

    2019 年 8 月 26 日

  • QCon 北京路宁专访:精益开发

    精益软件开发方法因其对市场和交付的重视和在各种场景下体现出的适应能力正在获得广泛的关注。特别是在精益创业(Lean Startup)渐渐兴起和技术日新月异的今天,其"极端"的思想也变得越来越必要和可行。讲师将结合自己在众多项目上的经验和行业的最新发展,介绍精益开发方法在市场,团队及管理、应用设计、以及开发测试和运维方面的最佳实践,帮助大家清楚地认识精益开发并学习到可直接应用于自己团队的实践。 InfoQ就此主题对他做了深入的采访。

  • Sandvik IT 实施看板三年:改进之旅的故事

    这是一个在企业范围内实施看板的故事。它阐述了为什么Sandvik IT选择了看板方法;如何使用快速启动的概念进行推广;如何使用看板深度评估进行跟进;目前为止的效果。关于如何一步步地快速启动和评估,文中提供了指向具体信息的链接。

  • 无迭代的增量式软件开发

    David Anderson描述了他的团队在运维工程(维护与Bug修复)活动中如何使用看板系统。尽管没有使用迭代,但软件仍旧保持每两星期发布一次。他们通过“看板”和每日站立会议来布置任务,并对其进行监控。

发现更多内容

2021腾讯Android面试题精选,复习指南

欢喜学安卓

android 程序员 面试 移动开发

个性化联邦学习算法框架发布,赋能AI药物研发

华为云开发者社区

联邦学习 药物研发 算法框架

云计算架构师-带你安装MySQL数据库并去除安全隐患

学神来啦

MySQL 数据库 Linux 运维 MariaDB

2021Java面试心得:kafka工具

Java 程序员 面试 后端

Linux ssh命令详解,连ssh命令都不了解就别说自己会用Linux了

北游学Java

Java Linux SSH

FIL云算力挖矿平台系统开发案例

Geek_23f0c3

云算力挖矿系统开发详解 云算力模式系统开发源码 filecoin矿机哪家好? fil挖矿

2021吊打面试官系列!mysql数据库版本最新

Java 程序员 面试 后端

2021年中国DevOps现状调查报告发布!

华为云开发者社区

DevOps 敏捷 安全 华为云DevCloud 信通院

校友卡微信小程序开发总结

CC同学

🏆【Java 技术之旅】带你深入理解和认识SPI运作机制

浩宇天尚

Java 抽象 spi 7月日更

2021Java面试总结!Java中VO的使用

Java 程序员 面试 后端

2021Java高级面试题!Java面试问题大全及答案大全下载

Java 程序员 面试 后端

吴亦凡都美竹事件:男人全员恶人?

6979阿强

golang--字典树

en

数据结构与算法 字典树

2021Java面试心得:docker运行springboot项目

Java 程序员 面试 后端

2021年最新大厂Android面试笔试题目,威力加强版

欢喜学安卓

带你看清梦饷集团如何成为上海在线新经济四小龙

华为云开发者社区

MySQL 数据库 mongodb 电商 华为云数据库

云小课 | 一分钟了解AppCube中的应用

华为云开发者社区

低代码 云小课 应用 AppCube 应用魔方

IM与办公平台的关系设计

superman

产品经理 架构师 IM 移动办公平台 自建移动办公

HarmonyOS开发者日杭州站举办,多维赋能开发者实现高效开发

科技汇

2021Java高级面试题总结!Java数组添加另一个数组

Java 程序员 面试 后端

Python开发篇——如何在Flask下编写JWT登录

DisonTangor

Python flask JWT

奥运神颜运动员

6979阿强

从0到1亿用户的架构设计

俞凡

架构

2021Java高级面试题总结:docker运行jar包依赖和程序分开

程序员 面试 后端

2021京东Java面试真题:Java枚举的作用与好处

Java 程序员 面试 后端

结对编程,到底是双剑合璧还是脚趾抠地?

华为云开发者社区

编程 软件 敏捷 敏捷开发 结对编程

7月日更,FAIL!FAIL?

Nydia

【翻译】数据包的旅程 - OSI模型

luojiahu

计算机网络 OSI模型

🏆「推荐收藏」【Git实战专题】代码提交错误怎么办?教你如何回退版本!

浩宇天尚

git git flow git reset git revert

iOS开发底层面试攻略

面试 移动开发 ios开发

2021星空论坛:破局创新,论道数字化转型

2021星空论坛:破局创新,论道数字化转型

解析精益产品开发(一)—— 看板开发方法-InfoQ