書評《自適應軟體開發》(一)--.com時代的遺物 (轉)

書評《自適應軟體開發》(一)--.com時代的遺物 (轉)[@more@]

聽人談了一些對於這本書的看法，感覺不是很同意他所欣賞並轉述的書的內容。所以昨天去書店站著看了大半本，覺得他的轉述和對書的理解都沒錯，也就是說我的確不是很同意書中的觀點。

書讀著令人激動，但是感覺作者過於理想化了開發的情況。
專案開發的著作，我以為分兩類。一類是著重考察專案過程本身，一類是主要考察專案的參與者。前者我以為如《人月》，後者如《最後期限》（我想《人件》應該也是的）。一本好的作品應該是承認實際環境中的種種侷限，並在實際侷限的基礎上考慮合適的策略。但是《自適應》似乎更加象一本市面上很多的勵志讀物，拿來鼓勵一下自己可以，不能全當得真。特別是在你開發的是一個大型應用而不是產品的時候。

指出我的看法有些難。摘錄一些觀點供大家參考。

一是強調小組成員要保持高度積極的開放心態去適應變化。我覺得大前提沒有錯。但是長時間的激烈變化的確是耗散小組成員鬥志的最佳方式。《期限》中說：壓力之下人無法很好思考。激烈的變化的確是產生壓力的好途徑。我不能期望我的小組成員人人在6個月以上的開發過程中一直保持這種心態，我自己首先做不到。這是大多數專案組的現實。

二是覺得客戶的需求最終會是收斂的，因此總有苦盡甘來的日子。我也以為不妥。我相信很多人經歷過客戶需求的變化，很多不是很有理性的，甚至有很多是顛來倒去的。有很多修改在員看來（包括事後證明）是沒有意義的，但是在客戶業務人員當時看來是很重要的，小組只能屈從。這也是小組士氣的殺手。

三是關於企業轉型，作者以為很簡單，老總用紙筆一畫就萬事OK。我正驚異於如何做到，作者舉了MS的例子。這就沒話說了，MS有幾個人是能夠學的？sun，hp，dell等都學不來呢。作者接著提到了能這樣做的理由，比如成熟的價值觀和卓越的領導人。可見這和所謂的自適應方法關係不大。業界有句名言：問500磅重的猩猩在哪裡睡覺？答案是：想在哪裡就在哪裡。行業領跑者想怎麼幹都是可以的。至於說到學習成功者是我們成功的捷徑，這個題目就更大了，有興趣的人另外討論。

四是強這種方法開發出的小規模產品能先投入使用，產生效益。這種方法有一定可行性，我做的資料分析專案也是類似做法。但是總體而言我基本不同意，特別是從我做過的大型業務系統而言，決不可行。問題不是開發組能不能做到，而是對於這樣的，召集一次業務人員進行培訓和推廣都是很耗費人力物力的。新的推廣畢竟不是買個檯燈來用。業務軟體的推廣往往意味著業務的重新整合，風險非常大（連《期限》的作者也只敢舉產品的例子），這個是不能很多次折騰的。

五是有點忽略政治的作用。這個問題比較大，但是我覺得大專案的開發肯定是要考慮的。上面的第三和第四點也都和政治有一定的關係。《期限》中的貝洛克部長就是政治影響開發的代表，現實中這樣的壓力會來自自己的領導和客戶的領導。小說中該人物被解決了，但是實際專案中就說不清了。《期限》的作者也說了：奇蹟會出現的，但是不要抱太大希望（大意如此）。

還有不少，先羅列這些吧。總的感覺是作者有點理想化，相比之下，《人月》《期限》的作者就現實得多。有興趣的人可以對照著看這些作品。

我一直有這樣的觀點：不用面對終端使用者的程式設計師是最幸福的，就象出國的人回來說：還是社會主義的祖國好啊。我的感覺麼，作者似乎是一個沒有面對過應用專案折磨的人。

有個疑惑：作者區分了螺旋式開發和所謂的自適應開發，我好像看不出有很大的區別。對此有人有深入的看法麼？

順便提一下：作者是個諮詢顧問的勝過作為實際的者，而且成書於瘋狂的1999年。當然這都不是判斷書的內容如何的論據，只不過我在確定了自己的看法後的一點聯想罷了。呵呵

個人一點淺見，方家見笑了。這書我不準備買，我等待《人件》。