這本書我個人認為是非常棒的，第一次從圖書館借回來，看了不到一半，到期了，覺得沒什麼，就還回去了，過了一段時間，由於工作上的經歷，對書中的一些內容慢慢有了感悟，才覺得這本書不錯，於是又第二次從圖書館借了回來細細看，現將一些感悟寫下來。
先來說說加班。
ea的加班非常嚴重，他們的hr甚至有這樣一種思想：「ea就是這樣，如果你忍受不了，那麼就去別的地方吧，否則就給我乖乖的忍受。」，ea每年的員工流失超過50%，大家都知道，新員工進來以後，公司要對他們進行培訓，然後慢慢的，這些新員工才能融入正常的開發流程。培訓的開銷，時間的花費，這些都是一筆不小的開銷，而這麼高的員工流失率，意味這ea大部分都是新員工，他們可能連培訓成本都沒收回來，更別期望這些員工能為公司創造什麼價值了。
策劃、主管經常讓我給出乙份開發工作的工作量評估，而當我告訴他們乙個結果的時候，他們總是會問我「這個時間不包括休息日的吧？如果把周6週日算進去，時間是不是會更短一些？」，我給他們的答案一般都很堅決「是不包括休息日，但如果你把休息日也算進去，總的時間只會長不會短！」
這種問題，我覺得更本就不能用簡單的加減法來計算！！
我真的非常非常認同書中的觀點：你覺得加班就一定會帶來效率嗎？？認真的看看你周圍的同事，每天下午下班後，吃過晚飯回來，有誰是一坐下就開始工作的？到了周6週日，又有誰是按照平常的上下班時間來公司的？人的大腦都會有一種潛在的規律，到了下班時間，總是會花那麼一些時間用來瀏覽網頁，聊天之類的。所以，如果按照每天晚上加班一小時來算，那這一小時裡，真正用來工作的時間是多少？？況且，周6週日本來是用來陪女朋友逛街的，你把他拉來公司加班，本來8點半上班，他可能睡到10點才來，然後女朋友還不高興，**裡和他吵了一架，到了公司後，他先花個乙個小時上網，用來解解悶氣，然後才開始寫**，寫**的時候還在想著和女朋友吵架的事，越想越不爽，**裡可能**寫的出了bug都不知道，以後的測試或者上線過程中，測試人員測了幾輪終於發現這個問題，然後寫測試報告反饋給專案經理，最後輾轉反側終於提交到了這個開發人員手裡，然後他又花了一天的時間去測試重現這個問題，最後終於找到癥結所在，然後修復，然後打包發布…整個過程消耗了多少人力？浪費了多少時間？而原因，僅僅是因為這個開發人員花了周6整整一天中的2個小時來編碼導致的？？？
所以，不要以為周6過來加班就能縮短專案時間！在成都工作bronnie曾經說過：「加班，其實就是能力不足的表現，不過不是你們開發人員，而是你們的teamleader，是你們的pm，是我。是我們沒有把握好整個專案的程序，沒有充分考慮到專案過程中的各種變化及風險才導致了你們的加班！」。現在想想，確實是這樣，大家也都做開發這麼久了，真正開發過程中有哪些東西是需要你加班加點的來寫**才能完成的？很少很少！其實回想一下，業務其實都很簡單，都不複雜，那麼又是什麼讓我們消耗了這麼多的時間？
這真的是乙個需要好好考慮一下的問題。
讀《Joel談優秀軟體開發方法》之「填補鴻溝」
看 joel談優秀軟體開發方法 這本書，讓我印象最深，收穫最多的是eric sink的幾篇文章。在前面已經寫過了關於 雇用人員 這篇就寫 填補鴻溝 吧 這篇文章寫的是如何填補 產品 顧客 之間的鴻溝，其講述的主要是銷售方面。不知道是這篇文章淺顯易懂呢，還是我沒有這方面的知識，感覺寫得非常不錯。有兩種...
軟體開發方法
軟體開發方法 1 結構化方法 結構化分析，結構化設計，結構化程式設計組成，面向資料流的開發方法 依據分解與抽象原則，按照資料處理流程，利用資料流圖建立系統功能模型，從而完成需求分析工作。適合資料處理領域問題，不適合大規模，特別複雜的專案，且難以適應需求變化。2 jackson方法 面向資料結構的開發...
軟體開發方法
常見的軟體開發方法有結構化方法 jackson方法 維也納開發方法 vdm 和物件導向的開發方法。1.結構化方法 指導思想 自頂向下，逐步求精 基本原則 功能的分析與抽象。優點 1 適用於資料處理領域的問題 2 支援工具較多，發展成熟。缺點 1 不適應規模大的專案 2 不適應特別複雜的專案 3 難於...