克服在企业中应用敏捷方法的技术挑战

　　在企业中应用敏捷方法是一项具有挑战性的任务。实现敏捷不像安装软件那样能在一天内完成。而是需要适应企业环境，其中包括：文化、技术和组织方面。本文将探讨面临的一些挑战，这些挑战与建立开发环境、自动化测试、持续集成相关，并且同在企业环境中明确完成的定义（DoD）相关。

　　建立开发环境

　　每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间。然而，为了在项目中获得较高的产出，开发人员要持续投入许多精力，让事情变得有条不紊。缺乏文档，是建立开发环境时间过长的关键原因。第二个关键原因是建立过程中包含多少手工步骤。那么，如何克服这些挑战呢？关于文档我遵循几个信条——简单，注重细节和自动化。简单是指，让文档的创建、维护、查看以及传播保持简单。在为我的团队建立开发环境相关的内容时，我使用wiki来管理。wiki页面有一名所有者，它会作为迭代的一部分被更新。注重细节是指，记录建立环境所需的内容时，要形成明确且易懂的指南。这表示，为了让开发人员开始编写代码并与团队的其余工作进行整合，要记录下开发人员所需的所有细节。下面是我在有关开发环境的wiki页面中所记录的：

• 需要安装的软件包列表：在我的案例中，这部分需要Java Developer Kit (JDK)、 Eclipse整合开发环境(IDE)、Apache Ant、Apache Axis 以及SQL Server精简版管理工具。
• 每个安装包要包括安装文件的位置（网络驱动器/外部网/内部网/其他）以及安装所需的证书。例如，apache ant，在我们subversion版本库中的位置，是由subversion工作副本指定的相对路径——/Software/Apache/Ant/1.7.0。
• 对于每个安装包，要指出在机器上需要配置的系统变量及本地变量。例如，ant需要ANT_HOME变量，axis2 需要AXIS2_HOME环境变量指向开发机器的目录结构。
• 需要获取的其他库列表——包括任何java文档（JARS）、.NET DLL文件或是其他文件。例如，用于访问Microsoft SQL Server 2005的Java数据库连接(JDBC) JARs，或者使用IBM Websphere MQ所需的JARs。
• 如何让用户访问消息队列服务器、数据库服务器和远程机器——联系人、以及相关步骤和表单的链接。诸如开发环境中的应用程序认证信息或用户特定的认证表单这类细节，可以在这里指定。例如，我指定了一个email模板，其中包括登录用户名、我们团队的应用程序标识符和联系人姓名，这一模板用于给我们的中间件支持组发送email，以获得访问消息队列服务器的权限。
• 源代码是如何组织的？如何获取代码库的访问权限？这一部分会提供一个代码组织结构的概要。例如，我是基于数据域（客户数据、账户数据、文档数据）以及核心可重用的公共模块（例如：logger、router、exception handler、notifications manager等）来组织代码的。这一部分也会提供subversion主干的位置以及如何得到代码库写权限的指南。
• 通过源代码控制系统建立代码的工作副本（或者本地开发副本）。基于企业桌面应用程序的政策，这一部分提供了关于工作副本位置的指南。例如，用户只拥有某个特定目录的写权限。
• 关键文件的位置——应用程序日志文件、错误文件、服务器跟踪日志、线程（堆栈）信息。例如，Tomcat servlet 容器日志和Websphere MQ 绑定文件的文件路径。
• 浏览队列和添加队列的步骤。这一部分指出了在消息队列服务器中开发人员需要注意的重要队列。这部分还会提供创建新队列的命名规范，以及相关的支持信息。
• 浏览数据库表格，创建像数据库表格、数据库视图和存储过程之类的数据库对象。在我的案例中，这一部分包含了用SchemaSpy生成的SQL Server 2005数据库文档。
• 开发人员使用的脚本/工具——开发人员用于自动化日常任务的工具。例如，能编译并执行JUnit测试套件的apache ant脚本，以及能基于java源码生成javadoc的脚本。

　　建立开发环境最重要的方面或许就是自动化了。自动化有几个优点——在整个流程中坚持自动化，就算不能消除错误，也能显著地减少错误。下面是一些自动化所面临的挑战：

1. 缺少机器的管理权限：由于安全原因和公司政策，系统管理员也许不会对开发人员开放开发机器的所有权限。这可能会阻碍软件安装、设置环境变量和执行脚本。
2. 需要与外部部门进行协调：外部部门可能会提供安装软件，提供证书或是批准安装软件的请求。
3. 需要利用托管解决方案：大型企业会有为中间件功能（消息队列，企业服务主线，应用程序适配器）提供支持的专用共享主机，与它们交互通常需要得到技术支持。

　　这些挑战或许并不总能被解决，但还有一些办法来处理它们。对开发人员而言，所有所需的软件——不管来自何处——把它们加入源代码控制系统。确保使用一致的命名和放置规范来组织软件包，标识出版本号和程序库依赖关系。这能确保每个开发人员不用在公司内四处询问就可得到所需的软件包。

　　对于那些需要由其他部门去安装的软件包，可以创建脚本来生成请求，如果可能的话，甚至可以通过程序提交请求。一旦他们从源代码控制系统中得到文件的工作副本，你就会想要建立一个“设置”脚本。在我的项目中，我有一个apache ant脚本，用于建立用户级环境变量、在开发数据库中创建用户编号/密码、从网络目录拷贝许可密钥至用户的windows配置中，并为团队支持的各种web服务生成XML消息样例。

　　自动化测试和持续集成

　　开发人员因各种各样的技术原因而不进行自动化测试。我常听到下面这些理由：

• “我有我更喜欢用的工具”——这个工具可能是开发人员自己创建的，或是来自某个特定的开源或厂商的软件套件。这个工具可能会些局限，但开发人员会拒绝承认或予以解决。
• “没有测试数据”——尤其在需要多系统/进程之间协调数据时。

　　工具问题可以通过各种方式解决。向他们说明使用如JUnit或NUnit等标准测试工具的好处，指出用脚本进行整合的好处，并具有可持续的、可重复的方式进行测试的能力。在大型企业中，不太可能所有的人都使用同一工具。更现实的做法是，同一部门的开发团队至少有一套标准的工具集。

　　我所做的是，提供标准的自动化测试脚本——这些脚本用于对JUnit测试用例进行编译、执行，生成报告并通过email发送报告——这些脚本是每个开发人员开发环境的一部分。当开发人员从源代码控制系统中下载工作副本时，测试脚本已经就位，并且他们会继续加入自己的测试用例。我们团队有一个标准的测试目录结构，其中放置着测试用例和测试套件，脚本会从中选取并执行测试用例。

　　另外，在代码复查期间，我会确保不但要复查代码，同时也要复查测试代码。对未包含在自动化测试中的测试用例进行重构也是复查工作的一部分。这同样适用于包含了硬编码数据的测试代码，把硬编码数据改为从配置文件或者数据库中读取。例如，一个测试方法指定用户角色为 BRANCH_SUPERVISOR，而不是从配置文件中去获得。复查时，把这一属性保存在一个由名称-值数据对组成的文件中，重构该测试方法，使之从属性文件获取用户角色。这样一来，这一属性也可以被其他测试使用了。

　　对 SOA项目来说，服务中整合了应用程序服务器、遗留系统、数据源或应用程序包，一系列的系统测试也是必不可少的。最初，这些测试可以使用暂时代替后端整合点的mock对象执行。但最终你会希望在真实的整合点上运行这些测试。

　　在这种情况下，测试数据以及与多系统相关的数据极为重要。缺少良好的测试数据，特别是需要跨系统的数据，是导致无效自动化测试的一个重要原因。对需要依靠数据复杂性和系统运行时依赖较多系统的情况，可以分阶段解决这一问题。可以从数据的本地副本开始，开发人员查询多种数据源并填充到本地存储。这听起来非常像是手工操作，但如果数据是新的并且ETL作业/批处理过程对数据存储的填充还未完成，这也许是启动测试更为简单的方式。

　　随着时间的推移，你可以建立起一套类，封装了来自多种数据存储的测试数据，确保数据的有效性和质量，并把填充测试数据作为持续集成脚本的一部分。无论如何，如果把测试用例代码和获取测试数据的细节解耦，就更易于改变数据源策略而不影响测试代码。我的团队最初用配置文件来提供测试数据，随后把数据迁移到一组数据访问类中，并通过这些类获取所需测试数据。

　　例如，我们用Data Access Object设计模式创建了一组java类，这些类封装了对客户数据和账户数据项的操作。这些类提供了一个简单的有增删查改方法的接口，JUnit的测试方法可以通过它访问这些类。如果一个测试方法需要获取客户数据，它会导入DAO工厂和特定的DAO类并调用getCustomer()方法。在提取特定客户对象时，测试可以继续执行其余的逻辑。测试不需要了解如何查询数据并将其打包至一个对象中的，而且这些接口能被其他测试重用。

　　定义什么是完成

　　在企业中，为完成指定一个标准是非常棘手的。在开发环境中执行地非常好的代码在测试环境下也许根本无法工作。这也许是由于安全令牌/安全政策、网络/连接问题、系统不稳定或是由于质量保证（QA）团队或终端用户更严格的质量测试。为了尽量减少迁移代码时的意外，完成标准中应当包括：

• 建立一套全面的测试套件，这些测试套件是可复用的，并最大限度的减少（如果没法消除的话）硬编码的数据值。
• 在持续集成的过程中加入测试套件。例如，在我的团队中，这意味着在特定目录中加入JUnit测试套件，apache ant 脚本可以从这一目录中提取并执行那些测试。
• 自动化测试用例不但要覆盖功能测试还要覆盖性能测试（例如，使用像JUnitPerf这样的工具，通过使用性能阈值实现测试场景自动化）。
• 获得广泛的测试数据。如果测试需要整合遗留系统，让开发遗留系统的团队同你们一起创建测试并定义测试标准。开发人员未必总能了解在遗留系统上工作需要注意的细微差别。开发环境下测试良好的一些场景，并不能反映生产环境中的实际数据。
• 代码复查不仅要在内部团队中进行，而且也要在基础团队中进行（例如，DBA、系统管理员）。

　　总结

　　本文谈到了在企业中应用敏捷方法面临的一些挑战，并提出了一些应对的策略。使用自动化脚本和检查清单以一致的方式建立开发环境，使用标准的工具和透明的测试数据有助于自动化测试和持续集成，并确保对完成有一个更严格的标准。这些方法并非无所不包，但它们会帮助团队在企业环境中获得更高的生产效率。

　　关于作者

　　我是Vijay Narayanan，一名软件开发团队的负责人，为一家金融服务公司建立可重用的数据服务及商业过程自动化组件。我参与过的一些项目，从单用户系统到大型分布式多用户平台上的一些服务，都有涉及。我关于软件重用的博客是：http://softwarereuse.wordpress.com/

　　【英文出处】：Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise