看完這本書，有一些小故事想分享一下。

故事一：某位開發人員計劃修改一個bug，需要4小時，但是實際上8個小時也沒做出來，甚至給他8天也解決不了。文中提到的這個bug最終被解決是在幾個月後。有時候修改這種棘手的bug正的像這位開發人員所說：有時候，你一覺醒來，腦中靈光閃現，於是手到擒來--大抵如此。

故事二：開發模式的選擇，書中提到了“大教堂與集市”這本書，大教堂的模式可以說是傳統的開發模式，而集市模式被很多開源專案採用,比如Apache Web伺服器,Linux。咱們一般開發自然用的是大教堂模式了。

故事三：歷史上有很多失敗的專案，例如FBI耗資1億7千萬美元，為了提高反恐能力的計算機專案失敗，失敗原因是FBI受到９／１１事件的刺激把需求列表陡然拉長。美國國內稅務局至今用的系統是20世紀60年代開發的，在95年曾試圖升級，花費了20億美金後，國會取消了這個失敗的專案，失敗原因：需求不斷改變，預算和進度安排不切實際等。04年英國養老金系統全面停止運作，事故原因是：在把７臺window 2000升級至window XP時，不小心把升級範圍擴充套件到數千臺沒準備好的機器上。所以，如果你正在做的專案失敗了，別太氣餒，你不是第一個，也不是最後一個。

故事四：專案語言的選擇。書中提到的專案經過了大家無數次的討論，最終決定使用：Python。但是在專案的後期，另外一個Python高手加入後，曾經隱晦的說過，其實大家在用編寫Java程式碼的方法編寫Python。這讓我想起，雖然大家都說其實語言是相通的，如果你一門語言很熟練了，其他語言也大同小異，但是畢竟每個語言都有自己不同的特性，所以專案組有機會選擇語言的話，最好還是考慮一下開發人員對哪種語言最熟練。

故事五：以時間來驅動版本的釋出。書中提到專案的0.2版是一個很爛的版本，但是還是釋出了，因為承諾的釋出時間到了。雖然書中的專案組汲取這次的教訓，不再以時間來驅動，但是我覺得用時間驅動版本釋出是一種比較有效的方式，它讓開發人員有一個奮鬥的目標，儘快完善自己的開發模組。

故事六：GTD（get things Done）,是一本書的名字，這本書的中心思想是讓大家把所有要做的事情寫下來，讓腦子清空。我覺得這種方式不錯。一次，我覺得事情太多，有點煩躁不安，不知道該從哪件事入手去做，後來想到這個做法，就把腦子裡想的事情全部寫下來，然後再一件一件來做。
————————————————
版權宣告：本文為CSDN博主「cathy_2007」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/cathy_2007/article/details/5503537