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库来编写验收测试,以便你对这一做法有一个初步印象。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
package alm import org.specs 2 . _ class AccSpec extends Specification { def is = "This is a specification to check the 'Agile ALM' string" ^ p^ "The 'Agile ALM' string should" ^ "start with 'Agile'" ! e 1 ^ "end with 'ALM'" ! e 2 ^ end def e 1 = "Agile" must startWith( "Agile" ) def e 2 = "Agile ALM" must endWith( "ALM" ) } |