ACM通信

实践

关于软件，高管们应该知道的10件事

托马斯·a·利蒙切利著
ACM通信，2019年7月，第62卷第7期，34-40页
10.1145 / 3316776
评论

我的一个朋友是一家大公司的会计。首席执行官和其他管理人员不知道会计是什么，这没有关系。每个人都围绕着它工作。

好吧，这是个谎言。这样的公司是不存在的。

不过，我确实有一个朋友，他是一家大公司的软件工程师，这家公司的首席执行官和其他高管不懂软件。他们不理解合理地期望软件做什么，软件是如何制作的，软件项目是如何管理的，或者基于web的服务是如何运行的。

这不是员工可以“绕开”的事情。

也许几年前还可以，但现在就不一样了。事实上，我给这位朋友的建议是开始投简历。

许多不认为自己是软件公司的公司发现软件是他们运营的一个关键组成部分。如果执行人员和管理人员不了解软件是如何制作的，他们将比那些了解软件的人效率更低。这要么会限制他们的职业生涯，要么会对公司的业绩产生负面影响。不管怎样，他们都注定要失败。(你不必相信我的话:Gartner预测，到2020年，50%没有改变组织能力的cloo将被取代。⁹）

在本文中，我列出了“获得软件的高管”所理解的事情，以帮助那些在这个新世界中发现自己的高管和经理。这个列表并不详尽，因为完整的列表可以填满多本书，但它是基于对我在业内的朋友进行的非常不科学的调查。

回到顶部

软件吞噬了世界

2011年，马克·安德森¹写了一篇文章预言:“软件将吞噬世界。”他这么说的意思是两件事:第一，许多传统企业正在被软件公司所取代。其次，所有其他公司都发现，他们所提供的价值越来越多地来自于软件。

当安德森撰写这篇文章时，市值最大的10家公司中没有一家是软件驱动型企业。如今，10家最大的公司中有6家主要由软件驱动。其他公司转型的时机已经成熟。

第一类很容易理解;像苹果iTunes这样的在线音乐商店可能已经取代了你当地的音乐商店。物理位置被取消了，取而代之的是一个单独由软件定义的位置。

第二类是一个更微妙的变化。例如，虽然汽车还没有被网站所取代，但汽车公司的成功越来越多地来自于他们对软件的敏锐。他们的供应链、制造、营销和销售过程都由软件控制。一辆典型的汽车有1.01亿行代码。不同车型的主要区别在于软件驱动的功能，如仪表盘和音频系统。我喜欢我的新车的一切都是软件;我不喜欢的都是那些本可以做得更好的软件。

我最近买了一台科技含量很低的冰箱。据我所知，它里面没有软件。然而，在购买后不久，我收到一封电子邮件，提供一个水过滤器更换订阅。这个系统完全是软件驱动的。考虑到订阅过滤器的高价格，我认为他们负责更多的利润比原来的购买。

如果你不能控制让你的产品有价值的东西，那么你就不是一家好公司。因此，执行者和经理现在必须理解软件交付生命周期。

Stack Overflow Talent和LinkedIn现在列出的针对非技术公司的软件工程招聘广告，都超过了科技行业本身。¹¹这是经济的一个重大转变，表明公司正在加强他们的软件实践。

回到顶部

列表

以下是我认为所有高管和经理都必须知道的关于软件的10件事:

1.软件不是魔法。

通常它看起来像魔法，或者是魔法，但它不是魔法。每一个元素都是由人类设计的，有数学基础，也有能用人类语言解释的过程。

与魔法不同，软件不是凭空变出来的。它需要设计、建造和操作。就像房子有协同工作的系统层(基础、结构、管道、房间、家具等等)一样，软件也有创建整体的层和子系统。它可以设计得很好，也可以设计得很差，一个快速的设计很少是持久的。

如果你不能用语言描述它将会做什么(包括预期的结果和如何实现)，那么计算机就不能做它。“如何”被称为算法并不是魔法。

在网页上搜索椅子的图片并不能显示椅子的图片。它显示了经常出现在提到这个词的网页上的图片椅子。差别是微妙的，人们花了多年的时间才想出这个技巧，并完善了这项技术。然而，这并不是魔法。

你的电子邮件系统的垃圾邮件检测看起来很神奇，但它并不神奇。贝叶斯统计和其他数学模型在幕后工作，以实现您所看到的行为。

自动纠错感觉很神奇(试着把它关掉一天)，但最好的自动纠错系统会处理来自过去的数万亿数据点，创建一个预先计算的自动纠错数据库，供未来使用。

机器学习(ML)和其他人工智能技术不是魔法。ML是基于数据的预测，而不是明确的规则或指令。这是线性代数中的猴子看猴子做。ML系统通过向它展示数百万张有香蕉的图片，然后向它展示数百万张没有香蕉的图片来训练。现在，如果你给它看一张图片，它会告诉你它看起来像第一组还是第二组。不是魔法。ML在许多领域都非常有用，但有时它会表现得像魔法师的学徒。例如，使用ML根据过去的招聘决定来排序简历可能会放大种族主义的招聘历史，即使没有任何有意的偏见。²

2.软件永远不会“完成”。

软件是一个迭代的过程，在它的生命周期中有许多修订和更新。你的工作就是创造一个认识到这一点的环境。

同样地，我们从未期望营销和客户获取能够“完成”。它们也是迭代过程。我们在每次迭代中学习和成长，因为我们继续向业务交付价值。我们从不打算“停止”做这些事情，即使我们发现了一些成功的发行。

如果软件可以在一个版本中完成就好了，但这是不现实的。需求文档充满了歧义。软件的第一个版本充满了“哦，那是我写的，但不是我想要的”的时刻。最好的软件能激发新想法和新功能。看到新的销售管理系统更有效，会激发更多的效率。如果你不打算在未来的版本中整合员工的最佳想法，那么你就建立了一个只解决昨天问题的系统。世界在变化，你的竞争对手提供了新的功能，人们有了新的想法。总是有bug需要修复——可能是在你的代码中，也可能是在它所基于的底层软件框架和系统中。您的软件可能是完美的，但我向您保证，随着时间的推移，人们会在构建它的平台上发现安全漏洞。

你的工作就是期望一个认识到这一点的组织。

我们认识到这一点的方法是建立一个定期自信地生产新软件版本的组织。当完全自动化的测试和其他工程规程就位时，我们建立了信心。这种信心创造了避免多年发布周期的能力，取而代之的是每季度、每月、甚至每周发布高质量的软件。具体的频率并不重要;是信心。信心带来更快的创新。

这也意味着拒绝包含一个完美版本的项目计划。或者计划中没有包含足够的测试，或者取消beta测试期，或者允许开发人员对实时生产系统进行更改，而不是有一个经过批准和测试的发布路径。让软件更容易交付的特性不应该留到最后;运输的便利具有商业价值。

最后，让我们停止那些在显示任何进展之前被允许运行多年的软件项目。尽早并经常发布。要求发布一个最低限度的可行产品，然后定期发布添加功能的产品。第一个版本可能只是基本框架，或者只支持少数边界情况。每次发布都提供了获得反馈和改变进程的机会。早期版本可能只在beta区运行，真正的用户无法访问。至少你已经开始了反馈循环。Beta测试可以拯救生命和职业。

同样重要的是，幕后操作现在有机会开始开发他们的流程和过程，构建和审查基础设施，并测试支持其他一切的无形基础。想象一下，如果奥巴马医改网站一开始只支持罗德岛州，然后一次支持一个州。每次迭代的经验将推动它向前发展，并使它从一开始就获得成功。

3.软件是团队的工作;没有人可以做所有的事情。

软件开发人员既不是产品经理，也不是UX(用户体验)设计师，也不是质量保证分析师，也不是安全专家，也不是技术作者或运营工程师。你都需要。

没有一个高管会建议每个销售人员自己做营销，或者建议销售人员应该被解雇，因为营销人员了解产品，也可以做销售。市场营销和销售是相关的，但又不同。因此，两者之间存在着劳动分工。

同样地，软件团队需要在需求收集、质量保证和测试工程、技术编写等方面划分人员。

有一个关于开发人员“做所有事情”的神话，被称为“全栈开发人员”或“10x工程师”。这在小公司之外是不存在的。是的，一个非常小的公司可能只有一个人既负责市场营销又负责销售，但你可能不会为这么小的公司工作。你的工程师也不知道。

是的，你12岁的儿子自己做了一个网站。不要因此而认为它没有那么难，或者认为编码“只是打字”。我向你保证强尼的网站每小时不会处理数十亿的金融交易。在我10岁的时候，我用纸箱做了一个“机器人”。我的父母很聪明，他们认为这表明我对工程学感兴趣，而不是认为我可以跳过微积分。

这提醒了我:亲爱的父母们，你的孩子“擅长Facebook”并不意味着他或她会成为下一个扎克伯格。别在鸡尾酒会上这么说。这是令人尴尬的。(注:现在没有青少年使用Facebook了。你的孩子在Facebook上发帖只是作为诱饵，这样你就不会试图找到他们真正的去处。我很抱歉让你在这里学到这些。)

4.设计不是事物的外观;这就是它的运作方式。

史蒂夫·乔布斯有句名言:“设计不只是外观和感觉。设计就是它的运作方式。”UX设计师不会坐在那里决定菜单的颜色，或者按钮是圆的还是方的。它们决定了工作流和交互将是什么。

用户将在一个屏幕上看到三个选项，还是每次只在一个屏幕上显示选项?决策需要心理学，对用户的同理心，以及测试，测试，测试。

用户体验设计的最大挑战之一是，一旦你很好地了解了系统，你就失去了预测新用户期望的能力。设计系统的人自动被取消预测新用户需求的资格。

我记得我第一次有机会通过单向镜观察用户使用我参与的产品时的情况。“是左边的按钮!”看左边!哦，天哪，他们为什么不点击左边的按钮!”然后现实开始出现。我们之所以能够巧妙地放置按钮，只是因为我们非常了解这个系统。

因此，需要使用真实用户进行测试。这可以像招募一个还没有看过系统的同事一样简单，也可以像使用单向镜子和眼球追踪系统的双盲研究一样复杂。

我还记得看到有人测试谷歌地图。该用户被要求从纽约佩恩车站前往一家特定的酒店。任务完成后，用户体验设计师问:“你觉得你现在想做什么?”那个人回答说:“一旦我登记入住，我就会找到一家餐厅。”不久之后，谷歌地图增加了“寻找附近餐厅”的功能。这才是优秀的用户体验设计师!

用户体验可能是美丽而优雅的，可以与一件艺术品相媲美，但要求用户体验设计师将背景更改为一幅帆船的图片是没有帮助的。

您的工作是信任测试数据而不是意见，创建一个在产品发布之前计划多次修订并在产品发布之后期待进一步改进的环境。

不要将UX设计师与平面设计师混淆。平面设计师通过从宣传册到网站的各种媒体开发布局来激励和传达信息。让用户体验设计师设计公司节日卡片就像让技术写手写公司通讯一样失礼。这些都是不同的技能。

5.安全是每个人的责任

不管你知不知道，也不管你愿不愿意，你都在从事安全行业。所有软件都有安全需求和潜在的安全漏洞。生产软件所涉及的系统也有安全需求和漏洞。虽然安全基础设施组件(如防火墙和入侵检测)是必要的，但它们还不够:您还必须设计、实现和操作具有内置安全控制的软件平台。安全不仅是好的技术，也是好的过程。

如果你认为你不是目标，那你就错了。所有的计算机系统都是目标，因为奖励不只是其中的信息，而仅仅是这是一台计算机这一事实。例如，一个没有任何有价值信息的系统是一个网络安全目标，因为它可以被用来中继对其他计算机的攻击，或挖掘比特币，或存储某人的盗版视频库。

安全不是开/关的开关。有许多灰色地带。你不会建立一个系统，然后按下“确保它安全”的按钮。

安全是关于风险和你对风险的承受能力。对两点之间的通信进行加密并不能使其安全，但它增强了安全性，只有超级大国才有资源破解密码。在一个领域降低风险对其他领域没有帮助。保护网络并不能防止物理安全问题。一个员工把门撑开，别人就能偷走你的备份磁带。

---

与魔法不同，软件不是凭空变出来的。它需要设计、建造和运营……它可以设计得很好，也可以设计得很差，一个快速的设计很少是持久的。

---

正如吉恩·斯帕福德(Gene Spafford)的那句名言:“唯一真正安全的系统是关闭电源，浇铸在一块混凝土中，密封在一个铅内衬的房间里，配有武装警卫。即使这样，我也会怀疑。”^3.

遵守NIST CSF(国家标准与技术网络安全框架协会)、PCI DSS(支付卡行业数据安全标准)和SOC 2(服务组织控制报告)等安全标准可以量化风险，如果操作得当，可以降低风险。这些标准并不能保证完全安全;这种东西是不存在的。更重要的是，它们提供了如何负责任地应对和报告不可避免的安全漏洞的指导。诚实、直率、公开是我的建议。

安全性最好从一开始就进行设计。在事情发生后再做决定是昂贵的，而且通常是无效的。你不会建造一艘船，然后“添加”一个方法让它漂浮。

如今，安全问题最常见的载体不是昨晚某个精英黑客发现的性感高科技安全漏洞。这是一个老的、无聊的、别人多年前就修好了的问题，却被忽视了。您会惊讶于有多少系统已经僵化，无法更新，因为更新是不可能的、昂贵的或不可用的。它们在新的时候可能被认为(相对)安全，但是现在新的漏洞被发现了。如果不去管软件，它就会像面包一样变得不新鲜。

你的工作是平衡安全偏执和现实，合理预算时间和资源。

6.特性大小并不能预测开发时间。

功能大小(用户所感知的)与创建该功能所需的时间完全无关。小的功能可能需要几天甚至几年的时间。大型功能(如用户所感知的)可能需要几天或几年的时间。

您的工作是创建并支持一个接受这一点的软件开发过程，而不是事后猜测工程师的工作评估。产生工作评估本身可能需要惊人的长时间。

谈判是鼓励。工程师可能会给出一个长得令人惊讶的工作估计，但会对需求进行修改，从而大大缩短时间。记住要包括测试、培训、部署和意外的家庭或医疗假的时间。

在没有咨询工程师的工作评估之前，永远不要承诺一个功能。这并不是你的公司实力的标志，即在一定的期限内承诺一个功能。我向你保证，人们觉得更令人印象深刻的是一个专业的过程，在这个过程中，他们的请求被认真对待，工作评估被产生，请求被按时交付(或者因为诚实的原因被拒绝)。

7.伟大来自于成千上万个微小的改进。

伟大来自于在很长一段时间内所做的成千上万的，也许是数百万的小改进。测量每个更改的效果，如果结果是负面的，则回滚更改。

谷歌不是一天建成的。谷歌的搜索引擎是数百万个人改进的结果。搜索质量小组每周开会一次。工程师们走上讲台，介绍他们提出的改进方案。他们在模拟的基础上展示了改进的程度。委员会进行辩论并投票赞成或反对。几周后，测量结果被复查，更改被保留或回滚。

谷歌搜索是迭代开发对“大爆炸”思维的胜利。你不可能在第一次尝试的时候就做出一个好的搜索引擎。

只有在好莱坞电影中，一个聪明的年轻人才会想出一个令人惊叹的新点子，并在第一次就得到了完美的执行。在现实世界中，一夜成名需要数年时间。

无论你想要实现的伟大目标是为客户提供更好的服务、更高效、更少错误，还是只是组织上运行得更顺畅，都是如此。

您的工作是要求系统设计得易于尝试新事物，并定义相关的kpi(关键性能指标)，以便在更改前后容易度量。最重要的是，必须有一个检查结果的过程，并决定是保留还是回滚更改。回滚不应被视为失败或受到惩罚。从每次回滚中学到的东西与在每次保留的更改中学到的东西一样有价值。

托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当记者问他:“失败1000次是什么感觉?”他回答说:“我没有失败1000次。灯泡是一项有1000步的发明。”

这是软件系统需要支持快速发布的另一个原因。

最大的改进来自于跨部门合作和所有利益相关者的参与。如果没有跨团队的协作，那么每个团队都会优化他们的领域，通常会损害其他团队的效率。通过跨团队工作，你可以培养同理心，并可以创造最具影响力的变化。

我最近读到一家美国公司通过效率在外国竞争中保持领先。它能够通过不断地检查端到端流程来实现这一优势。在一个案例中，大量的材料和制造时间被花在塑料盖上。一个大客户正在拆除和处理这些盖子，因为它们碍事。如果制造商没有拜访客户，它永远也不会意识到，它可以通过销售一个没有盖子的模型来提高效率。

同样，无论是构建软件的过程，还是使用软件的过程，都必须不断地通过端到端检查进行修订。

8.技术债务不好，但不可避免。

技术债务是您将来需要做的工作，因为您现在选择了一个简单的解决方案，而不是使用一个需要更长的时间的更好的方法。任何规模合理的软件项目都有技术债务。⁷技术债务会让所有的进展变得更慢，你越忽视它，它就越像滚雪球一样。

我担心，有金融背景的高管听到“债务”，会认为这是一种未来会有回报的投资。技术债务则相反。它是有毒和痛苦的。这是一个定时炸弹。: l·迪克森⁴将其与“裸买入期权”(naked call options)进行比较，后者是一种随时可能出现的未来债务，无需提前通知，而且有无限的下行风险。

1972年，Fram为它的机油滤清器做了一个电视广告，一个汽车修理工解释说，一位顾客为了节省4美元而不更换滤清器;后来，客户不得不花200美元更换昂贵的主轴承。修理工总结道:“你可以现在付钱，也可以以后再付钱。”⁸

有一次，我参与了一个软件项目，其中一个子系统与供应商进行通信。最初，系统只与一个供应商对话，所以这非常容易。然后又移植了一个。然后另一个。有些功能必须实现三次，每个供应商一次。这是不可持续的。

当被要求支持第四个供应商时，开发人员表示反对。是的，他们可以在大约一个月的时间里把它接上去，但软件开始吱吱作响，就像飓风中的老房子一样。这些权宜之计积累了技术债务。

他们的建议是花两个月的时间重构(重做)供应商体系结构，使其成为一个插件系统。新的供应商可以在一周内增加，而不是一个月。

高管们很不高兴。为什么下一个供应商需要两个多月的时间来添加，而之前的供应商只需要一个月就可以添加?

花在偿还技术债务上的两个月时间将使未来的添加更快，稳定代码库，并使添加新特性更容易。准确的效益很难衡量。

你可以现在付款，也可以以后付款。

分配时间来偿还技术债务是您的工作。失控的技术债务减缓了添加其他功能的能力，并导致软件不稳定。偿还技术债务应该与业务目标联系在一起，这与非功能特性类似。

9.软件不会自己运行。

尽管供应商和开发人员可能会试图告诉您，软件并不只是自己运行。任何基于软件的系统(特别是网站和Web应用程序)都需要操作人员和流程;否则，它就会像一本合拢的书一样坐在那里。必须有人打开它，照顾它，满足它的需要。

我断言操作比软件开发本身更重要。代码只写一次，却要运行数百万次。因此，按照这个粗略的衡量标准，操作的重要性要高出数百万倍。

因此，期望操作成为任何基于软件的系统的一部分是您的工作。它必须像其他任何事情一样进行计划、预算、管理和有效运行。

操作特性(通常称为非功能特性)对用户来说是不可见的，除非是二级效应。数据备份是非功能性特性的一个很好的例子。无用户请求备份数据。不过，用户确实会要求恢复已删除的数据。不幸的是，没有备份就不能进行还原。恢复是一种功能特性;备份是一种操作(非功能)特性。

使软件服务易于操作或高效操作的特性从来都不是用户所需要的。然而，他们确实享受到一个具有成本效益和可靠的系统的好处。客户离开不可靠的网站，不再回来。

软件必须被扩展、监视、更新等等。Wikipedia有一个很好的非功能性需求列表，这些需求驱动了这些特性。¹³各家公司都在不断地提高效率。这通常需要新的代码。

持续改进的需求不仅包括新特性，还包括新的非功能性特性。因此，您的工作不仅是为客户需求的特性分配资源，而且还要为可操作的特性分配资源。在这两种相互竞争的需求之间取得平衡是困难的。

一个成功的产品是业务和操作需求的协商结合。

10.复杂的系统需要DevOps才能正常运行。

复杂的系统最好通过DevOps进行改进。这有很多定义，但我更喜欢这样想DevOps通过快速迭代加速价值(特性、bug修复、过程改进等等)的交付。要做到这一点，每个人都必须参与进来。也就是说，他们必须跨部门工作。DevOps这个名字来自于拆除开发人员和操作(IT)之间的墙的运动，这是实现快速发布的绝对需要。然而，优秀的DevOps环境将此扩展到所有竖井的端到端工作。

DevOps被误解为开发人员执行操作。这种“你建造它，你运行它”的策略是跨竖井工作的一种方式(消除竖井)，但它不是唯一的方式。稍后再详细介绍。

构建并不断改进软件的系统是一台机器。每次您打开曲柄，一个新的(希望是改进的)软件发布就会弹出并投入生产。

将产品交付给客户也是一种机器。你的营销、销售、物流、账单和其他系统都协同工作。每一次你转动曲柄，你的产品就交付了。

这两种机器都是一个具有许多依赖关系的复杂系统。为了运行良好，一个复杂的系统需要三件事:良好的流程，所有相关人员的良好沟通，以及尝试新事物的能力。

它们被编为DevOps的三种方式:

• 第一种方法是“系统思维”或“心流”。这里的重点是改进端到端流程，而不是如第7项所述的特定竖井。第一种方法是推动改进，将你从糟糕的过程转变为出色的过程。在病态的情况下，这个过程是不存在的——每次曲柄转动时，竖井都是即兴发挥和猜测它在这个过程中的方式。第一种方法的结果是提高速度和减少缺陷。事情做得更好。
• 第二种方法是“放大反馈循环”。重点是改进人员和系统内组件之间的通信。沟通是一个反馈循环，应该是双向的、响应性的、透明的和无可指责的。一个系统如果没有相关人员学习、分享和成长的能力，就不能很好地工作。第二种方法是推动改进，使你从缺乏的沟通转向全面的沟通。在病理性的情况下，沟通是受到惩罚的。第二种方式的结果是理解、同理心和对内部和外部客户的响应。需要知识的地方就有知识。
• 第三种方式是“持续实验和学习的文化”。在这里，您需要专注于创建一种文化，在这种文化中，您可以尝试新事物，评估结果，并决定是否保留或恢复更改。第三条道路是关于从一种抵制变化的文化到一种不断变化的文化。风险是接受。仪式奖励团队勇于冒险和从失败中吸取教训。在病理情况下，组织是钙化的:改变是不可能的，改变的建议被拒绝或可能被惩罚。第三条道路的结果是随着时间的推移而发生的进化变化，其间穿插着重大的飞跃和创新。

等等，还有…

事实上，一名高管应该了解的软件知识还有很多。不幸的是，文化压力和大卫·莱特曼(David Letterman)说我应该在10岁时停止。

以下是一些额外的项目:

奖金项目1。
正常运行时间从来都不是完美的。

要求100%的正常运行时间会让你看起来很无知。每一个数量级的改进成本都比之前的水平高得离谱:99.0%的正常运行时间对很多系统来说是可以的;99.999%贵得超出你的承受能力。因为停工而惩罚员工会传递出错误的信息。相反，问“我们学到了什么?”如果您的组织学到了什么，那么停机时间就是一份礼物。推荐阅读:超越指责，从失败和成功中学习，戴夫·茨贝克著，¹⁴以及维基百科的高可用性页面。¹²

奖金项目2。
垃圾邮件发送者和滥用者破坏了一切。

打击垃圾邮件和滥用是一场军备竞赛。如果你能在一周内创建一个在线应用程序，你将花一年的时间来解决如何防止垃圾邮件发送者破坏它。谷歌Sheets具有反滥用检测功能，因为犯罪分子会在电子表格中添加大量诈骗链接，然后将这些链接发送给那些认为提到谷歌的链接是安全的人。运行在线社区(如Twitter、Facebook或其他社交网络)所需的大量反虐待工作会让你哭。

奖励3项。
延展性是昂贵的。

软件的一些更改需要一个新的版本，而其他更改可以在系统运行时发生。后者价格昂贵。Facebook的个人资料很容易只存储你的姓名、地点和其他一些信息。存储任何字段的能力是一项昂贵的工程任务。在要求灵活性的时候要小心。它会影响测试、安全性、可用性等等。

回到顶部

结论

软件正在吞噬这个世界。为了做好他们的工作，技术以外的执行人员和经理将从了解软件和软件交付过程的一些基础知识中受益。

进一步的资源。如果你是一名需要软件敏感度的高管，这里有很多资源。第一个是你的工程副总裁或CTO。问问从事这些工作的人你应该学习什么。

我也强烈推荐阅读《凤凰计划:一本关于IT、DevOps和帮助企业取胜的小说》，吉恩·金、凯文·贝尔和乔治·斯帕福德著。¹⁰它提供了It的内部视图，以及如何使用DevOps技术来管理It的实际理解。

我也推荐加速:精益软件科学和DevOps:建立和扩展高绩效技术组织，作者:妮可·福斯格伦，杰斯·汉博和吉恩·金。⁶它提供了CEO对使DevOps工作的科学的观点。

回到顶部

致谢

林恩·巴拉德，妮可·福斯格伦，蒂姆·贝尔，兰斯·a·布朗，詹妮弗·戴维斯，特伦特·r·海因，马克·亨德森，史蒂夫·范德文德，哈拉尔德·瓦格纳。

相关文章
在queue.acm.org

企业开源启蒙的时代
保罗摩天
https://queue.acm.org/detail.cfm?id=945124

管理技术债务
埃里克·奥尔曼
https://queue.acm.org/detail.cfm?id=2168798

为什么云计算永远不会免费
戴夫Durkee
https://queue.acm.org/detail.cfm?id=1772130

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2019 ACM, Inc.

---

没有发现记录