面向全球化的有效敏捷交付

2011-05-25 来源：IBM

许多项目在语言、文化以及多种语言支持方面不能实现全球化（Globalization, G11N）需求，产品信息也不能实现产品交付的可译性。 1 当这个全球市场需要业务流程端到端集成的最后产品时，它通常很难改变当前的产品构架并创建代码变更来处理全球化问题。同时在传统的瀑布开发项目中也存在这样的问题。如果在启始阶段全球化需求没有适当的计划和处理，对于敏捷开发项目风险甚至更大。

全球化需求在软件生命周期的计划和执行阶段中通常并没有很高的优先级。代码的晚期全球化变更很难纠正设计模式，并且在更新代码时会产生问题。同时还会因为进度表的延迟，开发工作量的增加，以及额外的测试工作导致成本增加，并且在全球化支持方面导致低质量的交付。

下面的建议将使软件的全球化需求有更好的效力和功效。

迭代和增量开发项目应该把全球化需要作为优先级

在启始阶段提供统一字符编码标准（Unicode），可译性，以及多元文化的支持

通过重新使用组件和样例使产品全球化

确定主要全球化问题，并帮助开发人员早期移除缺陷而解决问题

利用 Web 2.0 技术为涉众加速协作的交流

这篇文章详细描述了每一条建议。

迭代和增量开发项目应该把全球化需要作为优先级

当将最高的价值重点投放于功能、证明，以及敏捷开发中为涉中提供价值的能力时，IT 组织通常会给全球化需求分配较低的优先级。这通常是因许多项目都是为英语客户和开发小组发起的，他们认为全球化仅仅是将英语版本的产品转换为其它语言即可。他们认为快速交付首个产品发布给说英语的国家效率会更高，在接下来的发布或者当他们拥有国际化客户时再将产品国际化。他们没有意识到国际化的思想和赢得全球业务，需要从迭代和增量开发项目的开始就将国际化纳入产品的计划和设计中（请看图 1）。全球化思想影响着软件构架。

图 1. 早期包含全球化作用是十分关键的

在敏捷开发项目的计划和设计之前学习有关全球化知识对于项目的成功起着关键性的作用。全球化所需要的不仅仅是“翻译”英语产品。根据全球化术语的 IBM 术语表：

全球化是开发、制造，以及营销需要在全世界范围内分配的软件产品的过程。它是系统、软件、服务以及程序的设计和实现，这样运行在单个服务器或者用户机器的软件实例就能够在一个多元文化的环境中从文化上纠正并处理使用多种语言的数据，比如国际互联网。数据的展现应该包括这些能力：允许每个单个的用户都能够给这个用户界面选择一种语言，这个界面可能与被处理或者展现信息的术语语言不同，比如数据和数字，即使用户来自不同的地方也能够是它们在文化上是正确的。

例如，日期数据 01/02/03 在日本可能翻译为 2001 年2月3日，在美国可能被译为 January 2, 2003 ，在法国为 February 2003 。软件的语言支持，文化支持，以及使用多种语言的支持对于电子商务软件来说更为重要，因为许多国际互联网用户并不来自美国（请看图 2）。

图2. 绝大多数互联网用户不是来自美国。

IBM 为消费者提供了全球可用的解决方案和结构的构架原则，从而满足全球化应用软件设计的不断增长的需求。如图 3所示，全球化的范围远不止是将英语产品翻译成其它语言的产品。尽管需求的晚期变更在迭代和增量开发项目中可以进行调解，但是从一开始就对全球化构架进行良好的设计是十分关键的。当在启始阶段合成一个候选构架以及为这个项目准备环境时，需要计划和设计关键的全球化组分，像统一代码的使用、可译性，以及多种文化的支持。可重新利用的组件或 API ，比如 International Component for Unicode (ICU) 应该列在考虑范围之内从而提高产品质量，同时估算成本，进度表以及资源。在精化阶段，全球化专家和测试人员应该验证关键的全球化构架，并评估这个可实行的原型是否已经处理了主要的构架问题。即时当前的消费者仅仅是美国消费者也建议这样做。如果不在项目的开始就作好充分准备，您将为翻译承担高成本的风险，并且会承担额外测试和开发的任务，在稍后的时间里支持统一代码方面也会遇到困难。在构建阶段，剩余少量全球化需求，比如地址和名称格式，也会不断并逐渐加强。当全球化需求适当地计划，设计并进行了测试，那么紧急关头的风险就会降到最低。

图 3. 全球化范围

在启始阶段提供统一代码、可译性，以及多种文化的支持

在迭代和增量开发计划的启始阶段，处理复杂的全球化构架需求是十分重要的。统一代码支持是一种暗示的全球化需求，需要在开始阶段就对它进行高度地优先化。对于书写字符和文本来说这是一种通用字符编码方案。要使软件国际通用化，基于统一代码的程序是必不可少的，尤其当不同字符集中的字符需要在同一个 Web 页面同时显现出来的时候（请看图 4），或者当应用软件用户分布在不同的国家的时候。统一代码数据库允许用户在一个单独的数据库中储存使用多种语言的数据，从而取代了为每一种不同语言创建一个数据库的操作，能够有效帮助减少成本来维护数据库。统一代码支持同时也是 IBM Global Architectural Imperative (GAI) 所推荐的，对于标准化支持、校对，以及在 Unicode Transformation Formats 之间进行转换都有着更好的字符处理方法。此外， Unicode 支持能够延长应用软件的生命周期，扩大未来需求集成的可能性。任何语言的文本都能够在世界范围内进行转化，旧代码页面也能很便利地进行转换。

图 4. 在同一个 Web 页面同时显示来自不同脚本的字符

全球化系统的效率和正确性的关键是有一个单独的执行，能够为所有的地区提供总的支持，如图 5所示。这样做的好处是减少成本，更容易地分配更新和进行调整，加速市场营销地时间，以及简化新的语言和文化的支持。事先计划能够在稍后的阶段大大减少整个开发，测试，以及维护成本。为了使开发人员能够避免用户界面中消息或者对话框的硬代码字符串，在启始阶段实现可译性需求是十分必要的。翻译是相当昂贵的，因此可译性问题例如文本翻译，文本扩展空间，以及在本地化包装程序中选择语言的能力，在早期都显得十分重要。

图 5. 对于所有地区的单一来源和执行

IBM 全球化组织打算利用本地包装管理程序来管理特定区域、加载，以及访问本地包装资源。本地化包装管理程序扮演着核心程序代码和本地化包装之间的媒介的角色，并且现有的平台服务程序为许多本地化包装功能提供了基本的支持（请看图 6）。基于本地化名称（例如，en_US，fr_FR， ja_JP，等等）。

图 6. 本地包装管理程序流程

为敏捷建模应用正确恰当的构架对于项目的成功是十分关键的。可重新利用的 API 对于多远文化的支持——就像 International Components 对于 Unicode (ICU) 一样——对于 ICU 网站的开发人员来说是可利用的， 3 他们可以获得快速软件开发和更高的代码质量。例如，有一些 ICU4C、ICU4J，以及 ICU4JNI 的 API 参考。对于 Unicode 支持，软件国际化(I18N)，以及全球化(G11N)来说，ICU 是 C/C++ 和 Java 程序库的一个成熟且可移植的装置。它为双向式(BIDI)，印度语，以及泰国语言提供了文化支持，比如多种日历，日期/时间格式以及复杂的文本设计。这些可重用组件和 API 很大程度上帮助降低风险并加固了解决方案的质量和可消费性。

通过重新使用程序库，组件和样例，使产品全球化

可重用性在敏捷开发中是一个非常重要的元素。它节省了成本并且加快了代码交付的速度。正如先前板块所提到的，ICU 为软件应用开发的 Unicode 支持和全球化支持提供了 C/C++ 和 Java 程序库的成熟且可移植的组装。众所周知，C 和 C++ 语言不能为 Unicode 和标准文本处理服务提供充分的支持。为补救这一点，ICU4C 程序库明了产业标准（例如，Unicode 和 Common Locale Data Repository）。ICU4J 很普遍地被使用，因为 Sun Java 有一个很长的发布时间表，并且很少为展开的标准进行更新。IBM 和 ICU 小组致力于向 Suns Java 提供全球化技术，这样高性能和更富有的 API 对于自定义 I18N/G11N 和 Unicode 支持来说就是可利用的了。利用 ICU 可以节省大量的实现工作，可以改良产品质量，这也是为什么越来越多的公司要为他们的软件开发使用 ICU 的原因。

除了多远文化支持的可重新使用 API 以外，像 ICU，可重用的组件比如 Dojo 对于开发人员来说也是可利用的，他们可以采取并使用。Dojo 是用 JavaScript 编写的 Open Source DHTML 工具包。它能够利用 DHTML 解决一些长期存在的历史问题，使创建动态 Websites 变得更加容易。利用这个 Dojo 工具包，您可以更快地构建交互式的小配件，激励变换，以及更容易地建造 AJAX 需求。它的确简化了复杂的 JavaScript 开发和优化了 AJAX 开发。图 7中是一个 Dojo 日期选择器小配件的例子。

图 7：Dojo 日历日期选择器模块

正如您在图 7中所看到的，您再也不需要为复杂的日历运算法则担心了。您所要知道的只是怎样指定可重用组件，以及为您的应用软件的使用对它进行自定义。尽管那些可重新使用组件仍然有一些全球化问题，但是开发人员可以在报告的全球化缺陷的基础上来提高它们，并且为 Dojo 工具包贡献解决方案。

可重用 API 或者组件都不仅仅局限于 ICU 或者 Dojo 工具包。还有许多其它的程序库或者工具包可利用。为了更有效的编码以及全球化组件更高质量的提高，组织可以通过部门和产品小组对开发资源进行评估，并通过利用在线通信方式与其他人一起分享这些构件，这些在线通信方式有超文本系统，论坛，博客，或者 RSS (Really Simple Syndication 2.0) 预定。通常，全球化的 API 或者组件不需要通过单一的小组来执行，它仅仅是对开发工作的重复。最好的编码练习，FAQs，或者指导方针可以在产品开发小组中间进行发布和引用。对应用软件开发者进行全球化编码有帮助的例子之一是 G11N Cookbook，由 IBM Globalization Center of Competency 出版。它包括最佳的编码实践，对 IBM WebSphere 的 Unicode 支持?， XML 以及数据库编码配置， FAQs，等等 (请看图 8中的一个 XML 样例)。所有这些可利用的资源和可重复使用的组件都可以加速软件交付以及提高产品质量。

图8： G11N Cookbook 中的 XML 样例

识别主要全球化问题，帮助开发人员解决问题，更早得除去缺陷

IBM Rational Unified Process (RUP?) 提出一种迭代测试得方法，并通过整个开发项目来实现。然而，Globalization Verification Test (GVT) 通常在构建阶段晚期才开始，目的是降低测试资源得成本。因此，在这种晚期阶段——比如本地化组装资源捆绑的数据库 Unicode 编码和文件构架—— 修改全球化构架是十分困难且昂贵的。通常会导致全球化支持不令人满意的交付质量或者致使传输失败。这样以来，全球化专家和测试人员就要在开发生命周期的早期进行紧密合作，持续的工作将是帮助分析和验证全球化构架，包括 Unicode 和可译性，以更早地出去缺陷（请看图 9）。

图 9：持续地全球化加强和质量改善应该发生在开发生命周期尽可能早地时期，最理想的状态是在需求收集阶段。

在美国发起的项目，其产品通常都是使用 ISO8859-1 (Latin-1 编码技术) 来进行数据编码的。这并不支持由日本，韩国，以及中国字符集使用的双字节字符的输入/输出。如果全球化专家能够在项目的开始就处理这些被忽视的问题，他们就能够很容易地将数据编码更改为 Unicode，并且程序也会更好地与数据库进行交互作用。相反，使用错误地数据库编码，并在 Construction 阶段地晚期才报告出来即将导致巨大的复杂性。在这个时候更改数据库编码，大量的程序需要被修改。在这些环境下，对于应用软件来说，要分布全球唯一的解决方案是为每一种语言提供一个数据库，这样每一个

据库就可以支持一个单一的字符编码。然而，这种方法的将会导致数据库的执行和维护非常复杂，而且成本较高。

全球化的另一个基本构架概念是，对所有的语言使用一个单一的可执行。如果这个可译的消息没有从编程逻辑中分离出来，那么开发人员就可能做出错误的硬编码，或者在没有按照标准惯例的情况下执行他们自己的消息文件。这样以来，可译性支持将需要大量的代码变更，或者将会大大增加可译性的成本。IBM 全球化验证测试小组甚至不需要转换消息就可以使用伪翻译来对软件进行检验。

一个内部工具通常会显示硬编码字符串的任何事件，这样就不可能来进行翻译。因此，使全球化专家和全球化测试人员尽早参与进来，验证 Unicode 编码和可译性支持对项目的成功是十分重要的。

IBM 的全球化远景是“用户可以在世界各地访问一个服务器，使用他或者她所选择语言的客户程序，利用这个应用软件，与他们所选择的语言和文化惯例的用户来交流”(请看图 10)。全球化任务不仅仅包括编程和开发技巧，还包括文化，翻译，以及语言专业知识。这种驱动测试开发技巧能使测试人员给予开发人员快速的反馈，从而提高代码质量并尽可能早地除去缺陷。全球化测试人员必须拥有强大的技术技巧，并且密切与开发人员进行合作，处理全球化问题并在需要的时候为开发人员提供解决方案。例如，全球化测试人员可以提醒开发人员在 GCoC Cookbook 或者 National Language Design Guide 中检验样例，告诉他们如何在不同的编程技巧中使用 Unicode编码，以及为文化格式遵循 ICU 规则。如果全球化测试人员能够验证主要的 GVT 指导方针，并为开发人员在早期提供反馈，将会降低缺陷的处理成本。开发人员和测试人员之间高效的全球化用例和高效沟通，能够帮助不断地提高产品质量，并能更快速地为消费者交付满意的软件。

图 10. IBM 的全球化视野：用户可以在世界各地访问一台服务器，利用他或者她自己所选择语言的客户程序。

利用 Web 2.0 技术加速涉众之间的合作交流

迭代和增量敏捷软件开发需要一种能够促进小组成员和涉众之间快速交流和广泛合作的环境。这种协作包括 (但是不仅仅局限于) 全球化需求，项目计划，以及测试结果。涉众需要跨越小组进行紧密地合作，并不断交流从而了解需求和反馈。随着全球化分布式开发以及测试地不断增加，有效的合作有时变得更加困难起来。时区的差异可能会导致信息的延迟，需求和反馈在实时方面可能并没有处理好。要改善这一问题的方法之一是利用现代的 Web 2.0 技术，比如超文本系统， RSS feeds，以及博客。

Web 2.0 是一个开源和轻量用户界面的集合，它能够帮助小组成员加速协作交流和频繁地交互作用，它将整个产品小组推向目标。如图 11所示，一个超文本系统可以被当作一个项目控制站点来使用。它包括项目范围，项目进度表，以及项目状态。项目相关文献也可以被附加上，比如涉众的文献，设计文档，全球化需求，或者敏捷的每日会议纪要。这种超文本系统的一个很好的联系是：允许每一个人编辑特权，因此信息更新频繁。一个超文本系统能够使全球分布的小组之间的协作变得更加简单，还能增强对敏捷声明中提到的变更和工作软件回应的敏捷值。

图 11: 项目控制目的的 Wiki 站点样例

正如上面所叙述的，另一个有用的 Web 2.0 技术是 RSS (Really Simple Syndication 2.0)。 RSS 是一个 Web-feed 家族，用来发布频繁更新的内容，有助于加速交流流程。它允许人们订阅更新的消息的供给，聚积实时的信息和知识。信息变更变成一个双向的(请看图 12)。如早期所提到的，对于开发人员来说，使用可重复使用的全球化组件和 API 的确是有益的，可以减少重复的工作和常见的错误。先前的开发代码和经验可以通过博客的方式与其他开发人员一起分享。他们可以挑选其中的代码，加以修改可以又更好的用途，或者他们可以给始发者提供一些反馈信息。通过不断地加强组件和代码，全球化需求的质量也可以大大提高。

这些 Web 2.0 技术为全球分布的小组提供了更好的协作交流平台，尤其是在一个敏捷开发环境中。

图 12： Web 2.0 技术的样例

总结

早期和有效的全球化工作是全球化新兴，以及业务需求成功的关键所在。国际经济为新兴的市场，像中国、印度、中欧、俄罗斯以及巴西带来一些投资机会。更早地实现全球化需求可以不断地降低风险是十分关键的，晚期在迭代和增量开发中有较大代码变更或者进度表延迟就是风险之一。这篇文章提出了一个有效的方法可以优化全球化需求，执行正确的全球化构架，加速代码交付，改善产品质量，以及最终达到有效小组间有效协作的目的。

全球化不仅仅是翻译英文版本产品的问题。事实上，全球化需要扩展到构架和需求聚集的领域。尽管晚期的变更在迭代开发中也是可能的，因此关键的全球化构架问题应该尽早地被处理，这样就可以节省整个成本，分配到全球消费者的软件质量也可以得到保证，软件也可以更快更有效地交付。

注意

1要从 IBM 获得更多关于全球化和 G11N 需求的信息，请看 Globalize your On Demand Business

2图 2中的信息是来自 InternetWorldStats.com 的，将它自己描述为 “Internet Market Research 的自由地址。它的目的是将 Internet Usage Statistics 变成业务界，学术界，以及整个公众可利用的资源。”

3一些优良的可利用的 API 参考来自 ICU 网站http://www.icu-project.org/。这里还引用了一些其它优良的文献。

参考资料

IBM Globalization Strategy，Global Architecture Imperatives(Globalization Architecture Imperatives，2003年3月)

International Component for Unicode (ICU) (ICU Home Page)

Globalization（IBM Unicode：全球化您的电子商务）

什么是 Unicode？(Unicode Home Page 1991-2007)

敏捷软件开发 Agile Software Development (Wikipedia)

迭代和增量开发 Iterative and incremental development (Wikipedia)