时间: 2020-09-03 00:08:26 人气: 2274 评论: 0
本文要点
由于为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
-深蓝源码网-www.69shenlan.com