軟件公司的開發(fā)管理流程

1、軟件公司的開發(fā)管理流程瀏覽： 110 次    博藍(lán)工作室 更新于：2009-05-31  關(guān)鍵字： 軟件開發(fā)流程 軟件公司開發(fā)流程 軟件設(shè)計流程 軟件 以下是引用片段：1. 項(xiàng)目計劃在一個產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改進(jìn)的地方?？蛻粼谑褂玫倪^程中會發(fā)現(xiàn)一些問題，提出更高的需求，市場也在發(fā)生變化，我們的競 爭對手也在發(fā)展，新的技術(shù)不斷地產(chǎn)生，這些因素推動著我們的產(chǎn)品不斷地向前發(fā)展，使它的版本不停地往上增長。這些發(fā)展的需求不是一下子提出來的，在客戶使 用的過程中發(fā)現(xiàn)某些不如意不方便的地方，他們會向我們的技術(shù)支持人員

2、提意見，而技術(shù)支持人員會把這些需求以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í)行效率更高。每個人把同自己相關(guān)的功能模塊收集起來，同時預(yù)估時間，其中主要包括寫文檔的時間、開發(fā)時間和單元測試的時間，一般要求精確到工作日。這些信息發(fā)送給組

3、長，組長再把本小組人員的任務(wù)和預(yù)估時間發(fā)送給管理層，由管理層對此任務(wù)及進(jìn)度進(jìn)行評估審核，管理層會根據(jù)產(chǎn)品發(fā)布時間及客戶需求、市場因素等方面作出選 擇，可能某些功能由于時間緊急會被推遲到下一個版本中去。若預(yù)估出來的時間同預(yù)計的產(chǎn)品發(fā)布時間有較大沖突，而且此功能是本版本中必須得做的，則開發(fā)小組 會被要求重新預(yù)估時間，加快開發(fā)速度來達(dá)到這個要求。雖然這個開發(fā)進(jìn)度時間是一個大概的估計時間，但我們要盡力按照這個開發(fā)進(jìn)度來執(zhí)行。每個星期五下午我們有一個Status Meeting（一般那時工作 效率較低，適合開會），在此會議上我們會根據(jù)這個進(jìn)度來review我們的工作，每個人手上的工作是否按照這個進(jìn)度在走

4、，是否有人延后了，是否block 住別人的工作了。在此會議上每個人都要報告自己的進(jìn)度，同時還要報告上個星期做了什么，正在做什么，以及下個星期打算做什么。通過這個會議，會讓你覺得有 人在監(jiān)督你，無形之中迫使你不斷地督促自己不要使任務(wù)延后，如果有延后的跡象也會盡早發(fā)現(xiàn)而趕上。若某些經(jīng)過努力不能趕上，那也沒有辦法，只能修改原先的 進(jìn)度表，因?yàn)槟鞘俏覀兊墓烙嬇c現(xiàn)實(shí)發(fā)生了偏差，我們必須使我們的進(jìn)度表符合實(shí)際情況，這可以避免許多項(xiàng)目發(fā)生最后的20%的工作量會占據(jù)80%甚至一直拖 后的情況。修改進(jìn)度表的情況我們曾經(jīng)發(fā)生過，有一次在按照原先的進(jìn)度執(zhí)行到將要完成的狀態(tài)時突然接到通知由于市場及客戶的原因要求加入另

5、一項(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í)的情況。2. 開發(fā)文檔在項(xiàng)目進(jìn)度安排中我們已經(jīng)把寫文檔的時間也規(guī)劃進(jìn)去了，這里雖然是寫文檔，其實(shí)是設(shè)計程序，整理一下思路與架構(gòu)，磨刀不誤砍柴工，這樣在實(shí)際寫代碼時會流 暢很多，節(jié)省時間，因此可以說真正有思想性的東西都在寫文檔這段時間內(nèi)完成了。當(dāng)然我們這里的文檔格式不象ISO那樣規(guī)定了條條框框，我們的文

6、檔格式相對 自由，基本上能隨意發(fā)揮，但對于幾個主要點(diǎn)一般來說是需要說明的。要求寫的文檔能讓他人比較容易地看明白，能把問題講清楚，能反映你的設(shè)計思想。文檔的數(shù) 量也不多，開發(fā)文檔有兩類，一類是function Spec，另一類是Design Document。function Spec中需要寫明的是本模塊完成的任務(wù)，解決什么問題，有什么作用，為什么要這些功能，此外我們還會添加進(jìn)適用范圍，有什么不足，注 意點(diǎn)是什么，還有哪些地方在以后可以進(jìn)行改進(jìn)。在這個function Spec中不涉及到任何非常詳細(xì)的算法。此文檔不光給開發(fā)人員看，還讓QA及其他 成員以及后來的新人能根據(jù)此文檔來了解此模塊的大致功

7、能，同時也會給文檔編寫者看，他們會根據(jù)這些function Spec整理出一份用戶手冊，告訴用 戶此版本中新增了哪些功能，各功能模塊有什么作用，如何使用等信息。因此在我們的開發(fā)過程中function Spec是很重要的文檔，此文檔完成后會抽 出一段時間同相關(guān)人員及QA一起review這個文檔，讓QA了解設(shè)計者的意圖，同時熟悉新的功能模塊，為接下來的測試作準(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)代碼的人，幫助人們

8、理解代碼。在某些功能模塊比較簡單的程序中，此文檔所描述的信息會比較少。此文檔不象function Spec要在開 始寫代碼前就編寫完成，它可以隨著代碼編寫的進(jìn)行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應(yīng)先修改文 檔，然后再修改代碼。3. 編寫代碼由于我們用JAVA語言進(jìn)行開發(fā)，因此我們借助了Jbuilder IDE工具。關(guān)于代碼風(fēng)格，我們基本上套用Jbuilder中自動的代碼格式編排，但 其中需要改變的是縮進(jìn)是4個字符，類與類之間間隔2行，方法與方法之間間隔2行，import類時用完整的類名。寫代碼時要對類及函數(shù)提供詳細(xì)的注釋及說 明，基本做到看它

9、們的說明就能知道這個類或函數(shù)的功能以及主要算法的實(shí)現(xiàn)原理。在開發(fā)過程中對主要的模塊要編寫UnitTest，同時要UnitTest 先行，也就是遵循XP規(guī)則中的測試驅(qū)動原則，當(dāng)所有的單元測試代碼通過時，此功能也就基本上完成了。4. 代碼管理我們采用VSS+SourceOffsite進(jìn)行版本控制，其中存放了此產(chǎn)品的所有源代碼、庫文件、文檔及release時的安裝程序，各個部分存放在不 同的目錄中。每天早上要求開發(fā)人員從VSS中g(shù)et latest version的源代碼，然后進(jìn)行編譯并開始一天的工作。在下班之前理論上要求員工 check in所有當(dāng)天修改的代碼，在check in 之前要保證編譯是

10、能通過的。若有誰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中拉下最新

11、的代碼并進(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)錯誤。5. 測試在開發(fā)人員完成了func

12、tion 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出去。6. BUG管理由于我們每天進(jìn)

13、行著測試，因此經(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、

14、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)行

15、BUG狀況報告，主要由QA組長報告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)險。在QA增加BUG和開發(fā)人員fix BUG的游戲中，BUG的數(shù)量曲線圖會象股市曲線一 樣上下波動，但總體趨勢一般是前期BUG放量攀升，后期震蕩下挫，若

16、到了后期新open的BUG數(shù)量一直上升則說明風(fēng)險在增大，有可能無法控制，也就是說 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ā)者的

17、，有些可能是此開發(fā)者本身 的，把這個BUG添加進(jìn)BUG庫中可以幫助開發(fā)人員在以后產(chǎn)生新問題時或類似的BUG時有一個借鑒和思路，但此BUG的verify必須要讓測試本模塊的 測試人員來verify。7. CodeFreeze當(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報告上來并經(jīng)討論確定是重大的且必須在本版本中fix的，則需要經(jīng)管理層同意并特殊地授予權(quán)限，在修改完成

18、后修改者要把修改了哪些文件，影響了哪些 文檔等信息上報給各部門如QA、build人員、文檔編寫者等。在code freeze階段，測試部門在緊張地進(jìn)行著各種測試，得出各種數(shù)據(jù)，并決定本 版本是否可以release了。8. Tech Talk計算機(jī)知識更新速度非?？?，經(jīng)常有一些新的術(shù)語、新的名詞、新的思想、新的技術(shù)所產(chǎn)生，如過離開此行業(yè)幾個月后重新回來就會對這些新的事物不解，而我們平 時為了自己的項(xiàng)目埋頭苦干可能忘了周圍的世界發(fā)生了什么。Tech Talk就提供了一個讓我們了解新知識和最新發(fā)展趨勢的機(jī)會，讓大家把知識共享，共同 提高。Tech Talk一般會在項(xiàng)目不是太忙碌的時候進(jìn)行，主持人會提

19、前一個星期指定某個人去準(zhǔn)備一下Tech Talk，一般此人可能對某方面比較感 興趣，然后他會花一些時間去了解這方面的情況，寫成一個文檔如PowerPoint并上傳到局域網(wǎng)內(nèi)，同時通知大家可以先去瀏覽。Tech Talk的內(nèi) 容非常廣泛，不一定同我們的項(xiàng)目緊密相關(guān)，任何新的思想、新的知識（當(dāng)然一般是限在計算機(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)品有一個全局的概念，從整體上來看自

20、己的產(chǎn)品，順便整理一下產(chǎn)品的架構(gòu)使之更加清晰有條理。平時大家 都只注重于自己負(fù)責(zé)的其中的一小塊，在Tech Talk中可以跳出自己的小框框來了解全局，同時這也是新員工了解公司核心技術(shù)整體框架的好機(jī)會。每個模 塊的負(fù)責(zé)人需要闡述此模塊的方方面面，讓大家來了解并回答問題。9. 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ì)過程，但是講的人