版權資訊
作 者：(美國)(AlistairCockburn)庫克伯恩出版社：機械工業出版社
出版時間：2008
敏捷軟體開發ISBN:9787111231660
開本：16
定價:52.00元
又名:AgileSoftwareDevelopment:Principles,Patterns,andPractices
作者簡介
AlistairCockburn，國際知名軟體項目管理方面的專家，用例技術，對象技術和敏捷方法大師，於2001年和2002年兩次獲得jolt生產力獎。他是HumansandTechnology公司的資深顧問，負責幫助客戶成功地進行面向對象項目。他在軟硬體開發方面有20多年的項目管理經驗，所涉及的領域有保險業，零售業，電子商務公司，並曾在大公司（如挪威中心銀行和IBM）中任職。除本書外，他還著有《編寫有效用例》（本書中文版已由機械工業出版社出版）、《OO項目求生法則》和《CrystalClear：小團隊的敏捷開發方法》。內容簡介
在這本書中，享譽全球的軟體開發專家和軟體工程大師RobertC.Martin將向您展示如何解決軟體開發人員、項目經理及軟體項目領導們所面臨的最棘手的問題。這本綜合性、實用性的敏捷開發和極限編程方面的指南，是由敏捷開發的創始人之一所撰寫的。·講述在預算和實踐要求下，軟體開發人員和項目經理如何使用敏捷開發完成項目；
·使用真實案例講解如何用極限編程來設計、測試、重構和結對編程；
·包含了極具價值的可多次使用的C++和JAVA原始碼；
·重點講述了如何使用UML和設計模式解決面向客戶系統的問題。
目錄
譯者序第2版前言
第1版前言
第0章不可知和不可說
0.1和解析體驗相關的問題
0.1.1解析模式的衝突
0.1.2檢測解析模式
0.1.3思考不準確的思想
0.2溝通的不可能性
0.2.1內部重新組織
0.2.2觸及共享體驗
0.2.3管理不完美的溝通
0.3聆聽的三個層次
0.3.1三個層次和方法集
0.3.2三個層次與本書
0.3.3守-破-離
0.4那么，明天我做什麼
第0A章不可知和不可說：演進
0A.1溝通和共享的體驗
0A.2守-破-離
第1章創造和溝通的合作博弈
1.1軟體和詩歌
1.2軟體與博弈
1.2.1博弈的類型
1.2.2軟體與攀岩
1.2.3創造和溝通的博弈
1.2.4軟體與工程化
1.2.5軟體與模型構建
1.3再論合作博弈
1.3.1程式設計師成為溝通專家
1.3.2更快地博弈
1.3.3標識物和道具
1.3.4減少回報
1.3.5對於首要目標的充分度
1.3.6對於積澱的充分度
1.3.7博弈中的博弈
1.3.8開放源碼開發
1.4這對我意味著什麼
第1A章創造和溝通的合作博弈：演進
1A.1沼澤遊戲
1A.2合作中的競爭
1A.3其他領域的合作博弈
1A.4軟體工程的重建
1A.4.1這一辭彙從哪裡來
1A.4.2我們從哪裡走錯了
1A.4.3重建軟體工程
1A.4.4技藝
1A.4.5合作博弈
1A.4.6精益製造
1A.4.7重建後的軟體工程
1A.4.8其他工程化中的協作
第2章個人
2.1人是古怪的
2.1.1尋找特徵函式
2.1.2古怪性格的元素
2.1.3不可避免的多樣性
2.1.4技術的作用
2.1.5相互衝突的共同點
2.2克服失敗模式
2.2.1犯錯誤
2.2.2寧可失敗也要選擇保守
2.2.3創新而不研究
2.2.4不能始終如一的習慣動物
2.2.5使用紀律和容忍來應對
2.3以一些更好的方式工作
2.3.1具體化
2.3.2實物
2.3.3在某些東西的基礎上進行修改
2.3.4觀察和聆聽
2.3.5支持專注和溝通
2.3.6工作分配要與個性相匹配
2.3.7天賦
2.3.8獎勵要能保留樂趣
2.3.9組合獎勵
2.3.10反饋
2.4利用成功模式
2.4.1善於四處尋找
2.4.2人們學習
2.4.3可塑性
2.4.4貢獻和採取主動
2.4.5組合成功模式
2.4.6英雄也是普通人
2.5明天我該做什麼
第2A章個人：演進
2A.1策略平衡
第3章團隊的溝通與合作
3.1信息的對流
3.1.1延遲和機會損失成本
3.1.2爾格-秒
3.1.3滲透式溝通
3.1.4穿堂風
3.1.5信息輻射源
3.1.6熱空氣理論的套用
3.2跨越溝通的鴻溝
3.2.1溝通的形態
3.2.2去掉某些形態所產生的影響
3.2.3利用各種形態
3.2.4黏度與跨越空間的鴻溝
3.3團隊就是集體
3.3.1友善和衝突
3.3.2工作時間的公民意識
3.3.3敵意的XP與友善的XP
3.3.4使用勝利來建立“團隊”
3.3.5團隊文化與亞文化
3.4團隊就是生態系統
3.5我明天該做什麼
第3A章團隊：演進
3A.1一個修訂後的辦公室布局樣本
第4章方法集
4.1一個交付軟體的生態系統
4.2方法集中的概念
4.2.1結構術語
4.2.2範圍
4.2.3概念術語
4.2.4發布一個方法集
4.3方法集的設計原則
4.3.1常見設計錯誤
4.3.2在方法集上成功的項目
4.3.3與作者的相關性
4.3.4七條原則
4.4細看XP
4.4.1XP簡介
4.4.2剖析XP
4.4.3調整XP
4.5到底為什麼使用方法集
4.5.1方法集解決什麼問題
4.5.2如何評估一個方法集
4.6明天我應該做什麼
第4A章方法集：演進
4A.1方法集與策略
4A.2組織級的方法集
4A.3過程就是循環
4A.4更簡單地描述方法集
第5章敏捷與自適應
5.1輕但足夠
5.1.1剛好足夠
5.1.2對於編制文檔的建議
5.2敏捷
5.2.1最佳擊球點
5.2.2虛擬團隊的麻煩
5.3變得自適應
5.3.1不厭其煩地進行反思
5.3.2方法集成長技術
5.3.3反思研討會技術
5.4明天我該做什麼
第5A章敏捷與自適應：演進
5A.1對於寓意的誤解
5A.1.1疊代必須簡短
5A.1.2敏捷團隊必須駐紮在一起
5A.1.3敏捷團隊不需要計畫
5A.1.4架構已死；重構是你全部所需要的
5A.1.5我們不需要什麼經理
5A.1.6敏捷開發在紀律上要求很低
5A.1.7敏捷只適合最優秀的開發人員
5A.1.8敏捷是既老又新的、失敗的、沒有嘗試過的
5A.2敏捷方法集的演進
5A.2.1XP第2版
5A.2.2Scrum
5A.2.3實用主義和無名的
5A.2.4可預測、計畫驅動和其他中心調整
5A.2.5約束理論
5A.2.6精益開發
5A.3新的方法集話題
5A.3.1敏捷項目管理
5A.3.2測試
5A.3.3用戶體驗設計
5A.3.4規劃管控、Burn圖和系統工程
5A.3.5用例和用戶故事
5A.4經久不絕的問題
5A.4.1最佳擊球點和下降
5A.4.2固定價格、固定範圍的契約
5A.4.3敏捷、CMMI和ISO9001
5A.4.4何時停止建模
5A.4.5高科技/高接觸的工具箱
5A.4.6敏捷的中心
5A.4.7你有多敏捷
5A.4.8引入敏捷
5A.5軟體開發之外的敏捷
5A.5.1項目組合管理
5A.5.2客戶關係
5A.5.3契約
5A.5.4將變更引入組織
5A.5.5程式設計師讀哈佛商業周刊
5A.5.6建造房屋
5A.5.7機場建設
5A.5.8圖書出版
5A.5.9會議組織和敏捷模型的限制
第6章Crystal方法集
6.1對Crystal家族塑形
6.1.1核心Crystal元素
6.2CrystalClear
6.2.1CrystalClear的簡要描述
6.2.2CrystalClear的反思
6.3CrystalOrange
6.3.1CrystalOrange的簡要描述
6.3.2CrystalOrange的反思
6.4CrystalOrangeWeb
6.4.1CrystalOrangeWeb的簡要描述
6.4.2CrystalOrangeWeb的反思
6.5明天我該做什麼
第6A章Crystal方法集：演進
6A.1Crystal基因代碼
6A.1.1合作博弈的理念
6A.1.2方法集的重點
6A.1.3方法集設計原則
6A.1.4高度成功的項目的7個特性
6A.1.5技術與選擇
6A.1.6樣本方法集設計
6A.2CrystalClear
6A.3把CrystalClear擴展到Yellow
附錄A敏捷軟體開發宣言
附錄Aa敏捷軟體開發宣言和相互依賴聲明
附錄BNaur、Ehn、宮本武藏
附錄BaNaur、Ehn、宮本武藏：演進
附錄C後記
參考文獻
……
----------------------------------------------------
敏捷軟體開發又稱敏捷開發
是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於"非敏捷"，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。
詞源
敏捷一詞來源於2001年初美國猶他州雪鳥滑雪勝地的一次敏捷方法發起者和實踐者（他們發起組成了敏捷聯盟）的聚會。
極限編程。
價值觀
雪鳥會議共同起草了敏捷軟體開發宣言。其中最重要的部分就是對一些與會者一致同意的軟體開發價值觀的表述：
人和互動重於過程和工具。可以工作的軟體重於求全責備的文檔。客戶協作重於契約談判。隨時應對變化重於循規蹈矩。其中位於右邊的內容雖然也有其價值，但是左邊的內容最為重要。
原則
宣言中還包括以下原則：
對我們而言，最重要的是通過儘早和不斷交付有價值的軟體滿足客戶需要。我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。業務人員和開發者應該在整個項目過程中始終朝夕在一起工作。圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。在開發小組中最有效率也最有效果的信息傳達方式是面對面的交談。可以工作的軟體是進度的主要度量標準。敏捷過程提倡可持續開發。出資人、開發人員和用戶應該總是維持不變的節奏。對卓越技術與良好設計的不斷追求將有助於提高敏捷性。簡單--儘可能減少工作量的藝術至關重要。最好的架構、需求和設計都源自自我組織的團隊。每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。
對比其他的方法
敏捷方法有時候被誤認為是無計畫性和紀律性的方法，實際上更確切的說法是敏捷方法強調適應性而非預見性。
適應性的方法集中在快速適應現實的變化。當項目的需求起了變化，團隊應該迅速適應。這個團隊可能很難確切描述未來將會如何變化.
對比疊代方法
相比疊代式開發兩者都強調在較短的開發周期提交軟體，敏捷方法的周期可能更短，並且更加強調隊伍中的高度協作。
對比瀑布式開發
兩者沒有很多的共同點，瀑布模型式是最典型的預見性的方法，嚴格遵循預先計畫的需求、分析、設計、編碼、測試的步驟順序進行。步驟成果作為衡量進度的方法，例如需求規格，設計文檔，測試計畫和代碼審閱等等。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，項目早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在項目進行過程中可能變化的情況下基本是不可行的。
相對來講，敏捷方法則在幾周或者幾個月的時間內完成相對較小的功能，強調的是能將儘早將儘量小的可用的功能交付使用，並在整個項目周期中持續改善和增強。
有人可能在這樣小規模的範圍內的每次疊代中使用瀑布式方法，另外的人可能將選擇各種工作並行進行，例如
敏捷方法的適用性
在敏捷方法其獨特之處以外，他和其他的方法也有很多共同之處，比如疊代開發，關注互動溝通，減少中介過程的無謂資源消耗。通常可以在以下方面衡量敏捷方法的適用性：從產品角度看，敏捷方法適用於需求萌動並且快速改變的情況，如系統有比較高的關鍵性、可靠性、安全性方面的要求，則可能不完全適合；從組織結構的角度看，組織結構的文化、人員、溝通則決定了敏捷方法是否適用。跟這些相關聯的關鍵成功因素有：
企業文化必須支持談判人員彼此信任人少但是精幹開發人員所作決定得到認可環境設施滿足成員間快速溝通之需要最重要的因素恐怕是項目的規模。規模增長，面對面的溝通就愈加困難，因此敏捷方法適更用於較小的隊伍，20、40人或者更少。大規模的敏捷軟體開發尚處於積極研究的領域。
另外的問題是項目初期的大量假定或者快速收集需求可能導致項目走入誤區，特別是客戶對其自身需要毫無概念的情況下。與之類似，人之天性很容易造成某個人成為主導並將項目目標和設計引入錯誤方向的境況。開發者經常能把不恰當的方案授予客戶，並且直到最後發現問題前都能獲得客戶認同。雖然理論上快速互動的過程可以限制這些錯誤的發生，但前提是有效的負反饋，否則錯誤會迅速膨脹。
方法列表
目前列入敏捷方法的有：
軟體開發節奏，SoftwareDevelopmentRhythms敏捷數據庫技術，AD/AgileDatabaseTechniques敏捷建模，AM/AgileModeling自適應軟體開發，ASD/AdaptiveSoftwareDevelopment水晶方法，Crystal特性驅動開發，FDD/FeatureDrivenDevelopment動態系統開發方法，DSDM/DynamicSystemsDevelopmentMethod精益軟體開發，LeanSoftwareDevelopmentScrum測試驅動開發，TDD/Test-DrivenDevelopmentXBreed極限編程，en:XP/en:ExtremeProgramming
外部連結
敏捷聯盟(英語，AgileAlliance)
