Red Hat 如何管理开发工作

本文要点

• 要有勇气选择和发展适合你团队的流程。

• 看板可以用于高度分布式的团队，处理高度复杂的项目。

• 看板可实现异步性并能很好地扩展。与 Scrum 相比，实现前者需要的资源更少。

• 在看板的帮助下，你能专注于理解和改善你们的实际工作方式。

• 启用看板必须有工具链。我们很高兴分享我们使用的：Overbård。

由于为 Red Hat JBoss EAP 规划开发工作的难度越来越大，Red Hat 决定引入看板，以使其开发流程更易管理，同时保持一个非常高的质量水平。在 2019 年敏捷希腊峰会上，Dimitris Andreadis 介绍了他们如何在自己分布式的团队中引入看板，并解释了为什么他们要开发自己的 Jira 插件来可视化工作状态，以及如何向看板卡添加并行任务来简化工作流程。

EAP 团队引入看板后，首先将他们流程的所有细节都映射到一个个看板状态上。Andreadis 说，在看板上可视化这些状态后，所有人就有了一致的视角。他们使用连续流程优化了添加、合并或删除状态的过程。

由于标准 Jira 插件具有许多状态和复杂的流程，所以很难用来可视化工作状态。于是他们决定开发自己的插件，名为 Overbård，使他们能够将所有内容都放在一块板上，并使用过滤器来显示出令人感兴趣的信息。Andreadis 说，这个插件还可以当场创建新视图。

Andreadis 提到，借助看板，你可以完全尊重你们现有的流程、角色和团队动态，捕获和可视化进行中的工作状态，然后对其进行迭代和持续改进。它使你处于一种持续自我完善的心态上。

InfoQ 在2019年敏捷希腊峰会上的这次演讲之后，采访了 Red Hat 工程总监Dimitris Andreadis，讨论了他们所面临的问题、为什么决定选择看板而非 Scrum、如何引入看板、Jira 插件 Overbård 如何帮助他们查看进行中的工作、在看板中使用并行任务的经验，以及看板为他们带来的好处。

InfoQ：你们遇到了什么样的问题？

Dimitris Andreadis：Red Hat JBoss EAP（企业应用程序平台）已经成为了非常复杂的产品。结果，为 EAP 新版规划开发工作的任务也变得愈加复杂。在一次极端情况下，团队在开发先前的次要版本功能时，还要开发下一个主要版本；那个主要版本的开发计划持续讨论了 14 个月，而需求还在不断变化。但是，花更多精力来做规划并不能改善最终结果；它并没有让我们变得更聪明或更准确。我们宁愿花更多的时间去做事情而不是夸夸其谈。当时我们面临的主要问题就是这个。

此外，在某些情况下需求可能会被误解或沟通不畅，等我们发现时已经是周期中较晚的时候了。我们必须找到一种方法来集体迭代需求，并确保每个人都知道要做什么。某些情况下，在确定我们完全理解问题和建议的解决方案之前，我们甚至可以进行概念验证。

最后，在如此庞大而分散的项目中跟踪新版进度是非常困难的。不同的子团队在处理多个组件时的并行操作太多了。没有一种简单的方法可以对当前状态产生一致的视角，也没有一个指派某人跟踪进度的地方。自然，遵守商定的发布日期也就更加困难了。

InfoQ：是什么让你们决定采用看板而非 Scrum 呢？

Andreadis：我们有一个大型的分布式团队，在特定领域设有小型子团队，因此使用严格的 Scrum 设置来协调所有这些工作看起来很困难，而且成本很高。为了使流程顺利进行，我们需要创建六个或更多的 Scrum 团队，上面还要有一个 Scrums 的 Scrum，这意味着我们必须找到或创建同等数量的 Scrum 大师，并找到一种方法来将我们的一位产品经理复制成许多产品负责人。

这些子团队由高度专业化的、通常资格较深的开发人员组成，他们对接自己的上游社区，并拥有经过多年发展而来的流程。我们不想改变他们久经考验的流程。而且，我们还得让同一个 Scrum 团队中的成员们处理不同的领域。例如，处理安全和集群工作的人们就没什么共同点；没什么理由将他们放在同一个 Scrum 团队中。

最后，许多复杂的功能通常需要数周甚至数月的开发时间，而试图在短冲刺内对它们进行细微管理是没有意义的。没有什么显而易见的方法可以将这些功能分解为许多有意义的部分，也没有一个“客户”可以测试这些中间的交付成果。涉及到实现规范（例如 Java EE 8）时，你的功能必须跟随规范来走，完成一项是一项。

InfoQ：你们是如何为 EAP 引入看板的？

Andreadis：逐渐地！第一步是识别你的实际流程，并尝试将其映射到一个个看板状态上。当我们谈论状态时，我们指的是“所有”状态。不只是简化的 ToDo、Doing 和 Done。你要捕获工作流的全部细节，这样就能做到我所说的“深度看板”。说起来容易做起来难。经过多年开发的复杂产品的开发流程往往会嵌入到人们的思维中。其中很大一部分可能是部落知识。所以你一开始发现的事情可能不怎么讨人喜欢，但这不是看板的问题，这是现实。

之后，你可以在看板上可视化你的状态，以便每个人都能看到相同的视图。根据选择的工具不同，这一步可能很有挑战性，但重要的是你使用的工具应该与你的票务跟踪器、JIRA、github 或其他组件紧密集成。你要拥有一个唯一事实来源。想想看，看板就是你工作的可视化结果。

最后，在准确映射了初始状态后，你就可以开始考虑优化方法了。例如，我们引入了一个新的分析阶段，以确保产品管理/工程/质量检查人员都认同对某个需求的解释。另一个例子是，我们使状态之间的过渡更加自由，以增强工作流中的并行性。

这基本上是一个连续的过程，因此重点在于一步一个脚印，不能急于求成，因为你不想吓到你的团队，或给他们的生活带来不必要的复杂性。重要的是，试着在每个点上解释你要解决的问题，并与团队达成一致的解决方案，因为他们会使用这套流程，所以取得所有人的认同是很关键的。

InfoQ：你们开发了一个名为 Overbård 的 Jira 插件。能否详细说明它的作用，人们又该怎样获取它呢？

Andreadis：将工作流映射到看板状态后不久，我们就遇到了麻烦，因为状态太多了（大约 23 个），并且我们找不到使用标准 JIRA 敏捷插件可视化它们的便捷方法。你甚至无法在屏幕上看到这些状态。我们也看过其他工具，但我们不想在多个系统之间同步状态，我们希望有唯一的事实来源，也就是我们的 JIRA 跟踪器。

我们还希望将所有内容都放在一块板上，并使用过滤器来显示让我们感兴趣的信息，而不是要维护许多链接在一起的看板。过滤器和泳道在 JIRA 中非常静态；它们必须手动设置，而在我们的情况下，我们想要更动态的东西，因为我们有太多动态的事物了，我们希望能够在现场创建新视图。

没能找到适合我们需求的工具后，WildFly/EAP Core 开发人员Kabir Khan提出了一个想法，就是开发自定义的 JIRA 插件来解决这些问题；他也（非常成功地）扮演了版本协调者的角色。于是他顺着这个想法走了下去，创建了 Jibran，后来改名为 Overbård 开源（注意：这是挪威语）。本质上，Overbård 是其他常规 JIRA 项目之上的一个查看器。它使用一些有限的配置来知道应该从哪里获取信息以及如何可视化信息来创建看板。除此之外，其他所有状态都从 JIRA 问题抽身出来了，因此这里没什么奇妙的东西。

Overbård 支持水平滚动和可折叠状态或状态组，这样就能处理许多状态。它是完全动态的，并支持零配置的任意过滤方式。你创建的任何视图都可以添加书签，因此可以非常轻松地返回到它们上。而且它非常快，因为它可以在服务器上缓存数据。它实际上是将项目问题加载到缓存中，这样过滤就是即时完成的了。Overbård 的确拯救了我们，并为我们的敏捷转型之旅提供了便利。

你可以从这里免费获取 Overbård。

你还可以在此处运行一个 Overbård 演示板的只读版本。

InfoQ：你们是如何向看板流程中添加并行任务的？

Andreadis：我们还是很快就意识到了看板状态是非常连续的，而现实则更加平行化。通常来说，会有很多人在某项功能上协作，例如开发人员、测试人员和文档编写人员等，而且每个人都可能在整个工作流程中处于各自的阶段。在看板状态上映射所有这些情况可能颇具挑战性，并且可能导致状态数量爆炸或引入伪状态，这些伪状态无法捕获现实情况，同时毫无必要地让工作流变得很复杂。

解决这个问题的一种方法是引入某种相互链接的任务，但这会产生大量相互关联的票证，从而毫无必要地使事情变得复杂且难以管理。

因此，我们想到了一种方法，就是在 JIRA 票证上引入新的自定义字段，来捕获感兴趣的各种并行任务，例如，一个测试开发（TD）任务正在与主要功能的开发任务并行进行，所以可以有自己的状态，可能与其所属的主看板卡不一样。将任务并行化后，我们其实是在二维看板上引入了第三个维度。

这是一个看板卡的示例，最底部的一行标记了并行任务的首字母缩写，并带有相应的颜色代码以显示其当前状态。例如，TD 代表卡上描述的功能是“测试开发”，并且可以使用状态 ToDo / Red、InProgress/Yellow、Review/LightGreen 和 Done/BrightGreen。每个并行任务都可以有自己独立的状态集，例如产品文档（PD）带有七个不同的状态。并行任务状态可以直接在卡上更改，并且卡上的几乎所有内容都带有工具提示和额外说明。

并行任务是一个非常强大的概念，它具有多个优点：

• 它创建了更紧凑的看板视图，互连的票证更少。

• 它简化了整体工作流，因为你在主看板卡上需要的状态更少了

• 它更好地捕获了开发工作的现实情况。同一时间会有许多事情在发生，每件事在任意给定时刻都可以处于不同的阶段。

• 它使你只需单击几下即可创建任意查询，比如说展示文档尚未验证的，开发和测试完成的功能。

• 你可以使用并行任务来跟踪多种合并的前置条件，例如，当所有并行任务变为绿色时（可以对状态进行颜色编码），则我们准备合并到主线或部署到生产环境中。

现在，由于我们控制了工具链（Overbård），我们就可以对其进行增强以正确理解和可视化这些并行任务，这样它们就不再是 JIRA 票证上简单枯燥的字段，而是我们流程的有效推动力量。

InfoQ：采用看板可以给你们带来哪些好处？

Andreadis：采用看板有很多好处。

首先，当你开始使用看板后，就可以完全尊重你的现有流程、现有角色和团队动态。看板会迫要求你准确地建模工作流程，以及实际完成工作的方法。你需要非常详细地了解状态、输入、输出、切换点和完成的定义。只有做到这些，才能捕获和可视化进行中的工作，然后对其进行迭代和不断改进。看板将你带入这种不断自我完善的心态，这一点非常重要。

看板非常适合我们的异步工作方式，并帮助我们使交付保持很高的质量水平。通过精心整理的积压和定时发布，我们极大地简化了计划流程。我们就新版的主题取得一致认识，然后由开发人员负责推进工作，从而减少上下文切换并缩短规划时间。

总体而言，我们设法将 18 个月的平均发布周期缩短为 3 个月的迭代周期。对于这种复杂的项目来说，减少到六分之一是巨大的成果。而且，我们已经做到了基本上由一个人来主持工作，同时开发支持工作流所需的工具。在等效的 Scrum 设置中，我们需要 6-8 人（或更多）才能为流程本身提供资源。人们很难相信我们用很少的资源就取得了如此大的成就。

我认为看板与 Scrum 有点正交。对我来说，Scrum 看起来更像是一个盒子或一个工作框架，描述了盒子外围发生的事情。它定义了流程、角色、职责、仪式和发布节奏。但它几乎没有说明盒子中的内容，关注正在进行的实际工作。它假设的是如果让所有人每天参加站会，他们就能以某种方式来解决问题。Scrum 是非常同步化的。

相比之下，看板更像是一种可以在现有流程之上应用的方法。看板非常关心盒子里发生的事情；它关注正在进行的实际工作，如何捕获和可视化它，然后逐步迭代以优化它并增加流量并从而增加输出。看板可以放入不同大小的盒子中。你可以在 Scrum（ScrumBan）内完美地执行看板，此外它可以很好地异步运行，从而提供更好的可扩展性。

不管怎样，无论选择哪种方法，重要的是要让工具适应流程，而不是让流程适应工具的局限性，而这正是我们开发自己的 JIRA 插件 Overbård 的原因所在。既然这个工具对我们很有用，那么它可能对其他人也很有用，所以请随时试用 Overbård，看看它是否适合你的开发流程。

作者介绍

Dimitris Andreadis 在 IT 领域拥有 20 年的经验，他目前是 Red Hat 的工程总监，负责 Quarkus 团队。在此之前，他曾多年负责 WildFly/JBoss 企业应用服务器团队。他还曾担任 JBoss AS 项目负责人，并且从企业初创期开始就一直是 JBoss 的粉丝和贡献者。他之前曾在 Intracom 和摩托罗拉的 NMS/OSS 领域工作，设计可重复使用的框架和分布式系统。ANdreadis 在雅典技术教育学院学习计算机科学，并获得爱尔兰都柏林大学的硕士学位。

原文链接：

Using Kanban with Overbård to Manage Development of Red Hat JBoss EAP