1. 前言

　　本人曾就職于多家公司，但留給我印象最深刻、開發(fā)管理最規(guī)范的公司是I公司。該公司總部位于美國(guó)硅谷，其開發(fā)的產(chǎn)品曾獲得PC Magazine的最高五星級(jí)的優(yōu)秀好評(píng)?，F(xiàn)我根據(jù)在此公司中所感受到的經(jīng)歷及自身的一些感想寫出來，希望能給大家和其它公司有所借鑒。

　　2. 項(xiàng)目計(jì)劃

　　在一個(gè)產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方?？蛻粼谑褂玫倪^程中會(huì)發(fā)現(xiàn)一些問題，提出更高的需求，市場(chǎng)也在發(fā)生變化，我們的競(jìng)爭(zhēng)對(duì)手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動(dòng)著我們的產(chǎn)品不斷地向前發(fā)展，使它的版本不停地往上增長(zhǎng)。這些發(fā)展的需求不是一下子提出來的，在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方，他們會(huì)向我們的技術(shù)支持人員提意見，而技術(shù)支持人員會(huì)把這些需求以BUG的形式存入BUG數(shù)據(jù)庫(kù)中，其級(jí)別一般定義為下一個(gè)版本的Feature。有些上一個(gè)版本未解決的BUG也可能需要在本版本中來解決。因此當(dāng)我們來開發(fā)下一個(gè)版本時(shí)，其許多特性已經(jīng)存在于BUG數(shù)據(jù)庫(kù)中了。當(dāng)然新版本的特性不是只從BUG中獲得，管理層可能從市場(chǎng)的角度來提出新的特性以求領(lǐng)先競(jìng)爭(zhēng)對(duì)手，開發(fā)人員本身也可提出某些要求來納入新版本開發(fā)的計(jì)劃中，如要求對(duì)某部分代碼進(jìn)行重構(gòu)以使其結(jié)構(gòu)更清晰更容易維護(hù)，執(zhí)行效率更高。

　　每個(gè)人把同自己相關(guān)的功能模塊收集起來，同時(shí)預(yù)估時(shí)間，其中主要包括寫文檔的時(shí)間、開發(fā)時(shí)間和單元測(cè)試的時(shí)間，一般要求精確到工作日。這些信息發(fā)送給組長(zhǎng)，組長(zhǎng)再把本小組人員的任務(wù)和預(yù)估時(shí)間發(fā)送給管理層，由管理層對(duì)此任務(wù)及進(jìn)度進(jìn)行評(píng)估審核，管理層會(huì)根據(jù)產(chǎn)品發(fā)布時(shí)間及客戶需求、市場(chǎng)因素等方面作出選擇，可能某些功能由于時(shí)間緊急會(huì)被推遲到下一個(gè)版本中去。若預(yù)估出來的時(shí)間同預(yù)計(jì)的產(chǎn)品發(fā)布時(shí)間有較大沖突，而且此功能是本版本中必須得做的，則開發(fā)小組會(huì)被要求重新預(yù)估時(shí)間，加快開發(fā)速度來達(dá)到這個(gè)要求。

　　雖然這個(gè)開發(fā)進(jìn)度時(shí)間是一個(gè)大概的估計(jì)時(shí)間，但我們要盡力按照這個(gè)開發(fā)進(jìn)度來執(zhí)行。每個(gè)星期五下午我們有一個(gè)Status Meeting(一般那時(shí)工作效率較低，適合開會(huì))，在此會(huì)議上我們會(huì)根據(jù)這個(gè)進(jìn)度來review我們的工作，每個(gè)人手上的工作是否按照這個(gè)進(jìn)度在走，是否有人延后了，是否block住別人的工作了。在此會(huì)議上每個(gè)人都要報(bào)告自己的進(jìn)度，同時(shí)還要報(bào)告上個(gè)星期做了什么，正在做什么，以及下個(gè)星期打算做什么。通過這個(gè)會(huì)議，會(huì)讓你覺得有人在監(jiān)督你，無形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會(huì)盡早發(fā)現(xiàn)而趕上。若某些經(jīng)過努力不能趕上，那也沒有辦法，只能修改原先的進(jìn)度表，因?yàn)槟鞘俏覀兊墓烙?jì)與現(xiàn)實(shí)發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實(shí)際情況，這可以避免許多項(xiàng)目發(fā)生最后的20%的工作量會(huì)占據(jù)80%甚至一直拖后的情況。修改進(jìn)度表的情況我們?cè)?jīng)發(fā)生過，有一次在按照原先的進(jìn)度執(zhí)行到將要完成的狀態(tài)時(shí)突然接到通知由于市場(chǎng)及客戶的原因要求加入另一項(xiàng)重大的功能，這個(gè)功能對(duì)我們程序的結(jié)構(gòu)有非常大的影響，因此我們就要重新制定一個(gè)進(jìn)度來滿足需求。在這種情況下，產(chǎn)品原先的開發(fā)進(jìn)度被打亂，發(fā)布時(shí)間也因此推遲。當(dāng)然這種情況應(yīng)當(dāng)盡力避免，尤其在項(xiàng)目后期產(chǎn)生新的需求，若不得已也應(yīng)重新規(guī)劃進(jìn)度，而不是仍舊依照原先的進(jìn)度去執(zhí)行，因?yàn)槔系倪M(jìn)度已不能反映現(xiàn)實(shí)的情況。

　　3. 開發(fā)文檔

　　在項(xiàng)目進(jìn)度安排中我們已經(jīng)把寫文檔的時(shí)間也規(guī)劃進(jìn)去了，這里雖然是寫文檔，其實(shí)是設(shè)計(jì)程序，整理一下思路與架構(gòu)，磨刀不誤砍柴工，這樣在實(shí)際寫代碼時(shí)會(huì)流暢很多，節(jié)省時(shí)間，因此可以說真正有思想性的東西都在寫文檔這段時(shí)間內(nèi)完成了。當(dāng)然我們這里的文檔格式不象ISO那樣規(guī)定了條條框框，我們的文檔格式相對(duì)自由，基本上能隨意發(fā)揮，但對(duì)于幾個(gè)主要點(diǎn)一般來說是需要說明的。要求寫的文檔能讓他人比較容易地看明白，能把問題講清楚，能反映你的設(shè)計(jì)思想。文檔的數(shù)量也不多，開發(fā)文檔有兩類，一類是function Spec，另一類是Design Document。

　　function Spec中需要寫明的是本模塊完成的任務(wù)，解決什么問題，有什么作用，為什么要這些功能，此外我們還會(huì)添加進(jìn)適用范圍，有什么不足，注意點(diǎn)是什么，還有哪些地方在以后可以進(jìn)行改進(jìn)。在這個(gè)function Spec中不涉及到任何非常詳細(xì)的算法。此文檔不光給開發(fā)人員看，還讓QA及其他成員以及后來的新人能根據(jù)此文檔來了解此模塊的大致功能，同時(shí)也會(huì)給文檔編寫者看，他們會(huì)根據(jù)這些function Spec整理出一份用戶手冊(cè)，告訴用戶此版本中新增了哪些功能，各功能模塊有什么作用，如何使用等信息。因此在我們的開發(fā)過程中function Spec是很重要的文檔，此文檔完成后會(huì)抽出一段時(shí)間同相關(guān)人員及QA一起review這個(gè)文檔，讓QA了解設(shè)計(jì)者的意圖，同時(shí)熟悉新的功能模塊，為接下來的測(cè)試作準(zhǔn)備。如果其中有誤解或不明之處，大家會(huì)提出來探討并由開發(fā)者修正。

　　Design Document中主要描述實(shí)現(xiàn)此模塊所涉及到的主要算法、數(shù)據(jù)結(jié)構(gòu)、類的層次結(jié)構(gòu)及調(diào)用關(guān)系。這個(gè)文檔的閱讀者主要是開發(fā)人員，包括任何想了解詳細(xì)實(shí)現(xiàn)代碼的人，幫助人們理解代碼。在某些功能模塊比較簡(jiǎn)單的程序中，此文檔所描述的信息會(huì)比較少。此文檔不象function Spec要在開始寫代碼前就編寫完成，它可以隨著代碼編寫的進(jìn)行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應(yīng)先修改文檔，然后再修改代碼。

　　4. 編寫代碼

　　由于我們用JAVA語(yǔ)言進(jìn)行開發(fā)，因此我們借助了Jbuilder IDE工具。關(guān)于代碼風(fēng)格，我們基本上套用Jbuilder中自動(dòng)的代碼格式編排，但其中需要改變的是縮進(jìn)是4個(gè)字符，類與類之間間隔2行，方法與方法之間間隔2行，import類時(shí)用完整的類名。寫代碼時(shí)要對(duì)類及函數(shù)提供詳細(xì)的注釋及說明，基本做到看它們的說明就能知道這個(gè)類或函數(shù)的功能以及主要算法的實(shí)現(xiàn)原理。在開發(fā)過程中對(duì)主要的模塊要編寫UnitTest，同時(shí)要UnitTest先行，也就是遵循XP規(guī)則中的測(cè)試驅(qū)動(dòng)原則，當(dāng)所有的單元測(cè)試代碼通過時(shí)，此功能也就基本上完成了。

　　5. 代碼管理

　　我們采用VSS+SourceOffsite進(jìn)行版本控制，其中存放了此產(chǎn)品的所有源代碼、庫(kù)文件、文檔及release時(shí)的安裝程序，各個(gè)部分存放在不同的目錄中。每天早上要求開發(fā)人員從VSS中g(shù)et latest version的源代碼，然后進(jìn)行編譯并開始一天的工作。在下班之前理論上要求員工check in所有當(dāng)天修改的代碼，在check in之前要保證編譯是能通過的。若有誰check in的代碼導(dǎo)致daily build失敗則會(huì)被要求某些懲罰措施或警告，象微軟公司要負(fù)責(zé)照看當(dāng)日的每日構(gòu)建。有時(shí)我們編寫的代碼涉及到多個(gè)文件，而且此改動(dòng)是比較復(fù)雜需要花費(fèi)多天的工作量，如果現(xiàn)在check in進(jìn)去可能會(huì)導(dǎo)致BVT(Build Verify Test)測(cè)試通不過，因?yàn)橛行┐a沒有完全完成，而之前的代碼能使BVT測(cè)試通過，而且這些代碼基本上不會(huì)涉及到他人，在這種情況下可以不check in進(jìn)去，直到全部代碼完成能提交BVT測(cè)試時(shí)再一起check in進(jìn)去。

　　每天我們都會(huì)做daily build，一般是在凌晨4點(diǎn)進(jìn)行，那時(shí)有個(gè)程序會(huì)自動(dòng)從VSS中拉下最新的代碼并進(jìn)行編譯。因?yàn)槲覀兺绹?guó)進(jìn)行同步開發(fā)，因此如果想要把修改的代碼進(jìn)入到這個(gè)build中去那就需要在凌晨4點(diǎn)之前把相應(yīng)的代碼check in進(jìn)去。若有人check in進(jìn)去的代碼導(dǎo)致編譯通不過則會(huì)在本步驟中被發(fā)現(xiàn)。當(dāng)編譯完成之后自動(dòng)產(chǎn)生安裝包，測(cè)試部門將會(huì)對(duì)這些代碼進(jìn)行BVT測(cè)試，同時(shí)對(duì)VSS中開發(fā)庫(kù)打上label，如果發(fā)現(xiàn)了什么BUG就能根據(jù)這個(gè)label知道是哪個(gè)時(shí)候開始出現(xiàn)這個(gè)BUG的。BVT是指Build Verify Test，是對(duì)組件中基本功能的測(cè)試。這個(gè)測(cè)試每天都會(huì)進(jìn)行，看新加入的代碼或修改是否會(huì)影響系統(tǒng)的基本功能，便于及早發(fā)現(xiàn)錯(cuò)誤。

　　6. 測(cè)試

　　在開發(fā)人員完成了function Spec后，測(cè)試部門開始了測(cè)試規(guī)劃，確定需要測(cè)試哪些方面，如何測(cè)試及進(jìn)度安排。測(cè)試人員需要寫許多測(cè)試代碼，有些測(cè)試代碼需要集成進(jìn)BVT測(cè)試，有些可能需要進(jìn)行單獨(dú)的測(cè)試，目的都是為了使產(chǎn)品符合要求，使開發(fā)人員容易找出問題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測(cè)試人員決定的，因此測(cè)試人員也比較辛苦，責(zé)任重大。通過了每天的BVT測(cè)試，還有一些性能測(cè)試、兼容性測(cè)試、災(zāi)難測(cè)試等需要在產(chǎn)品發(fā)布前進(jìn)行。在完成這些測(cè)試之后由測(cè)試人員決定本產(chǎn)品是否能release出去了，如果沒有什么問題則會(huì)給某些關(guān)系較好的用戶進(jìn)行β測(cè)試，之后再最終release出去。