代码定义的是方法列表的一些规格段（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中的底层变化，或者：收集组件储存库中所有语义上属于同一类的二进制产出，目的是把它们作为一个集合来在上面执行某些操作。

结束语

Agile ALM跨越了软件工程中的多个学科，Agile ALM关乎人和策略，以及使用轻量级的工具链来实现这些策略。Agile ALM有助有提供敏捷结构，有助于以一种坚定、务实的方式来逐步实现ALM。使用一种敏捷的ALM做法，您将赢来更快的胜利和更好的结果。可以谈及的内容还有很多，但我希望本文能够给您建立起这样一个初始印象，即什么是Agile ALM，以及哪些是我所著的“Agile ALM”一书会更加深入探讨的内容。

参考资料

1. Agile ALM——作者所著书的介绍页面

2. huettermann.net——作者的网站

Michael Huettermann是一位自由开发者、架构师、教练、作家，以及是一位Java/JEE、ALM/SCM和敏捷软件开发方面的导师。

附件　　　　　　　　大小

agilealm-phases.gif       14.68 KB

agilealm-jenkins.png     75.11 KB种ALM可借助来提供敏捷结构的方式。