《微軟的秘密》有感
今天終於可以看完《微軟的秘密》了，這是一本非常難讀的書，需要你去思考和帶著問題去讀，如果你對軟體開發過程不是很感興趣，奉勸你不要讀了，因為你一定會覺得異常枯燥。
當然，我之所以能夠讀下來，而且認真努力的進行研讀兩遍，的確是希望能從微軟的開發流程和方法上得到一些體會，然後應用到公司的研發過程中。讀此書，有乙個非常明顯的感受：他把微軟的研發流程非常詳細的記錄並呈現給讀者。我常常對照公司的情況，發現微軟公司的之前面臨的問題和現在我們軟體開發遇到的問題基本一樣，甚至細節也十分相似。
在讀書過程中，對於軟體進度控制和安排，我給予了非常大的關注力度，對於微軟自下而上的個人承諾方式的專案控制方式，比較贊同，當然，我也強烈的意識到，其基礎是微軟開發人員的高水平和高能力，以及不斷提公升的計畫安排能力。我們很多程式設計師對於做計畫都是新手，我們也沒有歷史資料提供給他們進行參照。我們的程式設計師達不到，所以我們制定的計畫總是延遲，而且沒有任何緩衝時間的概念。
怎麼做呢？我想到乙個最直接的方法就是選取我們軟體企業的度量指標，並進行統計和積累，因此我們參考這些度量標準來做出專案中的關鍵決策，比如里程碑階段何時應該走了，何時應該推出產品了。開發前期我們可以使用歷史預估資源需求情況。
今天在和測試部經理和產品部經理談話時，他們也說出了他們的擔心，一是擔心我們做的改進只是為了改進而改進，而沒有真正的意義。而是擔心，加大他們的工作量。的確，進行可度量的過程改造，的確需要我們進行一些額外的工作量，但是如果我們本地化的措施真能有效的建立起來，應該對規範公司的軟體開發行為是非常有利的。
同時，對於微軟的做法，我們發現其是非常靈活和坦誠的，沒有複雜繁瑣的流程控制，小組具有非常寬泛的權力。乙個偌大的微軟就是通過乙個個特性小組聯合起來，通過每日構建和里程碑同步的開發。
我們小企業如何做呢？是否也需要每日構建和里程碑呢？
就公司現實情況來講，實現每日構建和結對測試從技術上講是可以的，但是可能會浪費很多時間，我們團隊的規模較小，可能每日構建所產生的好處遠沒有想象的大。實施快速測試倒是非常好的，開發人員把私人版本進行快速測試，減少測試時間。
里程碑是非常有必要的，之前研發部也有迭代開發的思路，但是沒有強化里程碑的概念，現在我們需要強化里程碑概念，強化質量控制和測試。這恰恰是我們需要的。
總之，從《微軟的秘密》中受益匪淺，明確和強化了我的一些軟體過程管理的概念，也為我提供了一些現實的具體操控方法。建議從事公司cto，研發總監，開發、研發經理都可以讀一讀。
研發過程對比 讀《微軟的秘密》有感
2010年在成都三官堂買的 微軟的秘密 這兩年陸陸續續看了幾次。如同 走出軟體作坊 的作者阿朱說的一樣，每看一次都有一些感想。這本書寫的是微軟90年代及其之前的開發經驗，但是對我們當前的開發來說，仍然有很多值得汲取的經驗。當今各種敏捷 scrum開發方法大行其道，可從本質上來說，也是對軟體工程管理的...
對專案質量的無止境追求 讀《微軟的秘密》有感
2010年在成都三官堂買的 微軟的秘密 這兩年陸陸續續看了幾次。如同 走出軟體作坊 的作者阿朱說的一樣，每看一次都有一些感想。這本書寫的是微軟90年代及其之前的開發經驗，但是對我們當前的開發來說，仍然有很多值得汲取的經驗。當今各種敏捷 scrum開發方法大行其道，可從本質上來說，也是對軟體工程管理的...
微軟的秘密！
一 word2000 狐狸和懶狗 這個知道的比較早了。在乙個空白的word2000 或者以上版本 使用英文輸入法輸入 rand 200,99 然後回車，看到什麼了？5號字型228頁的 the quick brown fox jumps over the lazy dog.word2003則是這句話的...