興工具之利 善敏捷之事

來源：軟體世界
　　雖然在敏捷開發過程中，工具的使用已經不會再被反覆地強調，但是實踐證明，我們仍然無法忽視工具對敏捷開發專案的重要意義。合理的選擇和使用工具，將使敏捷開發真正受益於工具，而不是受工具所累。
　　隨著軟體規模和複雜度的不斷加大，想在計劃的時間和預算內完成一個專案似乎越來越難。主要原因就是不可控制的因素對整個開發過程的影響日益凸現，如人員流失、需求變更、分散式團隊難於協調等。針對於此，一些被廣泛認可的方法，譬如敏捷和CMMI，越來越受歡迎。根據VersionOne在2006年的調查報告，大約有80％的公司在採用敏捷方法後生產力提高或明顯地提高。
　　敏捷開發強調以人為本，認為面對面溝通是軟體專案成功的一個重要因素。
　　當我詢問一個研發經理關於敏捷開發所需的工具時，他開玩笑地說，一張白板和兩杯咖啡。這也反映出開發人員對於敏捷方法的普遍認知。
　　事實上，許多開發專案主管雖然認同敏捷開發所強調的快速反應和溝通的理念，卻擔心它的“雜亂無章”帶來的“不安定因素”。因為它極度地強調人的因素，使得人員的素質對敏捷團隊的影響，遠比對其他團隊更大。
　　舉例來說，配對檢入是個保證程式碼質量很好的方法。但程式設計人員不瞭解其重要性，可能為了進度，常常一個人草草就檢入了。因此，在採用敏捷方法時，若能適當地使用工具來儲存累積的知識並固化關鍵過程，必能使敏捷專案更加成功。我們試以敏捷開發的幾個主要特點為例，探討工具在敏捷開發中扮演的角色。
　　特點一：測試驅動開發
　　傳統的瀑布方法先編碼再測試，等到發現需求和設計上的問題，為了節省費用，常常不了了之。測試驅動開發是在需求產生後，設計模組和其之間的介面，並將單元測試程式碼完成。在此過程中，需求和設計上的偏差將會被發現。由於編碼尚未進行，只需更改需求和設計即可，避免造成太大浪費。
　　特點二：簡單設計
　　敏捷開發崇尚簡單的漸進設計，而不是劇烈的顛覆式設計。其目標是首先只設計我們所瞭解的那些部分，然後使該設計隨著時間的推移而逐漸改進，這有助於提高靈活性並將變化導致的成本最小化。
　　特點三：配對程式設計
　　儘管兩人一組的配對程式設計從理論上看使眼前目標和長遠目標都得以保證，這卻是敏捷方法中備受爭議的做法，反對者普遍認為它會導致耗時加倍。廣義的配對程式設計也包括前面提到的配對檢入(Pair Check-in)，也就是由兩人一起檢驗程式碼的正確性，然後才檢入。
　　特點四：小型釋出
　　釋出週期短可使對專案的評估提前，進而降低了風險性。但這所帶來是大量的可執行文件，造成管理上的困難。
　　工具所扮演之角色
　　現在讓我們以一個典型的敏捷團隊DevAgile為例，看看該如何用工具實現其敏捷過程和設想。Smart先生是DevAgile團隊的專案經理，他被要求在開發過程中體現我們以上所列的幾方面特點，在配對程式設計方面還要求配對檢入。
　　角色1：需求管理的利器
　　對專案需求和設計文件的管理是DevAgile必須首先面對的問題。他們要完成的，恰恰是一個需求變更很快的專案，這也是他們選擇敏捷開發的重要原因。在敏捷開發中，需求的變化常常是為下一次迭代提供資訊和進度計劃的依據。
　　因此，DevAgile的大多數成員認為，記錄下每一次關鍵的需求變更很重要，儘管最初有些人堅持敏捷開發並不需要文件。
　　同時，他們也注意到，要遵循簡單設計的原則，並非意味著設計文件不需管理。相反，文件的數量和版本都會比採用其他開發方式更多。這些設計文件及其歷史應該被妥善地管理，也要和相對應的配置項鍊接。
　　另外，小型釋出意味著整個生命週期中有更多的釋出，如何對這些釋出進行系統化管理也是DevAgile團隊必須解決的問題。
　　綜合以上這幾點考慮，Smart先生認為，應該找到一種需求管理的武器。DevAgile團隊在進行了一番市場調查後，決定嘗試TechExcel DevSpec這種需求管理工具。它不僅提出“以知識為核心”的概念，滿足需求和設計文件管理的要求，還實現了真正的“功能驅動開發”。
　　儘管DevAgile目前沒有清楚的看到後者如何實現，但DevSpec對產品需求、產品功能及知識文件的系統管理還是吸引了他們。
　　它成全了設計團隊的敏捷性，支援簡單設計，並對他們經常修改設計的做法提供了管理上的幫助。一些成員還指出，在敏捷開發的道路上，太多的不確定因素和靈活性難免會影響大家對最終產品的認識，有一個這樣的工具能夠時時刻刻描繪出要釋出產品的清晰輪廓，記錄下產品需求和功能變更的每一步，實在是很令人欣慰。
　　另外，為了配合數量多的小型釋出，DevSpec還有整理髮布功能點的能力。也就是說，將和某一發布有關的新功能、功能變更，以及缺陷修復，全都進行統一組織和管理。
　　例如，要完成6.1的釋出，他們只需把6.1功能資料夾裡所有的新功能、功能變更，以及缺陷修復全都做完，6.1版本也就可以釋出了。為了更大程度上提高開發效率，Smart先生還別出心裁的對這些功能及缺陷設定了優先順序，優先順序低的任務可能被延緩執行。實踐證明，這種具靈活性且針對釋出來管理的系統使小型釋出越發容易。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-402107/，如需轉載，請註明出處，否則將追究法律責任。