敏捷軟體開發：關於它的起源以及創始人的傳記

Gary Pollice, 實踐教授, Worcester Polytechnic Institute

本文來自於 Rational Edge：自從2001年開始，“敏捷”一詞在軟體開發領域已經被賦予了一種新的意義。您真的明白敏捷一詞的含義嗎？這篇文章是由一名敏捷實踐參與者所撰寫。文章討論瞭如今越來越重要的迭代和增量開發風格的基礎方面，並用以文學評論的方式作了總結。

 在 Princess Bride 這部電影中，Dread Pirate Roberts 正在攀爬 Vizzini 將要剪斷的一條繩索。當 Roberts 並沒有掉下來的時候，Vizzini 說了一句"他沒有掉下來？難以置信！" Inigo Montoya 回答道，"你經常使用的那個詞，我並不認為他是你所認為的那個意思。"

當我和別人談論敏捷一詞的含義時，我的感覺和上面場景中 Montoya 的一樣。我常常認為我們說的是同一件事。但是這不意味著我是正確的，他們是錯誤的。這隻能說明敏捷一詞的含義非常混亂。 ¹ 軟體行業中的人們有一個習慣，就是喜歡製造他們想要表達意思的詞語，特別是在新技術領域。為了讓這個新技術更易理解：我們的技術變化的太快，很多新的術語和簡稱幾乎天天都會出現，我們很難跟上這個速度，因此我們試圖對這些新術語產生麻痺的態度，並且希望我們更加的正確。

雖然敏捷一詞已經出現很久了，但是仍然存在很多術語的濫用問題。

這個月，我將要公佈一份關於敏捷前景的調查。我們首先要給這個術語做個定義。這並不是一件容易的事情。實際上，我並不確定能夠勝任這項工作，不過我會努力的。首先，讓我們從定義開始，來看看人們是如何曲解敏捷的意思。在我們達成定義的共識後，我會回顧一些有用的書籍和參考資料，他們能夠為敏捷的前景指明方向。

最開始...

在2001年2月以前，"敏捷"一詞意味著"標記快速的優雅的移動的能力"，或者是"擁有快速的機敏和適應能力的角色。" ² 從2001年開始，這個詞對於軟體開發人員來說擁有了更多的意義。由17個人組成的一組自稱為無政府組織的團體出現了， ³ 但他們實際上主要由軟體開發領域的軟體顧問和思想的領導人構成， 他們聚集在 Snowbird Utah 來定義敏捷的軟體開發過程。雖然他們能在普通層面上對敏捷的理解達成一致，但是每一個與會者都有自己對於如何建立一個高質量軟體的看法。

這種普通層面上的一致是在 Snowbird 舉行的 Agile Manifesto 大會上面達成的。 ⁴ 我在之前已經討論過這個宣言了，但是在這裡我們仍然值得重複這四個值得定義，因為它告訴了我們 敏捷（以大寫字母'A'開頭）一詞的意義。這些是軟體開發領域的一些引數習慣用語：

1. 過程和工具層面的分離與互動。
2. 全面文件層面的工作軟體。
3. 合約商議層面的客戶協作。
4. 根據計劃相應變化。

這就是四個值得定義，他們看起來非常的簡單明瞭。但是它引發的誤解比任何一個詞引發的誤解都要多。這是為什麼呢？我認為有三個原因。

首先，人們將 "敏捷" 一詞理解為普通的用法。當我們談到敏捷開發時，聽眾聽到 "敏捷" 一詞，正如我在介紹中提到的，會慣性的理解為我們在談論一個很快速移動和變化的事物。當然，我們的軟體專案變化是很快，但並不是所有的都是這種情況。如果在 Snowbird 大會上與會者沒有事先定義描述軟體開發過程的詞彙，那麼同樣的問題也會發生。在當時，有很多人使用 輕量級 一詞來將其和重量級過程區分，這些過程是由大型軟體開發顧問公司強加給他們的。

其次，即使人們意識到敏捷一詞的背後可能有其他含義，他們也會按照自己的想法來定義它。他們或許之前閱讀過關於敏捷開發的書籍和文章，並嘗試過使用這些方法來使他們的專案更加敏捷（根據他們自己的定義）。不幸的是，人們試圖扭曲敏捷一詞的含義，這些人中甚至包括一些專家和接觸敏捷一段時間的人群。您所要做的就是參加一個敏捷討論會，這樣您就會明白我說的意思了。很多人都將敏捷概括為一種藝術："我看到它就會理解它，"或者是"它是一個非常個性化的定義。" 在去年的敏捷大會上，一些人說他們已經實現了"成熟的" 敏捷。當我問到他們這意味著什麼的時候，他們的定義是，他們正在做單元測試和持續的整合。這些實踐雖然可以用來支援四個值，但是它們本身並不是敏捷。

最後的理由來自於這些值的宣告。很多人都會考慮這些值是如何規定的，但是許多人只是瞭解一下它們是怎樣劃分的。例如，"全面文件化"和"工作軟體"相對立嗎？這些值好像暗示了這種可能，但是這兩個方面是對立的，但是實際上並不存在合理的理由。因此我們擁有的四對值，每一個都被 Agile Manifesto 創造者放置在了和其他四個相對立的位置。我的目的並不是爭論選擇的正確性，而是簡單的說明您只有在接受了成對值，並評價每一對中的第一個和第二個值。如果您決定了全面文件化比單獨和互動更加合適，那麼我可以嚴肅的告訴您，您沒有使用比較的方式來談論 敏捷。這就是我們在談論敏捷時容易產生混亂的第三個原因。我們很多人都不同意初始化配對。

一個科學的方法

接觸一個學科的最好的方法，不管它是新的或者已經很好的制定的科目，我們都應該從定義開始，然後是嚴格的分析與質問，看它能引導我們做什麼。讓我們對敏捷這麼做吧。

如果我們把 Agile Manifesto 作為資源文件，那麼我們可以確定所有的組織或者專案都希望敏捷必須能夠顯示四個值中標識為第一位的特性（例如"客戶協作"），要比標識為第二位的特性（"合約商議"）更能夠評估它。Alistair Cockburn 曾經告訴我，敏捷是宇宙中16個可能存在的位置中的一個。他的意思是如果您考慮每一對值，您就擁有評估第一個和第二個值的選擇。這是一個二擇其一的問題。因為現在有四對值，所以有16種配置的可能性。我想這是理解敏捷的最簡單，最清晰的方式。這就避免了我們試圖區分敏捷的程度而產生的問題。使用 Cockburn 的描述，我們可以決定組織或者專案是否是敏捷的。如果組織具備這些評估數值，並按照執行方法應用它們，那麼它就是敏捷的。如果不是則相反。

我們還可以從相反的觀點來了解敏捷，這種思想是 Jeff Foxworthy 提出的。 ⁵ 如果您儘可能多或者超過使用單獨互動這個值所規定的過程和工具，那麼您也不是敏捷的。如果您評估的結果是完全文件化過多或者超過工作軟體，那麼您就不是敏捷的。如果您評估的結果是合約商議過多或者超過客戶協作，那麼您就不是敏捷的。如果您的評估的結果是計劃過多或者超過相應變化，那麼您就不是敏捷的。

上面的措辭中需要強調的是您不需要更多的評價非敏捷的特性。相對於敏捷來說，您最好儘量少的評價它們。如果您是一名專案的系統工程師，我猜想您的評估更多的是考慮到您的計劃，而不是響應改變。您會涉及到硬體和軟體問題，並且需要努力的將它們根據時間表整合起來。相對於硬體來說，改變軟體更加的容易。

因此，如果我說我們不需要敏捷，那麼我相信敏捷團體會嚴厲的抨擊我。我們選擇敏捷，是因為它對我們的專案和組織有重要的意義，而不是它本身有什麼意義。當您和敏捷團體的成員對話時，他們都很明白這個道理並且在這一點上有共識。但是，像能夠看到光，並想要分享它的福音傳道者一樣，他們強烈的熱誠可能會壓制您的想法。

您擁有確定的價值，並將這些價值轉化為實踐。宣言的作者為想要遵循敏捷的人提供了一系列原則。 ⁶ 如果您按照這些原則進行您的工作，那麼您就是一個敏捷執行者。

文章的剩餘部分將會介紹您使用敏捷和敏捷的一些定義。敏捷是按照 Agile Manifesto 大會上的定義，以及一系列相應的原則定義的。

哪裡出了問題？

我剛提到的定義非常簡單。在組織和專案是否是敏捷這個問題上面，為什麼還存在著這麼多混亂和衝突的意見？部分的問題是由於原則的制定方式引起的，它為這些實踐留出瞭解釋和執行的空間。讓我們看看一對問題。

我們的原則規定"根據個別的動機構建專案。為它們提供環境和所需的支援，並信任它們能夠完成任務。"您如何執行這個實踐？首先，您需要知道什麼是一個個別的動機？一些人是出於簡單的商業利潤動機。另外一些人的動機來自於龐大的團隊。一個團隊的個別動機可能會干擾到另一個團隊的動機。當您擁有一個組織事先挑選的人才時，您可能不需要適合您的專案小組定義的動機的個人。您還能繼續敏捷麼？

另一個原則規定 "敏捷過程促進開發的維持。專案出資方、開發人員和使用者應該可以長期的維持一種不變得步調。"很明顯的，如果我們將標誌杆設低，並少做工作，這也是我們能夠長期維持的一種步調。還有一點也很明確，就是意圖不一定就在原則之後。

我們可能單獨的採用大部分原則，並將它歪曲為背離敏捷的精神。當完成整個工作時，它們確實會相互支援。但是仍然存在很多執行原則的空間。這為敏捷訓練，顧問、方法學家和其他想要幫助組織成為敏捷和提供顧問的敏捷組織提供了有利的市場。它同時還促成很多組織採用新的實踐，並宣告他們已經根據方法學家的解釋獲得了敏捷。

獲得一個敏捷的解釋很容易。達到一個有效的解釋程度卻非常難。沒有聖賢準確的告訴我們的專案或者組織是否是敏捷的。您必須要問的問題就是，這很重要嗎？如果有效的生產出符合投資人所有需求的軟體，那麼您就非常的成功。您應該不斷改進，但是您真的需要適應所以得需求嗎？這是在您試圖使用 CMM 和 CMMI、RUP 和其他方法學時會遇到的問題。個人和組織會"被鑑定"處於哪個層級，而不是簡單的集中在最後的目標身上——軟體的交付使用。方法學和實踐意味著它們不是結束。

好的，如果它就是這麼簡單的話...

在2006年明尼阿波利斯舉行的敏捷大會上出現了一個問題："如果敏捷這麼簡單的話，那為什麼會有這麼多的教科書教我們應該怎樣去做？"當然這種說法有些開玩笑的意味，但是確實存在這樣的問題。坐在學校的辦公室裡，我幾乎有一整個書架的關於敏捷的書籍。至少有30本。另外我的家裡還有10幾本這樣的書。關於敏捷的書籍太多了，為什麼會有這麼多種類的書呢？

對於這個問題最簡單的回答就是，書籍可以讓那些顧問們更好的推銷自己。書籍同樣可以讓那些理論學習者和從業者更好的擴充套件他們的視野。書籍可以在藝術級和實踐級別上都給人以影響。不論何時當有新的觀念被發現時，書籍，期刊論文和各種文章將會很自然地釋出訊息。那些具有很大影響力的觀念一般會在討論會上面形成。關於技術方面的話題是那些書刊所要報導的重點，因為，正如我在文章的開始所提到的，對於那些整天投身於 IT 行業——不斷變更的專案，最終期限的到來，控制在預算之內，所有這些需要滿足客戶需求的事情——的人來說，隨時關注能夠幫助他們完成任務的最新方法，沒有這些商品和幫助的指導是不可能的。

第二種解釋就是，很多作者都在他們出版的書中宣告自己有了關於某個熱點話題的一種新方法。這就導致幾乎每一本書都宣稱自己介紹了一些作者關於價值和原則的新的有趣的想法。其中很多書重複的介紹了執行原則和價值的一種方法。比如一些自助書籍，它們聲稱只要按照他們的程式做，您就會成為敏捷的。如果您曾經嘗試過不同的飲食習慣，娛樂節目，閱讀改程式序等等，那麼您應該很清楚的知道，有些事情對於一個人來說很成功，但是對於另一個人來說可能沒有任何效果。同樣的道理在敏捷方面的書籍上面也適用。一種方法在專案 A 上適用，但是到了專案 B 上可能會慘敗。每一個專案和組織都要找到適合它們自己的那個敏捷，當然前提是您的專案和組織適合使用敏捷。

無處不在的敏捷

敏捷現在可以說無處不在。它不僅存在於軟體開發領域。如果一個實踐值得我們花時間和努力去學習和應用，那麼它就是敏捷的。如果一個工具值得在我們的專案上學習和使用，那麼它必須支援敏捷。這不僅是滿足實際需要的問題，更是一個市場營銷問題。敏捷就像一個新品牌的運動鞋，我們買來是想讓它幫助我們的開發小組跳得更高，跑得更快。

有一天我在一個書店中挑選了一本關於 Ruby 程式設計的書籍。在這本書的封底上印著："Ruby　是一種敏捷的物件導向程式設計語言。"雖然他們沒有將敏捷一詞的字母 'a' 大寫，但是我並不確定普通的讀者是否能夠意識到這個問題。Ruby 真的是 Agile Manifesto 上包含的價值嗎？這顯然是一個荒謬的問題。但是我們現在談論的是市場問題，邏輯上的問題並不是最重要的事情。使用 "敏捷" 一詞去吸引客戶的注意力，讓您可以進入門檻。（我真希望有一天我們的顧客也能夠變得聰明起來，他們可以提出正確的問題，並重視敏捷。）

我並不反對敏捷。但我也不是一個敏捷主義者。我希望被認為是一個實用主義者，我只使用那些可以幫我的東西，忽略那些對我沒有用處的東西。有時候敏捷可以在工作上幫助我。但有時候我需要一些其他的幫助。

關於敏捷的書籍和方法學

在文章的後半部分我將簡要的介紹一些關於敏捷的書籍，這些書籍我認為很重要。我會向您解釋為什麼說我給您提供的每一本書都很重要。我會站在很高的視角列出這些書籍——它們的內容主要都是關於敏捷的價值和原則。之後我會詳細的列出方法學和實踐的內容。

關於敏捷價值和原則的書籍

Agile Software Development：Cooperative Game，2ed.，Alistair Cockburn，Addison-Wesley Professional，2006，ISBN 0321482751。

作者是 Alistair Cockburn。這本書是從敏捷思想的原創者之一的視角，給了我們一個關於敏捷的最好的描述。文章寫得非常清晰和均衡。Cockburn 描述了敏捷並把它放在了光譜值的其他位置。他老練的指出了 sweet spot 作為敏捷方法，以及為什麼使用它以及您能從中獲得的好處。

Cockburn 的處理方法並不是一種技術上的方法。他並沒有涉及程式碼的編寫以及更多的細節問題，而是給您了充足的材料讓您理解敏捷。Cockburn 是由於他致力於人與人之間關係在軟體開發領域的研究，並花費了大量的時間討論了敏捷受人的影響等問題而被人所熟知。如果您對於敏捷軟體開發一無所知，那麼這本書非常的適合您。

Agile & Iterative Software Development A Manager's Guide，Craig Larman，Addison-Wesley，2004，ISBN 0131111558。

Craig Larman 是一名軟體開發領域的大師，尤其在物件導向的實踐領域。他精通不同的方法學，並且知道怎樣以及何時需要使用它們。在這本書中，Larman 涉及到了迭代方法，Scrum、XP、RUP 和 Evo. Scrum 以及敏捷部分涉及的 XP，還有更多偏重於傳統的（計劃驅動的）迭代方法 RUP 和 Evo。Larman 比較和對比了不同的方法學，幫助讀者評價它們之間的好壞，以及哪種型別的過程最適合特定型別的專案和組織。

方法學之間的對照出現在本書的後半部分。開始的六個章節是本卷書的精華所在。在這些章節中，Larman 以批判的眼光談論了軟體開發，敏捷度，迭代開發，並給讀者提供了使用迭代開發和敏捷方法的證據。這些證據來自於研究，實踐經歷或者其他資源。Larman 在這本書中表現的非常的敬業。

Balancing Agility and Discipline A Guide for the Perplexed，Barry Boehm 和 Richard Turner，Addison-Wesley，2004，ISBN 0321186125。

這本書適合那些來自於大組織和專案的經理，或者在軟體工程（不是軟體開發）領域有很堅實知識背景的人員閱讀。 ⁷ Boehm 和 Turner 是擁有大型專案經驗（其中大部分是國防部的專案）的理論家。他們通過介紹每一種方法學最適合應用的領域型別來切入主題—— sweet spots。Boehm 最為人所知的成就是專案評估中的 COCOMO 模型的開發，並且發表過很多有啟發作用的軟體工程領域的論文，其中包括介紹迭代開發的文章。 ⁸

我最擔心的關於這本書的問題，就是我不確定 Boehm 和 Turner 是否在我經常研究型別的專案中有工作經驗。其中一人只寫過不到 100K 行的程式碼。他們主要的研究方向是那些使用傳統軟體工程學方法的超大型專案。但是這並不妨礙您閱讀這本書，因為它從一個不同於我所列出的其他書籍的視角，談論了敏捷的應用。

關於敏捷方法學的書籍

Agile Software Development with Scrum，Ken Schwaber 和 Mike Beedle，Prentice Hall，2001，ISBN 0130676349。

Scrum 在過去的幾年中獲得了廣泛的關注。它是專案管理的一種簡單的方法，並且和軟體開發有鬆弛連線關係。對於大部分情況來說，Scrum 由一些成熟的實踐構成，但是執行起來非常嚴格。Scrum 的支持者聲稱它適用於所有規模的軟體開發專案。這裡沒有任何我可以參考的技術實踐來證明這個方法學。它們都是關於專案的管理。

這本書使用 Scrum 方法創造人 Schwaber 和 Beedle 的話描述了 Scrum 的方法學。使用 Scrum 非常愉快的一件事就是它的實踐可以和大部分其他實踐相結合。如果您想要了解敏捷專案如何處理專案管理方面的問題，那麼這本書很適合您閱讀。

Extreme Programming Explained：Embrace Change，2ed.，Kent Beck 和 Cynthia Andres，Addison-Wesley Professional，2004，ISBN 0321278658。

在這本書的第一版中，包含更多關於進行敏捷活動的效果。實際上，很多從業人員開始將 Extreme Programming (XP) 和敏捷放在同等重要的地位。對於軟體開發人員來說，XP 這種方法學能夠更多的吸引他們的注意力。Beck 以及她的助手 Andres 合著的第二版書中，描述了他在軟體開發者之間使用最多的敏捷方法學的基礎實踐。我提到它是最多被使用的，因為只有很少的組織真正實際的將實踐應用到他們的環境中，但是他們往往自稱使用 XP。

這本書的第二版要比第一版厚了很多，其中新增了很多我認為有用處的內容。第二版中加入了很多關於基本 XP 方法學的策略和更改材料。如果您對於敏捷方法很陌生，那麼我建議您最好先看第一版的書籍，對 XP 有一個大體的瞭解。

Extreme Programming Installed，Ron Jeffries，Ann Anderson 和 Chet Hendrickson，Addison-Wesley Professional，2000，ISBN 0201708426。

這是我推薦的眾多與 XP 相關的書籍中的第二卷，它的出版方是 Addison-Wesley。這本書很值得我們去讀，因為它描述了 XP 實踐以及它是如何被最初眾多的 XP 專案小組使用的。 ⁹ 這本書的可讀性非常強，您會從中感覺到在專案中使用 XP 是一件非常愉快的事情。這本書所有介紹的 XP 實踐應用程式，都不是我會選擇從事的專案型別。這本書幫助我確定了有一些很好的實踐我應該去學習。即使 XP 不斷的在進化，但是這本書還是非常適合那些沒有經驗，從未進行過 XP 開發的小組人員去閱讀。

關於實踐細節的書籍

Test Driven Development：A Practical Guide，David Astels，Prentice Hall Ptr，2003，ISBN 0131016490。

我相信測試驅動的開發 (TDD) 是敏捷活動中最為重要的一種實踐。它關心的重點是開發人員的質量以及責任的質量。它需要我們在開發的整個週期中都關注產品的質量，而忽略我們所使用的方法學。這是一本介紹 TDD 的好書。它使我領略到了簡單的測試所帶來的強大效果。

Pragmatic Unit Testing in Java with JUnit，Andrew Hunt 和 David Thomas，The Pragmatic Programmers，LLC，2003，ISBN 0974514012。

這本書介紹了大量的實踐，補充了之前那本書關於如何真正執行 TDD 實踐。Pragmatic Programmers 出版了一系列很好的書籍，它們針對軟體開發人員講解最新的技術。這本書是他們的早期作品之一，它是每一個想要很好的編寫單元測試用例的 Java 程式設計師的必讀書籍。它用 TDD 的替換掉了單元測試的內容，並給了讀者所有需要編寫，管理和自動操作單元測試的工具。

User Stories Applied，Mike Cohn，Addison-Wesley Professional，2004，ISBN 0321205685。

使用者的經歷往往是很多敏捷專案的需求規範的傳達手段；雖然還存在很多其它方法，例如用例等。使用者的經歷只是功能性需求的一小部分，它被客戶寫在一張索引卡片上面。這僅僅是 XP 和其他敏捷方法中的一小部分。像編寫用例，編寫使用者經歷都是一種需要學習和實踐的能力。Mike Cohn 為我們提供了我所見過的編寫使用者經歷的最好的介紹。他的書偏重於使用者經歷，而 Alistair Cockburn 的書更偏重於用例。 ¹⁰ 如果您經常使用用例，但是還沒有閱讀過 Cockburn 的書，那麼 Cohn 將會給您關於如何在您的專案中編寫和應用使用者經歷的完整的教學指南。他為您提供了很多例子，並且他在真實專案中的經驗也會給您提供很大的幫助。如果您是一個對使用者經歷有興趣的分析員，那麼這本書再適合您不過了。

Planning Extreme Programming，Kent Beck and Martin Fowler，Addison-Wesley Professional，2000，ISBN 0210710919。

XP 專案另一個關鍵實踐就是 planning game。這是一系列非常簡單的活動，它能幫助客戶和小組人員決定在每一個迭代過程中應該做什麼，如何評估效果，以及如何追蹤結果，好讓您更好的做評估。Beck 和 Fowler 描述實踐的方法能夠很好的吸引開發人員，經歷和所有 XP 小組的成員。

其它相關書籍

雖然下面的兩本書不屬於上面所列書籍的種類，但是我認為這兩本書都很有用處。我用下面的第二本書作為我一年兩次的軟體工程課程的教科書。

Agile Software Development Principles，Patterns，和 Practices，Robert C. Martin，Prentice Hall，2002，ISBN 0135974445。

這是開發人員的開發人員寫的一本開發人員的書籍。Bob Martin 是一名高階開發人員，他在物件導向和敏捷原則領域有很深的造詣。在這本書中，Uncle Bob 給我們介紹了這兩個概念，並且帶我們瞭解物件導向設計原則，以及如何在敏捷專案中使用它們。這是每一個開發人員都應該瞭解的內容。

Extreme Software Engineering：A Hands-On Approach，Daniel H. Steinberg 和 Daniel W. Palmer，Prentice Hall，2003，ISBN 013047812。

這是一本小冊的書籍，它公正的談論了敏捷專案，尤其是 XP。它並不是教條的方法，這本書中介紹了敏捷既不是偶然出現的軟體開發方法，也不是按照任何舊方式執行的方法。我認為這本書很適合我的學生去讀，讓我有更多的時間強調我認為重要的軟體開發方面。這本書很適合您在週末去閱讀它。

結論

敏捷無處不在。如果您忽視它，那麼您會失去很多現今熱門的技術話題。學習它，您將會在今後的工作中更加智慧的作出決定。同時您還可以理解很多其他的實踐和方法學。如果您是某個層級技術的經理，那麼學習它是您的職責，也是您賴以生存的必需品。

我強烈建議您開始閱讀我上面所列的書籍，還有一些其它書籍，例如 Mary Poppendieck （瘦開發），Scott Ambler （資料庫），Jim Highsmith （管理實踐），以及其他直接投身於敏捷活動或者已經開發出，並且被敏捷小組和專案"執行良好"的原則和實踐。我希望您能夠通過學習獲得一些對於您的團隊，專案和組織有用的資訊。毋庸置疑，您會發現很多可能誤導您的書籍——並不是因為它們的內容是錯誤的，而只是它們不是您所需要的。成為一名見多識廣的客戶，會增加您在團隊中的價值。

關於作者

		Gary Pollice 是伍斯特市伍斯特工學院的一名實踐教授、文學碩士。他講授軟體工程、設計、測試以及其它電腦科學的課程，同時也指導學生設計。在進入學術界之前，他有35年多的開發各種軟體的經驗，從商業應用到編譯器和工具。他的最後一份工作是在 IBM Rational 軟體，他是有名的“ RUP 倔老頭”，同時也是最早的 Rational Suite 團隊的成員之一。 他是 小團隊開發軟體：一種以 RUP 為核心的方法 的主要作者，該書由 Addison-Wesley 在 2004 年出版。他在數學方面取得了學士學位，在電腦科學領域取得理科碩士學位。

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