敏捷开发如何提升大型机性能？(1)(2)

虽然在z/OS上安装可能有困难，敏捷开发还是有可能适用于贵公司大型主机上的Linux。我们就从这里讲起。

我们的想法是，如有可能，把系统管理员的“性能问题数据”融入敏捷开发组织的快速反应故障修复进程和为下一次发布所做的努力中。希望开发中团队最终能听到系统管理员受表现缓慢，瓶颈式新发布内容的压迫而发出的痛苦呐喊，将会给予快速修复。系统管理员，以同样的方式，给敏捷开发者提供关于现实中的应用在发布后如何到达客户的有价值信息。我们就把这些作为我们的主要目标，逐一分解。

第一步，识别和执行ALM计划。该计划要能涵盖敏捷开发和大型主机管理--不用说应该允许使用某些大型主机APM工具。实际操作并没有听起来这么难。几种主要的ALM工具的确在某种程度上，既适用于Linux和z/OS，又适用于Linux在大型主机和其它主要平台上进行的敏捷开发。(这些主要的ALM工具，除了少数几种情况，能够在下列系统中运行并参与开发任务：zLinux,其它Linux，z/OS和其它操作系统--Window, UNIX等。能够在所有这些平台上工作的组成部分在细节方面有显著区别，但这些不同点正在慢慢消失。)REXX和COBOL并不纯粹适合敏捷开发，但它们在围绕复合应用和前段遗留z/OS应用的网页服务界面方面做了许多工作。在那些领域中，Linux/web功能性比重往往超出了新型大型主机汇编码的数量。新的ALM应该能轻松满足贵公司几乎全部的需求，若有例外，预期可以临时解决。

在期望的ALM计划准备就绪，并取得初步的经验之后，我们就可以回过头来再讨论那几个关键目标：

·识别：利用现有或可获取的APM工具，识别出管理员发现的重要性能问题的根源代码。

·追踪：如果可能，在敏捷开发者各自责任下，回溯追踪应用中的特定代码。方法是，让系统管理员在存储于ALM系统里的操作版本上作标示，然后把标示内容发送给该代码现任开发者。

·整合：把故障报告与ALM系统的持续整合行动相融合，针对操作版本和现行开发版本，特别指出修复办法。这是个棘手的过程，需要开发者在现行开发版本中进行修复操作，让问题经由测试团队返回到操作测试版本中，从而不致更进一步影响开发者。

·截取：尽快对新近修复的操作版本进行截取并反馈。可以反馈到预操作测试员或直接告知系统管理员，以便快速进行隔离测试和旧操作版本的更换。

·标准化：一旦上述总结的“识别-追踪-整合-截取”几个常规步骤在几次案例中得到贯彻落实，就可以将此过程标准化。

在多数情况下，按上述操作可以实现快得多的操作故障修复，让系统管理员满意。并给敏捷开发员提供了数量惊人的信息，那些客户不愿见到、让人心烦的性能意外。也免了下一周忙着建立原型的苦差。