采访和书评：企业软件交付

《企业软件交付：将敏捷和高效带入全球软件供应链》是 Alan W. Brown 的新书。对任何大型组织机构里与软件开发和交付有关的人来说，该书都是一本必读指南。

整本书是对企业软件交付的一个总结，而下面这段来自附录的文字或许最好地总结了这个概念及其重要性：

基本上，企业软件是一种软件密集型解决方案或产品，它为组织机构的日常业务提供核心服务。因此，企业软件交付组织是一种支撑性组织机构，负责创造、演进或不间断的运营一个企业的计算机系统……企业软件交付是组织机构获得成功的前提条件。它为组织机构提供平稳运行其关键业务流所依靠的基础架构、提供区分组织机构业务产品的关键信息导向服务，并支撑各类利益相关者通过由组织机构管理的公用信息集进行沟通。

最初几章设置了一些场景，来阐述为何企业软件交付这样困难，以及目前软件交付团队和项目一般坚持的特性。

……企业软件交付组织承担着不断增长的压力，它们来自于管理成本、具备生产力、减少进入市场的时间，以及维护和演进那些超期使用的系统。此外，他们必须基于更高的透明性和可核查性业务来实现这一切。

此书的核心部分，透彻分析了构建一个成功的企业软件交付组织的一些关键主题。

关于软件供应链和软件工厂的章节基于这样的思想：为使软件开发变得更有效率，我们需要借鉴来自其他领域的理念，例如制造业。该章节还包括对软件测试工厂的详细讨论，以及一些案例，比如 IBM 应用程序组装优化（AAO）方法的概览。

用于企业软件交付的软件工厂解决方案，需要一个完善的、跨平台的流程以及能够将商业战略与工程和系统部署相匹配的工具。这样的跨平台流程将在构建满足客户需求的应用的过程中发挥关键作用。它们帮助企业识别商业需求和利益相关者的要求，然后驱动这些商业目标纳入企业软件交付项目和解决方案，保证尽可能以低成本高质量的方式提供最终产品来满足商业目标。

关于协作的一章详细讨论了如何最好地处理分布式交付（作者在这里认为是实际中的方案），以及协作开发环境和应用生命周期管理（CALM）的重要性。

在企业软件交付中，一个新兴的主题正在占据主导地位：协作为王。

不出意料的，这本书用单独一章来讨论敏捷这个话题。这本书没有陷入方法和实践中，而是详细阐述了一些敏捷的相关讨论，并给出了一些如何将其规模部署的建议。

我从多家大型企业软件交付组织中获取的经验指出，敏捷方法可以在几乎每一种开发团队和几乎所有的组织机构中取得成功。

作者分享了一些从他自己的观察中总结出的规模部署敏捷的关键成功因素：

1. 执行经理、产品经理和项目经理的角色被敏捷方法改变得最多
2. 从多层次进行规划，并为敏捷规划采用“度量和引导”的方式
3. 不要为任何事都使用敏捷方法（不要滥用）；要将实践与项目特性相匹配以获取更优化的成果
4. 在项目临近交付时适应和强化敏捷过程

在针对软件质量和治理的章节中，通过使用度量的指标的例子，以及对自动化、可视性及安全性进行讨论，来强调了它们的重要性。

……当我们选择一套指标，我们正在显式或隐式地启动我们希望控制（但实际上没有做到）的企业软件交付流程和组织机构的一部分。

这本书的最后一章，总结了书中所讨论技术的教训、限制和挑战，并讨论了那些影响企业的未来方向的技术，例如云计算、多方外包、众包和移动技术。

1. 使用企业特性来引导在哪里以及如何更容易地在企业软件交付中运用工业化的方法。
2. 评估企业的过程成熟度，并关注它是如何与供应链上其他组织机构的成熟度相关联。
3. 不要过度聚焦在标准化和费用削减上，以防止其达到扼杀创新和创造力的程度。
4. 了解你的供应链的弱点，并安排明确的方法解决这些问题。
5. 努力从其他领域的供应链管理和产业化交付解决方案的历史经验中获得见解。
6. 从其他人的失败中学习，并记录你的失败以便自己或他人能够从中学习。

此书的亮点之一是使用了大量现实世界的例子（每章都含有例子，并且有三章做了深入地案例分析），同时还通过图表和图形来阐述作者所探讨的关键概念。这反过来引发了我对此书唯一的批评：由于作者在 IBM Rational 的角色和背景，许多例子都发生在 IBM 的大环境中。

总之，这是一本所有现有的和有意向的技术架构师和领导者们应该阅读的书，他们可从中汲取理念和方法来提高他们的交付方法。对于某些读者，我想这本书在肯定当前使用方法的同时，也提出了一些不同的值得思考的理念。对其他人而言，这是一本令人大开眼界的书，也是对（实践）行动的召唤。

关于此书，作者最近接受了 InfoQ 的采访。

InfoQ: 什么原因促使你编写此书？你希望解决社区的哪些问题？

我的主要动机来自于，在许多情况下当我为软件开发和交付组织机构提供咨询建议时的挫败感，我看到同样的挑战和压力不停出现，而几乎没有得到改善或解决。我开始寻找一些方法来分析和探索这一问题，当尝试着在现有文献中寻找好的材料和框架时我失败了。我开始与 IBM 或别处的同僚们讨论这些，却被告知几乎没有这样的内容而我只有“依靠自己”。所以在研究了若干客户行为后，我决定把我的经历和我看到的成功模式写下来，试着解析为什么敏捷和管理层之间存在这样一种基本的紧张关系，以及为什么在全球软件供应链、外包和多公司合作关系的世界中它被加剧了。

InfoQ: 你提到“已经过渡到一个更敏捷的指导性管理方式的管理者们”更容易取得成功。什么标志着一个企业已经采用这样的管理方式？

当我关注一些较为成功的敏捷项目时，我在项目管理、度量和治理方面的多个维度中看到了更多的灵活性。用于展示未来许多个月活动的占据半面墙的大量甘特图已经成为过去。作为替代的是，你能够看到在做出决策的过程中，更大的自主权被下放到组织机构中较低的层级，你能够看到“思考 - 行动 - 学习”这样更短的循环，也能够看到一个基于那些正在被学习（的经验）的管理优先排序和重新进行优先排序的方法。在许多组织机构中这种想法和做法非常顺利，而他们在项目交付中所经历的差异是非常巨大的。

InfoQ: 在书中你谈及了“同类最佳产品和服务公司是那些已经打造了强大的企业软件交付能力的公司”。你如何判断一个组织机构是同类最佳的？

目前企业组织机构中的执行能力有着巨大差异。你可以开始围绕着构建周期、构建频度、新构建过程中断的百分比、自动回归测试的百分比等方面运用一些度量手段。这都是有帮助的指示器。但是那些我认为是“同类最佳”的组织机构，清晰明确的聚焦于将开发和交付活动联接成一个更持续的循环，将“开发 - 运营”的结合作为核心竞争力，而且他们会告诉你，他们希望如何从理论到行动来优化贯穿其生命周期的“流”。当你与管理人员和高级工程师探讨这些方面，你会很快了解正在发生什么事情。

InfoQ: 在书中你介绍了 CDE（协作交付环境）的概念。在你的构想里 CDE 是可以由组织机构直接购买的一个软件，还是更像一种虚拟环境、（C）ALM（指应用生命周期管理）和其他协作软件的结合？

如果它是现成的工具那当然很好。但不幸的是，没那么简单！现在确实有一些自动化工具能够帮助将流程变得更平顺，并使你能够控制、度量和洞察其进展情况。但实际的问题在于引入技能并转变思想，从而使每个人都专注地为了尽快将价值传递到客户手里而工作。CDE 工具对此提供了鼓励和支持。

InfoQ: 你提出了这样一个观点：软件交付是发展的，而在发布首个版本后的阶段是最关键的。那么关于如何更好的把这一思路的关键转变教给组织机构及其领导者，你是否能给出一些建议？

是的，我发现最好的方式是采用一些简单的视觉化手段。例如，在 IBM 我们曾经使用过一些视觉化软件来分析一些我们大规模系统的变更日志。我们能够看到一个庞大、复杂的代码库在 6-12 个月的时间段内，如何以一种非常快速的方式变化和演进，包括升级、bug 修复、修复包等等。你还能看到所有接触代码、文档、测试脚本等内容的人。看到这一切并认识到需要多少努力来控制和治理这一切，以及管理这种努力本身，对我们的管理而言永远是让人大开眼界的。

InfoQ**：书中你提到“单一、集中的企业交付组织机构已经成为过去”，以及“（现在）每个项目都是分布式的”。你的经验中，是否存在一些分布式对组织机构不那么有效或者是有害的情况？**

分布式已经成为一种必然的手段，适用于使用遍布世界的资源、降低成本并将你的交付模型向组织外部展示。但是这显然也会带来一些不利因素。这在以下项目中更明显：项目必须快速前进，使用新的、无前例可依的技术或流程，而且在其中需要对外部因素（例如隐私和安全）加强控制。典型的例子是一些政府或军队 / 航空的情况，分布式项目在其中尚未立足。在这些情况下，对分布式团队的管理（成本）会超过所能得到的好处。

InfoQ：在敏捷软件交付这一章，你宣称：“从多家大型企业软件交付组织中获取的经验告诉我，敏捷方法可以在几乎每一种开发团队和几乎所有的组织机构中取得成功。”许多因循守旧的人会找出你这段话的漏洞，那么你是否能大致描述一下在什么情况下敏捷方法不会起作用？

“敏捷”这个词具有广泛的含义……而且它是与上下文相关的。所以我认为我们需要谨慎思考在何时何地敏捷能够起作用。例如，在最近与一个卫星技术公司一起进行的工作中，他们有一个带有苛刻限制的多年期任务，显然“敏捷”一词在这里有着被限定的解释。他们不能每过几天就重新设计这个项目的参数。尽管如此，他们需要清晰了解自己是如何聚焦于紧密的利益相关者的反馈，如何从原型和仿真中学习，以及保证项目管理对交付方法而言是合适的。在广泛意义上我们仍旧能够为其方法引入一些敏捷性和灵活性，必定将比其曾经使用的更多。

InfoQ：书中你提到了软件质量的重要性和敏捷方法的好处，然而你还谈及了与敏捷团队中的许多测试理念相悖的软件测试工厂的角色？对于软件测试工厂如何帮助开发团队尽早捕捉 bug 从而免除昂贵的返工，你是否有一些建议？

我相信在综合性跨职能团队的敏捷性，与基于角色的离岸服务的效率二者之间必要的平衡是一个非常好的例子。所有组织机构都正在考虑如何融合这些想法来获取快速变更的能力，而又仍旧保有重复性的效率和规模。所以在测试工厂模式中，当一个项目需要一些围绕性能测试、加载测试和开源扫描的核心工作时，他们能够提供快速转向。如果你使用得当，它会成为软件交付中的一个真正的加速器。

InfoQ：以你在 IBM 的角色，以及基于书中的这些例子，我相信你看到了许多不同的企业软件交付方法。在此书出版后，你是否看到什么趋势？

在过去数月中，关于外包和离岸的讨论蔓延得比我预计的更广。在经济、政治环境和新技术交付速度方面的重大转变，正在推动组织机构为了可扩展性和价值来平衡本地、国内以及具有核心离岸服务的敏捷团队。在若干案例中，我与大型组织机构一同工作，彻底重新考虑他们的交付模型。当前大的推动是将沟通、协调和协作模型变得更透明并得到商业模型和合同的支持以鼓励这些关联关系……而不是禁止它们。这包括更密切地观察开源、众包和其他形式的创新的商业伙伴关系。情况变得比我之前预计的更加复杂。

InfoQ：对阅读此书的技术领袖和架构师，你是否可以提出一个希望他们记住的核心建议？

我想要强调的重点是，软件交付经理需要通过一系列新的原则、实践和经验来武装自己，从而在他们未来工作中变得更有效率。简单的外包机制限制了价值。敏捷软件编写实践则已经对小型团队产生了巨大的影响，但在大型团队中尚未立足。成本效率将持续推动预算和决策。所以实际上需要新的关于如何处理敏捷性和效率的平衡的思想。如此书所展现和举例说明的那样，一些极好的新的思想正在出现。使自己跟上这些技术，你、就会被更好的武装并在我们面对的具有挑战性的时代中取得成功……并将它持续到可预见的未来。

关于作者

Alan Brown博士是英国萨里大学（The University of Surey）商学院企业家精神和创新方面的教授。他是 IBM Rational 软件方面的一位杰出工程师。在公司中最新职务是 IBM Rational 的欧洲首席技术官（CTO）。担任这一职位，他为遍布欧洲的客户提供软件工程战略咨询服务，涉及企业解决方案、流程改进和向敏捷实践过渡。

Alan Brown 编写的《企业软件交付：将敏捷和高效带入全球软件供应链》由 Pearson/Addison-Wesley Professional 于 2012 年 6 月出版，ISBN 9780321803016。了解更多信息请访问出版商的网站。

查看英文原文： Interview and Book Review: Enterprise Software Delivery ****

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。