好消息！你曾经设法说服高级管理者尝试敏捷项目。现已形成几个试点团队，并且“概念验证”项目也成功运行。在短期迭代过程中团队也开发了一种可交付的软件，商业客户为此感到高兴。高级管理者得知后也非常高兴，并承诺将大力支持全面敏捷改革。从此，敏捷改革和应用生命周期管理(ALM)开始了。

许多敏捷团队和组织都追随ShuHaRi学习mastery阶段的轨迹。当组织采用敏捷方法时，他们也许在mastery 的Shu阶段只是生搬硬套敏捷实践。进入Ha阶段后，业务就会打破这种模式，开始采用敏捷方法，满足各自所需。然而，ICAgile的常务董事Ahmed Sidky认为Ri阶段才开始真正使用敏捷方法。只有当组织把这种敏捷的思维方式、4个敏捷值以及12条指导原则恰当地内在化，并且能选择恰当的实践和方法来满足各种需求时，我们才能说这个组织开始使用敏捷方法。

随着敏捷变革的推移，不仅仅是业务和开发团队要实施敏捷变革，运营团队也必须这么做。然而问题是，我们如何将敏捷融入到ALM框架中？我们能做到吗？从概念角度出发，敏捷和ALM就相互排斥吗？也许我们需要弄清楚ALM和敏捷的确切含义。

敏捷对适应性规划、进化式开发与交付和定时迭代方法起到促进的作用，提倡快而灵活的改变。这是一个概念框架，以促进整个开发周期的预见性和密切的相互作用。

敏捷和ALM业务看起来彼此不相容。虽然都涉及到流程管理，但是在许多方面他们的方法有很大不同。最重要的是，敏捷强调灵活和对变化的快速响应，而ALM会严格地控制那些未能较好地适应业务需求变化的流程。然而，如果我们仔细研究敏捷变革流程，我们会发现，采用敏捷方法不仅仅会使ALM方法发生变化，也会使组织的思维方式发生变化。

在最近举办的Agile New England会议上，Ahmed Sidky将Carol Dweck的思维研究运用到敏捷变革中。他认为“敏捷思维方式”是一种成长型思维，通过学习以尽可能有效的方法来处理不确定性。

如果我们将敏捷作为组织的思维方式，那么，敏捷变革就会覆盖整个战略层，并实现ALM目标。如果一个组织形成了敏捷思维方式，那么，它就形成了一种承诺基础，仅仅是敏捷变革的保障，也是其他类型组织变革的保障。而这些变革会发展在重组团队、地理上分散的团队或者ALM中，因此，我们会面临这样的问题：我们如何开发一种敏捷的ALM？

随着一切事情趋于敏捷化，能否设计出一种有效的、包含敏捷框架的ALM策略的关键在于“敏捷宣言”和12条指导原则。敏捷ALM策略将仅以一个客户为中心，并且具备处理来自从项目定义到项目发布不同阶段的不同需求的能力。例如，如果我们主张开发人员向测试人员和业务分析师们要早期的反馈结果，那么我们就形成了一种协作文化。当我们鼓励测试人员进行探索式测试，并提交发现的故障，即使这些故障并没有严重地偏离规范标准，我们也提倡不断地返回早期反馈的意见。

在挑选ALM工具时，也必须遵从敏捷原则。我们应该选择在应用生命周期流程中容易集成的和容易维护的工具。重点应该放在可提升流程且不妨碍需求变革接受的工具，同时该工具也可以迅速开发出可发布的软件。

选择ALM工具策略有许多方法。像Atlassian Jira和Rally这样的产品对敏捷工作就非常有效。但是如Kanban、backlog管理、用户事故管理和缺陷追踪这样直接的工具也很有效，可以建立一个对特定团队和组织都非常适用的敏捷流程。

因此，敏捷ALM管理的关键在于敏捷思维和ALM流程。如果ALM真正能实现敏捷化，那么敏捷与ALM就会成为天作之合。