本書是特為每個關注專案開發成敗的人，特別是尋些沒有經過正式軟體專案管理訓練的
人而寫的一本書。作者利用在研究與工作中獲得的經驗告 訴您專案開發過程中的規劃、
設計、管理、質量控制、測試與完工所需的策略與觀念，並利用大量技巧建立一套精簡
可靠的框架來成功地管理專案。不論是新手還是老練的專案管理者教將從中獲益匪淺。
本書將是每個專案人員案頭不可或缺的指導書。
本書作者曾著有兩本頗受好評的微軟經典著作，通過他的親身經歷，現身說法，使您獲
得「原汁原味」的微軟經驗與法則，助您攀著巨人肩膀步入巨入行列！
有一些感想記錄下來
看這些書，感覺核心思想就是告訴人如何去控制（改進）軟體開發的過程。
對照自己的開發經歷來說，
大多數時候都是隨心而為，雖然在大體方向上面隨著**寫的越多，經驗積累的越多，對程式整體走向的控制力越強，但還是在某些方面有比較大的不足。
也就說，以前靠經驗，現在要靠理論來指導。
從沒有過程控制到有目的的控制軟體開發過程，到改進軟體開發過程。說來容易，作起來難。
按章節來說說，
直接進入第二章
第二章 軟體專案求生測驗
中心要點
首先，開始乙個專案的時候，最好作足準備工作，
這樣專案存活下來的機率要大的多。
驗證乙個專案是否會成功，可以使用下面幾個要點來檢查
需求》是否獲取了明確的需求。
>是否跟最終的使用者交換了意見
>是否有規範的文件
（文件不在於多和詳細，而在是否描述了應該記錄的資訊）
>是否有介面雛形來描述軟體功能
規劃》有否詳細規劃工程進度表
包括人員的出勤時間
配置程式時間
溝通交流時間
整理資料時間
>有否架構設計和說明檔案
>有否所有開發團隊都認可的時間表和工作進度表
專案控制
>專案是否有一位決定權的主管並充分獲得全力支援
>專案主管是否有能力兼股專案
>專案是否有明確的里程碑進行控制
>專案的所有變更是否能及時通達到專案相應的人員那裡
>有否控制源**版本，缺陷等軟體支援
風險管理
>有否及時更新的風險控制表
>能夠敏感的查覺到風險並標識出來
人事》人力足夠麼
>有否乙個能帶領大家成功的技術主持人
>工作組的人具備專案開發的技術麼？
>工作環境是否令人滿意
本章節說的如何在產品出來之前就驗證軟體是否能夠成功。
其實也就依據一些規律性的經驗總結的規則，仔細一看，我也可以總結出來大多數。
只可惜大多數的人或公司都作不到。
因為我們嫌麻煩，所有我們只作到了一半，甚至沒到一半，自然最後的結果可想而知了。
前兩天，看了乙個小故事，這裡來引用一下。
half-assed
剛到stanford念書時，發現教室的設計很特別：劇場式階梯、馬蹄型桌子，坐下來，看到桌上有一條長長的細縫。
白蟻蛀的嗎？怎麼可能這麼整齊！「這是插名牌的！」同學告訴我。註冊時，教務處發給你一張橫式長方形厚紙卡，上面寫著「王文華」三個字。上課時你要把名牌插進細縫，好讓老師看清楚你的名字，方便點你發言。階梯式教室、馬蹄型桌子，都是為了讓老師同學看到彼此，討論時容易產生火花。
學期中我把學校發給我的名牌搞掉了，自己做了乙個，插進細縫中。下課後老師跟我說：「我看不清楚你的名字。」「為什麼？」「因為你做的名牌，名字和紙張底部之間的留白不夠，插進有深度的縫隙，一半名字都塞進縫隙裡。」我拿出名牌，果然是這樣，「你應該叫教務處幫你重做，他們做的名牌都是精密量過的，插進細縫中剛剛好。」老師臨走前一語雙關地說：「把你那張half-assed的名牌丟了吧，那張名牌只讓我們看到一半的你。」
當時我聽不懂「half-assed」（直譯：半個屁股）是什麼意思。去查字典，上面寫著「凡事只做一半，不注細節」。
沒錯，在那之前，我一直是個大而化之、半個屁股的人。好的學校，連學生名牌上名字和頁緣之間的距離都斤斤計較，而過去的我，只會嘲笑這樣的人吹毛求疵。
stanford第一年暑假，我和一位帶著兩歲小孩的朋友去拜訪在蘋果計算機工作的學長。在員工餐廳吃午餐，朋友抱著小孩，吃不到兩口，學長走到角落，拿來一張兒童椅。「你們的員工餐廳還有兒童椅？」「當然啊！雖然很少員工會把小孩帶到公司，但我們總要預防那種萬一！」
畢業開始工作後，常常出差。有一次我坐新航的長程飛機。第一餐結束後，機艙的燈變暗。空服員問我要不要睡覺，我說要。於是她把一張貼紙貼在我的椅子上，上面寫著客人要休息，下次餐飲不要打擾。大部分的航空公司會拍醒你，問你要不要用餐，你說不要，但被吵醒後再也睡不著。新航用一張貼紙，兩全其美地解決問題。
工作這些年來，我發現成功的人和公司，屁股都很完整。不論大事小事，他們總能做到滴水不漏。他們不靠革命性的創意，因為革命性的創意可遇不可求。他們有耐心和能力把例行公事做到完美，和二流之間的差別就在細節。
我永遠記得stanford的細縫、蘋果的兒童椅，和新航的貼紙。它們代表的，是一種細緻和體貼，一種成本很小、容易做到，卻是大家最不屑一顧的美德。所以，就叫我吹毛求疵吧！因為我終於醒悟到工作路上的顛簸，都是因為我行走時少了半邊屁股。
第三章使用了"開發程式"這個片語，
容易讓人迷惑。應該叫"開發流程"
它提出上下游的關係，並認為在每個階段應該堵截各自的錯誤。
它同時給出了錯誤產生的階段以及在此階段產生的錯誤需要的多大代價去修正
分別是需求清理
架構設定
細節設計
構建過程
按此順序，修改錯誤造成的代價越小。
未完待更新
好書共享 《微軟專案 求生法則》
碰，碰，碰 軟體開發人員 各級主管與顧客們幾十年來不停地敲著頭面對同樣的問題。許多中型專案由於不合理的原因而失敗，那些專案並沒有用到半點先進的技術，也沒有採用其他學科的頂尖研究成果。那些專案只是被自己的笨重給壓垮了。軟體專案的存活不是一種意外的結果。要讓乙個專案成功所需的努力並非特別困難或耗時，只是...
《極簡法則》讀書筆記
本書作者將一家公司想要在商業上取得突破，總結出兩條產品發展路線，即 簡化和命題簡化。將產品或者服務的間隔減半，甚至更多，往往不是提供劣質的產品，而是以完全不同的新方式來組織產品的配送過程，使其載量更大 效率更高，並且常常還會吸納客戶本身來做一些工作。只有當你可以讓生產製作過程變得更簡單，從而將成本減...
讀書筆記 迪公尺特法則
迪公尺特法則 lod 也叫最少知識原則。迪公尺特法則 lod 如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者 這個呼叫。迪公尺特法則首先強調的前提是在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權。也就是說，...