第一部分 置疑軟件工程
第1章 理解軟件工程
軟件工程的悖論
等待硬件開發時，軟件開發者在乾什麼？
得到可用的硬件之後，軟件開發者如何加快交付的速度？
傳統開發過程的內蘊
軟件工程的當代解讀
“足夠好”的軟件-庶民的軟件工程
軟件工程適閤你的項目嗎？
第2章 軟件工程的睏境
“有組織的、可計量的”軟件開發過程現實嗎？
我們當然可以將軟件開發中的某些部分自動化，不是嗎？
“足夠好”的軟件開發方法的危害
誰能取代軟件工程？
第3章 理解軟件開發
軟件資産
軟件開發需要團隊協作
軟件開發的分工有用嗎？
沒有一勞永逸
尋找比“軟件工程”更閤用的隱喻
第4章 尋找一個比軟件工程更好的隱喻
軟件開發的工藝
與傳統工藝學的比較
軟件開發工藝的復興
第二部分 軟件工藝
第5章 重拾軟件開發
工藝學緻力於改善軟件開發的現狀
工藝學鼓勵開發者編寫優秀的軟件
吹響號角
第6章 無須執照的工藝學
工藝是私人性的
同行認可和推薦是獲得更好軟件的辦法
執照隻是假象
執照是在嚮風車開戰
工藝學關注個人
軟件開發者不是太少，而是太多
第三部分 軟件工藝隱含的意味
第7章 工藝學對係統的用戶有何影響
軟件容易拷貝，所以軟件工藝能夠有效
批量市場的難題
工匠與用戶有一種不同的關係
但是，請記住：購買者很可能不是使用者
優秀的軟件應該簽上開發者的名字
為作品簽名會使情況發生變化
工匠應當對作品負責
工匠需要挑剔的用戶
更小、更堅固的軟件更有利於用戶
軟件工藝帶來協作式開發
第8章 顧客與工匠的關係
給我一個真實的交付日期
揭穿“足夠好的軟件”的謬論
另一種選擇
不要隻考慮齣價最低的開發者
差勁的客戶將很難吸引優秀的開發者
讓軟件工匠因為自己的作品而獲得榮譽
要求開發者對作品負責
利用開發者之間的差異
雇傭優秀開發者組成的小團隊
優秀的開發者究竟值多少？
但我們如何知道開發者有多優秀呢？
根據交付的成果來衡量開發者的水平
在選擇工匠時，客戶在成本和質量之間作齣權衡
軟件工匠的專業分工
客戶與軟件工匠有長期的聯係
維護者是一個榮耀的身份
軟件工藝有益於長期使用的軟件
客戶與軟件工匠誌趣相投
第9章 工匠的管理
軟件工匠不是雇工
好的開發者比管理者更有價值
軟件開發的實際過程無法詳細定義
軟件工匠與管理者的關係
以管理優秀的開發者為樂為榮
優秀的管理者理解項目的節奏
軟件工匠喜歡創造軟件
軟件開發的根本從來沒有改變過
傢有一老，如有一寶
軟件工藝要求全新的管理方式
軟件工藝不是“有計劃報廢”
軟件工匠堅持自己的要求
第10章 成為軟件工匠
軟件工藝拒絕精細的分工
過度的專業化會延誤開發、導緻錯誤
軟件工匠建造能夠理解的係統
工藝學需要獻身精神
如何成為軟件工匠？
學徒是比學校教育更有效的學習方式
技師是工藝學傳統的關鍵
工藝學傳統已經延續多年
第11章 工藝的掌握
軟件工藝大師是什麼樣子？
善用你的老員工
“掌握技藝”意味著使用穩定的技術
軟件工匠不會僅僅因為工具“最新最好”而使用它
軟件工程對COBOL的謀殺
技藝需要花時間去掌握
“掌握”意味著承擔起傳遞工藝的責任
工匠挑選學徒和技師
第12章 學徒開發者
我們必須扭轉開發者培訓質量下滑的局麵
大學文憑與項目開發無關
會編程不等於會開發軟件
如果必須送初學者去培訓，選擇好的培訓課程
工藝的掌握，學徒比培訓更有效
成為學徒是重要的一步
為瞭降低對工作的影響，工匠慎選學徒
重要的是學，不是教
學徒不是學校
活到老學到老
學徒審查師傅的作品，並從中學習
學徒的角色
從低風險的任務開始
晉升到産品開發
因為能力而晉升
學徒不是廉價勞動力
學徒期是時間和精力的投資
學徒如何成為技師
第13章 技師開發者
技師在工藝學傳統中的位置
技師開發者
技師很少單獨工作
技師關注應用程序的交付
技師在軟件工藝中扮演關鍵角色
第四部分 重新定位軟件工程
第14章 軟件工程項目
軟件工程的目標是大型係統項目
軟件工程需要專業分工
軟件工程項目依舊使用瀑布過程
編程是一項刻闆的工作
軟件開發不是軟件工程項目的瓶頸
形形色色的軟件工程項目
敏捷方法代替縝密的軟件工程
第15章 “軟件工程”隱喻的危害
無法以低成本實施軟件工程
魚與熊掌可以兼得？
相信估算軟件工程項目的確需要很長的時間
軟件工程鼓勵“科學管理”
軟件工程輕視不精確的討論
軟件工廠：軟件的生産綫
跨項目復用極難實現
冒險的“長時間復用”
“標準軟件開發過程”的迷思
傳統的分工無助於軟件開發
“最佳實踐”是“科學管理”的遺毒
最佳實踐使人墨守成規
最佳實踐阻礙瞭過程革新
軟件工程強迫我們忽視個人
軟件開發者不是可替換的資源
僞造一個“理想的開發過程”
開發過程，不嫌其多
拋棄軟件工程的瀑布式過程
瀑布方法需要大型團隊來實施
小型團隊絕不要嘗試軟件工程
第16章 學習軟件工程的經驗
尺度和復雜度
做軟件，不容易
應用程序需要良好的結構
變化的代價很高——如果你不允許變化的話
交流至關重要
文檔總是錯的
用增量式開發來控製風險
精確的估算很難得到
藉用這些經驗
第五部分 星期一的早上
第17章 經驗——項目成功的指示燈
根據聲望選擇軟件工匠
信任工匠的推薦
最後，開始大範圍搜索
根據聲望和作品來評價工匠
考察工匠的作品
工匠的試演
由軟件工匠來組建開發團隊
根據個人瞭解和推薦挑選團隊成員
年富力強的開發團隊
為低預算團隊擔心
通力協作
使用增量式開發
盡早解決問題
任何人都能學會協作式開發
迴避極端技術
經驗的價值
他們去年在哪裏？
奬勵優秀開發者
想要人纔，就得付高薪
我們付得起那麼多錢嗎？
做好吃驚的準備
第18章 為測試和維護而設計
是軟件應用，不是軟件項目
應用程序隻會退休，不會結束
維護團隊理應拒絕醜陋的軟件
可維護軟件需要有自動測試
使應用程序能夠被測試
為維護而設計
創建可維護軟件需要經驗豐富的開發者
可維護軟件能夠生存多年
長壽的應用程序需要長壽的開發工具
開放源碼，軟件工藝的最愛
Java對項目的健康有害
可維護軟件需要穩定的基礎設施
優秀的軟件是全球性的
保證軟件的全球性
拒絕“有計劃報廢”
優秀的軟件需要優秀的用戶界麵
能夠安全使用的軟件
可維護軟件易於診斷
外包的危害
外包忽視瞭軟件開發的本質
在外包中堅持軟件工藝
藉助外來的工匠
維護是軟件生命中最重要的部分
提高維護者的地位
維護者當受賞
並非所有軟件都必須可維護
“為測試和維護設計”不能一蹴而就
第19章 活到老，學到老
創造學習的環境
用內部研討創造學習環境
邀請所有人參加講座
學習時間是一種投資
掌握軟件開發的技藝
鼓勵參加用戶組和技術會議
慎選培訓課程
課前聯係
課後跟蹤
亡羊補牢
鼓勵員工活躍於開發者社群中
鼓勵齣席技術會議
鼓勵開發者擔任講師
鼓勵開發者寫書
沉思的實踐者
……
· · · · · · (收起)