雖然這本書很務實，沒什麼天馬行空的理論，所有的論點幾乎都是基於實證經驗。但是我對副書名有意見，它很容易誤導一些沒經驗的人，好像讀了這本書之後，寫程式的效率變成兩倍。當然不是這樣。要不至少他們也會理解成，開發效率變兩倍（書上還說在某些體驗中，兩倍算是少的，十倍都有），這雖不能算錯，但在本質上不是這樣的。

書中一開始就以一個秏費上億美元（4.05億＋之前失敗的1.7億），而且已經快失敗的ＦＢＩ資訊專案來做例子，在改用SCRUM進行管理之後，只用幾千萬美金，在計畫開展數年之後的最後幾個月裡，成功地把專案救回來。

這結果當然很神奇，但是細探其究竟，之前他們是使用「瀑布法」來開發的。「瀑布法」的昭彰惡名可以說在十餘年前讀大學時，老早就是如雷貫耳了，在那時即使沒有 SCRUM ，也有提出「螺旋法」等方法來做改良。

在實務上，在我畢業一段時間內，碰上數百人開發的大案也不曾使用過這種方法。

我們使用的方法，雖沒有 SCRUM 之名，卻有 SCRUM 之精髓的開發方式：基本上就是開發一階段，客戶看了之後提供意見，我們再進行下一階段的開發。而我們進行開發時也沒有一套完整文件，基本上 Designer 做好一段設計之後，發信給 RD 去認領分配工作（其實 Designer 也沒有做什麼精緻設計，多半的內容跟 SCRUM 裡說「故事」差不多），QA 即時測試並提供意見，Designer 與 RD 及時修改。唯一會維護的文件是整個 Database Schema 的 Excel 文件，在使用 VBA 程式進行管理之後，此文件不但是文件，而且還可以產生整套 Database 建立劇本。

在我們那時工作是很輕鬆愉快的，沒有什麼加班，專案也未曾逾時過，說不定，我們 RD 在等待新「故事」的時間比花在開發的時間還要多一些，所以趁空檔，我們 RD 還會把目前的 UI 元件或副程式進行改良(後來才知道這有一個名詞，叫 refactor)，讓下次開發更快速些。

與其說那時我們在使用什麼軟體工程方法，倒不如說我們都沒有在講究什麼軟體工程方法，大家就是很自然地，有默契地展開工作。

所以，效率會低下，其實是有人在作繭自縛，在我看來，SCRUM 架構其實把很多不必要的人為干擾拿走，還原原本的開發效率而已。

那是不是採用我之前那家公司的做法，大家無為而治就行了？其實不能這麼說，這和程式架構有相關，那個程式架構其實很鬆散，很容易進行分工，彼此不太容易有什麼切不開來的糾紛點。另外，這也與公司文化有相關，在我離開那家公司之後，很難再找到相同友善而肯合作的同事，事實上，到後期之後公司氣氛不知為何也有一點變化，大概年紀過了，想法就不一樣了。

子曰：「君子有三戒：少之時，血氣未定，戒之在色；及其壯也，血氣方剛，戒之在鬥；及其老也，血氣既衰，戒之在得。」大概就是這個道理吧！

你完全把希望建置在人性上，是不可靠的，人性是難以捉摸而易變的，還是必須要有一定的權威與手段，建立出一種平衡狀態。