研發過程對比 讀《微軟的秘密》有感

2021-08-26 18:29:47 字數 1677 閱讀 6727

2023年在成都三官堂買的《微軟的秘密》,這兩年陸陸續續看了幾次。如同《走出軟體作坊》的作者阿朱說的一樣,每看一次都有一些感想。這本書寫的是微軟90年代及其之前的開發經驗,但是對我們當前的開發來說,仍然有很多值得汲取的經驗。當今各種敏捷、scrum開發方法大行其道,可從本質上來說,也是對軟體工程管理的改進,希望能夠及時、快速的交付更好的軟體產品。

書中多次談到如何決定產品的優先順序。當產品面對非常多特性的時候,我們究竟是要全部完成還是只完成一部分。從scrum開發來說,解決方案非常明確的。我們每個月甚至每兩周收集專案的需求,然後對需求做綜合的評價,決定未來乙個月需要完成那些特性或者專案。如果我們把不重要、或者把當前緊急的專案給擱下了,事後上峰review專案進展的事後,肯定會追究責任的。不過這種優先順序排定也有弊端,比如一些可以改進使用者體驗,但是不重要的事情,很難排上日程。這也是大**某些時候使用者體驗改善慢的原因。

scrum開發方式,scrum master是乙個強調溝通的工作。需要和組員溝通工作、檢查進度、發現問題;和測試協調資源;和產品經理溝通需求,組織需求pk會;和專案相關的團隊討論各種需求。

在微軟,也強調建立學習型組織,講究在工作過程中帶領新人。通過「午餐會、休假會、轉崗」等到方式促進團隊的學習和交流。而我們有明確的師兄帶領徒弟的工作。我們會組織各種分享、講座分享經驗。我們甚至有內部的技術大學、講師來傳遞知識。在這一點上,我們比微軟走的更遠。

在微軟,提到乙個合適的軟體交付日期是有用。因為有乙個截止日期,會強迫大家對工作設定優先順序,對不重要的需求可以先砍掉再說。我們在這方面有一定的經驗,但是專案的延期明顯很多。都說是通過一線開發對開發時間的承諾來保證專案完成的日期,然後各種資源依賴、技術困難導致我們專案的延期。

在微軟強調專案的事後分析,強調自我批評和總結經驗。同時,有專門的人員總結好的經驗,並且主動建議到新的團隊。我們公司也有流程管理人員,貌似也有對經驗的總結。目前來看,一是推廣scrum開發,另外一種是推廣單元測試。還有是推廣各種管理工具如web編譯平台、專案週報和發布管理,還有bug管理、賬號申請等到。 這些都不錯,就是很少推薦其他團隊好的經驗過來。好的經驗、方法,是我們更需要的,而不是增加更多流程、更多的檢查點。 我們團隊自己也做專案總結或者月度總結。每次總結有點、不足和調整,為了防止大家不好意思開口,還讓大家先寫在紙上,彙總之後再討論。最有建設性的意見是整理**規範,指令碼的模板,整理了一批shell常用的函式。最後我發現,時間和資源的矛盾會經常出現。

在微軟強調code review,我們同樣重視。不過強調的是兩個dev,乙個test,3個人一起review,甚至要求架構師或者專家一起review**。**review,通過會反饋很多問題。甚至少了一行注釋,少了乙個空格之類,非常嚴格。經過了code review,最大的感觸是覺得自己有很多的不足,還有很多需要改進。

曾經通過會議review**,這種方式效率非常低下。首先很多人不清楚專案背景,需要先講清楚背景,說明實現的基本原理,最後才是真正的看**。由於多數人沒有做準備,這種review是乙個馬拉松式的折騰。從經驗來看,最好是完成乙個模組就做一下review,而不是專案完全完成之後再做。

在測試階段,我們強調上線手冊清晰、完整、有效,要求有code review的結果,絕對不能有「版本驗證錯誤(bvt bug)」,也就是不能安裝執行的情況。不過很難有完整的測試文件,估計這是因為網際網路行業的緣故。

最後在晉公升方面,也講述了微軟自己的方案。開發、測試等等有管理和技術的發展通道,各自都有自己的發展渠道和級別。在微軟,貌似開發的地位是比較高的,只做技術,照樣可以過的非常滋潤,甚至讓人「妒忌」。

讀《微軟的秘密》有感 辛苦中有些收穫

微軟的秘密 有感 今天終於可以看完 微軟的秘密 了,這是一本非常難讀的書,需要你去思考和帶著問題去讀,如果你對軟體開發過程不是很感興趣,奉勸你不要讀了,因為你一定會覺得異常枯燥。當然,我之所以能夠讀下來,而且認真努力的進行研讀兩遍,的確是希望能從微軟的開發流程和方法上得到一些體會,然後應用到公司的研...

對專案質量的無止境追求 讀《微軟的秘密》有感

2010年在成都三官堂買的 微軟的秘密 這兩年陸陸續續看了幾次。如同 走出軟體作坊 的作者阿朱說的一樣,每看一次都有一些感想。這本書寫的是微軟90年代及其之前的開發經驗,但是對我們當前的開發來說,仍然有很多值得汲取的經驗。當今各種敏捷 scrum開發方法大行其道,可從本質上來說,也是對軟體工程管理的...

關於研發過程中的思路

一般我們在研發過程中,控制會議,會遇到很多問題。有些人看的很長遠,但是過於理論化,實際實現起來,成本過高,這就是我們常說的over design 有些人只看眼前,認為能用就行。這時候主持人要思路清晰,匯集各方的精髓於己,加工運用。以下是個人的思路 臨時方案 最終方案 過渡方案 從臨時過渡到最終的方案...