資深專家談現代軟件工程（續）

　　能不能具體介紹一下你們公司在組織和人員劃分方面的情況。

　　鄒濤：

　　目前有產品經理、項目經理、項目開發人員、測試經理、文檔，還有最基本的五個模塊，要細分還有很多角色。

　　提問：

　　我想問一個企業文化方面的問題。軟件工程里面涉及到管理和人的問題，金山公司在國內軟件業做得是最好的，管理和人還有激情，因為做軟件過程中，激情是很重要的東西，你們在管理過程中如何協調管理、人和激情這三者之間的關系呢？

　　鄒濤：

　　這個問題我只能從我自身來反應一下，可以說在中國惡劣的軟件環境下，會來從事軟件開發的一定是對軟件充滿熱愛的，很有激情的，所以任何一個加入軟件公司的年輕人當他剛剛走進這個大門時，他肯定充滿激情的，但這種激情能維持到多久，這就涉及到對人員的管理。我們公司按我們雷總說金山是一個舞臺，你在這個舞臺上你唱戲，能唱多大就唱多大。這就是金山給員工一個非常好的前景，只要你愿意去做，只要做好，你就有前途的，我們的管理就是基于這個思想，緊緊圍繞這個思想。

　　楊永生：

　　微軟招人的時候會看看你是不是想做這個事情，還是僅僅因為是微軟才來應聘。另外靠一套完整的機制，包括獎懲激勵機制，以及使每個人感到被尊敬的公司文化。如果他有什么想法，可以加入產品中，或者可以去高層反映，主要是指這兩方面。

　　王東臨：

　　我理解他的問題是指軟件開發在很大程度上還是有一定創造性的勞動，如何在規范化可重復性的過程中，避免對創造性的壓制。

　　楊永生：

　　如果你僅僅是這個，因為在微軟如果到特性組一級，你完全可以做一些自己決定，按照自己的做法做產品。只要你自己在技術方面能實現的話。

　　王東臨：

　　比如說做文學創作，像現在寫電視劇一樣,集中幾個人,要求多長時間寫出幾十集劇本，工廠式地生產電視劇，那就很難寫出像《紅樓夢》這樣優秀的文學作品來。同樣像很規范化的軟件開發管理過程中，如何既保證它的質量，也能有很高的創造性產品出來？

　　楊永生：

　　第一給他做好的機會，另外微軟你可以內部輪換，你有很多工作機會，如果你做得好你可以做別的事情，如果你真的有想法，并且得到別人的認同，你也可以開展項目，這種事情是有的。象Xbox，原來實際上是幾個工程師閑暇時間做的東西，只要他能說服上面說這個東西確實有市場、有生命力，你就可以把這個想法變為一個產品。

　　提問：

　　剛才微軟那位先生說，軟件開發過程跟電影行業這是一個挺好的比喻，因為都涉及到人，但是人的能動性都在里面，但是軟件開發過程中可能跟拍電影有些類似，有一些時候我們所謂的軟件高手，好比我追求一種共性，追求一種工程化的東西，就要抹煞一些個性，因為每個人都有鮮明的個性就很難有共性了。怎么在開發過程中，特別像金山公司微軟公司，在開放過程當中怎么把程序員，特別國內的程序員一般自視清高的現象特別嚴重，怎么把個性和公司整體，包括項目產品追求的共同利益結合起來，因為有的情況在產品過程中追求最大的共性，追求產品的特性，而必須要犧牲一部分人自認為非常好的想法，這是一種矛盾，而這種矛盾多了對公司本身也不是很好的事情，那么二者是怎么有機地調和的？

　　鄒濤：

　　這種問題我們也經常碰到。你開始講了大家都是很有個性的人走到一起來，事實上最后大家還是要慢慢的有一部分的共性，因為大家是在一起做事情，如果大家我說這樣做，你說那樣做，這樣很難在一起合作，很難做出產品來。所以我們對程序員都有規范的要求，當然你可以有自己的想法，想法是想法，但是在編寫的規范，或者其它流程方面你一定得遵守，你的想法可以用規范表達出來并不會規范規則，因為你產品涉及到不是說做完就扔在那兒不管的，它需要后期的維護或下一代版本的，所以它的可讀性和可維護性是非常重要的問題。我們公司處理基本就是這樣的，還是需要你個性稍微收斂一點點，融到共性當中去。如果你的想法特別新穎獨特……

　　我還是沒有搞清楚他的是想法還是行為？(回答：行為)行為又表現在他編程的行為還是為人個性的……這個不好說。編程行為肯定是協調一致的，你的想法實現的方法很奇妙，當然大家就用你這一套，這是不矛盾的。如果你這個人個性比較古怪，很難和人合作，這個我們基本上不會把他放到團隊當中來。

　　提問：

　　項目經理他寫出需求文檔，他定出詳細技術規范，這個技術規范會詳細到什么程度？

　　鄒濤：

　　我得說明一點，剛才楊先生說的我理解，我們這個公司是什么，項目經理寫的并不是編程規范，編程規范是程序員日常編程的準則，項目經理寫的是針對產品來說，根據用戶需求分析，然后設計出功能點定的規范。假如你有一個窗口，點這個紐它會產生什么結果，是這個規范，而不是技術代碼怎么寫，這兩個規范是完全不一樣的。

　　楊永生：

　　產品說明規范比這個更詳細一些，最簡單的可能對話框什么樣，最復雜的有些可能會涉及到可能用哪個函數去實現可能更合適一些，前提是把這個問題描述得特別清楚，開發人員看到了以后，可能會去設計算法，或者能去做，而不會反過來再問你。

　　提問：

　　說到算法，軟件開發過程中，軟件有兩個大類，一種要求是技術，技術含量特別高，第二技術難度不是很大，但是需求特別大，軟件工程概念是不是特別適合技術難度不是特別高，但是需求特別多特別復雜的需求。如果涉及到一個算法，像微軟做的多媒體方面，比如這方面的編寫，這種算法和這個過程來說是不是用到軟件工程的概念？

　　周之英：

　　我想軟件工程對于所有的軟件來說，各種情況都是有用的。不光是對特別簡單的。但是在一些比較復雜問題的時候，可能你不是那么容易得到一個機械的步驟直接就到底了。軟件工程主要幫助你解決一些無效的工作，提高你的效率，并不是替代你的工作，就是把一些混亂的東西變成有條理。所以如果你有創意：有些人創意一會兒想到東，一會兒想到西，比如想到17、8遍，最后想出一個解決方案。如果你有軟件工程的思想規律，可能你就會縮短這無效的搜索途徑，你可能就會更直接地得到它，減少中間很多不需要、不必要的工作。應該從這角度來理解。不要把軟件工程看成一個架在你頭上的緊箍咒，這是你自己加的，何必呢？

　　我隨便舉一個例子，咱們國家大學里對學生的軟件工程訓練很少。這不光是中國的情況，現在國際上也在討論，就是大學里面教了學生編程語言，但是沒學習怎么達到工程化要求。有幾個人和我一起工作，我規定他們兩禮拜給我一次書面報告，簡單說明做了哪幾件事情。對報告中問題我可馬上返回給他們。他們從電子郵件送來的文件，愿寫什么名字就寫什么。我覺得很麻煩，今天“DZI.doc”，明天“設計.doc”。單看機器的文件夾，我搞不清楚那個文件是早期的，那個是后來的、是誰的、是什么內容。我就要求每一個文件規定命名方式：姓加上內容性質，是小結就寫小結，是設計寫設計，是需求寫需求，后面是日期，如果你這一天來了兩份，第二篇再杠一杠二，這樣就很清楚了。這就反映軟件工程。他們頭一天這么交來了，過了一禮拜又來了“DZI”了。這是什么呢？這不光是簡化我的工作問題，而是簡化你自己工作的問題，在自己機器中這一次報告跟另一次到底有什么差別，為什么我把你的報告退回去，自己可以有一個清晰的記錄。這就是軟件工程。軟件工程的思想就是把你無效的勞動去掉它，一查，可以查到我想要的東西。所以種種規定要來幫助你，你說束縛了我的創造力，我的文章名非要寫“DZI”，這何必呢？這么來看軟件工程是什么，就有很多好東西來幫助你。至于是不是需要每一個文檔都要規定：首先要寫什么名詞解釋，第二是總體目標什么，這倒不一定，看你具體情況，有一些情況需要，有一些情況不需要。有很多東西，關鍵是你要掌握它的思想。它是要把你的無效勞動去掉，幫助你自己總結哪些是你的有效勞動，哪些是你的無效勞動，把這些東西弄清楚。

　　主持人潘加宇：

　　下一位主講嘉賓是摩托羅拉全球電信解決方案部網絡方案技術中心的高級經理胡大慶。摩托羅拉網絡研發中心已經在2000年通過了CMM5的評估。CMM是目前國際上最實用的軟件開發過程標準，和軟件企業成熟度評估標準。目前我們國內一共有兩家企業通過CMM的評估，兩家都在摩托羅拉，另外一家摩托羅拉的中國軟件中心。胡大慶先生畢業于清華大學，多年來一直在中國、日本和美國公司從事軟件開發和管理工作，網上有一篇被大量轉載的文章，文章題目叫做《實施CMM是一條沒有終點的路》，胡先生在文章里面發表了許多精辟的見解。他今天發言的主題是《CMM與軟件過程改進，需求管理及軟件產品，質量保證》�，F在有請胡大慶先生。

　　摩托羅拉網絡方案技術中心高級經理胡大慶：

　　大家好。很高興有這樣機會，因為過去雖然都是中國人，都在海淀區，在中關村這一帶，但是隔離還是比較大，交流機會很少，今后多增加這方面的交流。因為從任何意義上講我們也是一個本地的公司，從國家信息產業部的文件規定，像我們公司的性質也應該納入到國家軟件行業管理的規范之內，從人員構成來講，現在百分之百都是本地人或在國內受過教育。

　　我剛才也聽了像周老師講的觀點,我非常贊成。我們在實施過程中是在2000年初，也請周老師給我們做過軟件工程的課�，F在經過不同的渠道，我們在第一線進行實踐，周老師在理論上繼續進行深入研究。但是我剛才聽了一些觀點非常一致，我也感覺有一些安心。

　　剛才大家的問題好象更多的是在企業管理和運營方面。今天也不是專門來討論CMM，我只是把軟件工程具體實現方法的其中一種可能選擇CMM，這方面稍微談一談。

　　我覺得你是否選擇CMM，或者有些企業已經用了ISO，或者其他的標準都是可以的，而且可行的，而且相應收到效果的。對于CMM，我希望大家應該有一個正確的認識，有一種看法應該糾正，我不是說在座，至少是社會上有很多人有這么一個想法，就是說比較簡單把CMM作為一個認證，就像ISO這樣，實際上CMM絕對不是一個認證，CMM它有五六個特征，它其中有一個可以作為認證的標準，但是現在我們過于突出了這一個特征了。所以如果你沒有一個具體的按照CMM的框架，按照它的目標來實現，沒有實踐積累的情況下，單純追求第幾級是非常危險的是事情，有可能導致你企業原有正常的運行機制失敗，因為CMM的引入有可能要求你做很大的改動，任何企業原有的一套制度方法是基于實踐很有價值的，如果你把它輕易放棄，引入另外一套東西是非常危險的。所以我覺得CMM更多的要具體的實踐，看是否符合你企業的需求，在一段時間之后，自然而然你可以把它作為一個手段去檢驗你目前達到的水平。

　　另外CMM確實不是盡善盡美也不是包羅萬象，CMM從出來也不斷版本更新，它還是代表了廣泛的軟件行業的共識。它是通過一些統計的規律顯示出采用CMM后對企業帶來的好處，或者如果我們對過程改善作出努力的話，CMM可以是一個比較有效的工具。就是說這工具是不是特別適合你，或者說你使用了工具肯定有效，這也沒有任何人來保證。