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" ) } |
[火星人 ] 敏捷應用生命周期管理已經有410次圍觀