欲善靈活開發 先利靈活工具

作者：Jack Vaughan 來源：ITPUB

靈活開發的潮流并不是由靈活工具來推動的。因為你可以僅使用指令行接口、單元測試工具和需求卡片來展開靈活開發。但近年來，為了更好地支援靈活開 發，靈活工具也有了很大的發展。其中部分工具是直接面向新型項目管理方式的。

特别是有些種類的工具已與靈活開發密不可分。根據Forrester研究公司（Forrester Research）進階分析師Carey Schwaber的研究結果，面向靈活開發的項目管理工具、持續內建建構工具和自動測試工具已是靈活開發不可或缺的工具。

她在《靈活過程研究（The Truth About Agile Processes）》的報告中指出，“靈活開發團隊将投資主要用于其團隊所必需的工具，其中最先考慮的是靈活項目管理工具，然後依次是測試工具、建構管 理工具和軟體配置管理工具。”

Schwaber還表示，各靈活團隊都有自己的管理方式，是以，他們對項目管理工具也有不同的需求。盡管如此，仍然有些團隊僅靠電子表格和WIKI進行管 理。不過Schwaber等人也指出，當靈活成為大型團隊開發進行大型項目的主流開發方式時，這些自己臨時組織起來的技術将難以滿足需求。

靈活開發催生靈活工具

靈活開發在20世紀90年代晚期随極限程式設計（Extreme Programming，XP）運動而興起。極限程式設計主要是關于單元測試、結隊程式設計和簡化的需求采集的運用，當然也有人會說極限程式設計還包括大量的提神飲 料。

諸多的項目失敗是促使極限程式設計出現的原因之一，比如無法準時傳遞産品，或者雖然成功傳遞卻因為産品不符合客戶需求而不能投入使用。牽涉諸多預先分析和模組化 的統一模組化語言（UML）和統一開發過程（RUP）的發展也是極限程式設計形成的原因。

可以認為，2001年的《靈活宣言（Agile Manifesto）》是對靈活過程最好的闡釋。在某種程度上，靈活過程将極限程式設計系統化，為靈活開發提供了參考标準和價值，并減輕開發人員面對需求變化 時的壓力。

基本上，這是一個緻力于尋找縮短傳遞間隔，并增加疊代頻率方法的靈活潮流。團隊有權限自行設定傳遞期限。傳遞可以使用的軟體是最為重要的目标，而預先模組化 和需求采集階段則要求盡量簡單。并且，需求采集并不是在項目早期便結束，而是會在項目開始後很長時間内一直進行的過程。

正因為以上原因，單元測試在靈活開發中變得尤為重要。這樣，在持續內建軟體單元時仍然可以迅速分析漏洞。而且，有效的自動建構工具也成為靈活工具的組成部 分。因為持續的疊代開發意味着經常要進行快節奏的內建。授權給開發團隊可以開闊項目開發思路，也使增強的項目管理軟體在靈活開發中得以發揮更重要的作用。

Forrester的分析師Schwaber稱這種新興的項目工具為“面向目标的靈活項目管理工 具（purpose-built Agile project management tools）”。她重點提到在這一領域有代表性的靈活工具開發商：Rally軟體開發公司，VersionOne和ThoughtWorks工作室。她還 指出，目前已有可用的靈活模闆，比如Conchango公司的Scrum模闆便是Microsoft Visual Studio Team System開發平台的傑出插件。

最新靈活工具一覽

2007年，靈活項目管理工具開發商都忙于新産品的疊代開發以滿足其靈活客戶的需求。這些産品支援新的工具插件，增強需求處理功能，并且：

Rally 2007.7版本支援使用者需求的篩選、擴充的篩選标準、改進版本剩餘時間表、新的通知規則（notification rules），以及用于Eclipse和CruiseControl.NET的連接配接器。

TargetProcess 2.6添加了清單即時編輯功能（inline editing in lists）、新疊代規劃（iteration planning）功能和Visual Source Safe內建。

VersionOne V1最新版本中增加了第三方開源內建工具Subversion和FitNesse。

著名的IT咨詢公司Thoughtworks也開始進入這一領域。2007年10月，公司釋出用 于靈活軟體開發的Mingle 1.1。雖然在第一個版本釋出僅三個月就釋出新版本，但公司聲稱這個版本可以更好地幫助項目團隊進行規劃、追蹤、優先分級和協作。Mingle 1.1中的日期屬性有助于對需求、漏洞和任務進行追蹤和劃分優先級。并且，這個版本擴充了需求卡片（story card）的篩選範圍，還增加了對遠端Subversion知識共享庫的支援。

IBM的Rational工具組有時會受到靈活擁護者的指責，特别是對其Rational統一開 發過程（Rational Unified Process）的指責。因為人們普遍認為它是一個自上而下的過程，這會增加一線開發人員的工作負擔。2006年，為傳播靈活方法，靈活傳道者Scott Ambler加入IBM公司。然後，2007年，IBM釋出其努力的成果——Jazz開發平台。

設計模式（Design Patterns）領域最有影響力的擁護者，目前也在IBM進行Jazz開發的工程師Erich Gamma說，Jazz延續了IBM Eclipse的成功。最終，這個新軟體将提供對定制過程的支援。他說，“在開發Jazz的過程中，我們發現各團隊都采用各自的過程，比如不同的開發方 式，來處理規則變化。”

目前，Jazz仍然是一個（功能有限的）測試中的技術，但IBM公司已經展示了以Jazz技術為基礎開發的主要用來提高團隊開發效率的IBM Rational Team Concert協作平台。

靈活開發加速産品傳遞

靈活開發過程是經常變化的。同樣，靈活工具也是可以改變的。DTS公司（Data Transfer Solutions）的進階項目經理Chris Spagnuolo和GIS軟體首席架構師Dave Bouwman在團隊正式引進靈活方法之前已經使用了一年半的靈活方法。他們的靈活開發正在迅速展開。

引入靈活方法之前，所有的開發對Spagnuolo和Bouwman來說都意味着冗長的需求清單 和大量的預先設計。但随着靈活方法的到來，這些都不再是讓人頭痛的問題。他們選擇的是基于Scrum技術的靈活方案，可以流水線化初始階段的需求采集，可 以在整個項目周期中随時增加需求，并可以集中開發按周傳遞使用的軟體版本。

剛開始，他們使用一些臨時拼湊起來的、簡單的項目管理工具。而現在他們接受了Rally軟體開發 公司的項目管理工具。

Bouwman和Spagnuolo在公司主要負責空間管理及相關資産管理應用軟體的開發。Spanguoloyu說，“以前，我們要預先做大量的需求分 析。采用靈活方法以後，我們更換了工作方式。現在我們在整個項目周期做需求采集，而不僅僅是項目開始時。這樣，客戶每周都可以對需求進行優先分級。”

Bouwman說，“靈活開發可以讓我們先傳遞最有用的部分。我們很快便發現了這麼做的好處。因為每次你給他們展示一些東西以後，他們的需求都會發生變 化，然後我們就能得到一些回報。這種回報是雙向的。你可以知道增量版本功能是否符合要求，而客戶則可以知道你現在在幹什麼。”

對Spagnuolo來說，靈活開發還意味着客戶也變得“靈活”。他說，“他們可以經常看到我們傳遞的軟體，需求改變也很靈活。”

Bouwman補充說，“軟體是一種比較飄渺的東西，但通過頻繁的疊代開發和‘利益相關人’的持續回報，客戶可以獲得比較具體的感覺。他們還會告訴你下一 步應該怎麼做。”

然後他又說道，“雖然也預先做需求分析，但通常并不一定按你想的發展。實時的需求采集要有用得 多。”

靈活工具改善靈活開發

Spanguolo還提到一個常見問題：索引卡片和即時貼反映的需求有時并不準确。随着項目複雜 性提高，僅使用簡單的工具開始有點力不從心。他說，“我們開始尋找工具，特别是需求方面的工具”。他們曾經使用一張電子表格追蹤使用者需求，然後根據需求用 另一張電子表格安排各疊代周期的任務。

他說，“開始的時候這個方法還是有效的。但随着靈活開發複雜度提高，以及參與的開發人員的增加，電子表格已經無法滿足我們的需求。單是管理這些表格就要花 費太多時間——每周需要大約四到六個小時。”

Spanguolo的團隊也曾使用任務卡來組織工作。和需要大量工作的電子表格一樣，低技術含量的任務卡同樣費時費力。Bouwman說，“整理任務卡是 一個艱苦的手工過程。”

後來Spanguolo他們開始使用Rally項目管理軟體，團隊才真正做到“實時追蹤”，按照計劃傳遞成果，并能減輕開發人員的壓力。 Spanguolo還說，簡報頁面（reporting dashboard）可以讓開發人員更有效地組織任務。其中成功完成的版本以綠色顯示，失敗的版本以紅色顯示。

Rally軟體是一個核心工具，但是功能很多。Spagnuolo和Bouwman的團隊工作于.NET環境下。他們使用MS Build建構工具和CruiseControl.NET持續內建工具。CruiseControl.NET對源碼控制工具進行監控，比如上文提到的 Subversion。如果有新的變動，它就會啟動一個新的建構過程。然後Rally各元件會與這個過程或持續內建引擎相連。

展望靈活工具前景

目前看來，在良好的知識共享庫和智能項目資料管理工具的支援下，圍繞建構管理和工作流程的标準過程正在形成中。盡管如此，這些被Burton Group分析師Joe Niski稱為“系統開發周期（SDLC）基礎結構”的每一步發展都将提高項目開發和項目團隊的效率。

Niski認為，關于知識共享庫（repository）最關鍵的一點是“它存儲了特定項目的中繼資料，其中源代碼控制庫正是我們建構項目所需要的”。作為 儲存項目管理軟體所依賴的知識共享庫也存儲了建構成果。

當然，作為靈活過程核心的是使用者需求。這些使用者需求（user stories）正在取代用例（use cases）成為應用廣泛的需求采集方法。并且，在諸多靈活開發過程中，多頁的使用者需求已經逐漸被簡單的需求記錄卡所取代。

新興的靈活項目管理工具大都支援以位圖或jpeg格式存儲這種記錄卡。可以預計，這種“靈活存儲”方式也将獲得廣泛應用。