摘要：經過了極限編程的洗禮，賽門鐵克的開發人員、測試人員、技術撰稿者和管理者們都感到收獲頗豐...甚至其高層管理者都為之震撼
正文
這是一個陽光明媚的三月早晨，我在猶他州的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�，F在確定它是讓開發人員能夠清晰的描繪出完整的用戶素材來”。人群之中，團隊的成員們快速的傳遞著五張卡片，在每一張上面都寫有編寫完驗收測試以及其所需的功能代碼完成構建所需要周數（只能是一周或是兩周）。突然，他們卡在了某張卡片的一項功能上，“我知道這是個難題”，Rowell插話道。她的意思是這需要一些簡要的實驗才能確定到底完成它需要多長時間�！斑@項功能是全新的，而且這次產品發布后可能就不用了”，她說。
要明白我們只有一個Rowell、兩個團隊和有限的一些時間，“我們不希望他們太依靠客戶（即Rowell，關于客戶在敏捷領域的真實含義請參見譯注4）”，主導這次XP變革的Object Mentor的高級顧問David Farber說，“如果他們非要她才能解決問題的話，他們應該寫在卡片上然后遞給她”。這樣做并非是不鼓勵與客戶進行緊密交互（XP恰巧非�？粗乜蛻艚粦簦�，而是在推動這些開發人員更快速的工作。
除了開發人員和管理者之外，還有一些測試人員和一個技術撰稿者也同在房間內�！拔覀冊谧屑汃雎犇亍�，QA團隊的高級經理Matt Sellers對我說，“如果我發現要測試三天的事情他們卻告訴我要用一天的話，我會馬上大聲告訴你們的”。
項目在一邊磨合一邊進展著。到中午為止，整個團隊已經想出了74個用戶素材，Faber得意洋洋的匯報到。這是自第一次發布計劃會議以來所取得的一個巨大進展，記得幾周前的第一次發布會議上，整個團隊只完成了大概20個左右的�！斑@個早上對于整個團隊來說都是個飛躍”，他解釋說，“在此之前，他們都在討論些非常抽象的概念：這是基于Web的，這是基于XML的，這是管理上的反映�，F在，他們能夠去處理真實可見的問題了”。團隊也在享受著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市的主要開發人員已經搬到了圣安東尼奧來跟他的合作開發人員一起以雙倍的效率結對編程�；氐紸mercian Fork，他們正在探索一種針對文檔撰寫的“結隊撰稿”方法。我對“結隊撰稿”的第一反應是恐怖，因為我觀察過很多開發人員對這種結對方法都有發自內心的恐懼感。經過進一步的思索，我發現很多文檔撰寫相關的工作是可以采用結對方式的，盡管如此，Cortez還是承認此種方法存在不少抵觸意見。
圣安東尼奧終于徹底的完成了XP的變革，并且他們用了“異地結對編程”（cross-site pair programming）的方法，用CRC卡片和UML圖表來交流工作。經過了這次的變革，他們中的五位開發人員加入到了Orca項目，這樣Orca就總共有10位開發人員、一個半的技術撰稿者、五個QA工程師和一個客戶代理。變革并未帶來不良影響，除了有一位測試人員離開去功讀微生物學，僅此而已。
Cortez認識到去度量并匯報一個XP項目有些困難，尤其是該如何與現有的解決方案為中心的過程（SCP）相結合�！百愰T鐵克傳統開發過程是試圖去做到充分的預期，但是問題不在計劃上。他們試圖將軟件開發過程看成是一組可以預先計劃清楚的事件，但它實際上是個非確定過程”。據Cortez所述，掌管企業解決方案的高級副總裁Gail Hamilton到訪了他們，并表示她被團隊的工作熱情感到震撼，并告訴Cortez要去改善SCP�；谶@點，他告訴我說這些主管們吵著鬧著要改進需求文檔（包括了預算、license條款和導致市場成功的因素等），并作為另一項用戶素材工作。
摸爬滾打
設施還存在一些問題，因為先前的會議室已經被XP團隊“占領”了并作為他們的XP戰場（所有會議和結對編程都在這里進行），這樣就太狹小了。Cortez帶我下樓，走到更寬敞的一樓，這里曾經布滿小隔間，而現在是團隊的所在。雖然開發人員非常樂意在幾千平米的寬敞房間里辦公，但Cortez打算劃分這塊區域。在必不可缺的中央辦公桌的上方懸掛著一條充氣鯊魚。白板、XP的小貼士和彩色的項目進度示意表（顯示了驗收測試的成功率和用戶素材的完成度）隨意的貼在墻上。
又是一個周三，Orca的團隊完成了一個新的發布。在七月，這個團隊代碼的完成進度比開發經理先前所預料的要早得多�！斑@與以前的情況相反，我們往往是有非常多的方法級函數而不是用戶級的”，Cortez興奮的說道�？墒堑媱潟h仍然比理想的兩個小時要長�！懊總�用戶素材不應該花半個小時來討論，如果真的用了那么多時間，那應該稱作是訓練，而不是真正的計劃會議”，他說。誰應該成為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對測試的結果并不認同�！拔也皇荍ava開發人員，我也讀不懂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已經慢慢地變成了他們的第二天性�！皥F隊更加善于自我完善了”，Joe Shull笑著說，“感覺運用XP更加自如了。軟件開發在周而復始的調整中進行著，雖然我經歷XP好幾年了，但這還是頭一次得到了管理層的充分支持”。目前為止，結對編程還沒導致什么人承受不了而離開房間，而且就像Alex Smith所說，“來自同行的壓力是保證代碼質量的首要原因，要不然的話，等到合并的時候就有你忙的了”。
“不幸的是Perforce（一種源代碼版本管理配置工具）影響了我們的進度，盡管我們正在試著去解決這個問題 ”，XP的方式增加了像Perforce這樣的版本管理系統的負載，因為它現在幾乎替代了調試器的位置�！斑^去我們一只習慣使用調試器，但這幾個月來我們都沒摸過它”。Shull自豪地說。
在我離開之前，Smith給我做了個安全響應系統的原型演示，這看起來基本上就是個產品了。
六個月后...
現在已經是十月下旬，我在和Carlos Cortez講電話，通過電話我瘋狂的記錄著Orca團隊的目前進度�！敖裉煳覀冮_了個很棒的會議”，他對我說，“我們已經按照意愿把安全響應列表加入到界面中了，你可以操控、排序、并通過拖動鼠標來動態轉換報表的格式”。我問他是否有任何的矩陣示意圖來描繪目前開發進度。
“嗯，在這兩階段開發的過渡期，我們發布了一個硬件產品，這可是是頭一次準時發布的，而且beta版僅遇到5個一般性bug。Orca今天結束了第二階段的開發，經過了這六個月的開發，我們在13次迭代過程中（每兩周一次）只遇到14個bug”。這可是一個大概有5000行Java代碼的產品，再加上另外4000個驗收測試和單元測試�！拔乙呀浤慷昧蓑炇諟y試帶來的代碼的不斷減少，這令我想起了讀過的一篇Grady Booch的文章，上面提到你應該會看到代碼行的減少，這就意味著重構的進行是成功的”，Cortez說。Booch白皮書建議去度量每個發布中的類的數量，而且記錄下代碼行數，并且將上述兩個數字進行對比來發現在重構過程中架構是否真正改進了。Cortez已經提議將一個類似的方法提交到委員會，并使之加入到賽門鐵克解決方案為中心的過程中。
更重要的是，他認為QA的難題最終得到了解決�！拔覀冊鴨栠^‘為什么測試的速度非常緩慢而且成本頗高？’，AQA部門認為是因為他們產品間的距離，它形成了阻隔。兩周前我們重新調整了QA的組織架構，我們打亂了原有的組織，而且把這些QA員工分散在了三個現有的產品團隊之中。技能的混合使得產品導向型新QA團隊可以創造出更清晰的產品測試，并且通過結對編程過程，他們能做到更高的測試覆蓋率。測試的可讀性和速度緩慢的問題也解決了75%”，Cortez指出，這意味著Rowell現在能理解它們了。
賭局的豐收
“你們對開發過程是無計可施的”，副總裁Stay說道，“我們曾經有一些懷疑論者，所以我們說如果大家都同意的話我們才會進行XP變革”。賽門鐵克把擴招雇員的經費轉移到了XP培訓上，并且希望通過效率的提高來平衡成本�！叭绻忝繑U招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年的編輯。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
