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