敏捷应用生命周期管理
Agile ALM使用敏捷的价值观和策略来充实了ALM，ALM的敏捷做法提升了产品的质量，缩短了上市时间，且有利于开发者以一种更加愉悦的心情来工作。我对Agile ALM的定义可归结为，一些灵活的、对改变持开发态度的、高质量的过程和工具链。这是其中的一
敏捷应用生命周期管理（Agile Application Lifecycle Management，Agile ALM）正得到越来越大的推动，记得我在撰写“Agile ALM”一书的书稿时，几乎没有人会想到使用敏捷来丰富ALM的做法，或是找出一种有实效的ALM做法，越来越多的工具厂商发现，他们的工具在贴上敏捷工具甚至是敏捷ALM工具的标签之后好卖多了。
但，敏捷ALM（Agile ALM）指的是什么呢？我的看法是，ALM把一些技术性的和功能性的元素综合在一起，为常见的项目活动和阶段提供了一种全面的做法，解决了构建、配置、部署、发布、测试、质量、集成和需求管理等方面的问题，参见图1。凭借其跨学科的做法，Agile ALM整合了项目的角色、项目的阶段和各种工件。Agile ALM使用敏捷的价值观和策略来充实了ALM，ALM的敏捷做法提升了产品的质量，缩短了上市时间，且有利于开发者以一种更加愉悦的心情来工作。我对Agile ALM的定义可归结为，一些灵活的、对改变持开发态度的、高质量的过程和工具链。这是其中的一种ALM可借助来提供敏捷结构的方式。
图1. ALM处理不同学科和不同开发阶段的问题
Agile ALM的一些基础方面并非是全新的，您应该要尊重过去几十年来的所有不同努力，认真研究所有结果，从中找出一个目前最适用的解决方案。在我看来，ALM是从软件配置管理（software configuration management，SCM）演变过来的，其相应地也要扎根于基本版本控制。在选择最适于给定任务的工具之前，您应该先定义自己的过程和需求。
个体和交互胜过过程和工具
最重要的是，敏捷ALM是一门学科和一种精神态度。使用敏捷ALM首先应从价值观和人，以及其背后的概念入手，敏捷ALM工具就是催生出敏捷过程的ALM工具。
Agile ALM工具必须能够增加系统的价值，促进相关利益者的合作。在我看来，Agile ALM工具链必须要实现 Agile ALM的一些构建块，比如说持续集成（包括了持续检查和持续部署）、功能/技术发布、利益相关者的关注（和协作开发）以及基于任务的开发等。许多项目非常适用于某些个单方面有着最佳优势的工具的一个编排，把轻量级的、可配置的工具整合成灵活的工具链，这种做法最终会得到恰好提供了解决给定任务所需功能的一个工具混搭。
Agile ALM工具应该具备一种开放式的架构，其支持进一步加入一些工具或是功能。对轻量级工具链的依托可大大提高灵活性，因为您可以轻易地替换掉整体基础设施的一些小单元，但又不会给基础设施的其他方面带来问题。现在我们来讨论敏捷ALM的一些重要的构建块，我们从基于任务的开发开始。
基于任务的开发
在使用基于任务的做法时，任务是交互的单元和工作的基础。基于任务的开发是这样的一种技术，其以一种可跟踪的方式来把工作项目链接到一组特定的以完成工作项目为目标的变更上，一个例子用例可能会是这样：您正在努力完成一项任务，该项任务列在您的签派系统（ticket system）中，其有着唯一的标示符AGILEALM-9。您的IDE（例如安装了Mylyn插件的Eclipse）与签派系统（比如说JIRA）集成在一起，CI（Continuous Integration）服务器Jenkins与JIRA集成在一起，使用版本控制系统（VCS）和组件储存库（比如说Artifactory）来透明化工作的进展，以及工件和工作项目之间的依赖，您可以驱动阶段构建来把发布版本部署到一些更高阶段的环境中，而又无需重构建发布版本（“一次构建，随处运行”）。图2展示了Jenkins与其他工具的整合方式，Jenkins的一个构建结果页面的放大显示，该页面很容易导航至VCS(查看底层的变更)，导航至签派系统（处理任务方面的事务），以及导航至组件储存库（处理二进制文件方面的事务）。
图2. 整合了VCS、签派系统和组件储存库的CI服务器Jenkins
协作开发
软件开发就是实现需求，需求是软件发布的核心单元和驱动器。单元测试（验证正确的事物是以正确方式开发出来的）和验收测试（验证正确的事物已被开发出来）一类的方法是早就存在了的。但在以前，这些方法往往是以一种孤立或是单纯的方式加以管理。而实际上，一种全面、务实的解决方案才是更加应该考虑的，这种解决方案把重点投放在需求本身之上，时刻为所有利益相关者打算。您可以使用一些专用的、轻量级的工具来编写验收代码，比如说Fit这个工具；或者使用一些特定的语言。Scala和Groovy这两种语言都提供了一些很有意思的功能，这些功能设置了一个多语言生态系统，通过提供涉及特殊用途语言的解决方案来利用现有的平台。您可以使用Scala和Groovy编写测试，这有助于跨越一些壁垒：
1. 项目阶段和项目活动之间的壁垒（因为编码和测试之间的合作更为密切）
2. 各种类型的工件之间的壁垒（因为代码和执行规范都是在同一个统一的基础设施上编写的）
3. 项目角色之间的壁垒（因为测试是以协作方式来编写的，其机制使用的术语与问题域的相近）
4. 工具之间的壁垒（因为使用了相同的工具来进行编程和测试）
下面这个简单的例子展示了如何使用Scala和specs2库来编写验收测试，以便你对这一做法有一个初步印象。
package alm
import org.specs2._
class AccSpec extends Specification { def is =
"This is a specification to check the 'Agile ALM' string"
"The 'Agile ALM' string should"
"The 'Agile ALM' string should"
"end with 'ALM'"
def e1 = "Agile" must startWith("Agile")
def e2 = "Agile ALM" must endWith("ALM")
} 代码定义的是方法列表的一些规格段（specification fragment），内容是简单的文本、例子或是格式段（p的作用是增加一个空行并开始一个新代码块），段由^字符来隔开和链接，欲了解更多关于specs2的内容，请参阅specs2.org。
发布管理
发布管理包括了根据定义的过程来生成软件工件并发布这些工件，发布管理可细分成一个功能性的部分和一个技术性的部分。若要成功交付软件，这两个组成部分都要受到重视，而且应该彼此整合在一起。自动化和持续集成是软件发布和交付过程的至关重要的两个方面。
功能发布管理
功能发布管理包括了高质量地分拣客户的需求、指定发布的需求和向客户交付功能。敏捷实践往往会被用来支持这一过程，许多项目通过使用管理模板Scrum达成了很好的效果。虽然只是定了一小组规则，但Scrum促进了原则的遵守并可视化了（软件和过程中的）缺陷。可惜Scrum过于抽象，只限于“纸上谈兵”。您必须要实现Scrum，再把它用到软件工程中。例如，在某个微观层面上，在某个Scrum版本内部，一些实现做法可能会包括了一些特殊开发阶段之间的区别：在发布阶段，您可能会考虑使用一个冻结区来关闭开发阶段，冻结区只允许开发者进行错误修正方面的工作，不考虑新功能的实现。另一种有效做法是使用代码冻结时间间隔来完成和发行最终的版本。
技术发布管理
技术发布包括了构建软件和向用户提供最终的产品，构建管理（包括了编译脚本、打包和分发组件）是Agile ALM必不可少的组成部分。技术发布管理描述了这样的一些活动：识别配置项、记录和审计需求和配置项的变更，以及整合和交付实现。在软件工程中，变更会经常发生而非偶然出现。因为需求会发生变化，故保持需求及其实现之间的同步是非常重要的。功能和技术发布之间可能会存在的差距应该被弥合，VCS钩子一类的策略有助于嫁接起发布管理的这两个组成部分。
持续集成（包括持续检查和持续部署）
自动化手工步骤意指以一种客观的并且是可再现的方式来交付结果。
自动化最容易出错、最经常重复的和最耗时的活动是绝对必要的，持续集成（CI，Continuous Integration）就是构建、测试和发布过程的自动化，其目标是整合同事的活动和其他人产出的工作项目。这可催生出一个构建的生态环境，在这一环境中，新代码的提交会直接触发一个包括了编译、技术测试、审计、打包、功能测试和部署在内的持续构建。所有不同的工件类型、平台和语言，比如说Java（Groovy、Scala……）、.NET、PHP和Cobol等，都应该使用一个统一的基础设施来进行整合，参见图3。若各种语言/平台没有各自相应的本地化构建系统存在，则可使用CI场中非本地化的构建技术来这些工件包含进来。
图3. 一个在统一基础设施上整合了不同工件类型的完善的CI生态系统
在一个持续集成过程中，构建报告和通知方法是要有的，信息要被共享和汇总。汇总信息意味着集成工具链横跨了整个异构的生态系统，这使得利益相关者可以聚焦“放大”需要了解的地方，获得更多的信息，从这些信息中得出一些结论。
这方面的一些例子是：给定一次具体的构建，您可以追溯出VCS中的底层变化，或者：收集组件储存库中所有语义上属于同一类的二进制产出，目的是把它们作为一个集合来在上面执行某些操作。
结束语