構建高效軟件開發(fā)流程和團隊及項目經理的職責

1、構建高效軟件開發(fā)流程和團隊1.前言 (22.項目計劃 (23.開發(fā)文檔 (34.編寫代碼 (45.代碼管理 (46.測試 (47.BUG管理 (58.Code Freeze (69.Tech Talk (610.Code Review (611.溝通與交流 (712.后記 (71.前言本人曾就職于多家公司,但留給我印象最深刻、開發(fā)管理最規(guī)范的公司是I 公司。該公司總部位于美國硅谷,其開發(fā)的產品曾獲得PC Magazine的最高五星級的優(yōu)秀好評?，F(xiàn)我根據(jù)在此公司中所感受到的經歷及自身的一些感想寫出來,希望能給大家和其它公司有所借鑒。2.項目計劃在一個產品發(fā)布并使用之后,其中肯定有許多地方不如意和

2、值得改進的地方?？蛻粼谑褂玫倪^程中會發(fā)現(xiàn)一些問題,提出更高的需求,市場也在發(fā)生變化,我們的競爭對手也在發(fā)展,新的技術不斷地產生,這些因素推動著我們的產品不斷地向前發(fā)展,使它的版本不停地往上增長。這些發(fā)展的需求不是一下子提出來的,在客戶使用的過程中發(fā)現(xiàn)某些不如意不方便的地方,他們會向我們的技術支持人員提意見,而技術支持人員會把這些需求以BUG的形式存入BUG數(shù)據(jù)庫中,其級別一般定義為下一個版本的Feature。有些上一個版本未解決的BUG也可能需要在本版本中來解決。因此當我們來開發(fā)下一個版本時,其許多特性已經存在于BUG數(shù)據(jù)庫中了。當然新版本的特性不是只從BUG中獲得,管理層可能從市場的角度來提

3、出新的特性以求領先競爭對手,開發(fā)人員本身也可提出某些要求來納入新版本開發(fā)的計劃中,如要求對某部分代碼進行重構以使其結構更清晰更容易維護,執(zhí)行效率更高。每個人把同自己相關的功能模塊收集起來,同時預估時間,其中主要包括寫文檔的時間、開發(fā)時間和單元測試的時間,一般要求精確到工作日。這些信息發(fā)送給組長,組長再把本小組人員的任務和預估時間發(fā)送給管理層,由管理層對此任務及進度進行評估審核,管理層會根據(jù)產品發(fā)布時間及客戶需求、市場因素等方面作出選擇,可能某些功能由于時間緊急會被推遲到下一個版本中去。若預估出來的時間同預計的產品發(fā)布時間有較大沖突,而且此功能是本版本中必須得做的,則開發(fā)小組會被要求重新預估時間

4、,加快開發(fā)速度來達到這個要求。雖然這個開發(fā)進度時間是一個大概的估計時間,但我們要盡力按照這個開發(fā)進度來執(zhí)行。每個星期五下午我們有一個Status Meeting(一般那時工作效率較低,適合開會,在此會議上我們會根據(jù)這個進度來review我們的工作,每個人手上的工作是否按照這個進度在走,是否有人延后了,是否block住別人的工作了。在此會議上每個人都要報告自己的進度,同時還要報告上個星期做了什么,正在做什么,以及下個星期打算做什么。通過這個會議,會讓你覺得有人在監(jiān)督你,無形之中迫使你不斷地督促自己不要使任務延后,如果有延后的跡象也會盡早發(fā)現(xiàn)而趕上。若某些經過努力不能趕上,那也沒有辦法,只能修改原

5、先的進度表,因為那是我們的估計與現(xiàn)實發(fā)生了偏差,我們必須使我們的進度表符合實際情況,這可以避免許多項目發(fā)生最后的20%的工作量會占據(jù)80%甚至一直拖后的情況。修改進度表的情況我們曾經發(fā)生過,有一次在按照原先的進度執(zhí)行到將要完成的狀態(tài)時突然接到通知由于市場及客戶的原因要求加入另一項重大的功能,這個功能對我們程序的結構有非常大的影響,因此我們就要重新制定一個進度來滿足需求。在這種情況下,產品原先的開發(fā)進度被打亂,發(fā)布時間也因此推遲。當然這種情況應當盡力避免,尤其在項目后期產生新的需求,若不得已也應重新規(guī)劃進度,而不是仍舊依照原先的進度去執(zhí)行,因為老的進度已不能反映現(xiàn)實的情況。3.開發(fā)文檔在項目進度

6、安排中我們已經把寫文檔的時間也規(guī)劃進去了,這里雖然是寫文檔,其實是設計程序,整理一下思路與架構,磨刀不誤砍柴工,這樣在實際寫代碼時會流暢很多,節(jié)省時間,因此可以說真正有思想性的東西都在寫文檔這段時間內完成了。當然我們這里的文檔格式不象ISO那樣規(guī)定了條條框框,我們的文檔格式相對自由,基本上能隨意發(fā)揮,但對于幾個主要點一般來說是需要說明的。要求寫的文檔能讓他人比較容易地看明白,能把問題講清楚,能反映你的設計思想。文檔的數(shù)量也不多,開發(fā)文檔有兩類,一類是Function Spec,另一類是Design Document。Function Spec中需要寫明的是本模塊完成的任務,解決什么問題,有什么

7、作用,為什么要這些功能,此外我們還會添加進適用范圍,有什么不足,注意點是什么,還有哪些地方在以后可以進行改進。在這個Function Spec中不涉及到任何非常詳細的算法。此文檔不光給開發(fā)人員看,還讓QA及其他成員以及后來的新人能根據(jù)此文檔來了解此模塊的大致功能,同時也會給文檔編寫者看,他們會根據(jù)這些Function Spec整理出一份用戶手冊,告訴用戶此版本中新增了哪些功能,各功能模塊有什么作用,如何使用等信息。因此在我們的開發(fā)過程中Function Spec是很重要的文檔,此文檔完成后會抽出一段時間同相關人員及QA 一起review這個文檔,讓QA了解設計者的意圖,同時熟悉新的功能模塊,為

8、接下來的測試作準備。如果其中有誤解或不明之處,大家會提出來探討并由開發(fā)者修正。Design Document中主要描述實現(xiàn)此模塊所涉及到的主要算法、數(shù)據(jù)結構、類的層次結構及調用關系。這個文檔的閱讀者主要是開發(fā)人員,包括任何想了解詳細實現(xiàn)代碼的人,幫助人們理解代碼。在某些功能模塊比較簡單的程序中,此文檔所描述的信息會比較少。此文檔不象Function Spec要在開始寫代碼前就編寫完成,它可以隨著代碼編寫的進行而增加,但基本上遵循文檔先行原則,也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應先修改文檔,然后再修改代碼。4.編寫代碼由于我們用JAVA語言進行開發(fā),因此我們借助了Jbuilde

9、r IDE工具。關于代碼風格,我們基本上套用Jbuilder中自動的代碼格式編排,但其中需要改變的是縮進是4個字符,類與類之間間隔2行,方法與方法之間間隔2行,import 類時用完整的類名。寫代碼時要對類及函數(shù)提供詳細的注釋及說明,基本做到看它們的說明就能知道這個類或函數(shù)的功能以及主要算法的實現(xiàn)原理。在開發(fā)過程中對主要的模塊要編寫UnitTest,同時要UnitTest先行,也就是遵循XP規(guī)則中的測試驅動原則,當所有的單元測試代碼通過時,此功能也就基本上完成了。5.代碼管理我們采用VSS+SourceOffsite進行版本控制,其中存放了此產品的所有源代碼、庫文件、文檔及release時的安

10、裝程序,各個部分存放在不同的目錄中。每天早上要求開發(fā)人員從VSS中get latest version的源代碼,然后進行編譯并開始一天的工作。在下班之前理論上要求員工check in所有當天修改的代碼,在check in之前要保證編譯是能通過的。若有誰check in的代碼導致daily build失敗則會被要求某些懲罰措施或警告,象微軟公司要負責照看當日的每日構建。有時我們編寫的代碼涉及到多個文件,而且此改動是比較復雜需要花費多天的工作量,如果現(xiàn)在check in進去可能會導致BVT(Build Verify Test測試通不過,因為有些代碼沒有完全完成,而之前的代碼能使BVT測試通過,而且

11、這些代碼基本上不會涉及到他人,在這種情況下可以不check in進去,直到全部代碼完成能提交BVT測試時再一起check in進去。每天我們都會做daily build,一般是在凌晨4點進行,那時有個程序會自動從VSS中拉下最新的代碼并進行編譯。因為我們同美國進行同步開發(fā),因此如果想要把修改的代碼進入到這個build中去那就需要在凌晨4點之前把相應的代碼check in進去。若有人check in進去的代碼導致編譯通不過則會在本步驟中被發(fā)現(xiàn)。當編譯完成之后自動產生安裝包,測試部門將會對這些代碼進行BVT 測試,同時對VSS中開發(fā)庫打上label,如果發(fā)現(xiàn)了什么BUG就能根據(jù)這個label 知道

12、是哪個時候開始出現(xiàn)這個BUG的。BVT是指Build Verify Test,是對組件中基本功能的測試。這個測試每天都會進行,看新加入的代碼或修改是否會影響系統(tǒng)的基本功能,便于及早發(fā)現(xiàn)錯誤。6.測試在開發(fā)人員完成了Function Spec后,測試部門開始了測試規(guī)劃,確定需要測試哪些方面,如何測試及進度安排。測試人員需要寫許多測試代碼,有些測試代碼需要集成進BVT測試,有些可能需要進行單獨的測試,目的都是為了使產品符合要求,使開發(fā)人員容易找出問題所在并改正。產品功能是否符合了要求,是否能被發(fā)布是由測試人員決定的,因此測試人員也比較辛苦,責任重大。通過了每天的BVT測試,還有一些性能測試、兼容性

13、測試、災難測試等需要在產品發(fā)布前進行。在完成這些測試之后由測試人員決定本產品是否能release出去了,如果沒有什么問題則會給某些關系較好的用戶進行測試,之后再最終release 出去。7.BUG管理由于我們每天進行著測試,因此經常有BUG被測試部門發(fā)現(xiàn),一旦發(fā)現(xiàn)了新的BUG,就會被添加進BUG Tracking System中。目前較流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla等。BUG tracking system是開發(fā)人員和QA之間的紐帶,開發(fā)人員和QA通過BUG tracking system聯(lián)系著。每個BUG有其類型和級別

14、,預定的類型有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)先級進入到下一個版本中去fix。QA發(fā)現(xiàn)一個BUG后在BUG Track中增加一個BUG,同時填入相關信息并assign給相應的開發(fā)人員,開發(fā)人員收到BUG 分析并fix后assign給QA去verify,其中要填上分析的結

15、果以及如何解決的詳細說明。若QA對此BUG verify通過則close BUG,否則verify failed并重新assign給開發(fā)人員并等待其fix。每星期在Status Meeting上會進行BUG狀況報告,主要由QA組長報告BUG的狀況,主要是新增BUG數(shù),fix掉多少,還有多少處于open狀態(tài),有多少處于等待verify的狀態(tài),據(jù)此可以了解開發(fā)及測試情況。有時在Status Meeting上我們也會進行BUG Review,BUG Review有時是單獨一個小組內進行,其主要作用是重新明確每個人頭上的BUG以及了解每個BUG的狀況,如開發(fā)人員對此BUG將作何處理等,以此來了解開發(fā)中

16、是否有碰到比較棘手的問題,增加了產品發(fā)布風險。在QA增加BUG和開發(fā)人員fix BUG的游戲中,BUG的數(shù)量曲線圖會象股市曲線一樣上下波動,但總體趨勢一般是前期BUG放量攀升,后期震蕩下挫,若到了后期新open的BUG數(shù)量一直上升則說明風險在增大,有可能無法控制,也就是說fix了一個BUG導致了多個新的BUG產生。在量化開發(fā)進度中也可以用代碼數(shù)量的曲線圖來粗略的呈現(xiàn)。在有大量新功能增加時可能代碼量的增加會較快,當在fix bug階段,代碼的修改較多,因此代碼數(shù)量的增幅會降低,依據(jù)代碼量可以看出開發(fā)的狀況處于何種階段。需要指出的是我們對BUG的定義比較廣泛,一些新功能也可以作為BUG被提出,只不

17、過這些BUG級別比較低,讓它們進入到下一個版本中去實現(xiàn)。因此BUG 的創(chuàng)建者也可以是技術支持人員、市場人員甚至開發(fā)人員本身。關于開發(fā)人員本身,因為他可能會找出一些BUG,有些是其他開發(fā)者的,有些可能是此開發(fā)者本身的,把這個BUG添加進BUG庫中可以幫助開發(fā)人員在以后產生新問題時或類似的BUG時有一個借鑒和思路,但此BUG的verify必須要讓測試本模塊的測試人員來verify。8.Code Freeze當P5之前的BUG都被修復了,這時離產品發(fā)布日期也就不遠了,一般是2個星期后就能release產品,這時要對VSS中的代碼進行freeze,以保證代碼庫的穩(wěn)定性。Code freeze階段一般會

18、把各開發(fā)人員的check in和check out 的權限關閉,若在這時仍有BUG報告上來并經討論確定是重大的且必須在本版本中fix的,則需要經管理層同意并特殊地授予權限,在修改完成后修改者要把修改了哪些文件,影響了哪些文檔等信息上報給各部門如QA、build人員、文檔編寫者等。在code freeze階段,測試部門在緊張地進行著各種測試,得出各種數(shù)據(jù),并決定本版本是否可以release了。9.Tech Talk計算機知識更新速度非常快,經常有一些新的術語、新的名詞、新的思想、新的技術所產生,如過離開此行業(yè)幾個月后重新回來就會對這些新的事物不解,而我們平時為了自己的項目埋頭苦干可能忘了周圍的世

19、界發(fā)生了什么。Tech Talk就提供了一個讓我們了解新知識和最新發(fā)展趨勢的機會,讓大家把知識共享,共同提高。Tech Talk一般會在項目不是太忙碌的時候進行,主持人會提前一個星期指定某個人去準備一下Tech Talk,一般此人可能對某方面比較感興趣,然后他會花一些時間去了解這方面的情況,寫成一個文檔如PowerPoint并上傳到局域網內,同時通知大家可以先去瀏覽。Tech Talk的內容非常廣泛,不一定同我們的項目緊密相關,任何新的思想、新的知識(當然一般是限在計算機領域內都可作為Tech Talk的內容,而在主講人講完之后還有一段時間被大家提問,共同對這個話題進行討論,答疑解惑。當然Te

20、ch Talk也可同我們的項目相關,如研究一下競爭對手的產品技術,本公司產品的架構等。研究本公司的產品架構可以使大家對本公司的產品有一個全局的概念,從整體上來看自己的產品,順便整理一下產品的架構使之更加清晰有條理。平時大家都只注重于自己負責的其中的一小塊,在Tech Talk中可以跳出自己的小框框來了解全局,同時這也是新員工了解公司核心技術整體框架的好機會。 每個模塊的負責人需要闡述此模塊的方 方面面，讓大家來了解并回答問題。 10. Code Review 當進行工作移交時我們會進行 Code Review，在碰到棘手的 BUG 時也會進行 Code Review， Code Review

21、是大家了解其詳細實現(xiàn)的一個好機會。 Code Review 在 之后會對此代碼產生親切感而不是陌生懼怕感， 相信很多人在讀他人代碼時會有 非常痛苦的經歷，Code Review 是減少此痛苦感的好藥方。在進行 Code Review 前，主講人會提前發(fā)出一個通知告訴相關人員要 review 哪些代碼，這樣參與者 可以抽出時間提前了解相關代碼，對不懂的地方做個筆記以便在 Code Review 進行中提出疑問。在我們碰到比較棘手的 BUG 沒有什么思路或大惑不解時，這時 找?guī)讉€相關人員或對此代碼也熟悉的人進行一次 Code Review，這時形式比較隨 意，大家可以臨時提出問題，讓主講人解答，在

22、這個過程中可能聽的人并不會非 ?？斓亓私馄渲械脑敿氝^程，但是講的人在這個過程中重新理了一下思路，對所 寫的代碼被迫重新審視了一遍， 在其中可能就會發(fā)現(xiàn)出解決問題的辦法。 Code 在 Review 時有時代碼非常多，但可以一個功能模塊一個功能模塊地從總體到局部， 由淺入深層層遞進的方式進行。一次 Code Review 的時間不要太長，但可以分多 次進行。Code Review 中大家會提出問題和建議，集思廣益，多個人共同出主意， 有些可能一個人沒有想到的問題會被大家發(fā)現(xiàn)，互相學習，共同進步。 11. 溝通與交流 大部分員工的大部分時間是在公司里度過的，因此公司的生活成了大家主要 組成部分。員

23、工之間關系的融洽，交流的暢通顯得非常重要，同時大家也不想自 己的生活這樣枯燥乏味，一直同機器打交道。溝通無處不在，交流隨時發(fā)生，有 許多關系是在工作之外建立起來的。軟件公司內是很容易產生各種矛盾的，因為 這是由你的工作性質所決定的，比如 QA 或用戶會對你的實現(xiàn)不滿意，提出各種 要求時，我相信你有時會有所抱怨的，無形之中就產生了對立，發(fā)展到后來會有 抵觸心理。我相信大部分人都會有此感受，這不是你的錯，這主要是由我們的工 作性質決定的。如果你的工作是把財富帶給對方，則對方會非常歡迎你的到來， 把你奉為財神爺來對待，同你的關系會非常融洽友好。因此我們需要在工作之外 來消除這種對立矛盾的關系，建立一

24、種融洽的工作氛圍。我們在平時吃飯的時候 飯桌上大家互相聊天溝通。我們建立了 happy 郵件列表，其中會發(fā)一些幽默笑話 之類的郵件，給我們緊張的工作增加點輕松的氛圍。在下班后大家可以組織一下 活動，增加了公司的凝聚力。一個產品發(fā)布后組織一下旅游，讓繃緊的神經松弛 一下，更好地迎接下一個挑戰(zhàn)。 12. 后記 不同公司有不同的做法，我只是把我認為比較好的流程與管理方式呈現(xiàn)出 來，讓大家有個借鑒，當然它也不是十全十美的，也不是放之四海而皆準的，如 果你覺得某些地方對你有所幫助或值得推廣，這是本文最想達到的效果。非常感 謝 I 公司給了我這么美好的經歷， 也非常感謝 I 公司的同事們曾給我的巨大幫助，

25、 在此衷心地祝福 I 公司越來越壯大，逐步走向成功！也衷心地祝福我的同事們幸 ?？鞓罚?搜集了一篇軟件開發(fā)中項目管理的文章，看看 當項目繁多的時候，需要規(guī)范，并且定義到細節(jié)，只有這樣，才能支持大規(guī)模的開 發(fā)。 PM 非常重要，PM 的能力將直接導致項目最后的質量。 本文是根據(jù)公司當前的現(xiàn)狀而描述的，并不一定普遍適用合適的，就是最好的。 項目經理職責： 1、 基本職責就是確保項目目標的實現(xiàn)，領導項目團隊準時、優(yōu)質地完成全部工作。 2、 與客戶溝通， 了解項目的整體需求。 并與客戶保持一定的聯(lián)系， 即時反饋階段性的成果， 和即時更改客戶提出的合理需求。 3、 制定項目開發(fā)計劃文檔，量化任務，并合理分配給相應的人員。 4、 跟蹤項