讀《移山之道》 去“移山”

 

   軟體工程課老師讓我們選一本教材，分別是《代碼大全》、《快速軟體開發》、《移山之道》 。作為初入茅廬的人，對三本書沒有先驗知識的情況下，對比了這三本書，最後選擇了《移山之道》。

· 為什麼我選擇《移山之道》？

   1. 《移山之道》名字讀起來霸氣外漏，所有人很喜歡物超所值，尤其是中國人，看著名字，好像是講方法的，”道”是個很高深的問題，淺可達到方法，深可達到哲學。加上老師推薦，這本書應該不會差，所以首先名字吸引 了我。

   2. 看著厚厚的《代碼大全》，裡面教你如何寫代碼，如代碼布局、注釋、測試等等，在原本時間不是很充裕的時候我果斷放棄了。而《快速軟體開發》雖不是很厚，但是對比《移山之道》還是不行，而且移山之道有插圖，很不錯的插圖，看起來頗有意思。

   3. 當然快速對這些書時，發現《移山之道》是以愚公移山為背景，類比情境，同時語言頗具獨特，網路用語、文言文、歌詞、現代詩等應有盡有，看起來很誘人。

     基於以上三點，我選擇了《移山之道》。當然我們是來學習的，不是看熱鬧的，也對此書表示懷疑，我們上軟體開發，作為教材這本書靠譜麼，噱頭搞那麼大，學不到東西時間豈不是白費了。就這樣半信半疑的開始讀了此書。

     由於軟體工程其實是一門最注重實踐的學科，脫離了實戰，再好的方法都是浮雲。軟體工程在繼續，書也在讀，實戰和閱讀中都遇到不少問題。下面就簡要談談我的問題、以及我的想法。

搜尋引擎裡搜“軟體工程中最大的難題”，很多情況下搜到的都是溝通問題，起初我感覺也很疑惑，但是通過一起daily scrum，一起討論問題，個人基本上都有個人的想法，一旦想法出現偏差，最後都會反映到代碼裡，產品裡面。

     同時在第二章“白話MSF方法論”時提到MSF（Microsoft Solution Framework）有8個基本原則，第一條就是 推動資訊共用與溝通（Foster open communications） 可見資訊溝通在MSF也佔有很重要的位置。

· 那麼如何解決？

      當然我們可以藉助TFS進行協助，如TFS裡面所有的資訊都是保留的，公開的，就像銀行賬戶裡的資金流動記錄，是不可以刪除的。這個外在客觀的限制，確實實現了代碼和bug的公開。當然除了TFS這種強有力的公開溝通工具之外，我們還有辦公軟體email,可以發郵件，可以預約會議，電話，以及daily scrum ，也可以通過communicator 聊天工具進行溝通。但是這些都是工具，如何解決其實還很大一部分依託於PM（專案經理）

   從這幅圖可以看出PM是一個紐扣，是上層老闆，客戶以及團隊的樞紐，一旦任何一個環節出現溝通出錯，就會導致工程無法進行，因此PM在團隊中起著舉足輕重的地位。

  但是PM坐在核心的位置，會不會危險係數很高？ 其實，一個良好的Team Dev，就應該降低團隊的風險，避免團隊中出現不必要的溝通問題。這時我認為前期的計劃是很關鍵的一個步驟

       前期的計劃是完全按照使用者需求，完全按照可行性，完全按照團隊的規模，團隊的水平定位的，一旦前期能夠有合理的定位，合理的計劃，就要按著計劃一步步走下去。前期的計劃是大家共同達成的共識，而且最後會分配成Task 匯入到TFS的Work Item。只要前面的計劃合理而有效，那麼後期的開發就很容易了，只需要按照Work Item進行工作，可以只看這些小的work. 但是PM在這裡就不能閑著沒事，這時要做好團隊的溝通，時刻觀察每個程式員的狀態，觀察他們的進度，觀察他們遇到的問題，站在高層，保證團隊的整體進度，保證團隊的整體工作效率。

       當然專案經理不能對工作進行簡單分解，雖說簡單分解會造成工程管理的方便，但其實這種共層這種工程管理方式看似方便，似乎也很符合模組層層細分的“工程方法”，其實是最低級的。因為一旦有問題就必須從頭開始推倒重來。

        專案經理不能強拉硬套，感覺自己是經理，就很牛，就可以那上級對下級的態度對程式員進行高要求，一旦達不到就當眾羞辱等等。專案經理我認為應該站在地位的最底層，但是思想的最高層。地位的最底層，可以讓大家一有棘手的問題，就可以提出，而不必害怕專案經理，讓程式員做到真正的自己，而不必考慮其他因素。這樣，PM掌握了第一手程式員的狀態，便於協調、預防問題、解決問題。思想的最高層，PM要懂得最佳化，要懂得一個問題的嚴重性，一個問題所產生的影響，甚至是幾個問題產生的影響。時間和進度怎麼最佳化這個函數，只有這樣，才能把問題看透，才能分配任務的優先順序，快速而又合理解決問題。

· 考核指標太剛性了，怎麼辦？

      程式開發的工作因為具有複雜性和不確定性，工作難以量化等原因，導致開發人員的具體進度往往是預估，是以個人經驗、個人能力預測等多種因素影響的，具有很大的不確定性，單純的從進度去考量開發人員“進度”指標，可以說是不公平的，尤其是我們剛剛踏入軟體工程，對開發不是很熟悉，但是進度往往是我們的管理層（老闆）和專案經理決定，做技術層面對進度的決定權不大。而進度恰恰是由在第一線工作的程式開發人員來完成的，有可能項目要求一個比較模稜兩可的進度要求，而項目團隊不得不接受。 網上有不少統計資料，比如在美國本土的軟體開發項目中，有超過70%的項目延期，近31%的項目因為進度原因而不得不終止或放棄。

因此完全固化的進度考核容易引起人員疲勞、士氣低落、主動性降低，從而影響項目團隊的穩定性。

如何解決呢？

       在《移山之道》這本書中衡量員工工作品質中（DEV）中其主要衡量兩個指標

（1） check in 的品質，也就是簽入破壞構建的次數

（2） 功能是否按期完成，如果延期，是否提前交流

      為了團隊的整體利益，我們肯定要努力按時完成計劃，必須體現剛性的一面，但是如果DEV確實態度很認真，任務沒有完成，如果延期，那麼肯定要有一個合理的機制，其實也就是交流和協調的問題。當一個問題跨不過去，那麼應該及時想PM報告，讓PM初步評估這個任務的優先順序，影響如何。如果優先順序高，及時找其他人員幫忙解決。當然平時開發人員也應該做些軟體開發培訓等。

結合書本和實踐說了兩個比較常見的疑惑下面就談談這本書中一些有意思的東西

· 問渠那得清如許，唯有源頭活水來？

     作者在此書中旁徵博引，引用的東西雖不能一個一個查詢是否正確，但是每次讀到時候，感覺一種現代的軟體工程和中國哲理結合起來，或者給我的感覺是中國文化之博大精華，在軟體工程中都能體現的淋漓精緻。

開篇，作者就直接引用了朱熹的《觀書有感》“問渠那得清如許，為有源頭活水來”。

    不是很理解，因為前八章都是VSTS與MSF基礎， 書的“源頭”是什嗎？書的“清如許”。 其實VSTS 是微軟多年開發經驗的一個工具，MSF是一個方法論，照著這種理解，估計就很容易了，MSF既然是方法，那應該是源頭，只有高層的方法務實，可行而且有效，那麼就會有源源不斷的活水。而且可以把VSTS看成“水渠”，按照“水渠”尋根問底，追朔源頭，便可找到MSF。 微軟在IT行業當老大也很多年，總結的產品團隊開發經驗和教訓應該是經過無說驗證的，所以這個源頭應該是很純的，經得起時間考驗。

    英語文中有 you can move mountains 作為創造奇蹟的表徵，中文中有愚公移山之傳說。作者軟體工程的具體實施比作移山之艱難。但是移山又是人類進步的階梯，要想富，先修路，把道路清空，把前面的大山移走，意味著軟體工程的開發是多麼有意思，趣味無窮。在這萬千艱難中，作者給了的“法子”是兩個東西：MSF和VSTS。前者，是思想理念，後者則是方法工具。

     此書確實有創意，但是由於剛接觸軟體開發，書中很多問題，很多話都沒有感覺。所以不敢妄下評論，但是網上評價都很好。書中作者寫了這句話：“我曾向大學軟體學院推薦這本書，得到反饋是，這本書“太活了”，不宜用於教學。”呵呵，可能確實太活了，裡面談古論今，裡面“談情論事”，裡面“引詩用典”，裡面“中西結合”。曆史扯上了，愛情扯上了，歌詞扯上了，名人扯上了，國外扯上了，最後核心的東西是軟體工程。如果，高校引用了這本教材，讓教師們情何以堪呀？

     最後一點很觸動：這本書的作者竟然在業餘時間把這本書完成的。平時作為項目開發經理，大家知道肯定很忙，真不知道作者的時間是怎麼擠出來的。表示好奇，表示欽佩。

 

by Haifeng Liu