敏捷 ALM:Java Champion 和 ALM 专家 Michael Hüttermann 访谈

作者:Janice J. Heiss

2012 年 2 月发布

本系列访谈聚集获得业界、学术界、Java 用户群 (JUG) 以及更大社区中 Java 开发人员特别认可的 Java Champion

Michael Hüttermann
Michael Hüttermann

Michael Hüttermann 是 Java/JEE、SCM/ALM、SDLC 工具和敏捷软件开发方面的开发人员和指导人员。作为一名 Java Champion,他获得了 SCJA、SCJP、SCJD 和 SCWCD 认证,同时还是 JCP 和敏捷联盟的成员、java.net JUG 社区领袖和科隆 Java 用户群的创始人。最近,他的新书《Agile ALM》刚刚上市,他还主持了 2009 年度敏捷大会的敏捷性工具分会场。

Oracle 技术网:您曾将 ALM 描述为一系列方法,Java 开发人员希望使用这些方法在各软件开发阶段集成灵活、敏捷的策略与轻型工具链。您认为这样做的效果是可以得到更加全面实用的构建、配置、部署、发布、测试、质量保证、集成和需求管理方法。

但 ALM 不会导致供应商锁定并增加应用程序的整体成本吗?我们如何平衡敏捷 ALM 的利弊?

Hüttermann:的确如此,传统 ALM 可能导致供应商锁定。我对敏捷 ALM 的定义可以解决这一问题。敏捷 ALM 应可带来灵活、易于更改、高质量的流程和工具链。有些组织使用 ALM 单点解决方案;而另一些组织则更喜欢使用单个最佳工具的组合。这两个方案各有优缺点。这两种方案的潜在风险都是过于复杂。敏捷 ALM 的目标是尽量减少意外的复杂性。依靠轻型工具链可以大幅提高灵活性,因为可以轻松替换整体基础架构中的小单元而不触及其他部分。最重要的是,在许多情况下,使用敏捷 ALM 将使开发人员非常轻松,因为这样做可以为敏捷软件开发(“敏捷”)提供结构。

Oracle 技术网:您认为现在的 ALM 实践和工具与 4 年前有何不同之处?

“许多工具不再是笨重、单一的载体,它们现在对开发过程支持很大。敏捷 ALM 工具不再需要覆盖 ALM 生态系统的所有方面。”

Michael Hüttermann
Java Champion

Hüttermann:最大的变化是“敏捷”越来越成为解决方案的一个有机组成部分。大多数 ALM 工具套件供应商甚至将其产品命名为“敏捷 ALM”工具。尽管我们对于大量过多使用“敏捷”一词应稍持怀疑,但这是一个好现象。许多工具不再是笨重、单一的载体,它们现在对开发过程支持很大。敏捷 ALM 工具不再需要覆盖 ALM 生态系统的所有方面。使用轻型、专门的、面向服务的、可定制工具混搭的发展势头越来越强劲。

Oracle 技术网:您曾认为,最重要的是敏捷 ALM 是一种准则和一种思想方法。为了使用敏捷 ALM 有效工作,开发人员需要何种思想和准则?

Hüttermann:敏捷 ALM 为敏捷提供结构。实现敏捷 ALM 的人员要负责应用敏捷价值(例如,尊重和开放交流)、敏捷战略(例如,持续集成、连续检查和持续部署)以及敏捷流程(例如 Scrum)。对于所使用的工具要持开放的态度,能够从一个工具自由切换到另一个工具,这很重要。这是持续改进过程的一部分,在此过程中,开发人员不断思考团队的工作以及如何改进。在工具链方面开放思想意味着您应密切关注市场,从一个工具切换到另一个工具而不必被迫大量接触整个工具链的其他部分。

Oracle 技术网:读者将从您的《Agile ALM》一书中学到什么?

Hüttermann:《Agile ALM》一书介绍了通过各种策略(例如,基于任务的开发、持续集成和实用的 Scrum 实现)简化开发流程的新构想,此外还讨论了协作开发、功能发布管理和技术发布管理,并且还回答了所有典型项目阶段利益相关方感兴趣的问题。除了策略之外,我还介绍了如何使用最佳工具和工具链实现示例策略。对于充满热情的初学者以及已经使用工具的专家,这些信息非常有吸引力。

Oracle 技术网:英国作家 George Orwell 提出了五条著名的有效写作法则,然后添加了第六条:“在你有更好的建议的时候,你可以大胆地打破所有的规则,当然前提是你是对的。”

同样是 Java Champion 和性能调优专家的 Kirk Pepperdine 曾说过,“不久以前,我在演示文稿中添加了一张幻灯片,上面写着‘我准备告诉你的一切都将是错误的。’我之所这样说,是因为随着时间的流逝,技巧会慢慢变得过时,所有事情需要重新评估。更可怕的是,有些技巧一开始就是完全错误的。这样考虑一下:给您朋友开的处方药,如果您去服用,结果就可能会生病。性能技巧同样如此。”

人们有时到底有多必要忽略您的一些方法,我想知道您对此有何建议。

Hüttermann:我希望我的方法(在上下文中理解)可以长期有效。一方面,我的书反映了现状,例如关于多语言编程、云计算和 DevOps。另一方面,我相信任何项目未来都不能忽视现实。因此,敏捷性将在未来发挥更重要的作用。当然,我们将改变的是工具。其他工具将进入市场,而现有工具将迎头赶上。这是导致我建立演变的思想方法的方案的正常开发周期。即使您更改了整个工具链中的单个工具,概念仍将保持不变,这些单个工具可以更换为其他工具。我的书粗略介绍了工具。我的示例不依赖于这些工具未来版本中可能显著更改的特定 API 或特定特性。相反,我的书着眼全局,就如何使用工具实现策略提供建议。

更松散、更庞大的结构

Oracle 技术网:您可能认同有些组和项目在有更多结构时工作得更好,而有些则在结构更少时工作得更好(这有很多影响因素)。您能不能谈一谈在哪些软件开发领域适合更松散的结构?

“在复杂环境(分布式团队、复杂应用程序、对兼容性的高级要求)下,使用集成工具链将最佳工具粘合在一起以端到端的方法为所有开发阶段提供服务非常重要。”

Michael Hüttermann
Java Champion

Hüttermann: 是的,我认同你的看法。在有直接、简单的组织驱动因素(如团队大小或组织分布)和条条框框更少的驱动因素(如应用程序复杂性或治理)的环境中,可以使用务实的方法和务实的工具。如果这些驱动因素的密度不断增加,致使环境和基本情况越来越复杂,您的方法应相应地发生变化,以便通过端到端的集成使用最佳工具。换句话说,复杂性和工具使用之间存在相互依赖关系:在复杂环境(分布式团队、复杂应用程序、对兼容性的高级要求)下,使用集成工具链将最佳工具粘合在一起以端到端的方法为所有开发阶段提供服务非常重要。

适用于敏捷 ALM 的轻型工具

Oracle 技术网:请给我们简要介绍一下近年来敏捷 ALM 中地位非常重要的一些轻型工具。

Hüttermann: 例子很多。有一个很有吸引力的工具链,它集成了 JIRA、Hudson、Eclipse、Mylyn 和 FishEye。这个工具链支持跨不同项目角色和不同项目阶段的基于任务的开发。另一个有趣的工具链可以将 Java 与 Scala 和 Groovy 集成,以便在 Java 虚拟机 (JVM) 上利用不同语言特有的特性。例如,这可能有助于配置环境以合作方式指定和开发软件。Scala(带 specs2 库)和 Groovy(带 easyb 库)是编写验收测试或在 JVM 上应用行为驱动的开发(其中程序员和测试人员共享相同的基础架构且因此不得不紧密协作)的示例。  

行为驱动的开发

Oracle 技术网:请谈谈 BDD(行为驱动的开发)的情况。

Hüttermann:BDD 是编写验收测试的特殊方法。BDD 风格的验收测试重点关注软件的预期行为。它们通过定义示例用户场景来提供软件规范。但如果置于上下文环境中,BDD 可以提供更多功能。作为持续集成生态系统的一部分连续运行规范将生成实时(始终是最新的)软件文档。因此,BDD 有助于消除测试人员、开发人员和客户之间的屏障。

Oracle 技术网:谈谈您对 JVM 的各种替代语言的印象。

Hüttermann:JVM 上有许多替代语言。我特别喜欢 Groovy 和 Scala,这两种语言在我的书中有所介绍。Groovy 是一个不拘泥于形式的动态语言,能够与 Java 完美集成。有极好的工具可用,Groovy 本身就包含工具。例如,Gradle 基于 Groovy,它是一个极好的构建系统。我喜欢 Scala,因为其在面向对象和功能方面的强大混合。作为一种具有更多学术背景的静态类型语言,它具备成为一种良好补充语言的特性,尤其是对于觉得主流语言(如 Java)的创新速度太慢的高级用户。

Oracle 技术网:您觉得编程过程中哪些部分最有趣?

Hüttermann: 编程过程中没有哪个特定部分是我最喜欢的。我喜欢许多不同方面,从设计、开发和测试到交付软件,因为它们是一个整体。因为软件开发涉及这么多不同的活动和阶段,因此,项目成员应紧密协作,以便从可能的最佳解决方案受益,我重点关注完整的“应用程序生命周期”。最重要的是,软件是为人开发的,也是由人开发的,因此,最好在提出解决方案的过程中听取众多不同利益相关方的意见。

Oracle 技术网:对于您来说必不可少的 Java 类是……?

Hüttermann:java.lang.Object。

另请参见