Compuware：告别瀑布式开发，实现大型机领域 DevOps

本文要点

• Compuware 公司的创新来自这样的团队：他们自由地分享大胆的想法、实验并迭代直到一些伟大的东西结出硕果。

• 在推进工具集的时候，他们拥抱创造力和创新，而不是仅仅作为其产品的管理者，Compuware 公司的例子表明，大公司不再能打败小公司，而是速度快的公司打败速度慢的公司。

• Compuware 公司拆除了壁垒，以鼓励透明、沟通和跨团队协作。

• 该大型机软件公司找到并使用了旨在支持敏捷和 DevOps 方法的工具。

• Compuware 公司的发展历程表明，对速度、效率和质量的度量可以显示自己已经走了多远的路以及还有多远的路要走。

如果我们在 5 年前去 Compuware 的底特律总部逛逛，就会看到一个陷入困境、苦苦挣扎的软件巨人，这与我们如今所处的敏捷和DevOps下不断改进的创新文化截然不同。

那时候，我们以大型机作为支撑并且主要关注该领域，现在仍然如此，但是，我们曾停滞不前。我们曾通过线性、缓慢、瀑布型的开发，每 12 到 18 个月交付一次软件维护更新。当时的文化曾经缺乏灵感，流程缓慢而冗长，工具缺乏。最糟糕的是，很少关注如何解决客户的问题。

如今，大家可能会遇到很多一直在 Compuware 工作的开发人员。他们曾经喜欢藩篱而害怕改变，但现在，借助敏捷，他们很快适应并协作以克服新挑战；他们还使用为期两周的 sprint 方法以开发新的大型机解决方案，并集成到 DevOps 工具链中。每隔90天，他们就能够交付支持客户数字化转型的技术。如果我们，作为一家公司，未曾首先自我转型并改变创新方法，那么，这些都不可能发生。

通过使用 DevOps，大型机软件公司打败了衰落的惯性，再次开始创新——没有裁掉或换掉大多数员工，也没有失去放弃 45 年前让这家公司起步的计算平台：大型机。在此过程中，我们确定了三个核心理念和大量关于创新、速度及质量的最佳实践，指导我们进行这次 DevOps 之旅。

为什么要转移

数字时代，由于害怕和抗拒改变，很多曾经统治市场的老牌企业在衰落。但是，如果认为这些组织的每个员工和领导感觉都是这样的话，那就太天真了。事实上，在这些企业中有创新、投入和充满热情的探索者，如果他们得到授权，就可以改变公司的命运。

在苦苦挣扎的 2014 年，我们中有很多人知道可行的拯救方案会要求对文化、流程和工具进行重大的改变，但是，我们需要领导希望并知道如何驱动这个转型，他们愿意赋权给充满热情的探索者、投资实验并施行改变。幸运的是，当Chris O’Malley作为 CEO 加入 Compuware 时，他看到了一个复兴的机会、一个通过向敏捷和 DevOps 过渡来摆脱困境的机会。

DevOps 转型的三个指导原则

有了新的愿景和使命，我们确定了三个核心理念，它们将指导 Compuware 的DevOps之旅。整个组织，从 IT 到 HR，都遵循这三个理念，这对于瀑布式开发的成功转型和生存都是至关重要的。

1. 授权创意和创新

为了使交付的技术能够满足或超过客户的需求，需要一种持续改进的文化，鼓励员工成为充满热情的探索者。在开发环境中，充满热情的探索者是那些渴望尝试和学习新事物的人，即使这可能意味着失败——他们会利用这些经验教训为转型服务。

这些人对推进公司目标和激励他人是至关重要的。他们将是那些去实验、去冒险的人，为我们和客户在大型机领域面临的大量挑战规划有竞争力的解决方案。他们会帮助我们将大型机像其他平台那样集成到 DevOps 生态系统中，确保 CI/CD 管道像其他平台一样重要。

那么，这些想法在哪里呢？它们就在眼前，只是被隐藏了起来。那些有这些想法的人没有权利实现或分享它们。我们有这样的文化，这种文化不允许整个公司中伟大的想法浮出水面。我们意识到，不能把开发人员看作是跟着鼓点划船的人，而应把他们看作是需要时间和空间来持续改进的顶级运动员。他们需要自由地分享大胆的想法、实验和迭代，直到一些伟大的事物结出硕果。

2. 速度快的打败速度慢的

我们还需要速度。对于花了一年多时间才能实现的创新，我们没有信心，这些想法所带来的成就可能已经过时了。就像如今很多落后的大公司一样，我们认识到大公司不再能打败小公司——而是速度快的公司打败速度慢的公司。

我们需要提高敏捷性，把伟大的想法转换成软件交付以满足业务需要并超越外部竞争对手。更快地满足客户的需求——换句话说，就是快速地产生解决方案以帮助我们的客户解决他们在大型机现代化方面的挑战——就需要减少把想法投入生产的时间、创造快速反馈循环、缩短发布周期，以及在整个组织中产生更高的效率等等。

敏捷开发——采用 Scrum 和为期两周的 sprint——变得至关重要。我们必须从项目管理转到产品管理，并开始专注于构建我们可以快速交付和迭代的最小可行产品，以满足客户最关键的需要。但是，我们关注的不只是速度。

3. 质量依然是根本

在大型机开发中，考虑到大型机事务工作负载的关键任务特质，质量是优先考虑的。这就是为什么大多数大型机团队在历史上都依赖瀑布型开发方法，该方法遵循一个严格的 12 到 18 个月的开发序列，包括配置需求、设计、开发、测试、分析以及最终的部署——正如我们在转型之前所做的那样。尽管该开发方法在前数字经济时代有效，可以帮助公司维持高质量标准，但是，如今要这么做是危险的，因为它阻碍了如今的组织需要竞争的速度和效率。

我们新的敏捷方式使我们又快又高效，足以在数字时代参与竞争。它还迫使我们以不同的方式实现高质量，这是因为确保质量的时间缩短了。随着我们发展新的想法和体验以交付独特且有竞争力的解决方案，这给了我们迅速失败的新自由，但也需要我们不惜一切代价地持续保持、衡量并提高质量。

通过不断地增加自动化测试的数量和代码覆盖率，再加上增加执行这些测试的频率，有助于我们更好地确保质量。我们的自动化测试套件如今每天晚上都会运行，因此，在新代码完成时，能够更快地验证。自动化测试流程如今更加精简和高效，使我们能够提高频率。

实现 DevOps 的最大障碍

我们知道，如果想要推动我们的公司走出恶性循环，进入市场领先地位，遵循这些理念将需要转向敏捷和 DevOps 思维。但是，在我们所处的位置和我们想去的位置之间存在着一条鸿沟。我们必须找到一条跨越这条鸿沟的方法，这需要我们克服几个与我们文化、流程和工具相关的障碍。

冷漠的文化

如果想要改变整个组织的现状，那么，变得敏捷并拥抱 DevOps 需要高管的参与和强有力的领导的改变。Chris O’Malley 作为 Compuware 新的 CEO 体现了这些品质，但是，正如所预料到的，这并没有引起所有人的共鸣。

并不是每个人都赞同敏捷和 DevOps，并且，很多人不知道如何比其他人做得更好。他们所依赖的流程、习惯和惯例，从没期望去改变。这种现状很舒适，真的有效——至少对他们而言是这样。但是，对改变的冷漠对公司或客户都不起作用。正如 Chris 所说的：“冷漠就是满足‘足够好’，而不是为卓越和创新去奋斗。”冷漠是种病毒，正在杀死我们。

孤立的流程

现在，我们有多个团队来负责我们不同的软件产品，但是，5 年前，这些团队很少交流或协作。每个团队专长于其所做的工作，团队的成员则专长于为其团队完成的工作。这造成了知识和技能无法分享的孤岛，使我们变得效率低下、速度缓慢、不太可能改进整体质量以及整个工具集的创新。

在这些过程中，我们随着人员的流失而失去专家，和大多数大型机公司一样。这些专家没有分享给同事们的知识将最终随着他们的离去而消失，让我们陷入无人知道如何完成的工作中。

流程中的冗余是孤岛工作的另一个主要后果。跨团队的相关任务有多个流程，而不是每个人都可以遵循的一些标准。这只会造成更多的技术债务，更多的混乱，让我们难以设置客观的标准来衡量我们整个组织，只能以主观、本地化的水平衡量团队的工作。

过时的工具

从技术的角度来看，我们的大型机工具是孤岛的一种表现。它们不容易跨平台集成，对我们的客户和我们的团队来说，难以让他们流畅地工作。我们提供的特定于大型机的技术使用了经典的绿色屏幕 3270 仿真器界面，而其他非大型机工具使用的基于 Eclipse 的界面，从而阻碍了团队拥有生产所需的工具——通用界面和工具。

这些工具甚至影响了招聘工作。由于大型机开发带来的耻辱（更不用提和文化及流程相关的问题了） ，我们难以吸引下一代的程序员，也难以对他们进行入职培训，他们可不愿意忍受老派的工作方式。我们需要适应他们。

为了吸引下一代人才，我们需要这样的工具：

• 现代的、直观又简单的

• 支持敏捷和 DevOps 流程

• 用最佳的解决方案集成到跨平台的 DevOps 工具链

• 能够让缺乏经验的开发人员高效地更新和增加复杂的程序

我们还需要为我们的客户提供这类工具，以便他们能够获得成功。

如何解决这些问题

这些是阻碍我们从崩溃向持续改善转变的大问题。借助敏捷和 DevOps 驱动正确的改变，我们已经成功地克服了它们。以下就是我们所做的工作。

文化：从冷漠到觉醒

为了去掉我们组织中的冷漠病毒，我们需要激励我们的开发人员拒绝现状，并让他们感到已经得到授权以拥抱创造性和创新性，从而推进我们的工具集，而不只是作为我们产品的管理者来提供服务。

为了超越概念并激发团队的灵感，我们开始向客户做出大胆的承诺。自 1990 年代以来，我们一直没有发布新产品，但是，我们决定创建一个新功能的生命周期，做到每 90 天向客户交付新产品。首个产品的灵感来自我们工程部门一个充满热情的探索者，他的想法直接提交给了 Chris O’Malley。这是一个功能，为大型机程序之间复杂的交互提供了前所未有的图形化可见性。

这是一个多样化的开发团队——其中有些人有 35 年的开发经验，有些人的开发经验不足两个月——这个产品从概念到交付只花了84天。这一成功鼓舞了每个人，大家相信我们能够重复这样的努力，一次又一次。它成为我们还在进行的季度新功能发布的第一次发布——截止撰写本文时，已经持续了 19 个季度。

流程：从孤岛到协同

随着我们推动一种新的受激励、授权的文化，要承认的是，这并不比大多数人所习惯的现状轻松，我们需要领导者来指导我们 90 天敏捷交付的新节奏。

我们开始培训敏捷方法论的领导者。角色改变了，像产品经理、产品所有者和 Scrum Master 这样的新角色出现了。随着整个组织中的开发、运维、安全、QA 和其他角色在 Scrum 团队中逐渐走到一起，我们的团队变得不那么同质化，更加混合了。

我们开始打破孤岛，鼓励透明、沟通和跨团队协作。人们跨越了产品团队的边界，形成了具有更多不同技能的团队。随着流程和技能的分享，知识共享得到增加和改善，成为这类协作和沟通的必需和成果。

在我们转型之前，我们的大型机开发人员和非大型机开发人员之间几乎没有交互，这导致了交付功能增强方面的延迟。新团队聚到一起成为更广泛的团队，致力于整体的增强。这意味着 Scrum 团队将同时拥有大型机和非大型机开发人员，他们肩并肩地进行日常工作。在不了解其他平台交互的情况下，孤立的团队不再致力于功能增强方面的工作。最初，这造成了一些紧张状态，但是，随着常用工具（如 Jenkins 和 SonarQube）的引入，团队能够更好地一起工作了。DevOps、持续的集成和持续的交付迫使所有的团队成员进行交互。

随着我们开始召开两周一次的大会，以便让每个人都了解团队和公司的成功及失败，这种文化传播到了公司的其他部门。新的敏捷和 DevOps 支持是有传染性的。公司内部的每个组织现在都更关注公司正在做的事， 从市场营销部门，到财务部门，一直到法务部门，以他们的角色，更快地工作，以确保我们推出的每 90 天交付得到有效的支持。

工具：从过时的工具到现代的工具

实现这一切需要我们改变的不只是理念和流程。我们还需要工具，这些工具旨在支持敏捷和 DevOps 方法以构建出色的软件。

我们开始开发一个名为Topaz的基础软件套件，用以支持现代大型机开发和测试，我们还开始把我们现有的“经典”工具集按季度进行创新改造——为客户和我们自己，因为我们自己的团队使用 Compuware 工具以构建我们的软件。Topaz Workbench是基于 Eclipse 的 IDE，为我们的开发人员和客户提供现代、易于使用、作为“绿屏”替代品的直观界面。

用于程序分析的Topaz和全面测试的Topaz产品还允许开发人员更好地理解大型机代码，并自动创建以及执行单元、功能、集成测试。

随着我们对工具集的改进，我们开始与其他大型机和非大型机软件供应商合作，把我们的工具集成到他们的产品中以构建复杂的工具链，从而允许大型机可以在整个 DevOps 生命周期进行集成。

DevOps 转型成果

采用 DevOps 尤其有挑战性。我们不得不通过整个组织的转型来进行改变，这是由大量非常有经验的开发人员和一小部分下一代开发人员组成的组织。我们的“破釜沉舟”方法有疏远开发团队的风险，并危及使用 DevOps 和敏捷的行动。因此，Scrum Master 和产品所有者而不是每个成员会被送去进行认证培训。他们回来后，成为其新团队的培训师。团队观看了视频并阅读了过渡到 DevOps 和敏捷所需的步骤。这个方法让每个独一无二的团队有输入并拥有新开发方法论所有权的机会。

这些变化要求我们的团队付出巨大的努力。但是，它们是我们 DevOps 之旅的一部分，自我们承诺开始改变以来，我们一直在不断地改进它们。它们是实现敏捷和 DevOps 最佳实践的成果，是我们每天持续迭代和转型得到的东西。

我们已经到达了鸿沟的另一边，在敏捷和 DevOps 指导之下，我们已经进行了 19 个季度（还在继续着）的新产品交付、产品功能增强、集成和合作，我们可以回顾一下，看看我们从曾经所处的冷漠之处出发已经走了多远。现在，我们正在实现更好的质量、速度、效率，并且每年，每个季度都在成长。现在，我们：

• 在减少逃逸缺陷数量的同时，识别出的陷阱缺陷增加了 25%

• 每个开发人员交付双倍数量的代码

• 经历了收入增长

• 在过去的三年中，已经完成了 5 次收购

• 增加了我们的员工数量，千禧一代的数量超过 30%并且还在增长

我们的经验教训

我们的转型还在继续，我们的学习也一样。以下是我们从 DevOps 中学到的一些重要的东西，并将继续改进它们：

创新

• 做到客户第一：我们以客户为本。激发我们交付创新的是我们的客户，这样他们才可以得到更好的工具去做他们的工作。

• 赋权于人：赋权给每个人和团队，允许他们茁壮成长并实现创新是持续成功的关键。

• 拥抱挑战：挑战我们自己和他人，以做得更好、变得与众不同，并抓住机会，这些都能帮助我们获得成功。

• 寻找想法：新想法的产生对业务成长至关重要。在更大的公司中，新想法可以来自任何地方。我们已经知道，创造一个协作和透明的环境，可以让伟大的想法浮出水面。

• 找到合适的领导者：高管的支持和强有力的领导者创建愿景，并提供让整个组织蓬勃发展的环境。

速度、质量和效率

• 设置高标准的期望：我们对自己设置高标准的期望。我们对每 90 天的交货负责，并邀请客户加入我们的旅程。

• 失败来得很快，但成功来得更快：我们已经知道，如果能够恰当地感知失败，并习惯于在未来做得更好，那么，失败也可以是件好事。

• 依靠指标：了解我们可以完成多少（速度）、要完成的东西中什么是最重要的（效率），以及是否能在缺陷数量较低（质量）的情况下正常运行，这些都很重要。对速度、效率和质量的衡量表明我们已经完成了多少以及还有多少需要完成。

人们很容易自满，接受现状并忽视改变的需要。为了找到改进的方法而变得有创意、协作以及暴露失败是很难的。

敏捷、DevOps、文化、流程、工具和人员——这些词汇能够很好地描述我们公司的转型。在做到每 90 天交付创新的同时，速度、质量和效率得到持续改进，这就是我们在做的。在做这些困难的事情时，我们变成了大型机生态系统的创新力量。

作者介绍

David Rizzo 是 Compuware 的产品开发副总裁。他为 Compuware 工作的时间已经超过了 19 年。他在为 Compuware 产品组合确定技术方向、设计、测试、新功能实现以及持续维护方面发挥了重要作用。

原文链接：

How Compuware Escaped Its Waterfall for True Mainframe DevOps