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