如何將項目的開發(fā)掌控好是技術(shù)領(lǐng)導(dǎo)（Team Leader）必須做好的。何為掌控項目的開發(fā)，即開發(fā)的進(jìn)度和質(zhì)量在計劃內(nèi)，不在期限快到時慌手慌腳，也不需交期到時天天加班，更不能刪減測試時間?？偠灾褪情_發(fā)工作有節(jié)奏，按部就班到達(dá)預(yù)期目標(biāo)。
理想總是好的，可現(xiàn)實總是殘酷的。你有過每個周六都加班，每晚都加班的經(jīng)歷沒？你有項目完不成，接二連三申請延期發(fā)布的經(jīng)歷沒？你有過遇見過你委以重任，但他卻誤了你事的同僚沒？如果你工作了一段時間，又恰好又有帶過小隊伍的經(jīng)歷。我想你應(yīng)該也遇到過這些問題中的一個或幾個吧。
我當(dāng)然也遇到過，一回是將一個很重要的功能組件重寫的任務(wù)分派給一個新的團(tuán)隊成員，給予了我能給的最多資源，并將其他任何任務(wù)，可能的干擾源我都給擋了。但結(jié)果呢，開始我還滿懷希望，因為他非常自信，也不斷的給我好消息，比計劃更快更好。但時間過去一半也就是約兩個月后，痛苦開始來了，他創(chuàng)建了一個新的分支，因為接口變了，無法和其他組件集成構(gòu)建，而這一切我之前竟然不知道。但離版本發(fā)布已經(jīng)只有2個月時間了。這還包括測試。而該模塊功能上都還只完成一半的樣子，而且完全拋棄了原有做法。更慘痛的是兩個星期后他離職了，面對不能集成，功能不全的半成品真是欲哭無淚。最后版本發(fā)布時，此過程中代碼僅作參考，而使用舊代碼修改版本，預(yù)期的一些功能沒有，預(yù)期的效率提升沒有，還加班一段時間。這也是我的軟件開發(fā)歷程中最大的遺憾。
事后，我總結(jié)了該次技術(shù)事故的教訓(xùn)，但沒有及時發(fā)貼。現(xiàn)在做一下簡單的總結(jié)，如何避免此類事故的發(fā)生。
一、認(rèn)識問題
在將較大的模塊分配之前，必須確保模塊主人明確了需求，了解了問題。很多程序員有一拿到問題立馬動手的沖動，此時你至少應(yīng)保證他看到了所有的問題。此步絕對不能省略，你不能假設(shè)他自己會去找需求，他能找到需求。你也應(yīng)該將你對需求的認(rèn)識，你從全局上的觀點傳遞給他。
二、搭架子
在甩手出去的工作，尤其是較重要的模塊給一個不了解的人的時候。必要的模塊架構(gòu)設(shè)計是不能少的，這個時候你可以了解他的思路；討論中提升設(shè)計的質(zhì)量；更重要的是可以從整體的角度評判設(shè)計是否合理，是否可以和其它模塊較好的工作。同時還可以減少模塊開發(fā)人員的困惑，減少獨自摸索的時間。
三、分解工作
在架構(gòu)設(shè)計的基礎(chǔ)上，將工作分解開來，獨立出來一段一段做。分解時最好和開發(fā)人員討論，他在細(xì)節(jié)上可能會比你更清楚。
a. 工作項的大小。從經(jīng)歷來看每個工作項1-2周比較妥當(dāng)，時間太長不利于管理時間，也較難準(zhǔn)確預(yù)估。太短又太細(xì)，而且有些事情又沒那么容易做完做好，此外還可能涉及其他方面的修改。很多人習(xí)慣做完任務(wù)就不管了，也沒有足夠的時間測試，調(diào)整。
b. 工作項的獨立性。必須保證每個工作項的獨立性，可以單獨開發(fā)，單獨集成。每一到兩周將代碼集成編譯并做簡單的集成測試（保證主體不受影響，新增功能有效）。
四、及時跟蹤設(shè)計，時間，代碼
先說設(shè)計上的跟蹤，在新成員剛參與時。可以要求必要的設(shè)計文檔，如類圖，核心部分的序列圖。再就設(shè)計與程序員討論我們現(xiàn)有的設(shè)計樣式，使設(shè)計與已有設(shè)計有一定的相似性。并可借此機(jī)會培養(yǎng)新成員的設(shè)計水平和設(shè)計方法。此討論可以多討論一些OO，設(shè)計模式什么的。不一定要用，但要有用的準(zhǔn)備和用于不用的判斷。
時間上的跟蹤，主要是每周的周會，周會上可以依照總的時間安排和工作進(jìn)度一起簡要討論，讓大家心中有底。此外還有每周的工作安排和回顧，新成員可以要求寫細(xì)點，每周要有兩到三個檢查點，及時跟蹤。出現(xiàn)問題可以及時發(fā)現(xiàn)。
代碼上的跟蹤，主要
是要求在最新代碼上開發(fā)，保證有交互的組件可以正確編譯。此外新成員要在開始一段時間對代碼進(jìn)行Review，保證編碼符合規(guī)范。模式和已有代碼一致。
另外就已有組件的修改，可以要求逐步改進(jìn)，使用橋接或其他方式逐個替換進(jìn)新的模塊。
很晚了，先就想到這了，歡迎大家提出好的想法。到時我再抽時間補(bǔ)充完整。