《自適應軟體開發》這本書，剛讀時，覺得是有點理想化，但是我對把生態系統的概念引入到軟體開發管理非常欣賞。書還未讀完，從晚上發現別人寫的書評，有點極端，但也不無道理。故先**，作為自己讀書筆記的第一步。
聽人談了一些對於這本書的看法，感覺不是很同意他所欣賞並轉述的書的內容。所以昨天去書店站著看了大半本，覺得他的轉述和對書的理解都沒錯，也就是說我的確不是很同意書中的觀點。
書讀著令人激動，但是感覺作者過於理想化了開發的情況。
專案開發的著作，我以為分兩類。一類是著重考察專案過程本身，一類是主要考察專案的參與者。前者我以為如《人月》，後者如《最後期限》（我想《人件》應該也是的）。一本好的作品應該是承認實際環境中的種種侷限，並在實際侷限的基礎上考慮合適的策略。但是《自適應》似乎更加象一本市面上很多的勵志讀物，拿來鼓勵一下自己可以，不能全當得真。特別是在你開發的是乙個大型應用而不是產品的時候。
一是強調小組成員要保持高度積極的開放心態去適應變化。我覺得大前提沒有錯。但是長時間的激烈變化的確是耗散小組成員鬥志的最佳方式。《期限》中說：壓力之下人無法很好思考。激烈的變化的確是產生壓力的好途徑。我不能期望我的小組成員人人在6個月以上的開發過程中一直保持這種心態，我自己首先做不到。這是大多數專案組的現實。
二是覺得客戶的需求最終會是收斂的，因此總有苦盡甘來的日子。我也以為不妥。我相信很多人經歷過客戶需求的變化，很多不是很有理性的，甚至有很多是顛來倒去的。有很多修改在程式設計師看來（包括事後證明）是沒有意義的，但是在客戶業務人員當時看來是很重要的，小組只能屈從。這也是小組士氣的殺手。
三是關於企業轉型，作者以為很簡單，老總用紙筆一畫就萬事ok。我正驚異於如何做到，作者舉了ms的例子。這就沒話說了，ms有幾個人是能夠學的？sun，hp，dell等都學不來呢。作者接著提到了微軟能這樣做的理由，比如成熟的價值觀和卓越的領導人。可見這和所謂的自適應方法關係不大。業界有句名言：問500磅重的猩猩在**睡覺？答案是：想在**就在**。行業領跑者想怎麼幹都是可以的。至於說到學習成功者是我們成功的捷徑，這個題目就更大了，有興趣的人另外討論。
四是強調用這種方法開發出的小規模產品能先投入使用，產生效益。這種方法有一定可行性，我做的資料分析專案也是類似做法。但是總體而言我基本不同意，特別是從我做過的大型業務系統而言，決不可行。問題不是開發組能不能做到，而是對於這樣的使用者，召集一次業務人員進行培訓和推廣都是很耗費人力物力的。新軟體的推廣畢竟不是買個檯燈來用。業務軟體的推廣往往意味著業務的重新整合，風險非常大（連《期限》的作者也只敢舉產品的例子），這個是不能很多次折騰的。
五是有點忽略政治的作用。這個問題比較大，但是我覺得大專案的開發肯定是要考慮的。上面的第三和第四點也都和政治有一定的關係。《期限》中的貝洛克部長就是政治影響開發的代表，現實中這樣的壓力會來自自己的領導和客戶的領導。**中該人物被解決了，但是實際專案中就說不清了。《期限》的作者也說了：奇蹟會出現的，但是不要抱太大希望（大意如此）。
還有不少，先羅列這些吧。總的感覺是作者有點理想化，相比之下，《人月》《期限》的作者就現實得多。有興趣的人可以對照著看這些作品。
我一直有這樣的觀點：不用面對終端使用者的程式設計師是最幸福的，就象出國的人回來說：還是社會主義的祖國好啊。我的感覺麼，作者似乎是乙個沒有面對過應用專案折磨的人。
有個疑惑：作者區分了螺旋式開發和所謂的自適應開發，我好像看不出有很大的區別。對此有人有深入的看法麼？
順便提一下：作者是個諮詢顧問的經驗勝過作為實際的專案管理者，而且成書於瘋狂的2023年。當然這都不是判斷書的內容如何的論據，只不過我在確定了自己的看法後的一點聯想罷了。呵呵
個人一點淺見，方家見笑了。這書我不準備買，我等待《人件》。
今天又逛書店，看完了《自適應》的後半本。更加確定自己的想法：這本書是.com時代的遺物，價值實在不大。
書的標題中唯一比較明確的是第七章：為什麼好的專案經理也會失敗。內容呢，提出了乙個作者認為是錯誤的觀點，就是：把專案交給乙個好的專案經理，成功的機會比較高。
覺得十分驚訝，於是比較仔細讀了該章。覺得不能同意作者。
首先說點吹毛求疵的東西。關於標題，其實沒什麼意思，勝敗兵家常事爾。再說那個觀點，雖然我們在讀完整個章節後都能知道他想說什麼，但是還是太不嚴謹了(不知是作者還是譯者的問題)。首先，什麼叫好的專案經理？顯然是做專案成功案例多的專案經理。於是論點變成了：做專案成功機會高的專案經理做專案成功機會不高，很好玩。其次，如果承認作者的觀點，顯然也就承認了：挑專案經理最好的方法，不是看他的成績，因為這和擲色子沒什麼區別，也很好玩。作為乙個「有價值」作品，這麼來表達乙個能單獨作為一章的觀點，也太馬虎了。
其次，拋開這個不提，我們知道他其實要表達的是：專案經理過去的成績如果很好，其以後的成績很可能會和蹩腳的專案經理一樣糟糕。我想，考察乙個個體，什麼結論都是有可能的。但是考察好的專案經理的整體和蹩腳專案經理的整體，這個結論顯然無法令人接受。作者的論據是什麼呢？閱讀他文中所述的斷裂性技術，我們能知道，作者是認為世界是急劇變化的（以後越來越厲害），以往的經驗將不能適應目前和以後（99年）軟體開發的變化了。必須進行作者提倡的自適應開發方式。
這個問題見仁見智，我不能同意作者的理由可以從幾個方面來說。第一，看看這套叢書的前言。描述了印度大量的老資格程式設計師和專案經理的存在是人家比我們強的地方。那我不禁要問：照作者的觀點，是不是這些人都沒有價值了？因為世界已經劇烈變化了。如果是是，顯然是荒謬的，而且叢書引入了一本觀點與其出書目的截然相反的作品（這不是一般的觀點不同，而是能完全否認出從書的價值）。如果是不，那麼原因是什麼？是不是這些印度人已經都掌握了自適應方式？這顯然也是荒謬的。第二，個人以為這書和99年的.com熱完全一致，強調速度、變化和拋棄，完全是那個時代的產物（書中有很多痕跡）。.com熱已經過去了，能夠繼續生存的.com大多已經被為本書所嘲笑的傳統經理人所控制，而且生存狀態也就是一般般，其他絕大多數死亡了。謂予不信。舉兩個例子。一是後來看當時最聰明的人，都是攢了乙個**然後趁亂賣掉的人。買的人基本都在哭（如果還能活著），就算你買的是aol也一樣。二是看錯網路熱潮的巴菲特，只為此道了一年歉，之後幾年，可都是和過去一樣笑的。
對於專案管理的論述，我還是堅持前文的看法：要麼是論述如何控制過程（假設組員都是正常的普通的人），要麼是論述如何將人力發揮到最大（並非是發揮到120%），不能混在一起：說自己發現了最好的過程控制方法，它的作用是能將人的作用發揮120%，但是前提是參與者必須120%地投入。這樣是犯了沒有不動點的分析錯誤。如果要我總結這本書的觀點麼，雖然有點偏頗，我還是想這麼打比方，就比如有個人跑來和你說：「我發現了一種絕對出色的**，給我最好的軍隊，我能打敗所有的敵人！」你很為這個**激動，經過仔細考慮，覺得好**當然要好軍隊來用，你決定答應他，於是問：「你覺得什麼隊伍是最好的，從而能用你的**？」他答道：「能打敗所有人軍隊！」
怎麼讀著象釘子湯的故事。
有點原則上的不同，表述得不是很清楚。閱者原諒了。總之，我覺得引入這本書是失敗的。無論如何，歷經時間考驗的《人月》《人件》這樣的神品，出版社不應將其和後面的作品並列為叢書！特別是：它居然比《人月》還貴十塊！
《敏捷軟體開發》讀書筆記3
1 如果乙個類承擔的職責過多，就等於把這些職責耦合在了一起。乙個職責的變化可能會削弱或者抑制這個類完成其他責任的能力。這種耦合會倒置脆弱的 fragile 設計，當變化發生時，設計會遭受到意想不到的破壞。p88 2 在srp 中，我們把職責定義為 變化的原因 a reson for change p...
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早並...
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件 客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早...