在企业中应用敏捷方法是一项具有挑战性的任务。实现敏捷不像安装软件那样能在一天内完成。而是需要适应企业环境，其中包括：文化、技术和组织方面。本文将探讨面临的一些挑战，这些挑战与建立开发环境、自动化测试、持续集成相关，并且同在企业环境中明确完成的定义（DoD）相关。
每位技术负责人和开发经理都想缩减团队成员建立开发环境的时间。然而，为了在项目中获得较高的产出，开发人员要持续投入许多精力，让事情变得有条不紊。缺乏文档，是建立开发环境时间过长的关键原因。第二个关键原因是建立过程中包含多少手工步骤。那么，如何克服这些挑战呢？关于文档我遵循几个信条——简单，注重细节和自动化。简单是指，让文档的创建、维护、查看以及传播保持简单。在为我的团队建立开发环境相关的内容时，我使用wiki来管理。wiki页面有一名所有者，它会作为迭代的一部分被更新。注重细节是指，记录建立环境所需的内容时，要形成明确且易懂的指南。这表示，为了让开发人员开始编写代码并与团队的其余工作进行整合，要记录下开发人员所需的所有细节。下面是我在有关开发环境的wiki页面中所记录的：
建立开发环境最重要的方面或许就是自动化了。自动化有几个优点——在整个流程中坚持自动化，就算不能消除错误，也能显著地减少错误。下面是一些自动化所面临的挑战：
这些挑战或许并不总能被解决，但还有一些办法来处理它们。对开发人员而言，所有所需的软件——不管来自何处——把它们加入源代码控制系统。确保使用一致的命名和放置规范来组织软件包，标识出版本号和程序库依赖关系。这能确保每个开发人员不用在公司内四处询问就可得到所需的软件包。
对于那些需要由其他部门去安装的软件包，可以创建脚本来生成请求，如果可能的话，甚至可以通过程序提交请求。一旦他们从源代码控制系统中得到文件的工作副本，你就会想要建立一个“设置”脚本。在我的项目中，我有一个apache ant脚本，用于建立用户级环境变量、在开发数据库中创建用户编号/密码、从网络目录拷贝许可密钥至用户的windows配置中，并为团队支持的各种web服务生成XML消息样例。
开发人员因各种各样的技术原因而不进行自动化测试。我常听到下面这些理由：
工具问题可以通过各种方式解决。向他们说明使用如JUnit或NUnit等标准测试工具的好处，指出用脚本进行整合的好处，并具有可持续的、可重复的方式进行测试的能力。在大型企业中，不太可能所有的人都使用同一工具。更现实的做法是，同一部门的开发团队至少有一套标准的工具集。
我所做的是，提供标准的自动化测试脚本——这些脚本用于对JUnit测试用例进行编译、执行，生成报告并通过email发送报告——这些脚本是每个开发人员开发环境的一部分。当开发人员从源代码控制系统中下载工作副本时，测试脚本已经就位，并且他们会继续加入自己的测试用例。我们团队有一个标准的测试目录结构，其中放置着测试用例和测试套件，脚本会从中选取并执行测试用例。
另外，在代码复查期间，我会确保不但要复查代码，同时也要复查测试代码。对未包含在自动化测试中的测试用例进行重构也是复查工作的一部分。这同样适用于包含了硬编码数据的测试代码，把硬编码数据改为从配置文件或者数据库中读取。例如，一个测试方法指定用户角色为 BRANCH_SUPERVISOR，而不是从配置文件中去获得。复查时，把这一属性保存在一个由名称-值数据对组成的文件中，重构该测试方法，使之从属性文件获取用户角色。这样一来，这一属性也可以被其他测试使用了。
对 SOA项目来说，服务中整合了应用程序服务器、遗留系统、数据源或应用程序包，一系列的系统测试也是必不可少的。最初，这些测试可以使用暂时代替后端整合点的mock对象执行。但最终你会希望在真实的整合点上运行这些测试。
在这种情况下，测试数据以及与多系统相关的数据极为重要。缺少良好的测试数据，特别是需要跨系统的数据，是导致无效自动化测试的一个重要原因。对需要依靠数据复杂性和系统运行时依赖较多系统的情况，可以分阶段解决这一问题。可以从数据的本地副本开始，开发人员查询多种数据源并填充到本地存储。这听起来非常像是手工操作，但如果数据是新的并且ETL作业/批处理过程对数据存储的填充还未完成，这也许是启动测试更为简单的方式。
随着时间的推移，你可以建立起一套类，封装了来自多种数据存储的测试数据，确保数据的有效性和质量，并把填充测试数据作为持续集成脚本的一部分。无论如何，如果把测试用例代码和获取测试数据的细节解耦，就更易于改变数据源策略而不影响测试代码。我的团队最初用配置文件来提供测试数据，随后把数据迁移到一组数据访问类中，并通过这些类获取所需测试数据。
例如，我们用Data Access Object设计模式创建了一组java类，这些类封装了对客户数据和账户数据项的操作。这些类提供了一个简单的有增删查改方法的接口，JUnit的测试方法可以通过它访问这些类。如果一个测试方法需要获取客户数据，它会导入DAO工厂和特定的DAO类并调用getCustomer()方法。在提取特定客户对象时，测试可以继续执行其余的逻辑。测试不需要了解如何查询数据并将其打包至一个对象中的，而且这些接口能被其他测试重用。
在企业中，为完成指定一个标准是非常棘手的。在开发环境中执行地非常好的代码在测试环境下也许根本无法工作。这也许是由于安全令牌/安全政策、网络/连接问题、系统不稳定或是由于质量保证（QA）团队或终端用户更严格的质量测试。为了尽量减少迁移代码时的意外，完成标准中应当包括：
本文谈到了在企业中应用敏捷方法面临的一些挑战，并提出了一些应对的策略。使用自动化脚本和检查清单以一致的方式建立开发环境，使用标准的工具和透明的测试数据有助于自动化测试和持续集成，并确保对完成有一个更严格的标准。这些方法并非无所不包，但它们会帮助团队在企业环境中获得更高的生产效率。
关于作者
我是Vijay Narayanan，一名软件开发团队的负责人，为一家金融服务公司建立可重用的数据服务及商业过程自动化组件。我参与过的一些项目，从单用户系统到大型分布式多用户平台上的一些服务，都有涉及。我关于软件重用的博客是：http://softwarereuse.wordpress.com/
【英文出处】：Overcoming Technical Challenges for Adopting Agile Methods in the Enterprise
相关文章
