極致編程(XP)於校園內軟體開發專案之應用

(1)

極致編程(XP)於校園內軟體開發專案之應用

劉文卿王琮信

國立政治大學資訊管理學系國立政治大學資訊管理學系

wliou@nccu.edu.tw

g1356001@nccu.edu.tw

摘要

現今軟體開發專案普遍有時程延宕、技術落後、預算及人力不足、無法應付使用者頻繁的需求變動等問題。為思考相關解決之道，本研究參考極致編程 (Extreme Programming, XP)軟體開發方法及應用架構(Application Framework)的分析技術，於校園內選擇一特定專案，配合XP相關研究中所提出的實行原則實際進行軟體開發；透過初步開發過程資訊蒐集，包括專案記錄與針對開發團隊深入訪談結果，我們探討XP於校園內軟體開發專案的適用性，並發掘可能的問題，以求進一步應用於業界個案及後續學術研究。關鍵詞：極致編程(Extreme Programming, XP)、軟體開發方法。

1. 前言

國內軟體發展在過去偏重技術面研究，不過隨著科技快速進展與各界對於資訊科技的需求大幅擴張，現今一般軟體開發專案所形成的特色是：時程短、高技術需求、預算吃緊、人力不足、使用者需求變動頻仍；各軟體公司或身處資訊部門的軟體開發人員錯失進度，無法準時交付產品，或無法維持軟體品質及滿足客戶需求、資金不足導致專案失敗等，類似的現象時有所聞。因此，如何有效地管理軟體專案，甚至回歸到基本面，尋求一個更好的軟體開發方法，乃近來逐漸受到重視之議題。 Kent Beck 於 1996 年提出 XP 軟體開發方法，認為軟體專案中所有問題的根源來自於「變動」，可能的變動包括使用者需求、系統設計、技術、人力資源等，其中又以使用者需求變動影響專案最鉅。大部份軟體開發方法是在專案初期採長遠性規劃、固定式設計而不易變更，未完全發掘使用者需求，亦缺乏人際溝通機制、過度承受時間壓力；一旦需求變動，因開發團隊無力回應「變動」之事實而大規模重新規劃、分析、設計，常使專案面臨失敗危機。XP 的宗旨即如何於專案期間隨時掌握引發「變動」的要素。XP 著重簡單而兼具彈性的開發流程，採用階段性規劃方式，對於可行性評估、需求分析、系統設計、編碼、測試、發行、維護等過程皆給予獨特的詮釋。

本研究參考 Kent Beck(1999)、Kent Beck & Martin Fowler(2000)、Don Wells(2003)、Ken Auer &

Roy Miller(2001)等之文獻，選定校園內一軟體開發專案，嘗試導入 XP 方法，並整合應用架構 (Application Framework) 中的關鍵抽象 (Key Abstraction)觀念實作應用系統，最後分析初步導入結果，以供實務界及學術領域研究參考。

2. XP 簡介

XP是Kent Beck於 1996 年提出的軟體開發方法，強調團隊合作與人際溝通，並協助軟體開發人員以最有效率之方式完成高品質軟體，以滿足需求多變之客戶。XP整合多人的觀點與技術經驗(Kent Beck, 1999)，以四個價值觀為出發點，衍生出十二項實行原則及反覆(Iteration)模式，進而期望能解決軟體專案因「變動」所產生之問題。以下將簡述XP 的涵義。 2.1 XP 的價值觀 Kent Beck(1999)以四個核心價值觀作為 XP 的基礎：溝通(Communication)、簡單(Simplicity)、回饋(Feedback)、勇氣(Courage)。「溝通」是將程式師、系統分析師、測試人員、客戶(使用者)、管理者均視為軟體專案開發團隊之一份子，藉由頻繁地互動讓所有成員的關鍵想法得以完整傳遞。「簡單」是聚焦於眼前的任務，不預設使用者未來需求，盡可能簡化系統功能設計，保留最大彈性。「回饋」分為二要點，其一，建立使用者對於系統之意見回饋機制，使開發人員與使用者的溝通更有效率；其二，持續藉由系統對於錯誤或缺陷的反應訊息，隨時改善系統架構，確保專案循正軌而行。「勇氣」是果斷地拋棄結構不佳的程式碼，並勇於接受改變，嘗試重大修改行動，以避免小瑕疵累積成大錯誤。 2.2 瀑布模式與反覆模式 Royce(1970)提出的瀑布模式(Waterfall Model) 包含系統與軟體需求分析、設計、實作、測試等階段，亦稱軟體開發生命週期 (SDLC, System Development Life Cycle)，使軟體開發依一序列階段進行，前一步驟完成才可進階。

Kent Beck(1999)將瀑布模式延伸改進成反覆 (Iteration)模式。XP 不鼓勵長遠規劃亦不凍結使用

(2)

者需求，在相同專案範圍內將整個專案發展切割成數個階段，每一階段稱為一個反覆，每個反覆都包含軟體開發之所有活動，因此可視為許多迷你專案 (Mini-Project)：分別詳細確認使用者需求，且完整實施分析、測試、實作、設計等工作。 2.3 XP 的實行原則 為更貼近實務面，Kent Beck(1999)提出十二項主要實行原則，但強調不必將它們奉為圭臬，開發團隊可視狀況選擇必要項目並調整做法。 (1) 規劃遊戲(Planning Game)：採用漸進式多次規劃法，參與規劃者應包含開發人員、客戶(使用者)、專案管理者。首先由客戶挑選自認最有價值之系統功能需求並排出優先實作順序；這些需求在 XP 中稱為使用者故事(User Stories)。隨後各方協定發行範圍和時間，將故事切割成適當數量之反覆，進而轉化成較小任務。 (2) 頻繁的小版本發行(Small Releases)：每一反覆中僅實作使用者選定之故事並經常推出小版本系統發行至客戶端。 (3) 註點的客戶(On-Site Customer)：至少能有一位關鍵使用者全程參與開發工作。 (4) 象徵(Metaphor)：以一種圖像或詞句來表達整個專案設計概念的源頭或系統運作方式。 (5) 簡單的設計(Simple Design)：設法排除重複的程式碼，並僅使用必要的類別 (Class) 和方法 (Method)。 (6) 測試(Tests)：分為單元測試(於正式寫碼之前先撰寫測試程式)與每個反覆結束前的系統驗收測試(Acceptance Tests)。 (7) 重整(Refactoring)：在不變更原始功能前提下經常改善程式碼結構。 (8) 程式碼撰寫標準(Coding Standards)：制定格式化的寫碼標準(如參數設定)。 (9) 持續的整合(Continuous Integration)：新產出的程式碼須與現有系統作經常性、循序性整合。整合前須通過所有單元測試。 (10) 共享程式碼所有權 (Collective Code Ownership)：所有團隊成員均有權改善系統中任何一支程式碼，但也負修改成敗之責。 (11) 二人組程式設計(Pair Programming)：所有程式碼皆由二人一組搭配產出，輪流擔任寫碼者、觀察與建議者。 (12) 每週 40 工時(40-Hour Weeks)：若非必要絕不加班。

3. 研究方法

3.1 應用案例概述 本研究選擇校園內單一軟體開發團隊、單一專案為試行對象，引導團隊全面實施 XP，但允許團隊於專案進行中彈性變動若干施行細節以符合現實所需。顧及團隊成員間溝通效率，XP 較適用於大約 2 至 10 人的小型開發團隊(Kent Beck, 1999)。經多方考量，本研究決定以「A 銀行 SFA(Sales Force Automation)應用系統委外開發專案」(以下簡稱 SFA 專案)為應用案例。 SFA 專案係由 A 銀行於 2003 年 6 月委託國立政治大學資訊管理學系「SFA 專案開發小組」協助開發。原訂專案時程三個月，但研究者撰寫本文時 (2003 年 10 月)尚未結案。專案主要目標為接續開發 A 銀行現有 SFA 系統中尚未完成之部份，建立一具備「客戶名單操作」功能之應用系統，用以支援顧客關係管理及行銷業務；系統使用者為銀行內部管理階級與業務人員。 SFA 專案開發小組成員共計 11 名，包括大學部四年級學生 6 名(含專案組長 1 名)，擔任主力開發人員；大學部三年級學生 5 名，擔任輔助開發人員。四年級學生實際軟體開發經驗約一年，三年級學生則無相關經驗。其中專案組長負管理團隊之責，行事決策則由開發團隊共同掌握。 3.2 整合 XP 價值觀與關鍵抽象概念 為將 XP 的四個價值觀充分融入應用案例中，本研究提出兩項做法： (1) 以人性層面來考量為實踐 XP 中的「溝通」、「勇氣」兩項價值觀，我們給予團隊高度自主權，暢通團隊內部、團隊與客戶之間的溝通聯繫管道，創造開放性的討論環境，鼓勵每位成員善用各種會議、電子郵件及電子佈告欄(BBS)，勇於提出個人想法、改善系統設計之建言及傳遞重要訊息。希望能藉此塑造出果決明快的團隊文化，培養足以應付外界變動之能力。 (2) 以系統層面來考量 XP 中「簡單」、「回饋」兩項價值觀的目標除了人為的管理、要求與配合之外，其實還需要依賴適當的系統設計概念或原則才能有效達成。本研究引入物件導向設計方法中的應用架構(Application Framework)及關鍵抽象(Key Abstraction)概念來實作系統，以核心抽象物件呈現簡單化的系統結構；藉其可修改、可擴充之特性，期能充分適應需求的不斷變動。本研究為使 SFA 專案應用系統保留最大彈性，將其結構抽象化成五個簡單的高層次核心概念，再由開發團隊加以設計與實作，包括：行銷案 (Campaign)、通路(Channel)、工作站(Workstation)、

(3)

佇列(Queue)及規則(Rule)等。簡言之，「行銷案」代表 A 銀行的所有行銷案資訊，每個行銷案會依不同市場區隔(Segment)分別推展行銷業務，且循各行銷階段(Stage)逐步進行，而各行銷階段代表運用某種特殊「通路」來接觸客戶，這些通路可能是透過電訪、電子郵件、郵寄，或由專員親洽。當行銷主管與業務人員登入系統時會啟動「工作站」，辨識登入者之身份與權限，以向「佇列」(客戶名單處理排程)索取自己應負責的客戶名單，同時透過「通路」判斷各特定客戶處於何種行銷階段，並設定「規則」(名單操作暨分派規則)，最後進行名單分派或新增、刪除、移轉等動作。當業務人員實際與客戶接觸時，依客戶反應將產生不同狀態(State)並有相對應細節作業；最後處理結果將回饋至 SFA 主系統，決定應進入的下一個行銷階段，同時可記錄行銷過程中客戶之行為模式，作為日後資料統計分析之基礎。以系統現況得知 A 銀行的 SFA 系統使用者涵蓋管理階級與業務人員，多達千人以上，於系統操作上勢必容易產生相當多樣化的需求，不過採用上述核心概念之後，相關的內容將來皆可隨使用者需求而快速地實施調整。 3.3 設定開發環境 基於集體作業便利性考量，SFA 專案應用系統於校內實驗室進行開發。為模擬 A 銀行現有系統執行環境，AP Server 採用 BEA Weblogic Serve，搭配 Oracle 資料庫管理系統；程式語言則採開發團隊較熟稔之 Java。該應用系統完成後將予以移植至 A 銀行 SFA 主系統。 3.4 擬定專案開發流程 本研究參考 Don Wells(2003) 之 XP 實作流程推動 SFA 專案開發，共區分為發行規劃(Release Planning)、反覆式開發、驗收測試、發行(Release) 四大階段(圖 1)，並針對實務要點擬定配套做法： (1) 蒐集使用者故事：由開發團隊挑選二位成員擔任「客戶代理人」以代表客戶身份，密切與客戶接觸並持續蒐集使用者故事。不過在各種大型會議中仍要求客戶盡可能親身參與討論。 (2) 建構前瞻性計畫(Architectural Spike)：此步驟含兩大施行要項，第一，於開始進行規劃前先評估技術需求、專案時程、所需人力，潛在問題等，並安排必要之教育訓練課程；第二，團隊須選擇適當的系統象徵。 (3) 發行規劃及反覆規劃會議：於專案初期、使用者故事範圍變動、優先順序改變、落後太多故事、團隊工作速度改變等時機啟動會議機制。發行規劃會議中依故事將專案劃分成多個介於 1 至 3 週之反覆，反覆規劃會議則是在每個反覆初期規劃出許多 1 至 3 日的任務。所有反覆循序漸進，一個反覆完成後方進行次一反覆。 圖 1 XP 實作流程 資料來源：Don Wells(2003)及本研究整理 (4) 站立會議(Stand Up Meeting)：為節省時間，每日例行性會議(非技術性會議)以站立方式開會，僅討論團隊重要問題。若發現任務量超過負荷，則可將多餘工作移至下一反覆中另行規劃。

(5) CRC(Class, Responsibilities, and Collaboration) 會議：專案中的系統架構設計會議，輔助工具為 CRC 卡(以卡片模擬物件，填寫物件類別、主要功用及互動之類別)，擬配合使用白板。 (6) 單元測試(Unit Test)：正式寫碼前須先建立單元

測試程式，通過測試後再新增程式碼，程式碼須 100%通過單元測試序列(Unit Test Suite)，即通過所有單元測試方進行整合工作。單元測試工具採用 Borland JBuilder 中之 JUnit 測試架構。 (7) 二人組程式設計(Pair Programming)：遵循配對編組之程式設計原則，將四年級成員以二人制編成 3 小組，三年級成員未予編組，僅平均分派至各組觀摩及協助開發作業。同組成員制定程式碼撰寫標準，於一部電腦協同進行寫碼、發行規劃會議反覆規劃會議 CRC 會議蒐集使用者故事建構前瞻性計畫建立單元測試二人組程式設計通過單元測試循序整合驗收測試通過驗收測試發行小版本任務量過多是否否是是否進度落後否是原始碼儲存庫發行規劃反覆式開發驗收測試發行站立會議

(4)

除錯、重整，並定期交換搭檔。

(8) 循序式整合(Sequential Integration)：選擇一固定主機作為程式碼 ( 含單元測試程式 ) 儲存庫 (Source Code Safe)。每次由單一小組負責該組的程式碼整合工作。 (9) 驗收測試：每個反覆完結前進行整合測試。若客戶接受測試結果則發行至使用者端，同時進行下一個反覆；否則便於下一個反覆進行改善。 (10) 發行小版本：每個反覆最終將發行小版本，並選用單一專用電腦建立發行站 (Release Station)，以維持版本一致性。另外，考量專案成員皆屬學生身份，本研究未採用「每週 40 工時」原則，但仍要求成員們確實記錄投入專案工作之時數以評估人力安排情形。 3.5 專案記錄與訪談 本研究於 XP 導入專案之後，詳實記錄專案開發過程、團隊成員工作時數、團隊行為、軟體使用者與開發人員互動情形等；另外亦於專案開發期間針對開發團隊持續進行個別訪談，以充分了解 XP 方法的實行結果、專案開發過程中可能遭遇的阻礙、受訪者對 XP 的認同度等。 3.6 驗證理論與實行結果 本研究最終將比較 XP 文獻論點與實際應用案例，分析校園內軟體開發專案引進 XP 的可行性，以嘗試進一步應用於其他個案及後續學術研究。

4. XP 應用案例初步實行結果

由於 SFA 專案尚未結案，故本文僅就現階段主要的 XP 初步試行成效及推行上的困難點來探討，專案後期將持續進行觀察、記錄與分析。根據本研究針對 SFA 專案成員訪談結果與專案記錄，發現實施 XP 對於團隊的人際溝通、系統設計、知識與經驗分享方面有明顯幫助；但在時程控制、團隊管理、反覆式開發等方面所呈現之結果並不理想，專案開發過程中也因受現實環境及團隊特性限制而使得 XP 原則窒礙難行。以下將作簡單說明。 4.1 XP 導入成效 (1) 強化團隊內部的溝通與協調機制人際溝通是 XP 的價值觀中極重要的一環。研究中發現 XP 的發行規劃會議、反覆規劃會議、CRC 會議對於團隊內部溝通有很大幫助。 SFA 專案團隊在過去的軟體開發經驗中，習慣一次分派工作再各自獨立作業，幾乎未曾共同討論與交換意見，常導致程式碼難以整合、系統設計概念互相衝突等現象。而實施 XP 之後開會次數變得相當頻繁，其中發行規劃會議已召開 9 次，反覆規劃會議有 3 次，CRC 會議更已達 17 次之多。這些會議均因專案範圍變動、進度落後、重新分配任務或更改系統設計架構而召開，藉由不斷地溝通與交流，團隊成員們不但能夠即時釐清自己問題所在，也能明白他人所需要的協助，更重要的是可以去思考如何與夥伴們搭配合作，如此一來即便外界環境及使用者需求產生變化，團隊也較能提出因應對策，共同突破專案開發過程中的障礙。 (2) 建構完整的系統全貌在 SFA 專案中團隊成員們一改以往各自獨立分析、設計、寫碼、測試，最後再整合所有部份之做法，而嘗試 XP 中的集體設計模式，如 CRC 會議。在實際 CRC 會議中，團隊並未採用 CRC 卡討論而是所有成員齊聚於白板前繪圖，運用前述的應用架構 (Application Framework) 及關鍵抽象 (Key Abstraction)概念模擬各物件間之關係，並於最後找出一個合理的系統象徵。據多位專案成員表示，此種設計方式可以集思廣益，使設計架構更加嚴謹。每開一次討論會，可能就會經歷一次重大設計模型變更。不過專案成員皆認為如此能使每個人熟悉系統全貌，而非一知半解或僅接觸到自己所負責的部份；此外也大幅減少實際寫碼時間及程式碼修改次數。 (3) 知識與經驗分享 XP 採用一種獨特的程式設計方式，即二人組程式設計。本研究中二人制編組方式係由團隊成員依過去個人 Java 程式設計能力及相關課程表現為標準，自行選擇搭檔對象，同一小組內以較不擅長程式設計者搭配能力較強者為原則。 SFA 專案團隊成員皆支持二人組程式設計的方式。而二人制編組的 6 名專案成員在嘗試過二人搭檔共同設計程式後，其中 4 名認為二人組程式設計有助於互相學習經驗及分享知識、了解自身的技術瓶頸與問題所在，兩人之間技術實力差距也逐漸縮小，且撰寫程式時由於各扮演寫碼者與觀察、建議者，責任感相形加重，使得精神及注意力須更加集中，程式發生錯誤之機率明顯降低了，艱澀的設計問題也較容易藉由互相討論獲得解決。 4.2 導入 XP 之困難點 (1) 時空環境之限制 XP 提倡團隊與客戶隨時進行溝通，共同參與專案開發，但在現實狀況中客戶是沒有辦法提供所謂駐點人員的，主要係受限於時間上的不允許，雙方地理位置也相距太遠。為接近「客戶參與專案開發」之理想，SFA 專案團隊採用變通方式，即客戶代理人制度，由團隊中的特定成員擔負起雙方溝通

(5)

的橋樑。然而根據專案記錄，客戶代理人與 A 銀行使用者實際面對面交談之次數，每月僅有 1 至 2 次，多數事項須依賴電子郵件及電話聯繫。另外，在已召開的 9 次發行規劃會議中，A 銀行客戶也僅參與 3 次，至於其他未能出席的會議，只得沿用客戶代理人制度，先由客戶代理人蒐集使用者故事，於會議中提出討論，會後將結論交予客戶作確認。不過採用如此一來一往的間接溝通方式畢竟不如即時性的資訊交流效果。因此在專案初期，使用者故事之蒐集並非十分順利，所蒐集到的資訊亦不甚完整。事實上團隊成員也坦承在規劃過程中無法立即取得使用者意見時，免不了會發生逕自猜測使用者需求之情形，而那些臆測結果事後亦無法獲得證實，進而影響規劃內容的正確性及真實性。由此看來，在實行 XP 時僅設有客戶代理人仍嫌不足。除了客戶方面無法充分配合之外，專案團隊本身也有時間安排上的問題。由於團隊成員平日個人所修課程不盡相同，可支配時間十分離散，欲讓所有人聚集起來協同作業或討論重要事項並非易事，這對於實施 XP 的效果有相當不利的影響。以站立會議為例，雖然專案團隊嘗試以站立方式召開例行性小型會議，但成員們普遍認為同聚時機不易掌握，勉強集會則與會人數零零星星，全無討論效果；多數成員表示僅能參與發行規劃會議、反覆規劃會議、CRC 會議等較大型之會議。因此根據記錄，SFA 專案團隊的站立會議僅實施過 2 次，可行性並不高。至於每日重要事項多公告於團隊專用電子佈告欄(BBS)上。再以二人組程式設計為例，儘管二人制小組運作情況不錯，仍難以確保小組內的兩個人能經常於同一部電腦寫碼。根據本研究所蒐集的團隊成員工作時數記錄資料，各二人小組協同作業次數平均每週僅約 3 次，每次作業時間不足 3 小時；有部份程式碼甚至是由單人完成後再整合，或以電子郵件及 BBS 傳遞程式碼修改訊息。可見在校園內要完全實施集體協同開發作業，實際上是非常困難的。 (2) 反覆式開發觀念不易實踐反覆式開發方法的精髓是在發行規劃會議中產生發行計畫，並將整個專案以「反覆」為單位作切割，逐步地、階段性地完成專案，並於每個反覆終了作一次小版本發行；不過 SFA 專案並未達成這個理想，主因在於專案本身的架構是不易切割的。專案團隊在首次發行規劃會議中僅依初始使用者故事規劃出一個反覆，但正當專案將進入開發階段之際，使用者又補充了許多其他關於操作上的需求。由於故事範圍已變動，專案團隊只得再次召開發行規劃會議修正反覆的切割，結果定出二個反覆。然而客戶代理人再次與 A 銀行確認行銷業務流程時，又發現新議題，於是團隊再度召開發行規劃會議；之後類似情形不斷發生。為避免頻繁的反覆範圍更動造成眾人無所適從，會議決定將新議題中旳功能需求移至第三個反覆而不再變動最初定案的二個反覆；此後再新增之故事也列入其他反覆。最終規劃結果，專案團隊認為系統架構經歷多次討論已形成完整輪廓，不過似乎因考慮得太過週詳而無法再將系統以反覆方式進行階段性切割，因此決議合併前二個「小反覆」成為一個「大反覆」，第三個反覆之後的故事則維持原規劃範圍。不過如此一來，由於前二個反覆合併之故事內容涵蓋大部份的使用者需求，開發時程必須重新訂定，顯然地無法遵循 XP 的「小版本發行」原則了。由此可見在強調彈性化的理念下，當系統規劃隨著不斷地討論與改進，其中的細節必然會越來越清晰，規劃出來的各項功能間彼此關聯性也會隨之提高而不易切割。對客戶而言，系統中的每項功能都是重要的，難以分出所謂的優先順序，而專案團隊為考量日後實作上的便利性與整合性，可能也不傾向採取階段性的開發方式。以 SFA 專案初步導入 XP 結果來看，顯然並未貫徹反覆式開發原則，雖將專案切分為各小型反覆階段，但若干反覆又合而為一；單以第一個大反覆而言，將來僅可就中大型規模的系統功能發行已完成的軟體，由客戶試用之後再逐步改版或更新。至於其他階段之反覆是否能遵循小版本發行原則，則待後續觀察。 (3) 團隊的專案經驗不足 XP 中需要團隊成員共同進行評估及規劃工作，但當團隊經驗未十分成熟時經常無法作出有效的結論。例如在建構前瞻性計畫時偏重技術需求評估及觀念養成，並須判定總時程、所需人力、潛在問題等，不過礙於團隊之經驗不足且係首次導入 XP，缺乏歷史性資訊作為評斷標準，故無法做出詳盡評估，僅有粗略的初步討論。又如反覆規劃會議，根據 Don Wells(2003)說明，反覆規劃會議是在每個反覆初期根據已劃分之使用者故事或者未通過驗收測試之程式，規劃該反覆的任務；每項任務工作時限以 1 至 3 日為範圍，大於 3 日者加以分解，小於 1 日之任務相互結合，受指派者須自行評估並簽署每一任務完成天數供日後比較。不過 SFA 專案團隊並無法從事如此詳盡之規劃，理由是學生們不知如何估算自己的開發速度，尤以三年級成員而言，全無過去的經驗可供參考，很難以完整的天數為任務分配單位。因此最終僅把每一反覆的故事大架構區分成數塊工作量相當的小故事群，再分配給各小組，於同樣的反覆時限內完成工作。不過如此一來，由於時程規劃不甚明確，對於整體專案進度的控制便產生不利影響了。 (4) 缺乏團隊約束力專案團隊是否能以高度熱誠來支持 XP 的推行，其實是很重要的 XP 導入成敗關鍵。在 SFA 專案中，採取的是高自主性的行動方式，所有決策也由團隊共同商議，不過這樣也使得管理機制較為鬆

(6)

散，約束力稍嫌不足，許多 XP 中的實施細節不易徹底執行。

例如本研究中要求專案團隊於正式寫碼前須先建立單元測試程式，但根據訪談結果，由於無人加以督導，3 個主力開發小組中僅有 1 組人員採用 Borland JBuilder 中之 JUnit 測試架構從事單元測試，其餘 2 組則習慣性地沿用舊有方式，於完成寫碼後再投入相關變數進行一般性測試。又如重整(Refactoring)工作係要求各小組在系統加入新功能之前後進行重整，並配合單元測試不斷修改程式碼，使它更精簡、執行效率更好、錯誤更少。不過以 SFA 專案而言目前的重整結果並不明顯，因為成員們普遍不會自動自發地多花一些時間重整程式碼。另外，專案組長也表示，由於並未嚴格管制團隊的工作時間，團隊中有若干成員經常未出席重要開會，或者遲到早退，態度不甚積極，長久下來對於團隊向心力產生很大的負面作用。由此看來團隊中可能還是需要一個較強勢的統御中心來協調團隊事務與督促 XP 之執行，也應設法建立起優良的團隊文化，否則過於強調表面上的開放、自主性的環境，約束力及激勵因子較不足，團隊運作效率也較無法如預期般地發揮出來。

5. 結論與後續研究

綜觀 A 銀行 SFA 專案導入 XP 之初步應用結果，可看出實施 XP 有助於改善團隊內部的溝通協調機制，配合應用架構觀念後也使系統設計全貌更加完整，對於知識與經驗分享亦有正面作用；不過總體而言時程控制不佳，並未達成反覆式開發之目標；團隊內部共識與約束力不足、客戶無法給予即時回饋等，也是實施 XP 的一大阻力。因此本研究發現在實務上並不容易完全實踐 XP 價值觀及實行原則，尤其須視專案團隊與客戶是否能多方面配合及支持。不過我們也並不能保證貫徹 XP 即可得到最佳成果。Kent Beck(1999)提出 XP 開發方法時並未訂出制式規章條文，因為一旦凍結規則，基本上便已違反 XP 所強調的彈性化理念；或許每個專案團隊擁有不同運作模式與軟體開發風格，若能選擇最合適的方法，因應現實環境而調整，團隊反而較能自由發揮潛能，也較能適應外界變動。由於 SFA 專案尚未結案，可供比較之資訊不甚完整，本文中有很多細節無法詳加探討，諸如軟體品質、使用者滿意度之評估等；專案後期將持續研究與分析。另外，本研究選擇校園內小型開發團隊、軟體開發專案作為導入 XP 之實驗對象，未來可望再於大規模開發團隊或大型專案中試行，甚至進一步推廣至實務界以探討其接受度。而本研究中要求專案管理者採取較自主、依團隊決策行動之高調整彈性方式來實行 XP，未來或許可嘗試研究在嚴格推動 XP 狀況下團隊行為與專案進行過程。若能依各項試行結果整合出一套適合國內各界應用的新式軟體開發方法，將有助於促進軟體產業之發展與軟體專案管理之成熟度。

參考文獻

[1] 林信惠、黃明祥、王文良，2002，軟體專案管理，台北：智勝文化事業有限公司。

[2] Don Wells, “Extreme Programming: A gentle introduction,” 2003.

http://www.extremeprogramming.org

[3] Ken Auer and Roy Miller, Extreme Programming Applied: Playing to Win, Addison-Wesley, 2001. [4] Kent Beck, “Aim, Fire,” IEEE Software, 18(5):

87–89, Sept./Oct. 2001.

http://computer.org/software/homepage/2001/05De sign/index.htm

[5] Kent Beck and Martin Fowler, Planning Extreme Programming, Addison-Wesley, 2000.

[6] Kent Beck, “Embracing change with extreme programming,” IEEE Computer, pp. 70–77, Oct. 1999.

[7] Kent Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999. [8] Marcus Fontoura, Wolfgang Pree, and Bernhard

Rumpe, The UML Profile for Framework Architectures, Addison-Wesley, 2001.

[9] Matthias M. Muller and Walter F. Tichy, “Case Study: Extreme Programming in a University Environment,” International Conference on Software Engineering, pp. 537–544, Toronto, Canada, May 2001.

[10] Royce, W. W., “Managing the Development of Large Software Systems: Concepts and

Techniques,” 1970 WESCON Technical Papers, Vol. 14, Western Electronic Show and Convention, 1970.

[11] Williams, Laurie, and Robert R. Kessler, “Experimenting with Industry’s Pair-Programming Model in the Computer Science Classroom,” Journal on Software Engineering Education, December 2000.

極致編程(XP)於校園內軟體開發專案之應用