推薦好書《JOEL說軟體》

前天去購書中心，發現沒什麼好書可以買，結果就買了一本《JOEL說軟體》。仔細一看，發現這個JOEL還是一個很厲害的人物，說的很多話讓我覺得很有道理的。

     

下面是這本書的前言部分

你可能從來沒有奢望自己成為一名經理。像我所知道的大多數軟體開發人員一樣，要是能夠讓你坐在那裡安安靜靜地寫代碼，你就會感到由衷地高興。不過，作為一名最優秀的開發人員，在小組老領導Nigel出了那場不幸的封裝繩與膝上型電腦事故之後，你晉陞為小組的主角似乎顯得順理成章了。<br />這樣一來，現在你有了自己的辦公室（而不是與整日待在房間裡的暑期打工仔共用一間臥室），並且必須去填寫每年兩次的業績評估表（而不是整天兩眼盯著CRT樂此不疲）。也就是說，現在不用浪費時間去處理女首席程式員提出的奇怪要求，應付拍肩膀的推銷員，以及傾聽充滿創造力的“使用者介面設計人員”（因為Pete之故，他們是作為圖形設計人員而錄用的）。這些設計人員想凸現有反射光的亮麗的“OK/ Cancel”按鈕。我想知道，“反射光”的RGB值是多少？另外，還要應對進階副總裁的空洞提問，他所知道的關於軟體的一切知識來源於Delta航班的旅途消遣雜誌文章。“我們為什麼不用Java，而要用Oracle？我聽說它顯得更為統一！”<br />歡迎進入管理世界！猜想到什麼了嗎？軟體項目的管理與程式設計是完全不相干的兩碼事。假如到現在為止你所做的一切就是寫代碼，那麼你會看到，人類大概比像花園裡的雜草一樣品種繁多的Intel CPU還要不可預測。<br />無論怎麼說，老領導Nigel從來就不很精於此道。“我不想成為那種將所有時間都花在毫無意義的會議上的經理人員！”他用充滿幾分自信的口吻說。“我覺得仍然可以將85%的時間用在編寫代碼上面，在管理方面只花一點點時間就行了。”<br />Nigel真正想說的話是：“我對如何管理這個項目沒有任何心血來潮的想法，也不會像我以前全心全意編寫代碼的時候充滿希望，在某種程度上，一切都像自然而然地自動產生一樣。”事情當然不會那麼順利發展，要切實解釋在那個命該如此的日子裡為什麼Nigel會被IBM ThinkPad電得跳起來，會有很長的一段路去走。<br />不管怎麼說，Nigel真的恢複得令人吃驚得好。鑒於此，他現在擔任一家小公司的CTO。該公司是從難兄難弟WhatTimeIsIt.com起家的，他只用了六個月的時間就從零開始發布了一個全新的系統，他再也不能碰運氣了。<br />軟體專案管理不是一門很知名的藝術。沒有人有軟體專案管理的學位，這方面的書籍也很少。那些在軟體項目方面真正做得很成功的稀有人物當中，有許多人在有機會將自己積累的經驗傳給下一代之前，就很富有並隱退到養魚場垂釣去了，另外一些人則筋疲力盡，找一份強度不大的工作，如給市內的癟三補習英語聊以度日。<br />結果就是，許多軟體項目以這樣那樣的方式，或公開，或無聲地失敗了，因為項目組當中沒有人知道一個成功的軟體項目可能是如何去運作的。於是乎，太多的小組永遠無法交付他們的產品，或者交付產品的時間顯得過長，或者交付的產品沒有人願意使用。不過，最讓我生氣的部分還是項目組的人不樂觀，整日裡抱怨這抱怨那。人生如此短促，沒有時間去厭惡自己的工作。<br />幾年前，我在自己的網站上提出了“Joel測試”概念，其中列舉了運作良好的軟體項目組表現出的12個指標。比如說，維護一個跟蹤故障資訊的資料庫，讓求職人員當場編寫代碼等（不要擔心，後面我還要就此進行更為詳細的說明）。令人驚訝的事情是，如此眾多的人通過電子郵件告訴我，他們的項目組在12項測試中只能得兩三分。<br />兩三分！<br />太異乎尋常了——可以設想一下，幾個從來沒聽說過螺釘是怎麼一回事的木匠卻試圖去做傢具，會是怎樣一番情景！他們完全要靠釘子來幹活，給木頭DingTalk子居然用舞鞋，因為沒有人告訴他們可以用榔頭。<br />軟體專案管理需要一套與編寫代碼完全不同的技能和方法，它們是兩個截然不同且毫不相關的領域。寫代碼與軟體專案管理之間的差別大得就像腦外科與烤法國麵餅。沒有理由希望一位才氣橫溢的腦外科醫生，因時空倒錯而到一家法國烤麵餅工廠，會精通烤麵餅，即便他畢業於哈佛醫學院。然而人們還是不可避免地認定，用不著任何調整就可以讓一位頂尖編碼人員去承擔管理性工作。<br />像前面提到的那位腦外科醫生一樣，你和Nigel會突然感覺到自己要從事一個全新的工作，管理，需要你與——上帝啊——項目組的人員，而不是編譯器進行交流。要是你認為Java編譯器故障很多且不可預見，那麼等著出現第一個首席女程式員問題好了。管理由人組成的隊伍使C++模板看起來顯得過於瑣碎。<br />軟體項目的成功管理是要有技術的。該項管理藝術目前發展的狀況遠遠超過了釘子與舞鞋的情形。我們已經有榔頭、螺絲刀與雙面兩用鋸可用。本書的寫作目的在於從各個層面盡我所知向你介紹一些方法，小到項目組負責人制訂進度表，大到軟體執行總裁提出富有競爭性的戰略，都在該書的介紹範圍內。<br />在本書當中，你可以學到：<br /> 如何聘用與激勵最優秀的員工——軟體項目成功當中惟一的最至關重要的因素。<br /> 如何評估與調度工作，以及為什麼要這樣做。<br /> 如何設計軟體功能，撰寫確實有用的規格說明書，而不僅僅是用做維修集體宿舍的“唯寫不看”的封裝紙。<br /> 如何避免落入軟體開發常見的陷阱，以及當程式員堅持按照“丟棄它而從頭開始”的想法行事時，為什麼總是錯誤的原因。<br /> 如何組織與激勵項目小組，以及為什麼程式員需要辦公室門窗都緊閉。<br /> 即使可以從網上下載足夠好用的軟體版本，那麼什麼時候需要自己從零開始去寫代碼。<br /> 為什麼軟體項目總是在經過開頭幾個月的快速奔跑之後就似乎裹足不前了。<br /> 擁有好的軟體策略意味著什麼，以及為什麼BeOS從第一天起就命中註定了灰色的結局。<br /> 其他更多的內容。<br />書中的內容顯得有些主觀，我只能如此。為了簡潔起見，每句話的開頭我都把“在我看來”的短語去掉了，因為實際上書中的每句話都是我的看法。這雖然不完整，但或許是一個很好的開頭。<br />呵，如此說來，你看過我的網站了……<br />本書的許多內容最初是以系列文章的形式在我的網站“Joel說軟體”（www. joelonsoftware.com）上發表的。那是承載我多年思想的地方。我希望你手中的這本書能夠比網站更有“粘結性”，我說粘結性的意思是“你可以在浴缸裡閱讀而不用擔心觸電”。<br />本書分三個主要部分。第一部分是關於開發小範圍軟體的所有內容：每件事情都應該由自己的團隊來完成，以確保軟體不會給人們帶來危害。第二部分包含關於程式員與開發小組管理方面的文集。第三部分雖然顯得有點隨意，但是介紹的主要精力放在構築可行的軟體開發業務大戰略之上。在這裡，你將瞭解到為什麼大件總是贏得現在，為什麼Ben & Jerry式公司與Amazon不一樣，並且我會試圖指出一種情形——存在成套的軟體開發模式通常是缺乏勝任工作的員工的一種表現。<br />雖然在這裡說了很多，但還是深入書本開始閱讀為好。

如果大家感興趣，可以到dearbook 或 china-pub 購買