1. 前言
本人曾就職于多家公司，但留給我印象最深刻、開(kāi)發(fā)管理最規范的公司是I公司。該公司總部位于美國硅谷，其開(kāi)發(fā)的產(chǎn)品曾獲得PC Magazine的最高五星級的優(yōu)秀好評?，F我根據在此公司中所感受到的經(jīng)歷及自身的一些感想寫(xiě)出來(lái)，希望能給大家和其它公司有所借鑒。
2. 項目計劃
在一個(gè)產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方?？蛻?hù)在使用的過(guò)程中會(huì )發(fā)現一些問(wèn)題，提出更高的需求，市場(chǎng)也在發(fā)生變化，我們的競爭對手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動(dòng)著(zhù)我們的產(chǎn)品不斷地向前發(fā)展，使它的版本不停地往上增長(cháng)。這些發(fā)展的需求不是一下子提出來(lái)的，在客戶(hù)使用的過(guò)程中發(fā)現某些不如意不方便的地方，他們會(huì )向我們的技術(shù)支持人員提意見(jiàn)，而技術(shù)支持人員會(huì )把這些需求以BUG的形式存入BUG數據庫中，其級別一般定義為下一個(gè)版本的Feature。有些上一個(gè)版本未解決的BUG也可能需要在本版本中來(lái)解決。因此當我們來(lái)開(kāi)發(fā)下一個(gè)版本時(shí)，其許多特性已經(jīng)存在于BUG數據庫中了。當然新版本的特性不是只從BUG中獲得，管理層可能從市場(chǎng)的角度來(lái)提出新的特性以求領(lǐng)先競爭對手，開(kāi)發(fā)人員本身也可提出某些要求來(lái)納入新版本開(kāi)發(fā)的計劃中，如要求對某部分代碼進(jìn)行重構以使其結構更清晰更容易維護，執行效率更高。
每個(gè)人把同自己相關(guān)的功能模塊收集起來(lái)，同時(shí)預估時(shí)間，其中主要包括寫(xiě)文檔的時(shí)間、開(kāi)發(fā)時(shí)間和單元測試的時(shí)間，一般要求精確到工作日。這些信息發(fā)送給組長(cháng)，組長(cháng)再把本小組人員的任務(wù)和預估時(shí)間發(fā)送給管理層，由管理層對此任務(wù)及進(jìn)度進(jìn)行評估審核，管理層會(huì )根據產(chǎn)品發(fā)布時(shí)間及客戶(hù)需求、市場(chǎng)因素等方面作出選擇，可能某些功能由于時(shí)間緊急會(huì )被推遲到下一個(gè)版本中去。若預估出來(lái)的時(shí)間同預計的產(chǎn)品發(fā)布時(shí)間有較大沖突，而且此功能是本版本中必須得做的，則開(kāi)發(fā)小組會(huì )被要求重新預估時(shí)間，加快開(kāi)發(fā)速度來(lái)達到這個(gè)要求。
雖然這個(gè)開(kāi)發(fā)進(jìn)度時(shí)間是一個(gè)大概的估計時(shí)間，但我們要盡力按照這個(gè)開(kāi)發(fā)進(jìn)度來(lái)執行。每個(gè)星期五下午我們有一個(gè)Status Meeting（一般那時(shí)工作效率較低，適合開(kāi)會(huì )），在此會(huì )議上我們會(huì )根據這個(gè)進(jìn)度來(lái)review我們的工作，每個(gè)人手上的工作是否按照這個(gè)進(jìn)度在走，是否有人延后了，是否block住別人的工作了。在此會(huì )議上每個(gè)人都要報告自己的進(jìn)度，同時(shí)還要報告上個(gè)星期做了什么，正在做什么，以及下個(gè)星期打算做什么。通過(guò)這個(gè)會(huì )議，會(huì )讓你覺(jué)得有人在監督你，無(wú)形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會(huì )盡早發(fā)現而趕上。若某些經(jīng)過(guò)努力不能趕上，那也沒(méi)有辦法，只能修改原先的進(jìn)度表，因為那是我們的估計與現實(shí)發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實(shí)際情況，這可以避免許多項目發(fā)生最后的20%的工作量會(huì )占據80%甚至一直拖后的情況。修改進(jìn)度表的情況我們曾經(jīng)發(fā)生過(guò)，有一次在按照原先的進(jìn)度執行到將要完成的狀態(tài)時(shí)突然接到通知由于市場(chǎng)及客戶(hù)的原因要求加入另一項重大的功能，這個(gè)功能對我們程序的結構有非常大的影響，因此我們就要重新制定一個(gè)進(jìn)度來(lái)滿(mǎn)足需求。在這種情況下，產(chǎn)品原先的開(kāi)發(fā)進(jìn)度被打亂，發(fā)布時(shí)間也因此推遲。當然這種情況應當盡力避免，尤其在項目后期產(chǎn)生新的需求，若不得已也應重新規劃進(jìn)度，而不是仍舊依照原先的進(jìn)度去執行，因為老的進(jìn)度已不能反映現實(shí)的情況。
3. 開(kāi)發(fā)文檔
在項目進(jìn)度安排中我們已經(jīng)把寫(xiě)文檔的時(shí)間也規劃進(jìn)去了，這里雖然是寫(xiě)文檔，其實(shí)是設計程序，整理一下思路與架構，磨刀不誤砍柴工，這樣在實(shí)際寫(xiě)代碼時(shí)會(huì )流暢很多，節省時(shí)間，因此可以說(shuō)真正有思想性的東西都在寫(xiě)文檔這段時(shí)間內完成了。當然我們這里的文檔格式不象ISO那樣規定了條條框框，我們的文檔格式相對自由，基本上能隨意發(fā)揮，但對于幾個(gè)主要點(diǎn)一般來(lái)說(shuō)是需要說(shuō)明的。要求寫(xiě)的文檔能讓他人比較容易地看明白，能把問(wèn)題講清楚，能反映你的設計思想。文檔的數量也不多，開(kāi)發(fā)文檔有兩類(lèi)，一類(lèi)是function Spec，另一類(lèi)是Design Document。
function Spec中需要寫(xiě)明的是本模塊完成的任務(wù)，解決什么問(wèn)題，有什么作用，為什么要這些功能，此外我們還會(huì )添加進(jìn)適用范圍，有什么不足，注意點(diǎn)是什么，還有哪些地方在以后可以進(jìn)行改進(jìn)。在這個(gè)function Spec中不涉及到任何非常詳細的算法。此文檔不光給開(kāi)發(fā)人員看，還讓QA及其他成員以及后來(lái)的新人能根據此文檔來(lái)了解此模塊的大致功能，同時(shí)也會(huì )給文檔編寫(xiě)者看，他們會(huì )根據這些function Spec整理出一份用戶(hù)手冊，告訴用戶(hù)此版本中新增了哪些功能，各功能模塊有什么作用，如何使用等信息。因此在我們的開(kāi)發(fā)過(guò)程中function Spec是很重要的文檔，此文檔完成后會(huì )抽出一段時(shí)間同相關(guān)人員及QA一起review這個(gè)文檔，讓QA了解設計者的意圖，同時(shí)熟悉新的功能模塊，為接下來(lái)的測試作準備。如果其中有誤解或不明之處，大家會(huì )提出來(lái)探討并由開(kāi)發(fā)者修正。
Design Document中主要描述實(shí)現此模塊所涉及到的主要算法、數據結構、類(lèi)的層次結構及調用關(guān)系。這個(gè)文檔的閱讀者主要是開(kāi)發(fā)人員，包括任何想了解詳細實(shí)現代碼的人，幫助人們理解代碼。在某些功能模塊比較簡(jiǎn)單的程序中，此文檔所描述的信息會(huì )比較少。此文檔不象function Spec要在開(kāi)始寫(xiě)代碼前就編寫(xiě)完成，它可以隨著(zhù)代碼編寫(xiě)的進(jìn)行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應先修改文檔，然后再修改代碼。
4. 編寫(xiě)代碼
由于我們用JAVA語(yǔ)言進(jìn)行開(kāi)發(fā)，因此我們借助了Jbuilder IDE工具。關(guān)于代碼風(fēng)格，我們基本上套用Jbuilder中自動(dòng)的代碼格式編排，但其中需要改變的是縮進(jìn)是4個(gè)字符，類(lèi)與類(lèi)之間間隔2行，方法與方法之間間隔2行，import類(lèi)時(shí)用完整的類(lèi)名。寫(xiě)代碼時(shí)要對類(lèi)及函數提供詳細的注釋及說(shuō)明，基本做到看它們的說(shuō)明就能知道這個(gè)類(lèi)或函數的功能以及主要算法的實(shí)現原理。在開(kāi)發(fā)過(guò)程中對主要的模塊要編寫(xiě)UnitTest，同時(shí)要UnitTest先行，也就是遵循XP規則中的測試驅動(dòng)原則，當所有的單元測試代碼通過(guò)時(shí)，此功能也就基本上完成了。
5. 代碼管理
我們采用VSS+SourceOffsite進(jìn)行版本控制，其中存放了此產(chǎn)品的所有源代碼、庫文件、文檔及release時(shí)的安裝程序，各個(gè)部分存放在不同的目錄中。每天早上要求開(kāi)發(fā)人員從VSS中g(shù)et latest version的源代碼，然后進(jìn)行編譯并開(kāi)始一天的工作。在下班之前理論上要求員工check in所有當天修改的代碼，在check in之前要保證編譯是能通過(guò)的。若有誰(shuí)check in的代碼導致daily build失敗則會(huì )被要求某些懲罰措施或警告，象微軟公司要負責照看當日的每日構建。有時(shí)我們編寫(xiě)的代碼涉及到多個(gè)文件，而且此改動(dòng)是比較復雜需要花費多天的工作量，如果現在check in進(jìn)去可能會(huì )導致BVT（Build Verify Test）測試通不過(guò)，因為有些代碼沒(méi)有完全完成，而之前的代碼能使BVT測試通過(guò)，而且這些代碼基本上不會(huì )涉及到他人，在這種情況下可以不check in進(jìn)去，直到全部代碼完成能提交BVT測試時(shí)再一起check in進(jìn)去。
每天我們都會(huì )做daily build，一般是在凌晨4點(diǎn)進(jìn)行，那時(shí)有個(gè)程序會(huì )自動(dòng)從VSS中拉下最新的代碼并進(jìn)行編譯。因為我們同美國進(jìn)行同步開(kāi)發(fā)，因此如果想要把修改的代碼進(jìn)入到這個(gè)build中去那就需要在凌晨4點(diǎn)之前把相應的代碼check in進(jìn)去。若有人check in進(jìn)去的代碼導致編譯通不過(guò)則會(huì )在本步驟中被發(fā)現。當編譯完成之后自動(dòng)產(chǎn)生安裝包，測試部門(mén)將會(huì )對這些代碼進(jìn)行BVT測試，同時(shí)對VSS中開(kāi)發(fā)庫打上label，如果發(fā)現了什么BUG就能根據這個(gè)label知道是哪個(gè)時(shí)候開(kāi)始出現這個(gè)BUG的。BVT是指Build Verify Test，是對組件中基本功能的測試。這個(gè)測試每天都會(huì )進(jìn)行，看新加入的代碼或修改是否會(huì )影響系統的基本功能，便于及早發(fā)現錯誤。
6. 測試
在開(kāi)發(fā)人員完成了function Spec后，測試部門(mén)開(kāi)始了測試規劃，確定需要測試哪些方面，如何測試及進(jìn)度安排。測試人員需要寫(xiě)許多測試代碼，有些測試代碼需要集成進(jìn)BVT測試，有些可能需要進(jìn)行單獨的測試，目的都是為了使產(chǎn)品符合要求，使開(kāi)發(fā)人員容易找出問(wèn)題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測試人員決定的，因此測試人員也比較辛苦，責任重大。通過(guò)了每天的BVT測試，還有一些性能測試、兼容性測試、災難測試等需要在產(chǎn)品發(fā)布前進(jìn)行。在完成這些測試之后由測試人員決定本產(chǎn)品是否能release出去了，如果沒(méi)有什么問(wèn)題則會(huì )給某些關(guān)系較好的用戶(hù)進(jìn)行β測試，之后再最終release出去。
7. BUG管理
由于我們每天進(jìn)行著(zhù)測試，因此經(jīng)常有BUG被測試部門(mén)發(fā)現，一旦發(fā)現了新的BUG，就會(huì )被添加進(jìn)BUG Tracking System中。目前較流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是開(kāi)發(fā)人員和QA之間的紐帶，開(kāi)發(fā)人員和QA通過(guò)BUG tracking system聯(lián)系著(zhù)。每個(gè)BUG有其類(lèi)型和級別，預定的類(lèi)型有Crash-Data Loss, Crash-No Data Loss, Incorrect functionality, Cosmetic, Feature request等, 級別有P1、P2一直到P6，它們分別代表了重要性及緊急程度，P1的BUG需要很快fix，P5之前的BUG在本版本release之前必須fix掉，若真的不能或不重要則由QA確定并降低優(yōu)先級進(jìn)入到下一個(gè)版本中去fix。QA發(fā)現一個(gè)BUG后在BUG Track中增加一個(gè)BUG，同時(shí)填入相關(guān)信息并assign給相應的開(kāi)發(fā)人員，開(kāi)發(fā)人員收到BUG分析并fix后assign給QA去verify，其中要填上分析的結果以及如何解決的詳細說(shuō)明。若QA對此BUG verify通過(guò)則close BUG，否則verify failed并重新assign給開(kāi)發(fā)人員并等待其fix。每星期在Status Meeting上會(huì )進(jìn)行BUG狀況報告，主要由QA組長(cháng)報告BUG的狀況，主要是新增BUG數，fix掉多少，還有多少處于open狀態(tài)，有多少處于等待verify的狀態(tài)，據此可以了解開(kāi)發(fā)及測試情況。有時(shí)在Status Meeting上我們也會(huì )進(jìn)行BUG Review，BUG Review有時(shí)是單獨一個(gè)小組內進(jìn)行，其主要作用是重新明確每個(gè)人頭上的BUG以及了解每個(gè)BUG的狀況，如開(kāi)發(fā)人員對此BUG將作何處理等，以此來(lái)了解開(kāi)發(fā)中是否有碰到比較棘手的問(wèn)題，增加了產(chǎn)品發(fā)布風(fēng)險。在QA增加BUG和開(kāi)發(fā)人員fix BUG的游戲中，BUG的數量曲線(xiàn)圖會(huì )象股市曲線(xiàn)一樣上下波動(dòng)，但總體趨勢一般是前期BUG放量攀升，后期震蕩下挫，若到了后期新open的BUG數量一直上升則說(shuō)明風(fēng)險在增大，有可能無(wú)法控制，也就是說(shuō)fix了一個(gè)BUG導致了多個(gè)新的BUG產(chǎn)生。在量化開(kāi)發(fā)進(jìn)度中也可以用代碼數量的曲線(xiàn)圖來(lái)粗略的呈現。在有大量新功能增加時(shí)可能代碼量的增加會(huì )較快，當在fix bug階段，代碼的修改較多，因此代碼數量的增幅會(huì )降低，依據代碼量可以看出開(kāi)發(fā)的狀況處于何種階段。
需要指出的是我們對BUG的定義比較廣泛，一些新功能也可以作為BUG被提出，只不過(guò)這些BUG級別比較低，讓它們進(jìn)入到下一個(gè)版本中去實(shí)現。因此BUG的創(chuàng )建者也可以是技術(shù)支持人員、市場(chǎng)人員甚至開(kāi)發(fā)人員本身。關(guān)于開(kāi)發(fā)人員本身，因為他可能會(huì )找出一些BUG，有些是其他開(kāi)發(fā)者的，有些可能是此開(kāi)發(fā)者本身的，把這個(gè)BUG添加進(jìn)BUG庫中可以幫助開(kāi)發(fā)人員在以后產(chǎn)生新問(wèn)題時(shí)或類(lèi)似的BUG時(shí)有一個(gè)借鑒和思路，但此BUG的verify必須要讓測試本模塊的測試人員來(lái)verify。
8. Code Freeze
當P5之前的BUG都被修復了，這時(shí)離產(chǎn)品發(fā)布日期也就不遠了，一般是2個(gè)星期后就能release產(chǎn)品，這時(shí)要對VSS中的代碼進(jìn)行freeze，以保證代碼庫的穩定性。Code freeze階段一般會(huì )把各開(kāi)發(fā)人員的check in和check out的權限關(guān)閉，若在這時(shí)仍有BUG報告上來(lái)并經(jīng)討論確定是重大的且必須在本版本中fix的，則需要經(jīng)管理層同意并特殊地授予權限，在修改完成后修改者要把修改了哪些文件，影響了哪些文檔等信息上報給各部門(mén)如QA、build人員、文檔編寫(xiě)者等。在code freeze階段，測試部門(mén)在緊張地進(jìn)行著(zhù)各種測試，得出各種數據，并決定本版本是否可以release了。
9. Tech Talk
計算機知識更新速度非?？?，經(jīng)常有一些新的術(shù)語(yǔ)、新的名詞、新的思想、新的技術(shù)所產(chǎn)生，如過(guò)離開(kāi)此行業(yè)幾個(gè)月后重新回來(lái)就會(huì )對這些新的事物不解，而我們平時(shí)為了自己的項目埋頭苦干可能忘了周?chē)氖澜绨l(fā)生了什么。Tech Talk就提供了一個(gè)讓我們了解新知識和最新發(fā)展趨勢的機會(huì )，讓大家把知識共享，共同提高。Tech Talk一般會(huì )在項目不是太忙碌的時(shí)候進(jìn)行，主持人會(huì )提前一個(gè)星期指定某個(gè)人去準備一下Tech Talk，一般此人可能對某方面比較感興趣，然后他會(huì )花一些時(shí)間去了解這方面的情況，寫(xiě)成一個(gè)文檔如PowerPoint并上傳到局域網(wǎng)內，同時(shí)通知大家可以先去瀏覽。Tech Talk的內容非常廣泛，不一定同我們的項目緊密相關(guān)，任何新的思想、新的知識（當然一般是限在計算機領(lǐng)域內）都可作為T(mén)ech Talk的內容，而在主講人講完之后還有一段時(shí)間被大家提問(wèn)，共同對這個(gè)話(huà)題進(jìn)行討論，答疑解惑。當然Tech Talk也可同我們的項目相關(guān)，如研究一下競爭對手的產(chǎn)品技術(shù)，本公司產(chǎn)品的架構等。研究本公司的產(chǎn)品架構可以使大家對本公司的產(chǎn)品有一個(gè)全局的概念，從整體上來(lái)看自己的產(chǎn)品，順便整理一下產(chǎn)品的架構使之更加清晰有條理。平時(shí)大家都只注重于自己負責的其中的一小塊，在Tech Talk中可以跳出自己的小框框來(lái)了解全局，同時(shí)這也是新員工了解公司核心技術(shù)整體框架的好機會(huì )。每個(gè)模塊的負責人需要闡述此模塊的方方面面，讓大家來(lái)了解并回答問(wèn)題。
10. Code Review
當進(jìn)行工作移交時(shí)我們會(huì )進(jìn)行Code Review，在碰到棘手的BUG時(shí)也會(huì )進(jìn)行Code Review，Code Review是大家了解其詳細實(shí)現的一個(gè)好機會(huì )。在Code Review之后會(huì )對此代碼產(chǎn)生親切感而不是陌生懼怕感，相信很多人在讀他人代碼時(shí)會(huì )有非常痛苦的經(jīng)歷，Code Review是減少此痛苦感的好藥方。在進(jìn)行Code Review前，主講人會(huì )提前發(fā)出一個(gè)通知告訴相關(guān)人員要review哪些代碼，這樣參與者可以抽出時(shí)間提前了解相關(guān)代碼，對不懂的地方做個(gè)筆記以便在Code Review進(jìn)行中提出疑問(wèn)。在我們碰到比較棘手的BUG沒(méi)有什么思路或大惑不解時(shí)，這時(shí)找幾個(gè)相關(guān)人員或對此代碼也熟悉的人進(jìn)行一次Code Review，這時(shí)形式比較隨意，大家可以臨時(shí)提出問(wèn)題，讓主講人解答，在這個(gè)過(guò)程中可能聽(tīng)的人并不會(huì )非?？斓亓私馄渲械脑敿氝^(guò)程，但是講的人在這個(gè)過(guò)程中重新理了一下思路，對所寫(xiě)的代碼被迫重新審視了一遍，在其中可能就會(huì )發(fā)現出解決問(wèn)題的辦法。在Code Review時(shí)有時(shí)代碼非常多，但可以一個(gè)功能模塊一個(gè)功能模塊地從總體到局部，由淺入深層層遞進(jìn)的方式進(jìn)行。一次Code Review的時(shí)間不要太長(cháng)，但可以分多次進(jìn)行。Code Review中大家會(huì )提出問(wèn)題和建議，集思廣益，多個(gè)人共同出主意，有些可能一個(gè)人沒(méi)有想到的問(wèn)題會(huì )被大家發(fā)現，互相學(xué)習，共同進(jìn)步。
11. 溝通與交流
大部分員工的大部分時(shí)間是在公司里度過(guò)的，因此公司的生活成了大家主要組成部分。員工之間關(guān)系的融洽，交流的暢通顯得非常重要，同時(shí)大家也不想自己的生活這樣枯燥乏味，一直同機器打交道。溝通無(wú)處不在，交流隨時(shí)發(fā)生，有許多關(guān)系是在工作之外建立起來(lái)的。軟件公司內是很容易產(chǎn)生各種矛盾的，因為這是由你的工作性質(zhì)所決定的，比如QA或用戶(hù)會(huì )對你的實(shí)現不滿(mǎn)意，提出各種要求時(shí)，我相信你有時(shí)會(huì )有所抱怨的，無(wú)形之中就產(chǎn)生了對立，發(fā)展到后來(lái)會(huì )有抵觸心理。我相信大部分人都會(huì )有此感受，這不是你的錯，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財富帶給對方，則對方會(huì )非常歡迎你的到來(lái)，把你奉為財神爺來(lái)對待，同你的關(guān)系會(huì )非常融洽友好。因此我們需要在工作之外來(lái)消除這種對立矛盾的關(guān)系，建立一種融洽的工作氛圍。我們在平時(shí)吃飯的時(shí)候飯桌上大家互相聊天溝通。我們建立了happy郵件列表，其中會(huì )發(fā)一些幽默笑話(huà)之類(lèi)的郵件，給我們緊張的工作增加點(diǎn)輕松的氛圍。在下班后大家可以組織一下活動(dòng)，增加了公司的凝聚力。一個(gè)產(chǎn)品發(fā)布后組織一下旅游，讓繃緊的神經(jīng)松弛一下，更好地迎接下一個(gè)挑戰。
12. 后記
不同公司有不同的做法，我只是把我認為比較好的流程與管理方式呈現出來(lái)，讓大家有個(gè)借鑒，當然它也不是十全十美的，也不是放之四海而皆準的，如果你覺(jué)得某些地方對你有所幫助或值得推廣，這是本文最想達到的效果。非常感謝I公司給了我這么美好的經(jīng)歷，也非常感謝I公司的同事們曾給我的巨大幫助，在此衷心地祝福I公司越來(lái)越壯大，逐步走向成功！也衷心地祝福我的同事們幸?？鞓?lè )！
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
