大中小構(gòu)建高效軟件開發(fā)規(guī)程和團(tuán)隊

1、精心整理構(gòu)建高效軟件開發(fā)流程和團(tuán)隊在一個產(chǎn)品發(fā)布并使用之后， 其中肯定有許多地方不如意和值得改進(jìn)的地方。 客戶在使用的過程中會發(fā)現(xiàn)一些問題，提出更高的需求， 市場也在發(fā)生變化，我們的競爭對手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生， 這些因素推動著我們的產(chǎn)品不斷地向前發(fā)展， 使它的版本不停地往上增長。 這些發(fā)展的需求不是一下子提出來的， 在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方， 他們會向我們的技術(shù)支持人員提意見， 而技術(shù)支持人員會把這些需求以

2、 BUG 的形式存入 BUG 數(shù)據(jù)庫中， 其級別一般定義為下一個版本的 Feature。有些上一個版本未解決的BUG 也可能需要在本版本中來解決。因此當(dāng)我們來開發(fā)下一個版本時，其許多特性已經(jīng)存在于BUG 數(shù)據(jù)庫中了。當(dāng)然新版本的特性不是只從BUG中獲得， 管理層可能從市場的角度來提出新的特性以求領(lǐng)先競爭對手， 開發(fā)人員本身也可提出某些要求來納入新版本開發(fā)的計劃中， 如要求對某部分代碼進(jìn)行重構(gòu)以使其結(jié)構(gòu)更清晰更容易維護(hù)， 執(zhí)行效率更高。?

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

4、 則開發(fā)小組會被要求重新預(yù)估時間，加快開發(fā)速度來達(dá)到這個要求。?????雖然這個開發(fā)進(jìn)度時間是一個大概的估計時間，但我們要盡力按照這個開發(fā)進(jìn)度來執(zhí)行。每個星期五下午我們有一個 Status?Meeting（一般那時工作效率較低，適合開會） ，在此會議上我們會根據(jù)這個進(jìn)度來 review 我們的工作， 每個人手上的工作是否按照這個進(jìn)度在走， 是否有人延后了，是否 block 住別人的工作了。 在此會議上每個人都要報告自己的進(jìn)度， 同時還要

5、報告上個星期做了什么，正在做什么，以及下個星期打算做什么。通過這個會議，會讓你覺得有人在監(jiān)督你，無形之中迫使你不斷地督促自己不要使任務(wù)延后， 如果有延后的跡象也會盡早發(fā)現(xiàn)而趕上。 若某些經(jīng)過努力不能趕上，那也沒有辦法， 只能修改原先的進(jìn)度表，因為那是我們的估計與現(xiàn)實發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實際情況，這可以避免許多項目發(fā)生最后的 20%的工作量會占據(jù) 80%甚至一直拖后的情況。 修改進(jìn)度表的情況我們曾經(jīng)發(fā)生過， 有一次在按照

6、原先的進(jìn)度執(zhí)行到將要完成的狀態(tài)時突然接到通知由于市場及客戶的原因要求加入另一項重大的功能， 這個功能對我們程序的結(jié)構(gòu)有非常大的影響， 因此我們就要重新制定一個進(jìn)度來滿足需求。 在這種情況下， 產(chǎn)品原先的開精心整理???由于我們用 JAVA 語言進(jìn)行開發(fā)，因此我們借助了 Jbuilder?IDE 工具。關(guān)于代碼風(fēng)格，我們基本上套用 Jbuilder 中自動的代碼格式編排，但其中需要改變的是縮進(jìn)是 4 個字符，類與類之間間隔 2 行，方法與

7、方法之間間隔 2 行，import 類時用完整的類名。寫代碼時要對類及函數(shù)提供詳細(xì)的注釋及說明， 基本做到看它們的說明就能知道這個類或函數(shù)的功能以及主要算法的實現(xiàn)原理。 在開發(fā)過程中對主要的模塊要編寫 UnitTest，同時要 UnitTest 先行，也就是遵循 XP 規(guī)則中的測試驅(qū)動原則，當(dāng)所有的單元測試代碼通過時，此功能也就基本上完成了。??5.?代碼管理????我們采用 VSS+SourceOffsite 進(jìn)行版本控制，其中存放了

8、此產(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)日的每

9、日構(gòu)建。 有時我們編寫的代碼涉及到多個文件， 而且此改動是比較復(fù)雜需要花費多天的工作量， 如果現(xiàn)在 check?in 進(jìn)去可能會導(dǎo)致 BVT （Build?Verify?Test） 測試通不過， 因為有些代碼沒有完全完成，而之前的代碼能使 BVT 測試通過，而且這些代碼基本上不會涉及到他人，在這種情況下可以不check?in 進(jìn)去，直到全部代碼完成能提交 BVT 測試時再一起 check?in 進(jìn)去。?????每天我們都會做 daily

10、?build，一般是在凌晨 4 點進(jìn)行，那時有個程序會自動從 VSS 中拉下最新的代碼并進(jìn)行編譯。因為我們同美國進(jìn)行同步開發(fā)，因此如果想要把修改的代碼進(jìn)入到這個build 中去那就需要在凌晨 4 點之前把相應(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)了

11、什么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