如何推销重构？北欧联合银行案例分析

本文要点

• 如何开始自下而上的技术变革
• 跨组织程序的快速变化是可能的
• 如何增加技术变革中员工的参与度
• 如何用“敢于犯错”式的实践来引导技术变革
• 基于以“我”为中心的信息技术来构造问题

令人惊讶的是，重构的挑战常常不是技术上的。通常，团队可以准确地诊断出代码设计是否效率低下。一般来说，他们知道应该做什么、使用哪些工具、要用什么样的转换。只要拥有足够的时间和预算，他们就能完成任务。

当提到重构，可能会考虑用抽象或者多态来处理，日常开发中用它们来处理代码是很重要的。在这篇文章中，我们专注于更复杂的情况 - 战略代码的重构。 BNS IT 顾问介绍了这一区别，称它为自然重构课程 （Natural Course of Refactoring） 的一部分，这个过程用来处理如何与旧系统协同工作。有关更多信息，请参阅重构的自然过程和工作流程重构。

然而，大多数时候重构对组织来说存在风险，必须获得批准和资助，而且需要长期的管理。本文介绍了我们在波兰的北欧联合银行运维中心设计电子银行系统时，是如何处理这一问题的。

背景

Nordea 的波兰 IT 中心（目前在波兰的运维中心）做了一个业务决策，不再在波兰市场开发其电子银行系统，仅将产品放在波罗的海国家。经过一段时间后，出现了以下的难点：

• 业务客户长时间等待功能请求的满足。从收到请求开始，平均需要几个月的时间才能完成
• 由于电子银行系统的技术限制，有些要求是不可能实现的
• 客户有时会要求一些新功能，而这些功能是当地供应商利用新技术开发的，Nordea IT Polska 不得不在银行系统中满足这些功能并进行整合

2015 年 1 月初，Michael Bartyzel / BNS IT 和 Nordea IT Poland 开始了双方的合作。目标制定如下：将提供新功能所需的时间缩短到 30 天。为了让这个新的举措在组织中有更具体的维度，我们将其命名为 Action-30。

现实是什么？

在特定主题的背景下与组织开始合作时，通常会遇到来自许多不同角度的观点。这些观点只是从不同角度对事实进行的描述，它们谁也不比谁更接近事实，从一开始就认识到这一点是非常重要的。在同一个组织内，可以与不同的人交谈，他们经常表达出相互矛盾的信息，但每个信息连起来都是一致而合理的。

尽管如此，这些信息集合本身有一些是重复的，对话者通常会谈论某人或其他事物：关于其他部门、员工、客户。他们很少谈论自己，例如：

• 团队进度落后
• PO 应该知道他们想要什么
• 要求不够清楚
• 客户改变主意
• 安全性总是实现的阻碍
• 等等

我们可以将这种表达方式称为以“你”为中心的信息。如果你现在想知道“那又怎样？ 人们都以这种方式谈话”这个说法的结果，看看图 1 对这种沟通方式的形象化。

图 1. 以“你”为中心的信息

当所有的信息都是对话者以“你”的形式来提供，将无法诊断组织的需求。 如果每个人都专门谈论某人或其他事物，唯一得到的就是对话者对某人或某事的看法。此外，这种沟通方式表明，这些“其他人”要对现存的问题负责。在这种情况下，解决方案可能是“与他们斗争”或“远离他们”。

在诊断组织情况的过程中，最好的选择是能够以以“我”为中心的形式获取信息，并用这种方式来管理对话。比如这些陈述：我想…、我不想…、我想要…、我需要…、我喜欢它…，等等。例如：

• 除了团队迟到，你会听到：
  • 我想按时结束项目
  • 我不想在时间压力下工作
  • 我想快速了解新出现的问题
• 除了 PO 应该知道他们想要什么，你会听到：
  • 我不太明白为什么我们在做这个产品
  • 我的工作需要更多的可接受标准
  • 我想对这个产品的开发有实际的影响

这一次，利用以“我”为中心的信息来看看沟通的形象化（图 2）。

图 2. 以“我”为中心的信息

请注意，这种表达形式为组织推荐了一种可能的解决方案。而且，公开个人、团队或组织单位的各自需求是一种开放的方式，可以为满足这些需求寻求合作。

问题的根源

为了找到电子银行系统的开发问题，第一步一般是准备 RCA（根本原因分析）图 [1] 。

图 3. RCA 图

我们先分析一个初步症状：“变化需要太长时间或者不可能实现”。我们一直在寻找一个能吻合这类症状和循环的起因，图 4 展示了一个循环的例子。

图 4. RCA 图上的一个循环

利用我们开发的图表，我们指出了“变化需要太长时间或不可能”的两个根本原因：

• Struts 1.2 做主干 - 我们工作的系统是近十年前开发的，最初它使用 Struts 1.2 来创建 Web 应用程序的主干。而在 2015 年，该解决方案已经太旧，并且大大限制了创建现代 Web 应用程序的能力。
• 过多的代码通用性 - 该系统是由许多人创建并在不同几个国家实施，由于银行服务条例不同，这些国家的一些功能有所不同。为满足不同的用户视图、应用程序服务和领域服务，通过配置不同条件指令来实现。因此，代码具有较高的圈复杂度 [2] 。

架构分析

图 5. 架构分析

下一步是组织会议，诊断与现有架构相关的问题。下面这些地方是关键点，因为它们直接并最大程度上影响了要花多少时间来提供指定的功能：

• 需要遵守 Struts 1.2 架构 - 这种架构不是根据配置范例的约定而设计的，延长了添加或修改单个功能所需的时间。
• JSP 页面上的业务处理（罕见情况） - 对于快速变更，这种代码编写方式非常不友好。
• 大量未使用的代码 - 由于系统不再在波兰实施，所以与其关联的代码不再被使用并且不被支持，但它仍然存在于代码库中。
• 对其他系统的强烈依赖 - 特别是当新的需求导致核心系统发生变化时，实施时间变得更长。

软件交付过程分析

图 6. 软件交付过程映射

在分析软件交付过程阶段，我们专注于业务需求与软件实施之间的个别活动。 在第一次分析中，我们寻找该过程中的各种瓶颈，以及由于技术限制而最常被拒绝的业务请求类型。以下这些是对过程的流程影响最大的元素：

• 多任务 - 开发人员参与了多个项目。在极端情况下，要在不同项目的工作之间切换，甚至在不同环境之间切换，而有效地开始执行工作将需要 30 到 60 分钟。
• 无效会议 - 同时实施大量的项目意味着更多的会议。
• 开发人员专业化 - 这一点阻碍了合作，给开发人员带来了巨大的工作量。

工作方法

从一开始，我们就意识到这些限制：

• Action-30 不能妨碍正在进行的项目。
• 最初，五名志愿者可以参加该项目。
• 每个开发人员每周可以投入一天时间来处理 Action-30。
• 我们必须尽快体现用于重构的投资能够带来的商业利益。
• 工作方法应该是有趣和有吸引力的，因为在 Action-30 上工作是一个额外的体验。

最终，我们决定用 A’la Scrum 的方式工作。叫 A’la 是因为它并没有完全符合 Scrum，可以看成是一种非正式的 Scrum。我们的方法叫做 A’la Scrum，更多的是基于项目资源和动机，而不是真正的 Scrum 框架。该工作方法基于以下假设：

• 整个团队只有周四为 Action-30 工作。
• A’la Sprint 持续一个月，即一共四个周四。
• A’la Sprint 之后是一个回顾，最大数量的利益相关者可能会参与并规划另一个 A’la Sprint。
• 结对工作。
• 经与部门主管协商后，共同承诺避免无产出的会议。
• 为了帮助团队成功，在规划时将严格地将工作进行裁剪，使得每个工作不超过 4 小时。
• 每个 A’la Sprint 都有一个具体和可度量的目标。

A’la Sprint 1

第一个 A’la Sprint 计划包含一系列组织性的工作，但只有一个技术性的工作。包括分离电子银行系统，以及一个用于共享视图数据的安全 Web 服务。

为什么 20 个工作日只有一项技术工作？首先，为了保证第一个 Sprint 成功的几率更大。Action-30 这样的举措在组织中相当不稳定，即使是正在进行的项目中一个小小的错误，也会在一定程度上阻碍团队按计划开展这类新举措。考虑到对整个项目的未来有好处，最好是在两个星期后才实现一个小的成功，而不是计划很庞大但最后热情受到打击。

回顾

第一个 A’la Sprint 的总结如下：

• 目标已经实现。
• 结对工作的感觉很好。
• 会议有次序和深度。从整体持续时间（Duration）来看，事实上会议开得比较少。
• 工作完成量超过了计划量。
• 欢迎更多的协同计划。

观察

引起我们注意的第一件事是， Action-30 项目开始自行运作了。其他工作人员在喝咖啡的时候议论这项举措，他们对此感兴趣，并询问是否可以加入。

令人惊讶的是，该团队设法做了比计划更多的工作。这是因为开发人员在周四投入了比计划更多的时间来处理 Action-30，这个事实是非常有趣的。 当然，没有一个项目因此遭受痛苦。在此基础上，我们得出结论，如果事情是有趣并有意义的，人们总会有时间去做 。此外，这个“额外”的时间不需要任何正式的程序和时间表，人们会主动通过自己的优化方式，去做他们真正喜欢的工作。

第一个 A’la Sprint 突出展示了这种类型经理的巨大价值 - 这类项目启动了变革。一个伟大的团队可以应付技术工作，但对于组织上的工作，特别是那些改变不同机构之间的合作方式和分解孤岛的组织工作，需要得到知道正式和非正式决策途径的人的帮助。在经理的帮助下，团队减少了所需的会议次数，并开启了部门合作所需的其他沟通渠道。

在这样的团队背景下，我们也开始看到新兴的团队准则：

• 我们结对工作。
• 我们庆祝成功。
• 我们避免无产出的会议。
• …

除此还有重构指南。这些指南是对典型工作、问题及其解决方案的一些描述，构成了团队的知识结构，甚至未来的团队成员也可以利用。

从第二个 A’la Sprint 开始，计划定期向利益相关者展示重构的商业利益。 虽然重构意味着代码结构的变化而不改变其外部功能，但如果不对业务结果产生积极的影响，是不可能“推销”出去的。我们采用了两种方法：

• 提升组织重构带来的好处 - 我们指出了重构对组织产生可度量的好处，例如缩短了开发时间。
• 以客户为中心特性的架构分片 - 重构任务总是以合理的比例相结合，来提高和增加有价值的功能。

报告 - 与组织沟通的基本工具

在初步分析中，我们指出了大量未使用的代码。如前所述，系统在波兰市场上已经不复存在，但核心仍然是与波兰银行业特殊性有关的守则。另外，代码没有被包装（“封装”），而是采用了内置算法。这意味着添加新功能时，为了不在算法中添加条件语句，需要管理系统的易变性和扩展性。

图 7. 删除未使用的代码的结果

为了将信息传达给决策者，我们决定在货币和日程语言中展示删除代码的好处。为此，我们准备了一个与波兰市场关联的示例代码，并测量了删除之前和之后的行数和圈复杂度。虽然测量代码行的数量给开发人员提供的信息很少，但对于非技术人员来说，这是非常有用的信息，因为它代表了软件的大小。

代码的圈复杂度更有意思。它提供了代码中决策路径数量的信息，因此也是功能所需的测试次数的度量。事实证明，在删除“波兰”代码之后，样本的复杂性下降了 15％，反过来还减少了 29 项所要求的测试次数。

在这一点上，我们沉迷于一个小小的突破性的外推估计 - 利用所有相似样本在代码中测试的近似结果，并且减少了几天的测试次数，我们可以估计出通过重构大致可以节省多少人天。 这绝对是个宝贵的意见…

在大型组织中，报告是主要的沟通工具。一旦发布，报告就会在邮箱之间传播，就像在厨房里的传言一样，所包含的信息会有非常广泛的听众。因此，我们编写了一份报告，并附上上面描述的估计，将其发送给最近的主管。正如预期的那样，他们听取和理解了重构能带来好处的信息。

展现商业价值

第二种操作方法，是将重构工作与改进 / 增加有价值的功能相关的任务相结合。 虽然根据定义，重构会使代码变得优雅，而不改变其功能，但由于组织和财务原因，似乎有必要将其与产品相结合 - 通常功能的优化更重要。

为了向业务人员展示重构，在那些业务人员已提出需求，但由于技术原因不可能实现的功能之中，我们决定选择其中一个进行开发。

如上所述，软件问题的主要原因之一是使用 Struts 1.2 做主干，于是我们决定尝试 AngularJS。

图 8. 向业务人员展示重构

由于该团队以前没有任何技术经验，因此我们主要专注于以精确的方式指定用户视图，然后我们邀请了一位 JavaScript 专家进行了几个小时的研讨。他的任务是准备 AngularJS 的意见，并提供依据协助建设和运营，使团队能够在系统中实施。

这样一来，开发人员就可以专注于如何重构后端，设计新视图，并将其与电子银行系统相结合。它大大降低了采用新技术的门槛，并且更容易成功。 在这个阶段，我们的优先事项是促进重构的需要，而不是迁移到新技术。

业务想要更多

其后，我们计划了其他的 A’la Sprint，使我们能够加入重构，并将这种重构以业务最需要的功能形式展示给他们。

在与我们合作的同时，经理确保让尽可能多的潜在利益相关者参与 A’la Sprint 评估。 这个行动的明显效果是，项目经理要求提供更“好”的功能。同时，其他团队的一些开发人员也加入了 Action-30 计划，所以我们的内部营销也是成功的。

当我们了解到“高层管理人员对 Action-30 感兴趣”时，这是最令人感到惊讶的。不过，经过核查的事实证明，这是一个谣言。不过，这对我们的创新是有利的。我们当时明白，Action-30 及其表达的信息使组织有了意识，并开始自行运作。

它是如何结束的？

由于公司层面的变化，组织决定逐步关闭波兰电子银行系统的开发。因此，我们无法最终结束 Action-30。然而，团队的积极态度受到了国外合作伙伴的关注，并邀请他们去接手一些需要“现代”技术的重要项目。

团队特别强调，整个举措都表达了“是的，他们可以”。这表明有可能发起和推动一个大型组织的重大变化，并由此创造出灵敏的软件。开发人员可以意识到，他们对组织的决策有影响，他们可以突破对技术的需求。还要求什么呢？这已经足够了。

图 9 团队准备的 Action-30 摘要

该文章是在波兰的 Nordea Bank AB SA 许可下编写的。

关于作者

Micha?Bartyzel 是一个拥有十年经验的软件开发人员、讲师、顾问和教练。他帮助开发人员和团队更好、更有效地开展工作，开发更好的软件。他主要侧重于促进与企业的合作、重构和提高工作效率。

?ukaszKorczyński 经验丰富的 JEE 开发人员，自 2011 年以来与 Nordea 集团合作。技术、软件工艺和敏捷的追捧者。

查看英文原文： How to Sell Refactoring? The Case of Nordea Bank AB

感谢薛命灯对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。