乙個團隊經歷了計畫/設計
/開發等階段，達成**完成這一目標，但是軟體生命週期的最後階段往往是最考驗團隊的，不但考驗團隊專案管理水平、應變能力，也考驗團隊的「血型」。
在穩定階段的初期，團隊只要決定需要修復哪些缺陷，然後團隊成員就會進行必要的設計、實現、測試工作，並簽入**修改。但是，隨著專案進展和發布日期的臨近，團隊還要保證修改方案不會給產品帶來負面的影響。這時，還要對修改方案進行會診，包括以下三個方面：第一步：開發者提交參加會診的bug和修改方案
；第二步：會議決定是否同意修改方案
；第三步：執行。
乙個里程碑結束了，要總結團隊有什麼經驗教訓、產品怎麼才能做得更好。這個軟體開發的週期結束了，反思一下這個軟體開發的流程，即要開事後諸葛亮會議。
最近幾年，我們整個社會似乎都對創新感興趣。對於創新有一些迷思如下：1.靈光一閃現，偉大的創新就緊隨其後
2.大家都喜歡創新
3.好的想法會贏
4.創新者都是一馬當先
5.要稱為領域的專家，才能創新
6.技術的創新是關鍵
7.成功的團隊更能創新
影響產品競爭的各種因素有：產品行業的因素、公司和市場因素、團隊執行因素、產品的價值因素。在it
創新的潮流中，我們要從小事做起，重質量，講信用，對產品負責，對工作自豪。
個人感受部分：
身處這個時代，要積極進行創新才能有立足之地。
團隊專案結束了也要開事後會議，善於總結自己的優點與不足。以後我如果參加團隊專案的話，也要參加事後會議，這是非常有必要的。
《構建之法》閱讀筆記六
第七章閱讀筆記 msf 微軟推薦的軟體開發方法。msf基本原則 推動資訊共享與溝通 就是盡量做到將資訊共享給團隊的每乙個成員，每個成員都對資訊有較為完整的了解，而且各個討論和決定都要涉及所有的角色，告知所有的人。為共同的遠景工作 就是每個成員心中都有遠景，為了實現遠景而努力，而且每個成員心中的遠景都...
《構建之法》閱讀筆記（六）
閱讀第八章所得 在估計專案用時多少時，往往沒有乙個準確的標準，所以要依情況而定。有些事客觀規律，而不是個人能力決定的，因為人的能力不盡相同。這裡有乙個關於時間花費的經驗公式 y 實際時間花費 x 對某事件的估計時間 x 對某事件的估計時間 n 做過類似開發工作的次數 這是在軟體工程師在長期的實踐中摸...
06構建之法閱讀筆記之六
整本書對軟體構建的方方面面寫的很清楚，包括需求，設計，開發，測試，專案管理.等實在無法一時消化，對我們以後的工作有很大的參考價值，至少對於我目前這樣的狀態來說，了解自己要怎麼做，做的方向比要做什麼更重要，本書提供了很多建議和方法，也由此了解到作為乙個軟體工程師，任務清單裡面不僅只有要編好程這一項而已...