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

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

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

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

4、 則開發(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í)還要

5、報(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ā)生過， 有一次在按照

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

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

8、此產(chǎn)品的所有源代碼、庫文件、文檔及 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)日的每

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

10、?build，一般是在凌晨 4 點(diǎn)進(jìn)行，那時(shí)有個(gè)程序會(huì)自動(dòng)從 VSS 中拉下最新的代碼并進(jìn)行編譯。因?yàn)槲覀兺绹M(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)生安裝包， 測試部門將會(huì)對(duì)這些代碼進(jìn)行 BVT 測試，同時(shí)對(duì)VSS 中開發(fā)庫打上 label，如果發(fā)現(xiàn)了

11、什么BUG 就能根據(jù)這個(gè) label 知道是哪個(gè)時(shí)候開始出現(xiàn)這個(gè) BUG 的。BVT 是指 Build?Verify?Test，是對(duì)組件中基本功能的測試。這個(gè)測試每天都會(huì)進(jìn)行，看新加入的代碼或修改是否會(huì)影響系統(tǒng)的基本功能，便于及早發(fā)現(xiàn)錯(cuò)誤。??6.?測試????在開發(fā)人員完成了 function?Spec 后，測試部門開始了測試規(guī)劃，確定需要測試哪些方面，如何測試及進(jìn)度安排。 測試人員需要寫許多測試代碼， 有些測試代碼需要集成進(jìn) BVT