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