禍起蕭牆(進度管理和監控的方法)
慢性的進度偏離是士氣殺手，這裡核心思想就是要意識到進度滯後往往如溫水煮青蛙一樣讓我們難以應付，最重要的就是要防微杜漸。重大災害是比較容易處理的，它往往和重大的壓力、徹底的重組、新技術的出現有關，整個專案組通常可以應付自如。 但是一天一天的進度落後是難以識別、不容易防範和難以彌補的。
進取對於傑出的軟體開發團隊，同優秀的棒球隊伍一樣，是不可缺少的必要品德。 為了加強我們對進度的監控，里程碑的定義就至關重要了。里程碑的選擇只有乙個原則，那就是，里程碑必須是具體的、特定的、可度量的事件，能夠進行清晰定義。以下是一些反面的例子，例如編碼，在**編寫時間達到一半的時候就已經「90％完成」了；除錯在大多時候都是「99％完成」的；「計畫完畢」是任何人只要願意，就可以宣告的事件。
里程碑有明顯邊界和沒有歧義，比它容易被老闆核實更為重要。如果里程碑定義得非常明確，以致於無法自欺欺人時，很少有人會就里程碑的進展弄虛作假。但是如果里程碑很模糊，老闆就常常會得到乙份與實際情況不符的報告。畢竟，沒有人願意承受壞訊息。這種做法只是為了起到緩和的作用，並沒有任何蓄意的欺騙。
在進度跟蹤和管理上，必須要在整個團隊中樹立這種觀念，就是要盡可能早的完成相關的任務，而不是拖到了最後在來做。類似於關鍵鏈進度管理中始終強調的乙個重點內容就是要壓縮前面的開發周期而在專案後期預留緩衝。
當進度出現偏差後，專案經理往往把問題掩蓋起來，而且經常主觀的認為可以通過各種趕進度的手段來挽回進度損失，但是往往情況並不是這麼簡單。因為很多時候 引起進度的偏差往往存在一些問題的根源，而這些根源往往是需要老闆提前介入並採取一些行動，因此老闆必須仔細區分狀態報告、毫無驚慌地接收報告、決不越 俎代庖，將能鼓勵誠實的匯報。
沒有銀彈：沒有任何技術或管理上的進展， 能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數量級上的進步。現代軟體系統中這些無法規避的內在特性：複雜度、一致性、可變性和不可見性。那麼軟體開發總是非常困難的。天生就沒有銀彈。沒有神話般的解決方案， 以及將來也不會有。
複雜性： 軟體系統與計算機、建築或者汽車大不相同，後者往往存在著大量重複的部分。由於軟體產品特有的複雜度導致了成員之間的溝通非常困難，帶來了軟體產品的進度，質量和成本多方面的問題。特別是在軟體規模增加的時候複雜度往往成倍上公升。同時複雜度不僅僅導致技術上的困難，還引發了很多管理上的問題。它使全面理解問題變得困難，從而妨礙了概念上的完整性。(在軟體產品開發工廠化的過程中，我們要注意到仍然解決的是次要因素，比如加大公用元件開發，加大平台和框架的建設，而業務功能本身導致的複雜性是無法避免的。)
一致性：在某些情況下，因為是開發最新的軟體，所以它必須遵循各種介面。另外一些情況下，軟體的開發目標就是相容性。在上述的所有情況中，很多複雜 性來自保持與其他介面的一致，對軟體的任何再設計，都無法簡化這些複雜的特性。
可變性：系統中的軟體包含了很多功能，而功能是最容易感受變更壓力的部分。所有成功的軟體都會發生變更。現實工作中，經常發生兩種情況。當人們發現軟體很有用時，會在原有應用範圍的邊界，或者在超越邊界的情況下使用軟體。功能擴充套件的壓力主要來自那些喜歡基本功能，又對軟體提出了很多新用法的使用者們。簡言之，軟體產品扎根於文化的母體中，如各種應用、使用者、自然及社會規律、計算機硬體等等。後者持續不斷地變化著，這些變化無情地強迫著軟體隨之變化。(軟體開發的過程必須要考慮如何適應變化，在需求，設計和編碼過程中都需要考慮如何快速響應變化，如何提高軟體產品的可擴充套件性。我們在軟體開發生命週期模型上強調增量迭代的思路，強調測試驅動的思路其根本目的就是為了快速響應變化，降低變化帶來的風險。)
不可見性：除去軟體結構上的限制和簡化方面的進展，軟體仍然保持著無法視覺化的固有特性，從而剝奪了一些具有強大功能的概念工具的構造思路。這種缺憾不僅限制了個人的設計過程，也嚴重地阻礙了相互之間的交流。(我們推薦快速原型法仍然是為了進來去解決軟體不可見性的問題。
對沒有銀彈的感觸**
1.現在有很多快速開發平台，但是真正能夠不寫**就完成業務功能的開發平台基本上沒有成功的，特別是在業務場景比較複雜情況下，程式設計自動化基本是不可能的事情。唯一看到有所突破的是關於統一框架和技術平台等方面的建設，在原有的框架基礎上我們來構建乙個產品開發平台，將跟業務關係不大的許可權模型，工作流引擎等整合進去，將常用的可復用元件整合進去，加快開發速度。
2.不要在追求自動程式設計平台上下功夫，可以在加強元件復用和技術平台建設上下功夫。
3.要多從開發模式的改進上來解決沒有銀彈所提出的各種實際問題，雖然不能夠徹底解決，但是可以通過努力來改進。比如增量迭代的開發模型，快速原型法，測試驅動，高階語言和圖形化程式設計等。
《人月神話》讀後感
不同的社會經驗，不同的思想狀態，對讀本書的心得也不一樣，我在此說說我的讀後感，書中有許多非常好的觀點，但我只把我感觸最深的寫下來。這確實是一本很值得多次閱讀的好書，每次閱讀可能都能從中得到一些提示。1.外科手術隊伍the surgical team 專案經理在專案的初期必須清楚的估計專案的人月運作模...
人月神話讀後感
人月神話 這本書風行已經很久了，寫成於1975年，經歷這麼久的時間，在當前又重新流行，讓我很驚訝,但是一直沒有時間讀。今天突然想起自己的機器上有本拷貝別人的電子書，決定讀讀。我今天只看了兩章，即焦油坑和人月神話。人月神話看上去這麼浪漫的名字，原來並不是真的說神話故事，作者闡述的主要觀點是在軟體開發專...
《人月神話 》讀後感
之前一直聽老師講 人月神話 彷彿這就是乙個傳奇。百聞不如一見，在這本300多頁 中文新版 的神書，在經過了20多年的歷史之後，仍然暢銷不衰，究竟是什麼讓它有如此的魅力？過去的乙個月，一點一滴的閱讀之中算是初步的了解到了它的一部分吧。人月神話的核心觀點 概念完整性和架構師 brooks認為，乙個整潔 ...