最近在與一位總經(jīng)理交流的時候，他談到他們公司的軟件研發(fā)管理，說：“我們公司最大的問題是項目不能按時完成，總要一拖再拖?！彼麊栁矣惺裁崔k法能改變這個境況。從這樣一個問題開始，在隨后的交談中，又引出他一連串在軟件研發(fā)管理中的遇到的問題，包括：
. 現(xiàn)有代碼質(zhì)量不高，新來的開發(fā)人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦?
. 重構(gòu)會造成回退，怎樣避免?
. 有些開發(fā)人員水平相對不高，如何保證他們的代碼質(zhì)量?
. 軟件研發(fā)到底需不需要文檔?
. 要求提交代碼前做Code Review，而開發(fā)人員不做，或敷衍了事，怎么辦?
. 當有開發(fā)人員在開發(fā)過程中遇到難題，工作無法繼續(xù)，因而拖延進度，怎么解決?
. 如何提高開發(fā)人員的主觀能動性?
其實，每個軟件研發(fā)團隊的管理者都面臨著或曾經(jīng)面臨過這些問題，也都有著自己的管理“套路”來應對這些問題。我把我的“套路”再此絮叨絮叨。
1. 項目不能按時完成，總要一拖再拖，怎么改變?
找解決辦法前，當然要先知道問題為什么會出現(xiàn)。這位總經(jīng)理說：“總會不斷地有需求要改變和新需求提出來，使原來的開發(fā)計劃不得不延長?！痹瓉砣绱?。知道根源，當然解決辦法也就有了，那就是“敏捷”。敏捷開發(fā)因其迭代(Iterative)和增量(Incremental)的思想與實踐，正好適合“需求經(jīng)常變化和增加”的項目和產(chǎn)品。在我講述了敏捷的一些概念，特別是Scrum的框架后，總經(jīng)理也表示了對“敏捷”的認同。
其實仔細想想，這里面還有一個非常普遍的問題。對于產(chǎn)品的交付時間或項目的完成時間，往往由高級管理層根據(jù)市場情況決策和確定。在很多軟件企業(yè)中，這些決策者在決策時往往忽略了一個重要的參數(shù)，那就是團隊的生產(chǎn)率(Velocity)。生產(chǎn)率需要量化，而不是“拍腦門子”感覺出來的。敏捷開發(fā)中有關(guān)于如何估算生產(chǎn)率的方法。所以使用敏捷，在估算產(chǎn)品交付時間或項目完成時間時，是相對較準確的。Scrum創(chuàng)始人之一的Jeff Sutherland說，他在一個風險投資團隊做敏捷教練時，團隊中的資深合伙人會向所有的待投資企業(yè)問同一個問題：“你們是否清楚團隊的生產(chǎn)率?”而這些企業(yè)都很難做出明確的答復。軟件企業(yè)要想給產(chǎn)品定一個較實際的交付日期，就首先要弄清楚自己的軟件生產(chǎn)率。
2. 現(xiàn)有代碼質(zhì)量不高，新來的開發(fā)人員接手時寧愿重寫，也不愿意看別人留下的“爛”代碼，怎么辦?
這可能是很多軟件開發(fā)工程師都有過的體驗，在接手別人的代碼時，看不懂、無法加新功能，讀代碼讀的頭疼。這說明什么?排除接手人個人水平的因素，這說明舊代碼可讀性、可擴展性比較差。怎么辦?這時，也許重構(gòu)是一種兩全其美的辦法。接手人重構(gòu)代碼，既能改善舊代碼的可讀性和可擴展性，又不至于因重寫代碼帶來的時間上的風險。
從接手人心理的角度看，重構(gòu)還有一個好的副作用，就是代碼重構(gòu)之后，接手人覺得那些原來的“爛”代碼被修改成為自己引以自豪的新成就?！禨crum敏捷軟件開發(fā)》的作者Mike Cohn寫到過：“我的女兒們畫了一幅特別令人贊嘆的杰作后，她們會將它從學校帶回家，并想把它展示在一個明顯的位置，也就是冰箱上面。有一天，在工作中，我用C++代碼實現(xiàn)了某個特別有用的策略模式的程序。因為我認定冰箱門適合展示我們引以為豪的任何東西，所以我就將它放上去了。如果我們一直對自己工作的質(zhì)量特別自豪，可以驕傲地將它和孩子的藝術(shù)品一樣展示在冰箱上，那不是很好嗎?”所以這個積極的促進作用，將使得接手人感覺修改的代碼是自己的了，而且期望能夠找到更多的可以重構(gòu)的東西。
3. 重構(gòu)會造成回退，怎樣避免?
重構(gòu)確實很容易造成回退