From ecaeb0fee67b1d748cfb7885977b569ca1fb92cc Mon Sep 17 00:00:00 2001 From: Frank Jia <474165491@qq.com> Date: Sun, 22 Sep 2019 15:23:16 +0800 Subject: [PATCH] Update 20180117 How technology changes the rules for doing agile.md --- ...w technology changes the rules for doing agile.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/translated/tech/20180117 How technology changes the rules for doing agile.md b/translated/tech/20180117 How technology changes the rules for doing agile.md index b5c1612912..1d7fec9083 100644 --- a/translated/tech/20180117 How technology changes the rules for doing agile.md +++ b/translated/tech/20180117 How technology changes the rules for doing agile.md @@ -19,19 +19,17 @@ Linux容器和[Kubernetes][3]正在改变团队交互的方式。此外，你可 ### 容器技术如何改变团队的工作？ -DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对于敏捷持怀疑态度。 +DevOps使得许多试图将这种工作方式扩展到更大范围的团队感到沮丧。即使许多IT(和业务)人员之前都听说过敏捷相关的语言、框架、模型(如DevOps)等承诺将会彻底应用程序开发和IT过程的全部相关内容，但他们还是对此持怀疑态度。 **[ 想要获取来自其他CIO们的建议吗？不放参考下我们的综述性资源, [DevOps: The IT Leader's Guide][5]. ]** -向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子： +向你的涉众“推销”快速开发冲刺也不是一件容易的事情。想象一下，如果你以这种方式买了一栋房子：你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 -你将不再需要向开发商支付固定的金额，而是会得到这样的信息：“我们将在4周内浇筑完地基，其成本是X，之后再搭建房屋框架和铺设电路，但是我们现在只能够知道地基完成的时间表。”人们已经习惯了买房子的时候有一个预先的价格和交付时间表。 +挑战在于构建软件与构建房屋不同。同一个建筑商往往建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 -挑战在于构建软件与构建房屋不同。同一个建筑商建造了成千上万个完全相同的房子，而软件项目从来都各不相同。这是你要克服的第一个障碍。 +开发和运维团队的工作方式确实不同，我之所以知道这一点是因为我曾经从事过这两方面的工作。企业往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些思维方式完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 -开发和运维团队的工作方式确实不同：我之所以知道这一点是因为我曾经从事过这两方面的工作。我们往往会用不同的方式来激励他们，开发人员会因为更改和创建而获得奖励，而运维专家则会因降低成本和确保安全性而获得奖励。我们会把他们分成不同的小组，并且尽量减少互动。而这些角色通常会吸引那些想法完全不同的技术人员。但是这样的解决方案注定会失败，你必须打破横亘在开发和运维之间的藩篱。 - -想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作：“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ +想想传统情况下会发生什么。业务会把需求扔过墙，这是因为他们在“买房”模式下运作，并且说上一句“我们9个月后见。”开发人员根据这些需求进行开发，并根据技术约束的需要进行更改。然后，他们把它扔过墙传递给运维人员，并说一句“搞清楚如何运行这个软件”。然后，运维人员勤就会奋地进行大量更改，使软件与基础设施保持一致。然而，最终的结果是什么呢？ 通常情况下，当业务人员看到需求实现的最终结果时甚至根本辨认不出。在过去20年的大部分时间里，我们一次又一次地目睹了这种模式在软件行业中上演。而现在，是时候改变了。