关于敏捷开发:对最近火热的DevOps已死的回应

4次阅读

共计 2062 个字符,预计需要花费 6 分钟才能阅读完成。

前几天看到 Infoq 转载的文章“DevOps 已死,平台工程才是将来”,心生感叹。因为这不禁让人想起 2014 或 2015 年左右,麻利宣言的提出者之一“Dave Thomas”在一次大会上发表的主题为“麻利已死”的演讲,两者有十分类似的外延。

“麻利开发”和“DevOps”在诞生之后都对软件开发畛域产生了微小的影响,借用“Al Tenhundfeld”的说法,没有人想被称为非“麻利”(或非“DevOps”),这是作为一种“标签”的胜利。然而,“麻利”或“DevOps”在真正的实际过程中往往偏离了一开始的初衷,甚至走向了背面。每个人都说他们在做麻利,但简直没有人是真正麻利的,DevOps 同理。

麻利已死?

让咱们先来重温一下“麻利软件开发宣言”的内容:

咱们始终在实践中探寻更好的软件开发办法,事必躬亲的同时也帮忙别人。由此咱们建设了如下价值观:

个体和互动 高于 流程和工具工作的软件 

高于 详尽的文档客户单干 高于 合同会谈 

响应变动 高于 遵循打算 

也就是说,只管右项有其价值,咱们更器重左项的价值。

而后,依照宣言内容提到的价值观来察看一下事实:

采购“流程与工具”比“集体和互动”容易的多 

生产不切实际的的打算和大量文档比生产可“工作的软件”容易的多 

“合同会谈”带来的安全感比“客户单干”须要建设的信赖更容易失去 

管理层对“遵循打算”的需要往往高于对变动作出反应而事实是如此残暴,因而当缺乏经验的团队施行麻利的过程往往会陷入凌乱。当各种“认证”、流程和工具自称能疏导实现麻利时,团队就会很天然的走向了麻利的“反模式”。当“麻利”曾经成为供应商抛售服务和产品的标签时,当“麻利”曾经被颠覆到了毫无意义的境地时,是的,麻利已死。

对于这个主题还能够看看 Al Tenhundfeld 的文章或者看看 InfoQ 的中文翻译版,本文不再赘述。DevOps 已死?“DevOps”的提出要晚于“麻利”,大概是在 2009 年为了突出器重软件开发人员和运维人员的沟通单干而被发明进去的组合词 (即 Development 和 Operations)。最后“DevOps”是一种理念,通过突破开发人员和运维人员之间的壁垒,来更快的交付和改良产品。

现实状况下,“DevOps”的落地会造成一个同时蕴含开发、运维人员的全功能团队并承当产品的上线运行、变更治理和保护等工作和职责。没错,这听起来就像是一个“麻利”的自组织团队,共同努力为客户交付价值。因而要正确执行 DevOps,所有参与者都必须承受麻利思维。

而事实是,在管理层正确的了解和反对的状况下,团队自底向上施行真正的 DevOp 近乎不可能。

某些组织会建设独立的 DevOps 团队来负责利用的部署和运维。这种状况下,即便应用了相干的工具,这种所谓的“DevOps”团队也只不过是对运维团队的另一种称说。

另外一些组织则是简略的将在开发团队中减少所谓的“DevOps 工程师”这类角色并负责相干职责,这岂但减少了对“DevOps 工程师”们的技能要求 (须要同时理解开发和运维常识),并且造成了新的“束缚点”。

而与“麻利”类似的,“DevOps”逐步标签化,逐步丢失了原有的语义而变成了流程、工具厂商推销产品的标签。开发与运维人员之间的壁垒不仅没有被突破,反而因为更高的交付压力而更加凸显。

寻根究底

“麻利”和“DevOps”等静止或文化衰亡的背地起因在于“软件危机”。

“软件危机”所形容的外围问题就是:

如何开发软件,以满足对软件日益增长的需要 
如何保护数量一直收缩的已有软件

在上世纪 60 年代至 90 年代,通过在软件畛域引入工程学而造成的“软件工程学”、结构化编程技术、面向对象的程序设计等等都是为了解决“软件危机”问题。而进入新世纪后,随着互联网等技术的倒退,市场对软件的需要产生了爆发式的增长。由此催生出了“麻利开发”、“DevOps”等新的形式来尝试解决“软件危机”。

能够预感的是,在上述问题没有解决之前,软件畛域依然会一直的催生出各种新的解决方案。例如,“低代码”工具心愿在特定畛域实现“公民开发者”(即非技术人员) 能够直接参与解决方案的开发。又或者前文提到的“平台工程”、“NoOps”等等。

但咱们仍应看到,软件开发的外围是开发者。“麻利”与“DevOps”的内核体现的是对人的关注而非流程、工具之类。即便在 2022 年,“麻利”与“DevOps”的准则也并没有过期。

放弃心态

软件开发自身是工程学畛域中一个比拟年老的分支。尽管倒退速度很快并且融入了诸多交叉学科实践,然而依然不能脱离工程学的根本准则,即“应用科学和技术的原理,来解决问题”。无论是“麻利”还是“DevOps”,所有实践皆须要在实践中验证与修改。

最初,作为“工程师”,咱们应该更深刻的理解问题的实质,能力更好的了解新兴的潮流并放弃一个安稳的心态。永远记得,“没有银弹”!

官⽹:https://jianmu.dev
代码:https://gitee.com/jianmu-dev
文档:https://docs.jianmu.dev
体验:https://ci.jianmu.dev

正文完
 0