|
自從2001年開始，“敏捷”一詞在軟件開發(fā)領(lǐng)域已經(jīng)被賦予了一種新的意義。您真的明白敏捷一詞的含義嗎？這篇文章是由一名敏捷實踐參與者所撰寫。文章討論了如今越來越重要的迭代和增量開發(fā)風格的基礎(chǔ)方面，并用以文學評論的方式作了總結(jié)。 在 Princess Bride 這部電影中，Dread Pirate Roberts 正在攀爬 Vizzini 將要剪斷的一條繩索。當 Roberts 并沒有掉下來的 時候，Vizzini 說了一句"他沒有掉下來？難以置信！" Inigo Montoya 回答道，"你經(jīng)常使用的那個詞，我并不認為他是你所認為的那個意思。" 當我和別人談?wù)撁艚菀辉~的含義時，我的感覺和上面場景中 Montoya 的一樣。我常常認為我們說的是同一件事。但是這不意味著我是正確的，他們是錯誤的。這只能說明敏捷一詞的含義非常混亂。 軟件行業(yè)中的人們有一個習慣，就是喜歡制造他們想要表達意思的詞語，特別是在新技術(shù)領(lǐng)域。為了讓這個新技術(shù)更易理解：我們的技術(shù)變化的太快，很多新的術(shù)語和簡稱幾乎天天都會出現(xiàn)，我們很難跟上這個速度，因此我們試圖對這些新術(shù)語產(chǎn)生麻痹的態(tài)度，并且希望我們更加的正確。 雖然敏捷一詞已經(jīng)出現(xiàn)很久了，但是仍然存在很多術(shù)語的濫用問題。 這個月，我將要公布一份關(guān)于敏捷前景的調(diào)查。我們首先要給這個術(shù)語做個定義。這并不是一件容易的事情。實際上，我并不確定能夠勝任這項工作，不過我會努力的。首先，讓我們從定義開始，來看看人們是如何曲解敏捷的意思。在我們達成定義的共識后，我會回顧一些有用的書籍和參考資料，他們能夠為敏捷的前景指明方向。 最開始... 在2001年2月以前，"敏捷"一詞意味著"標記快速的優(yōu)雅的移動的能力"，或者是"擁有快速的機敏和適應(yīng)能力的角色。" 從2001年開始，這個詞對于軟件開發(fā)人員來說擁有了更多的意義。由17個人組成的一組自稱為無政府組織的團體出現(xiàn)了， 但他們實際上主要由軟件開發(fā)領(lǐng)域的軟件顧問和思想的領(lǐng)導人構(gòu)成， 他們聚集在 Snowbird Utah 來定義敏捷的軟件開發(fā)過程。雖然他們能在普通層面上對敏捷的理解達成一致，但是每一個與會者都有自己對于如何建立一個高質(zhì)量軟件的看法。 這種普通層面上的一致是在 Snowbird 舉行的 Agile Manifesto 大會上面達成的。 我在之前已經(jīng)討論過這個宣言了，但是在這里我們?nèi)匀恢档弥貜瓦@四個條對于敏捷價值觀的定義： 個體與交互 重于 過程和工具
這四個條對于敏捷價值觀的定義看起來非常的簡單明了。但是它引發(fā)的誤解比任何一個詞引發(fā)的誤解都要多。這是為什么呢？我認為有三個原因。 首先，人們將 "敏捷" 一詞理解為普通的用法。當我們談到敏捷開發(fā)時，聽眾聽到 "敏捷" 一詞，正如我在介紹中提到的，會慣性的理解為我們在談?wù)撘粋€很快速移動和變化的事物。當然，我們的軟件項目變化是很快，但并不是所有的都是這種情況。如果在 Snowbird 大會上與會者沒有事先定義描述軟件開發(fā)過程的詞匯，那么同樣的問題也會發(fā)生。在當時，有很多人使用 輕量級 一詞來將其和重量級過程區(qū)分，這些過程是由大型軟件開發(fā)顧問公司強加給他們的。 其次，即使人們意識到敏捷一詞的背后可能有其他含義，他們也會按照自己的想法來定義它。他們或許之前閱讀過關(guān)于敏捷開發(fā)的書籍和文章，并嘗試過使用這些方法來使他們的項目更加敏捷（根據(jù)他們自己的定義）。不幸的是，人們試圖扭曲敏捷一詞的含義，這些人中甚至包括一些專家和接觸敏捷一段時間的人群。您所要做的就是參加一個敏捷討論會，這樣您就會明白我說的意思了。很多人都將敏捷概括為一種藝術(shù)："我看到它就會理解它，"或者是"它是一個非常個性化的定義。" 在去年的敏捷大會上，一些人說他們已經(jīng)實現(xiàn)了"成熟的" 敏捷。當我問到他們這意味著什么的時候，他們的定義是，他們正在做單元測試和持續(xù)的集成。這些實踐雖然可以用來支持四個值，但是它們本身并不是敏捷。 最后的理由來自于這些值的聲明。很多人都會考慮這些值是如何規(guī)定的，但是許多人只是了解一下它們是怎樣劃分的。例如，"全面的文檔"和"工作的軟件"相對立嗎？這些值好像暗示了這種可能，但是這兩個方面是對立的，但是實際上并不存在合理的理由。因此我們擁有的四對值，每一個都被 Agile Manifesto 創(chuàng)造者放置在了和其他四個相對立的位置。我的目的并不是爭論選擇的正確性，而是簡單的說明您只有在接受了成對值，并評價每一對中的第一個和第二個值。如果您決定了全面的文檔化比單獨和交互更加合適，那么我可以嚴肅的告訴您，您沒有使用比較的方式來談?wù)?/span> 敏捷。這就是我們在談?wù)撁艚輹r容易產(chǎn)生混亂的第三個原因。我們很多人都不同意初始化配對。 一個科學的方法 接觸一個學科的最好的方法，不管它是新的或者已經(jīng)很好的制定的科目，我們都應(yīng)該從定義開始，然后是嚴格的分析與質(zhì)問，看它能引導我們做什么。讓我們對敏捷這么做吧。 如果我們把 Agile Manifesto 作為資源文檔，那么我們可以確定所有的組織或者項目都希望敏捷必須能夠顯示四個值中標識為第一位的特性（例如"客戶協(xié)作"），要比標識為第二位的特性（"合約商議"）更能夠評估它。Alistair Cockburn 曾經(jīng)告訴我，敏捷是宇宙中16個可能存在的位置中的一個。他的意思是如果您考慮每一對值，您就擁有評估第一個和第二個值的選擇。這是一個二擇其一的問題。因為現(xiàn)在有四對值，所以有16種配置的可能性。我想這是理解敏捷的最簡單，最清晰的方式。這就避免了我們試圖區(qū)分敏捷的程度而產(chǎn)生的問題。使用 Cockburn 的描述，我們可以決定組織或者項目是否是敏捷的。如果組織具備這些評估數(shù)值，并按照執(zhí)行方法應(yīng)用它們，那么它就是敏捷的。如果不是則相反。 我們還可以從相反的觀點來了解敏捷，這種思想是 Jeff Foxworthy 提出的。 5 如果您盡可能多或者超過使用單獨交互這個值所規(guī)定的過程和工具，那么您也不是敏捷的。如果您評估的結(jié)果是完全文檔化過多或者超過工作軟件，那么您就不是敏捷的。如果您評估的結(jié)果是合約商議過多或者超過客戶協(xié)作，那么您就不是敏捷的。如果您的評估的結(jié)果是計劃過多或者超過相應(yīng)變化，那么您就不是敏捷的。 上面的措辭中需要強調(diào)的是您不需要更多的評價非敏捷的特性。相對于敏捷來說，您最好盡量少的評價它們。如果您是一名項目的系統(tǒng)工程師，我猜想您的評估更多的是考慮到您的計劃，而不是響應(yīng)改變。您會涉及到硬件和軟件問題，并且需要努力的將它們根據(jù)時間表整合起來。相對于硬件來說，改變軟件更加的容易。 因此，如果我說我們不需要敏捷，那么我相信敏捷團體會嚴厲的抨擊我。我們選擇敏捷，是因為它對我們的項目和組織有重要的意義，而不是它本身有什么意義。當您和敏捷團體的成員對話時，他們都很明白這個道理并且在這一點上有共識。但是，像能夠看到光，并想要分享它的福音傳道者一樣，他們強烈的熱誠可能會壓制您的想法。 您擁有確定的價值，并將這些價值轉(zhuǎn)化為實踐。宣言的作者為想要遵循敏捷的人提供了一系列原則。 6 如果您按照這些原則進行您的工作，那么您就是一個敏捷執(zhí)行者。 文章的剩余部分將會介紹您使用敏捷和敏捷的一些定義。敏捷是按照 Agile Manifesto 大會上的定義，以及一系列相應(yīng)的原則定義的。 哪里出了問題？ 我剛提到的定義非常簡單。在組織和項目是否是敏捷這個問題上面，為什么還存在著這么多混亂和沖突的意見？部分的問題是由于原則的制定方式引起的，它為這些實踐留出了解釋和執(zhí)行的空間。讓我們看看一對問題。 我們的原則規(guī)定"根據(jù)個別的動機構(gòu)建項目。為它們提供環(huán)境和所需的支持，并信任它們能夠完成任務(wù)。"您如何執(zhí)行這個實踐？首先，您需要知道什么是一個個別的動機？一些人是出于簡單的商業(yè)利潤動機。另外一些人的動機來自于龐大的團隊。一個團隊的個別動機可能會干擾到另一個團隊的動機。當您擁有一個組織事先挑選的人才時，您可能不需要適合您的項目小組定義的動機的個人。您還能繼續(xù)敏捷么？ 另一個原則規(guī)定 "敏捷過程促進開發(fā)的維持。項目出資方、開發(fā)人員和用戶應(yīng)該可以長期的維持一種不變得步調(diào)。"很明顯的，如果我們將標志桿設(shè)低，并少做工作，這也是我們能夠長期維持的一種步調(diào)。還有一點也很明確，就是意圖不一定就在原則之后。 我們可能單獨的采用大部分原則，并將它歪曲為背離敏捷的精神。當完成整個工作時，它們確實會相互支持。但是仍然存在很多執(zhí)行原則的空間。這為敏捷訓練，顧問、方法學家和其他想要幫助組織成為敏捷和提供顧問的敏捷組織提供了有利的市場。它同時還促成很多組織采用新的實踐，并聲明他們已經(jīng)根據(jù)方法學家的解釋獲得了敏捷。 獲得一個敏捷的解釋很容易。達到一個有效的解釋程度卻非常難。沒有圣賢準確的告訴我們的項目或者組織是否是敏捷的。您必須要問的問題就是，這很重要嗎？如果有效的生產(chǎn)出符合投資人所有需求的軟件，那么您就非常的成功。您應(yīng)該不斷改進，但是您真的需要適應(yīng)所以得需求嗎？這是在您試圖使用 CMM 和 CMMI、RUP 和其他方法學時會遇到的問題。個人和組織會"被鑒定"處于哪個層級，而不是簡單的集中在最后的目標身上——軟件的交付使用。方法學和實踐意味著它們不是結(jié)束。 好的，如果它就是這么簡單的話... 在2006年明尼阿波利斯舉行的敏捷大會上出現(xiàn)了一個問題："如果敏捷這么簡單的話，那為什么會有這么多的教科書教我們應(yīng)該怎樣去做？"當然這種說法有些開玩笑的意味，但是確實存在這樣的問題。坐在學校的辦公室里，我?guī)缀跤幸徽麄€書架的關(guān)于敏捷的書籍。至少有30本。另外我的家里還有10幾本這樣的書。關(guān)于敏捷的書籍太多了，為什么會有這么多種類的書呢？ 對于這個問題最簡單的回答就是，書籍可以讓那些顧問們更好的推銷自己。書籍同樣可以讓那些理論學習者和從業(yè)者更好的擴展他們的視野。書籍可以在藝術(shù)級和實踐級別上都給人以影響。不論何時當有新的觀念被發(fā)現(xiàn)時，書籍，期刊論文和各種文章將會很自然地發(fā)布消息。那些具有很大影響力的觀念一般會在討論會上面形成。關(guān)于技術(shù)方面的話題是那些書刊所要報道的重點，因為，正如我在文章的開始所提到的，對于那些整天投身于 IT 行業(yè)——不斷變更的項目，最終期限的到來，控制在預算之內(nèi)，所有這些需要滿足客戶需求的事情——的人來說，隨時關(guān)注能夠幫助他們完成任務(wù)的最新方法，沒有這些商品和幫助的指導是不可能的。 第二種解釋就是，很多作者都在他們出版的書中聲明自己有了關(guān)于某個熱點話題的一種新方法。這就導致幾乎每一本書都宣稱自己介紹了一些作者關(guān)于價值和原則的新的有趣的想法。其中很多書重復的介紹了執(zhí)行原則和價值的一種方法。比如一些自助書籍，它們聲稱只要按照他們的程序做，您就會成為敏捷的。如果您曾經(jīng)嘗試過不同的飲食習慣，娛樂節(jié)目，閱讀改進程序等等，那么您應(yīng)該很清楚的知道，有些事情對于一個人來說很成功，但是對于另一個人來說可能沒有任何效果。同樣的道理在敏捷方面的書籍上面也適用。一種方法在項目 A 上適用，但是到了項目 B 上可能會慘敗。每一個項目和組織都要找到適合它們自己的那個敏捷，當然前提是您的項目和組織適合使用敏捷。 無處不在的敏捷 敏捷現(xiàn)在可以說無處不在。它不僅存在于軟件開發(fā)領(lǐng)域。如果一個實踐值得我們花時間和努力去學習和應(yīng)用，那么它就是敏捷的。如果一個工具值得在我們的項目上學習和使用，那么它必須支持敏捷。這不僅是滿足實際需要的問題，更是一個市場營銷問題。敏捷就像一個新品牌的運動鞋，我們買來是想讓它幫助我們的開發(fā)小組跳得更高，跑得更快。 有一天我在一個書店中挑選了一本關(guān)于 Ruby 程序設(shè)計的書籍。在這本書的封底上印著："Ruby 是一種敏捷的面向?qū)ο蟪绦蛟O(shè)計語言。"雖然他們沒有將敏捷一詞的字母 'a' 大寫，但是我并不確定普通的讀者是否能夠意識到這個問題。Ruby 真的是 Agile Manifesto 上包含的價值觀嗎？這顯然是一個荒謬的問題。但是我們現(xiàn)在談?wù)摰氖鞘袌鰡栴}，邏輯上的問題并不是最重要的事情。使用 "敏捷" 一詞去吸引客戶的注意力，讓您可以進入門檻。（我真希望有一天我們的顧客也能夠變得聰明起來，他們可以提出正確的問題，并重視敏捷。） 我并不反對敏捷。但我也不是一個敏捷主義者。我希望被認為是一個實用主義者，我只使用那些可以幫我的東西，忽略那些對我沒有用處的東西。有時候敏捷可以在工作上幫助我。但有時候我需要一些其他的幫助。 關(guān)于敏捷的書籍和方法學 在文章的后半部分我將簡要的介紹一些關(guān)于敏捷的書籍，這些書籍我認為很重要。我會向您解釋為什么說我給您提供的每一本書都很重要。我會站在很高的視角列出這些書籍——它們的內(nèi)容主要都是關(guān)于敏捷的價值和原則。之后我會詳細的列出方法學和實踐的內(nèi)容。 關(guān)于敏捷價值和原則的書籍 Agile Software Development：Cooperative Game，2ed.，Alistair Cockburn，Addison-Wesley Professional，2006，ISBN 0321482751。 作者是 Alistair Cockburn。這本書是從敏捷思想的原創(chuàng)者之一的視角，給了我們一個關(guān)于敏捷的最好的描述。文章寫得非常清晰和均衡。Cockburn 描述了敏捷并把它放在了光譜值的其他位置。他老練的指出了 sweet spot 作為敏捷方法，以及為什么使用它以及您能從中獲得的好處。 Cockburn 的處理方法并不是一種技術(shù)上的方法。他并沒有涉及代碼的編寫以及更多的細節(jié)問題，而是給您了充足的材料讓您理解敏捷。Cockburn 是由于他致力于人與人之間關(guān)系在軟件開發(fā)領(lǐng)域的研究，并花費了大量的時間討論了敏捷受人的影響等問題而被人所熟知。如果您對于敏捷軟件開發(fā)一無所知，那么這本書非常的適合您。 Agile & Iterative Software Development A Manager's Guide，Craig Larman，Addison-Wesley，2004，ISBN 0131111558。 Craig Larman 是一名軟件開發(fā)領(lǐng)域的大師，尤其在面向?qū)ο蟮膶嵺`領(lǐng)域。他精通不同的方法學，并且知道怎樣以及何時需要使用它們。在這本書中，Larman 涉及到了迭代方法，Scrum、XP、RUP 和 Evo. Scrum 以及敏捷部分涉及的 XP，還有更多偏重于傳統(tǒng)的（計劃驅(qū)動的）迭代方法 RUP 和 Evo。Larman 比較和對比了不同的方法學，幫助讀者評價它們之間的好壞，以及哪種類型的過程最適合特定類型的項目和組織。 方法學之間的對照出現(xiàn)在本書的后半部分。開始的六個章節(jié)是本卷書的精華所在。在這些章節(jié)中，Larman 以批判的眼光談?wù)摿塑浖_發(fā)，敏捷度，迭代開發(fā)，并給讀者提供了使用迭代開發(fā)和敏捷方法的證據(jù)。這些證據(jù)來自于研究，實踐經(jīng)歷或者其他資源。Larman 在這本書中表現(xiàn)的非常的敬業(yè)。 Balancing Agility and Discipline A Guide for the Perplexed，Barry Boehm 和 Richard Turner，Addison-Wesley，2004，ISBN 0321186125。 這本書適合那些來自于大組織和項目的經(jīng)理，或者在軟件工程（不是軟件開發(fā)）領(lǐng)域有很堅實知識背景的人員閱讀。 7 Boehm 和 Turner 是擁有大型項目經(jīng)驗（其中大部分是國防部的項目）的理論家。他們通過介紹每一種方法學最適合應(yīng)用的領(lǐng)域類型來切入主題—— sweet spots。Boehm 最為人所知的成就是項目評估中的 COCOMO 模型的開發(fā)，并且發(fā)表過很多有啟發(fā)作用的軟件工程領(lǐng)域的論文，其中包括介紹迭代開發(fā)的文章。 8 我最擔心的關(guān)于這本書的問題，就是我不確定 Boehm 和 Turner 是否在我經(jīng)常研究類型的項目中有工作經(jīng)驗。其中一人只寫過不到 100K 行的代碼。他們主要的研究方向是那些使用傳統(tǒng)軟件工程學方法的超大型項目。但是這并不妨礙您閱讀這本書，因為它從一個不同于我所列出的其他書籍的視角，談?wù)摿嗣艚莸膽?yīng)用。 關(guān)于敏捷方法學的書籍 Agile Software Development with Scrum，Ken Schwaber 和 Mike Beedle，Prentice Hall，2001，ISBN 0130676349。 Scrum 在過去的幾年中獲得了廣泛的關(guān)注。它是項目管理的一種簡單的方法，并且和軟件開發(fā)有松弛連接關(guān)系。對于大部分情況來說，Scrum 由一些成熟的實踐構(gòu)成，但是執(zhí)行起來非常嚴格。Scrum 的支持者聲稱它適用于所有規(guī)模的軟件開發(fā)項目。這里沒有任何我可以參考的技術(shù)實踐來證明這個方法學。它們都是關(guān)于項目的管理。 這本書使用 Scrum 方法創(chuàng)造人 Schwaber 和 Beedle 的話描述了 Scrum 的方法學。使用 Scrum 非常愉快的一件事就是它的實踐可以和大部分其他實踐相結(jié)合。如果您想要了解敏捷項目如何處理項目管理方面的問題，那么這本書很適合您閱讀。 Extreme Programming Explained：Embrace Change，2ed.，Kent Beck 和 Cynthia Andres，Addison-Wesley Professional，2004，ISBN 0321278658。 在這本書的第一版中，包含更多關(guān)于進行敏捷活動的效果。實際上，很多從業(yè)人員開始將 Extreme Programming (XP) 和敏捷放在同等重要的地位。對于軟件開發(fā)人員來說，XP 這種方法學能夠更多的吸引他們的注意力。Beck 以及她的助手 Andres 合著的第二版書中，描述了他在軟件開發(fā)者之間使用最多的敏捷方法學的基礎(chǔ)實踐。我提到它是最多被使用的，因為只有很少的組織真正實際的將實踐應(yīng)用到他們的環(huán)境中，但是他們往往自稱使用 XP。 這本書的第二版要比第一版厚了很多，其中添加了很多我認為有用處的內(nèi)容。第二版中加入了很多關(guān)于基本 XP 方法學的策略和更改材料。如果您對于敏捷方法很陌生，那么我建議您最好先看第一版的書籍，對 XP 有一個大體的了解。 Extreme Programming Installed，Ron Jeffries，Ann Anderson 和 Chet Hendrickson，Addison-Wesley Professional，2000，ISBN 0201708426。 這是我推薦的眾多與 XP 相關(guān)的書籍中的第二卷，它的出版方是 Addison-Wesley。這本書很值得我們?nèi)プx，因為它描述了 XP 實踐以及它是如何被最初眾多的 XP 項目小組使用的。 9 這本書的可讀性非常強，您會從中感覺到在項目中使用 XP 是一件非常愉快的事情。這本書所有介紹的 XP 實踐應(yīng)用程序，都不是我會選擇從事的項目類型。這本書幫助我確定了有一些很好的實踐我應(yīng)該去學習。即使 XP 不斷的在進化，但是這本書還是非常適合那些沒有經(jīng)驗，從未進行過 XP 開發(fā)的小組人員去閱讀。 關(guān)于實踐細節(jié)的書籍 Test Driven Development：A Practical Guide，David Astels，Prentice Hall Ptr，2003，ISBN 0131016490。 我相信測試驅(qū)動的開發(fā) (TDD) 是敏捷活動中最為重要的一種實踐。它關(guān)心的重點是開發(fā)人員的質(zhì)量以及責任的質(zhì)量。它需要我們在開發(fā)的整個周期中都關(guān)注產(chǎn)品的質(zhì)量，而忽略我們所使用的方法學。這是一本介紹 TDD 的好書。它使我領(lǐng)略到了簡單的測試所帶來的強大效果。 Pragmatic Unit Testing in Java with JUnit，Andrew Hunt 和 David Thomas，The Pragmatic Programmers，LLC，2003，ISBN 0974514012。 這本書介紹了大量的實踐，補充了之前那本書關(guān)于如何真正執(zhí)行 TDD 實踐。Pragmatic Programmers 出版了一系列很好的書籍，它們針對軟件開發(fā)人員講解最新的技術(shù)。這本書是他們的早期作品之一，它是每一個想要很好的編寫單元測試用例的 Java 程序員的必讀書籍。它用 TDD 的替換掉了單元測試的內(nèi)容，并給了讀者所有需要編寫，管理和自動操作單元測試的工具。 User Stories Applied，Mike Cohn，Addison-Wesley Professional，2004，ISBN 0321205685。 用戶的經(jīng)歷往往是很多敏捷項目的需求規(guī)范的傳達手段；雖然還存在很多其它方法，例如用例等。用戶的經(jīng)歷只是功能性需求的一小部分，它被客戶寫在一張索引卡片上面。這僅僅是 XP 和其他敏捷方法中的一小部分。像編寫用例，編寫用戶經(jīng)歷都是一種需要學習和實踐的能力。Mike Cohn 為我們提供了我所見過的編寫用戶經(jīng)歷的最好的介紹。他的書偏重于用戶經(jīng)歷，而 Alistair Cockburn 的書更偏重于用例。 10 如果您經(jīng)常使用用例，但是還沒有閱讀過 Cockburn 的書，那么 Cohn 將會給您關(guān)于如何在您的項目中編寫和應(yīng)用用戶經(jīng)歷的完整的教學指南。他為您提供了很多例子，并且他在真實項目中的經(jīng)驗也會給您提供很大的幫助。如果您是一個對用戶經(jīng)歷有興趣的分析員，那么這本書再適合您不過了。 Planning Extreme Programming，Kent Beck and Martin Fowler，Addison-Wesley Professional，2000，ISBN 0210710919。 XP 項目另一個關(guān)鍵實踐就是 planning game。這是一系列非常簡單的活動，它能幫助客戶和小組人員決定在每一個迭代過程中應(yīng)該做什么，如何評估效果，以及如何追蹤結(jié)果，好讓您更好的做評估。Beck 和 Fowler 描述實踐的方法能夠很好的吸引開發(fā)人員，經(jīng)歷和所有 XP 小組的成員。 其它相關(guān)書籍 雖然下面的兩本書不屬于上面所列書籍的種類，但是我認為這兩本書都很有用處。我用下面的第二本書作為我一年兩次的軟件工程課程的教科書。 Agile Software Development Principles，Patterns，和 Practices，Robert C. Martin，Prentice Hall，2002，ISBN 0135974445。 這是開發(fā)人員的開發(fā)人員寫的一本開發(fā)人員的書籍。Bob Martin 是一名高級開發(fā)人員，他在面向?qū)ο蠛兔艚菰瓌t領(lǐng)域有很深的造詣。在這本書中，Uncle Bob 給我們介紹了這兩個概念，并且?guī)覀兞私饷嫦驅(qū)ο笤O(shè)計原則，以及如何在敏捷項目中使用它們。這是每一個開發(fā)人員都應(yīng)該了解的內(nèi)容。 Extreme Software Engineering：A Hands-On Approach，Daniel H. Steinberg 和 Daniel W. Palmer，Prentice Hall，2003，ISBN 013047812。 這是一本小冊的書籍，它公正的談?wù)摿嗣艚蓓椖浚绕涫?/span> XP。它并不是教條的方法，這本書中介紹了敏捷既不是偶然出現(xiàn)的軟件開發(fā)方法，也不是按照任何舊方式執(zhí)行的方法。我認為這本書很適合我的學生去讀，讓我有更多的時間強調(diào)我認為重要的軟件開發(fā)方面。這本書很適合您在周末去閱讀它。 結(jié)論 敏捷無處不在。如果您忽視它，那么您會失去很多現(xiàn)今熱門的技術(shù)話題。學習它，您將會在今后的工作中更加智慧的作出決定。同時您還可以理解很多其他的實踐和方法學。如果您是某個層級技術(shù)的經(jīng)理，那么學習它是您的職責，也是您賴以生存的必需品。 我強烈建議您開始閱讀我上面所列的書籍，還有一些其它書籍，例如 Mary Poppendieck （瘦開發(fā)），Scott Ambler （數(shù)據(jù)庫），Jim Highsmith （管理實踐），以及其他直接投身于敏捷活動或者已經(jīng)開發(fā)出，并且被敏捷小組和項目"運行良好"的原則和實踐。我希望您能夠通過學習獲得一些對于您的團隊，項目和組織有用的信息。毋庸置疑，您會發(fā)現(xiàn)很多可能誤導您的書籍——并不是因為它們的內(nèi)容是錯誤的，而只是它們不是您所需要的。成為一名見多識廣的客戶，會增加您在團隊中的價值。 注釋： 1我會使用大寫字母來分辨這個詞和普通詞匯。這是敏捷團體的習慣用法。 2出自于 Merriam-Webster OnLine 字典（http://www.）。 3查看 “敏捷宣言的歷史”（History: The Agile Manifesto）。 4 《敏捷軟件開發(fā)宣言》（Manifesto for Agile Software Development）。 5 Jeff Foxworthy 是一名喜劇演員，他經(jīng)常使用：“如果您……您就是一個鄉(xiāng)下人” （美國南部的鄉(xiāng)下勞動力，通常被當作笨蛋的原型）的句式來引人發(fā)笑。 6 “敏捷開發(fā)原則”（Principles behind the Agile Manifesto）。 7察看我在 2006 年 2 月發(fā)表的專欄文章，該文講述了他們之間的區(qū)別。“教學軟件開發(fā)與軟件工程”。 8Barry Boehm，"A Spiral Model of Software Development and Enhancement"，ACM SIGSOFT Software Engineering Notes，August 1986。 9引起很多書關(guān)注的這個項目 :-) 這就是 Chrysler Comprehensive Compensation System，它開始于1995年。這是第一個將所有 XP 實踐應(yīng)用，記錄和精煉到方法學中的項目，我們后來稱其為 XP。 10 Writing Effective Use Cases，Alistair Cockburn，Addison-Wesley Professional，2000，ISBN 0201702258。如果您經(jīng)常使用用例，那么建議您去閱讀這本書。 |
|
|
來自： rookie > 《技術(shù)帖》
