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

你可能已经注意到，在我的描述中关于敏捷开发者在这里扮演的角色有诸多变幻。如果你是一名系统管理员，可能在想，“我是要开发者立即修复性能问题，而不是让它淹没在各版本和测试的切换之中。”这就是最佳实践出现的地方--敏捷的最佳实践。

你知道，有了敏捷开发，你不必设法达到最初的目的，就能实现最终的需求。特别是，当一个敏捷最佳实践处于不断重构时，不仅能使代码从任何方向上进行变更都更容易，而且降低了现行版本中代码与操作版本中代码差异过大的可能性。这意味着回溯路径是简单明确的，能让你在不到一周时间里把以往需要9个月才能完成的修复工作搞定。

第二个敏捷最佳实践是“百花齐放”。换句话说，与其通知开发者修改故障或别的问题，应该鼓励开发者或测试者--他们还能利用敏捷ALM工具修复之前的版本--在每周的建模竞赛中添加越来越多能调校的敏捷选项。敏捷的关键要义在于把那些称为“技术债”，日后务必要解决的遗留问题最小化。在此再次出现了敏捷的悖论：我们强调最大限度进行变更，并在此过程中，最小化技术债。从而使修复动作减到最少并提高质量。忽略时间，成本和质量，而我们却能够在这三方面比采用传统方法达到更好的效果。这种情况下，即使不会更早，故障也能在周末前修复。这就是持续整合。

这里还有一个最奇妙的最佳实践：提高系统管理员的敏捷度。你知道，能够让开发者深刻理解系统管理员调查结果的ALM工具同样也能帮助系统管理员及他的APM工具发掘出开发者可利用的资料库和处理进程。聪明的系统管理员将能够利用这些资源，并在ALM工具的指导和帮助下，不再需要或者较少依赖开发程序就能够修复应用中的故障。这意味着系统管理员能够完全不求助开发团队情况下也能完成修复;借由ALM把信息发送到开发团队，必要时，修复会不可思议地穿插进他们的工作中。虽然要花点时间设置，但对于双方来讲是值得的。

大型主机的本质内容

聊够了科学假想，现在让我们回头看一下可以立即着手的工作和相应的回报。出于回顾考虑，你会要加强ALM和APM来处理大型主机/系统管理员/敏捷开发者之间的交互作用。短期内，你希望系统管理员能看到更快的修复，敏捷开发者能看到更多的操作信息。为获取最大效果，你可以采用我们提到的最佳实践做法。你将会看到客户满意度大幅度提升，系统管理员提高了工作效率，技术债也减少了。那么这之后呢?

不过，为什么要问下一步呢?敏捷的价值在于能灵活应对意外情况，发掘并欣然接受变化而不是焦躁不安地试图预期，并且能大胆采取行动--哦，科学假想。如果你非要问，也许你可以四处看看敏捷开发能修复的那些悖论情形。或许可以从商业智能入手，虽然解决这个矛盾可能需要更多一些时间。