賽門鐵克公司的XP探索實踐之旅

正文

　　這是一個陽光明媚的三月早晨，我在猶他州的American Fork市，這裡的小型工業園區被Wasatch眾山所環繞，其中有一座雙層建築，在它的二樓的一間寬敞的四面玻璃的房間裡，25個工作人員（一共有120位工作人員）正環繞著中間的一組辦公桌和電腦圍成一圈。這是一個站立的會議，團隊每位與會成員要向大家彙報工作進展情況，而且彙報時間最長不能超過20分鐘。討論內容包含了像是以下的這些事情，“我們正開始搭建自動化測試工具。”；“我們已經完成了資料庫結構的更改。”；“我們正在和HP的管理者一起工作，而且我們需要會HP-UX的人過來幫忙！”；“我們已經定位了問題所在！”；“夜構建（譯註1）跑起來了！”。

　　我應OO大師Robert Martin之邀來到賽門鐵克探訪，這是為了瞭解他們的工程師是如何對其安全響應方面的新產品Orca用Java進行歷時一年開發的。受探訪的開發團隊正是其公司向極限程式設計（譯註2）變革的先頭部隊。此外，還有另外兩個產品開發的先頭團隊，一個是同在猶他州的Rubicon更新版的開發團隊，還有一個是叫做Jaguar的新產品的開發團隊，他們在德克薩斯州的聖安東尼奧市。

　　以終端使用者軟體Norton AntiVirus而享譽中外的賽門鐵克公司也提供各種安全產品和服務，諸如缺陷評估（vulnerability assessment）、防火牆、入侵防護（intrusion prevention）、內容過濾和反垃圾郵件（Internet content and e-mail filtering）、端點安全技術（remote management technologies）和安全服務。該公司於1982年成立，總部位於加利福尼亞的Cupertino市，這家上市公司與36個國家間都有業務往來。在2000年的12月，賽門鐵克收購了一家從事企業安全的公司Axent Technologies，並於2001年三月，賽門鐵克宣佈於聖安東尼奧正式啟動這家公司，將其作為提供管理、監控和響應服務的安全控制中心。

　　可是，將極限程式設計技術應用於賽門鐵克這樣的公司可以說遭受的質疑多於贊同。XP最初興起於1996年，是Kent Beck和他的幾位同事在從事C3（Chrysler Comprehensive Compensation）人力資源專案的時候發明的。可是作為一個獨立軟體開發商，它該如何去適應XP過程中必不可缺的“客戶”（譯註3）角色呢？是否可以從地緣上來劃分多個彼此獨立的團隊並進行XP呢？當產品開發進入到兩週一次的迭代開發過程中的時候，該如何撰寫需求文件來達到高階主管們的要求呢？獨立的質量保證和文件撰寫部門該如何適應這種以程式碼為中心且測試為優先導向的開發過程中呢？該怎麼才能知道XP行之有效？最後，如果允許談論這家公司的技術細節及其相關領域的話，一個採訪者是否能夠清楚的描繪出這家公司的開發過程呢？

　　要找到這些問題的答案，我要在接下來的六個月裡仔細觀察賽門鐵克的程式。

　　這是個好點子，而並非命令

　　看起來過渡來得並不太痛苦，American Fork研發中心要求入侵檢測和缺陷評估的專家們參加為期12個月的“XP變革”課程。這其實也只是Object Mentor（1991年Martin在伊利諾斯州的Vernon Hills領導建立的培訓諮詢公司）第三次做這樣的培訓。為什麼要摒棄原有的做法？是否有什麼不可抗拒的命令驅使他們將XP付諸實施？

　　賽門鐵克的開發過程管理總監Carlos Cortez說：“公司僱用我是要我來改善開發過程的可預見性、效率、內容和質量的，沒有必要使之成為一種強制，這是形勢所趨”，他負責猶他和德克薩斯州的開發團隊，曾與賽門鐵克掌管產品釋出的副總Russel Stay在加入賽門鐵克之前共事於辛辛那提的Structural Dynamic Research Corp.公司有超過10年之久。在賽門鐵克於2000年收購Stay的公司後不久，他向Cortez申請從事改善開發過程方面的工作。

　　Cortez懷疑僅通過讓開發人員從書本自學是否足夠有效，他回憶曾經對Stay說：“要改變我們開發的傳統和方法，並從C語言過渡到C++或是Java，不僅僅是每個人自己努力的事，我們還要依靠曾有過成功合作的Object Mentor的Robert C. Martin。我曾目睹過Martin在很短的時間內就為一些糾纏複雜的難題帶來了希望，並告訴那些自認為洞悉OO一切的優秀工程師們該如何真正做到OO”。在Stay的邀請下，Cortez很快就開始展開了在賽門鐵克的開發過程優化的工作。

　　挑戰困難

　　其實原本極限程式設計並非是唯一的開發方法的候選，有擁有25年IT經驗，曾發明過軟體成熟度模型（CMM）的Watts Humphrey（譯註4）所建立的個人軟體過程（PSP）曾一度引起了Cortez的關注，況且賽門鐵克也已經實現了自己的“解決方案為中心的開發過程”（譯註5）。此過程包括了六個階段（探索、定義-評估-再定義、計劃、實現、釋出和考量）和五個檢查點（隨機、需求、實現過程、準備釋出和釋出後），實現了開發過程事無鉅細地呈現於開發團隊面前。最後，PSP這種以自我完善和度量為導向的方法還是沒能戰勝來自XP的強大誘惑，尤其是考慮到一些American Fork的開發人員已經有了XP的苗頭。

　　“我們已經從事XP兩年了，雖然還處於菜鳥水平”，在賽門鐵克工作過五年的開發總監Joseph Shull說到，“高層管理者們曾猶豫該向左走還是向右走，但現在已經傾向於它了。當培訓剛開始的時候，只有25%的工程師知道XP是什麼，而現在的情形大有改觀”。

　　“我們過去曾實踐過很多方法”，Stay談起變革的頭一個月的感觸，“那些都過於教條、拘禁，大家都覺得束手束腳。和當時向瀑布模型變革時情形一樣是，一開始都有很多人抱怨變革。不同的是，現在隨著接觸的時間久了，這些抱怨之聲也都慢慢的消失了，可是過去的情形卻是正好相反的。不過最大的改變還要屬結對程式設計了，開發人員擔心會‘失去個人空間’，我也在懷疑難道接下來的6到12個月裡他們都要這樣靠在一起工作？”

　　這項工作要花多長時間？

　　現在是早上10點，這是他們XP變革以來開的第二次釋出計劃會議，Orca的開發人員已經被劃分為了兩組（每10人一組），他們正在一張3乘5寸的索引卡片上記錄著使用者素材（譯註6）--即可能在兩週以內實現的簡單功能。因為賽門鐵克的產品素來是為市場而設計的，並非為了內部的需要，產品經理Karen Rowell就正在代表客戶的角色。她快步的穿梭於各團隊之間，併為之解答問題。

　　“我們正在確定所要支援平臺”，Rowell解釋說，“HP-UX、Solaris、Windows。現在確定它是讓開發人員能夠清晰的描繪出完整的使用者素材來”。人群之中，團隊的成員們快速的傳遞著五張卡片，在每一張上面都寫有編寫完驗收測試以及其所需的功能程式碼完成構建所需要週數（只能是一週或是兩週）。突然，他們卡在了某張卡片的一項功能上，“我知道這是個難題”，Rowell插話道。她的意思是這需要一些簡要的實驗才能確定到底完成它需要多長時間。“這項功能是全新的，而且這次產品釋出後可能就不用了”，她說。

　　要明白我們只有一個Rowell、兩個團隊和有限的一些時間，“我們不希望他們太依靠客戶（即Rowell，關於客戶在敏捷領域的真實含義請參見譯註4）”，主導這次XP變革的Object Mentor的高階顧問David Farber說，“如果他們非要她才能解決問題的話，他們應該寫在卡片上然後遞給她”。這樣做並非是不鼓勵與客戶進行緊密互動（XP恰巧非常看重客戶交戶），而是在推動這些開發人員更快速的工作。

　　除了開發人員和管理者之外，還有一些測試人員和一個技術撰稿者也同在房間內。“我們在仔細聆聽呢”，QA團隊的高階經理Matt Sellers對我說，“如果我發現要測試三天的事情他們卻告訴我要用一天的話，我會馬上大聲告訴你們的”。

　　專案在一邊磨合一邊進展著。到中午為止，整個團隊已經想出了74個使用者素材，Faber得意洋洋的彙報到。這是自第一次釋出計劃會議以來所取得的一個巨大進展，記得幾周前的第一次釋出會議上，整個團隊只完成了大概20個左右的。“這個早上對於整個團隊來說都是個飛躍”，他解釋說，“在此之前，他們都在討論些非常抽象的概念：這是基於Web的，這是基於XML的，這是管理上的反映。現在，他們能夠去處理真實可見的問題了”。團隊也在享受著XP的使用者素材所帶來的好處--避免不必要的複雜性。像這樣的事情就經常發生在我們中間：Rowell希望實現的一項使用者素材超出了Orca的能力範疇，因為它實現起來太耗時了。在討論這個特定使用者素材的時候，開發人員解釋了為何實現這項功能需要花上六個月，於是Rowell就砍掉它了。

　　Orca專案進行得很順利，可是Cortez說American Fork的第二個XP的專案--Rubicon產品的更新，進展得並不如意。可能誤以為我有超強的分析能力吧，他讓我對於Rubicon進展緩慢的問題給出一些可行建議。當我加入了他們的會議，我能看見唯一還保持著微笑的人就只有Object Mentor的企業教練James Grenning和“客戶”了。在這兩個人的指導下，團隊成員開始試圖去定義使用者素材，但還是有人不斷的抱怨這些方法是徒勞的。直到我們離開時，依然還沒看到任何的使用者素材完成。

　　從使用者需求到使用者素材

　　就像她的大多數的同事一樣，Karen Rowell擁有電腦科學的學位，而且熱愛所從事的安全領域。她曾是Unix系統工程師並工作過12年，還有6年半的時間工作在賽門鐵克。在團隊瞭解到公司已經採納此法之前，她從未聽說過XP。在做“客戶”之前，她用過一些傳統的需求蒐集的辦法來建立關於Orca這個安全響應產品的市場計劃，她從客戶顧問或是政府和安全學術機構那裡來汲取有效的商情報告。

　　Rowell現在發現用編寫使用者素材代替先前的空憑想象，並且關注兩週一次的迭代過程意味著所有的使用者需求都能按照客戶或市場價值所需正確的表達。“這並非亦步亦趨的方法，實際上我們已經直接看到了結果--兩個介面已經完成了”，她自豪地說。

　　使用者素材本身並非是使用者需求，然而，“這是一個挑戰，因為每次迭代都要去釋出一些部件”，Joseph Shull說，“我們總是傾向於作出一些功能卻無法釋出，在能測試它之前我們都無法親眼看到它。我們需要一個支援測試優先程式設計的基礎架構”。其實相關的QA正在進行這樣的一個專案，而這個新開發的基礎架構是福是禍還有待繼續考察。

　　讓QA融入進來

　　XP的一方面創新構想就是試圖去整合傳統的質量保證部門到定義、評估和編碼階段之中，而避免過去那種把問題丟擲腦後的習慣。然而真想做到這一點，絕非易事。

　　“按照我們過去的做法，開發工程師的工作結束了，QA才開始測試產品”，開發過程管理的高階經理Bruce Ackerson解釋說，“現在，我們整合了整個團隊，這包括QA（IQA）部門和自動化測試QA部門，並在開發過程中就與之協同工作”。開發工程師編寫單元測試，AQA工程師編寫驗收測試，而IQA工程師對使用者集中關注的功能作評估。為了達到如此程度上的緊密協同，他們坐在一起開了八、九個會議，令Cortez感到悲哀的是到目前還有些角色和職能尚未清晰界定。

　　“還有一個QA總是和我們的這種開發過程對著幹”，Object Mentor的Faber觀察到，“那些‘反對陣營’的人數目前還多於我們這些支持者”。

　　然而，七位AQA工程師的經理Matt Sellers對這種做法的可行感到非常興奮，他計劃去實現一個更加自動化的QA說法，他研究了這本經典的《實現極限程式設計》一書（譯註7），說：“上面講道客戶應該提供驗收測試，並且將其自動化。於是我們已經編寫了很多用於自動化測試的素材，而且已經開始用XP的方式在開發這個執行的框架”。他設想用一個資料庫來儲存這些測試用例，“在Orca專案之前，我們沒有搭建一個庫的需要，現在，我們將會用到資料驅動的執行測試指令碼的部件，這會帶來更多的重用價值”。

　　三個月後...

　　希望也能像是電影慢鏡頭回放一樣並從中發現一些跡象，我又回到了American Fork ，這回是在八月裡的炎熱的一天，依然為這眾山環抱之城的美麗所傾倒，我期待著再次的駕車到訪Carlos Cortez他們。

　　Orca這個新產品的進度還在掌控之中，然而，另外的一個產品Rubicon的更新專案卻依然停滯不前。幾周前，開發人員撤出了那個專案並轉移到了當前Orca中，因為這個產品需要保證其按時釋出。Orca現在就成了American Fork的唯一的XP團隊，雖然Cortez還指望著Rubicon團隊能與十月中旬再度開工。

　　“問題是難於給產品方向做出定位”，他說，“人們已經轉移到其他專案了，就像你所看到的，在使用者素材的問題上還存在分歧”。

　　分歧的部分原因是因為Rubicon專案已經違背了XP的關鍵原則--保證客戶的參與其中。這位在一開始就擔當產品經理一職的同事每週只能從東海岸過來四天，而對於此，Cortez認為是個錯誤。

　　他們下回不會再這樣做了。

　　Orca的開發人員成功地將它們的成功經驗傳授給了負責入侵檢測產品Blackbird的聖安東尼奧團隊的同事們，此產目前內建於防火牆之中執行，負責過濾和檢測入侵，而後項功能是到目前為止Blackbird產品中唯一用XP方式打造的部件。

　　“我們努力讓聖安東尼奧的團隊轉向XP，眾望所歸，他們也成功的按時完成了這個歷時四個月的專案，而且還比我們之前所計劃的具備更多的功能”，Stay誇讚道。他說聖安東尼奧的團隊雖比Orca稍小些，但在變革過程中卻更加守舊，“三個領頭的架構師想用Rational統一過程，但我們讓他們去參考比較工作。還有三個不在本地的同事，我們讓那些開發人員通過遠端連線與開發人員協同工作，但XP卻讓我們更需要工作於同一間辦公室裡”，他說。遵照Stay的想法，一個過去工作在奧蘭多Boulder市的主要開發人員已經搬到了聖安東尼奧來跟他的合作開發人員一起以雙倍的效率結對程式設計。回到Amercian Fork，他們正在探索一種針對文件撰寫的“結隊撰稿”方法。我對“結隊撰稿”的第一反應是恐怖，因為我觀察過很多開發人員對這種結對方法都有發自內心的恐懼感。經過進一步的思索，我發現很多文件撰寫相關的工作是可以採用結對方式的，儘管如此，Cortez還是承認此種方法存在不少牴觸意見。

　　聖安東尼奧終於徹底的完成了XP的變革，並且他們用了“異地結對程式設計”（cross-site pair programming）的方法，用CRC卡片和UML圖表來交流工作。經過了這次的變革，他們中的五位開發人員加入到了Orca專案，這樣Orca就總共有10位開發人員、一個半的技術撰稿者、五個QA工程師和一個客戶代理。變革並未帶來不良影響，除了有一位測試人員離開去功讀微生物學，僅此而已。

　　Cortez認識到去度量並彙報一個XP專案有些困難，尤其是該如何與現有的解決方案為中心的過程（SCP）相結合。“賽門鐵克傳統開發過程是試圖去做到充分的預期，但是問題不在計劃上。他們試圖將軟體開發過程看成是一組可以預先計劃清楚的事件，但它實際上是個非確定過程”。據Cortez所述，掌管企業解決方案的高階副總裁Gail Hamilton到訪了他們，並表示她被團隊的工作熱情感到震撼，並告訴Cortez要去改善SCP。基於這點，他告訴我說這些主管們吵著鬧著要改進需求文件（包括了預算、license條款和導致市場成功的因素等），並作為另一項使用者素材工作。

　　摸爬滾打

　　設施還存在一些問題，因為先前的會議室已經被XP團隊“佔領”了並作為他們的XP戰場（所有會議和結對程式設計都在這裡進行），這樣就太狹小了。Cortez帶我下樓，走到更寬敞的一樓，這裡曾經佈滿小隔間，而現在是團隊的所在。雖然開發人員非常樂意在幾千平米的寬敞房間裡辦公，但Cortez打算劃分這塊區域。在必不可缺的中央辦公桌的上方懸掛著一條充氣鯊魚。白板、XP的小貼士和彩色的專案進度示意表（顯示了驗收測試的成功率和使用者素材的完成度）隨意的貼在牆上。

　　又是一個週三，Orca的團隊完成了一個新的釋出。在七月，這個團隊程式碼的完成進度比開發經理先前所預料的要早得多。“這與以前的情況相反，我們往往是有非常多的方法級函式而不是使用者級的”，Cortez興奮的說道。可是迭代計劃會議仍然比理想的兩個小時要長。“每個使用者素材不應該花半個小時來討論，如果真的用了那麼多時間，那應該稱作是訓練，而不是真正的計劃會議”，他說。誰應該成為XP導師也尚未明確，因為團隊的內部成員現在都成了XP的積極擁護者。

　　QA在過去兩個月來...

　　測試人員在過去的幾個月裡一直非常繁忙於構建基於XML格式的測試框架，並用HTTPUnix中的JUnit、Perl、Python和Java的指令碼來呈現測試結果。我在一間昏暗的房間裡看著螢幕上的命令列正在飛快的滾動過一系列的單元測試的執行狀態。高階QA工程師Mike Kirsch和QA主管Matt Sellers向我演示了XML是如何在夜構建完成後的驗收測試執行過程中輸出，並彈出自動生成的測試結果頁面。

　　“因為每個團隊都有他們自己的測試指令碼語言：Orca專案用JUnit，聖安東尼奧的青睞Perl。所以我們已經搭建了一個稱之為shell的程式，它能將結果返回到XML之中，”Kirsch解釋說。程式會根據結果自動生成了一張彩色示意圖（就是我先前說過貼在牆上的那種）來展示驗收測試的成功和失敗率。在迭代的一開始，驗收測試完全失敗了，但隨著迭代開發的進行成功率也在逐漸增加，直到他們經過最後一次為時兩週的迭代，所有的就都跑通了。從這裡可以看出，除了使用使用者素材，否則很難去展現真實的進展。

　　雖然說QA的團隊認為他們的工具很棒，他們的代理客戶Karen Rowell對測試的結果並不認同。“我不是Java開發人員，我也讀不懂Java。這些測試還不夠有說服性，公司怎麼知道我們是成功的呢？”她問道，“我想讓他們換一種方式來做這些事情，我想讓QA詳細地說明任何的一種可能的測試組合”。當然，我也參加了這個會議，Rowell拿起一個寫著“#382：可理解的驗收測試”的卡片然後宣佈，“我想要在這次迭代裡面做這件事情，因為我無法理解它，我給你們時間來作它”。開發經理Alex Smith告訴團隊他們也需要指出過去的那些單元測試都是用來做什麼的。

　　顯而易見的進度

　　如果測試過程還算波瀾不驚的話，測試優先程式設計的結果卻不然。這是一箇中午，我和Shull、Ackerson、Smith、Rowell、Cortez和Grenning圍坐在一起。我們離中心工作臺只有幾步之遙，那裡有好幾本《Inside XML》和《Software for Use》（譯註8）很整齊的擺放在其他零散的書旁；我們談論的時候，開發人員正在使用Visual SlickEdit進行程式設計。

　　我感覺空氣中散佈著成功的味道，可能真是如此，也或是作為一個到訪者對在這裡所做得感到很滿意吧，因為Orca團隊已經成功釋出了產品最新版到位於愛爾蘭的i18n團隊（譯註9）了。這個團隊與Orca的進展時刻保持著同步，所以用句Ackerson的話說，他們能確保一直收到穩定的程式碼。而且他們現在已經完成了所有必要的字元本地化。

　　不只如此，XP已經慢慢地變成了他們的第二天性。“團隊更加善於自我完善了”，Joe Shull笑著說，“感覺運用XP更加自如了。軟體開發在周而復始的調整中進行著，雖然我經歷XP好幾年了，但這還是頭一次得到了管理層的充分支援”。目前為止，結對程式設計還沒導致什麼人承受不了而離開房間，而且就像Alex Smith所說，“來自同行的壓力是保證程式碼質量的首要原因，要不然的話，等到合併的時候就有你忙的了”。

　　“不幸的是Perforce（一種原始碼版本管理配置工具）影響了我們的進度，儘管我們正在試著去解決這個問題 ”，XP的方式增加了像Perforce這樣的版本管理系統的負載，因為它現在幾乎替代了偵錯程式的位置。“過去我們一隻習慣使用偵錯程式，但這幾個月來我們都沒摸過它”。Shull自豪地說。

　　在我離開之前，Smith給我做了個安全響應系統的原型演示，這看起來基本上就是個產品了。

　　六個月後...

　　現在已經是十月下旬，我在和Carlos Cortez講電話，通過電話我瘋狂的記錄著Orca團隊的目前進度。“今天我們開了個很棒的會議”，他對我說，“我們已經按照意願把安全響應列表加入到介面中了，你可以操控、排序、並通過拖動滑鼠來動態轉換報表的格式”。我問他是否有任何的矩陣示意圖來描繪目前開發進度。

　　“嗯，在這兩階段開發的過渡期，我們釋出了一個硬體產品，這可是是頭一次準時釋出的，而且beta版僅遇到5個一般性bug。Orca今天結束了第二階段的開發，經過了這六個月的開發，我們在13次迭代過程中（每兩週一次）只遇到14個bug”。這可是一個大概有5000行Java程式碼的產品，再加上另外4000個驗收測試和單元測試。“我已經目睹了驗收測試帶來的程式碼的不斷減少，這令我想起了讀過的一篇Grady Booch的文章，上面提到你應該會看到程式碼行的減少，這就意味著重構的進行是成功的”，Cortez說。Booch白皮書建議去度量每個釋出中的類的數量，而且記錄下程式碼行數，並且將上述兩個數字進行對比來發現在重構過程中架構是否真正改進了。Cortez已經提議將一個類似的方法提交到委員會，並使之加入到賽門鐵克解決方案為中心的過程中。

　　更重要的是，他認為QA的難題最終得到了解決。“我們曾問過‘為什麼測試的速度非常緩慢而且成本頗高？’，AQA部門認為是因為他們產品間的距離，它形成了阻隔。兩週前我們重新調整了QA的組織架構，我們打亂了原有的組織，而且把這些QA員工分散在了三個現有的產品團隊之中。技能的混合使得產品導向型新QA團隊可以創造出更清晰的產品測試，並且通過結對程式設計過程，他們能做到更高的測試覆蓋率。測試的可讀性和速度緩慢的問題也解決了75%”，Cortez指出，這意味著Rowell現在能理解它們了。

　　賭局的豐收

　　“你們對開發過程是無計可施的”，副總裁Stay說道，“我們曾經有一些懷疑論者，所以我們說如果大家都同意的話我們才會進行XP變革”。賽門鐵克把擴招僱員的經費轉移到了XP培訓上，並且希望通過效率的提高來平衡成本。“如果你每擴招100位員工，卻不能提高至少百分之三、四的產能的話，其實是南轅北轍了”。有意思的是，以前聖安東尼奧的那些保守主義者，現在倒成了XP的激進分子。

　　聖安東尼奧的XP變革是由那些高階工程師們推動的，Cortez解釋說，而它麼現在已經成功地釋出了兩個較小專案（三到四個人月）。“開發總監和開發流程總監曾是兩個最不看好XP變革的人，最近他們告訴我說，從現在起，他們絕不會再用XP以外的方法了。我說，‘你們倆是不是也太對XP偏執了，沒有任何過程是完美的。’”

　　一年以後...

　　Cortez讚揚了Orca產能的提升和這種歡愉氣氛的瀰漫開來，Stay期望通過Orca，Rubicon和Jaguar團隊來培訓希望採納XP的團隊。高階開發人員Stan Paulson已經被任命為XP導師，負責保持此種開發方法在傳授過程中的純粹性，同時避免向老習慣退化的跡象。Alex Smith被任命為導師長，這與目前的他管理者的職責相一致，他更是一位跟蹤者，他要保持跟蹤每個人的進度和所有在迭代過程中被列為任務的情況。這兩位將會幫助其他的組員，他們甚至也要負責自己XP技能的不斷提升。

　　儘管QA團隊成員們還並未培訓過XP，變革之風也使得他們認識到與開發團隊更緊密合作的重要性。

　　賽門鐵克的研發團隊再過六個月會怎樣？可以想象在接下來的六個月中，Orca團隊會持續的實現目標，每兩週就能釋出一次“可釋出”的軟體。是什麼讓XP如此具有吸引力？可能是因為它那質樸而又迭代的過程，不像是其他的那些強調程式設計細節的敏捷方法。經過我這次的訪問，問題已經清晰起來，採納極限程式設計並非是下屬的意願，軟體開發的高層管理者們進行干預和執行，員工們遵循公司的開發過程，這才是賽門鐵克到目前為止成功的關鍵。更重要的是，要在高質量的培訓上進行投資，並鼓勵整個核心團隊都進行改變。在用一句Kent Beck的話來結尾吧--擁抱變革才是XP精髓所在。

　　譯註：

　　1，nightly build，夜構建，與日構建基本相仿，但強調構建的時間是在夜間進行，避免與白天的開發過程相沖突。

　　2，極限程式設計，即XP，全稱是eXtreme Programming，是敏捷方法中最重要的一個。它是由一系列簡單卻相互依賴的實踐組成。這些實踐結合在一起形成了一個勝於部分結合的整體。

　　3，客戶，XP強調客戶和開發人員在一起緊密地工作，以便於彼此知曉對方所面臨的問題，並共同去解決這些問題。XP團隊中的客戶是指定義產品的特性並排列這些特性優先順序的人或是團體。有時，客戶是和開發人員同屬一家公司的一組業務分析師或是市場專家。有時，客戶是使用者團體委派的使用者代表。有時，客戶事實上是支付開發費用的人。但是在XP專案中，無論誰是客戶，他們都是能夠和團隊一起工作的團隊成員。

　　4，Watt S. Humphrey，在軟體工程領域享有盛譽，被美國國防軟體工程雜誌CrossTalk評為近百年來影響軟體發展的十位大師之一。他曾於卡內基·梅隆大學提出能力成熟度模型（CMM）思想。在CMM浪潮席捲軟體工業界之時，他又力推個人軟體過程（Personal Software Process），成為軟體開發人員和開發團隊的自修寶典。

　　5，解決方案為中心的開發過程，原文是Solution Centered Process，賽門鐵克內部簡稱其為SCP。

　　6，使用者素材，原文user stories。索引卡片，原文index card。為了進行專案計劃，必須要知道和專案需求有關的內容，但是卻無需知道得太多。需求的特定細節很可能會隨時間而改變，因此，在離真正實現需求還很早時就去捕獲該需求的特定細節，很可能會導致做無用功以及對需求不成熟的關注。在XP中，我們更願意客戶在索引卡片上寫下一些我們認可的詞語，這些片言隻語可以提醒我們一起這次交談。使用者素材就是正在進行的關於需求談話的助記符。它是一個計劃工具，客戶可以使用它並根據它的優先順序和估算代價來安排實現該需求的時間。

　　7，國內將此書譯為《實現極限程式設計》，原文eXtreme Programming Installed，作者Jefferies R、Anderson A、Hendrickson C，於2001年Addison-Wesley出版。

　　8，《Software for use》，國內一般譯此書名為《面向使用的軟體設計》，此書曾於1999年獲得Jolt大獎，作者Larry L. Constantine & Lucy A.D. Lockwood，於1999年Addison-Wesley出版。

　　9，i18n，全稱是internationalization，即國際化，因為在第一個字母i和最後一n之間存在18個字元，所以一般簡稱為i18n。

 （原文連結網址：http://www.objectmentor.com/processImprovement/xpCaseStudies; Robert C. Martin的英文blog網址： http://www.butunclebob.com/ArticleS.UncleBob）

　　本文作者Alexandra Weber Morales，是Object Mentor公司的高階顧問。Robert C. Martin是Object Mentor公司總裁，物件導向設計、模式、UML、敏捷方法學和極限程式設計領域內的資深顧問。他不僅是Jolt獲獎圖書《敏捷軟體開發：原則、模式與實踐》（中文版）（《敏捷軟體開發》（英文影印版））的作者，還是暢銷書Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主編，並與James Newkirk合著了XP in Practice。他是國際程式設計師大會上著名的發言人，並在C++ Report雜誌擔任過4年的編輯。

 

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