如何構建高效軟體開發流程和團隊-上篇

前言

本人曾就職於多家公司，但留給我印象最深刻、開發管理最規範的公司是I公司。該公司總部位於美國矽谷，其開發的產品曾獲得PC Magazine的最高五星級的優秀好評。

現我根據在此公司中所感受到的經歷及自身的一些感想寫出來，希望能給大家和其它公司有所借鑑。

👁 Image
...

1.項目計劃

在一個產品發布並使用之後，其中肯定有許多地方不如意和值得改進的地方。客戶在使用的過程中會發現一些問題，提出更高的需求，市場也在發生變化，我們的競爭對手也在發展，新的技術不斷地產生，這些因素推動著我們的產品不斷地向前發展，使它的版本不停地往上增長。

這些發展的需求不是一下子提出來的，在客戶使用的過程中發現某些不如意不方便的地方，他們會向我們的技術支持人員提意見，而技術支持人員會把這些需求以BUG的形式存入BUG資料庫中，其級別一般定義為下一個版本的Feature。

有些上一個版本未解決的BUG也可能需要在本版本中來解決。因此當我們來開發下一個版本時，其許多特性已經存在於BUG資料庫中了。

當然新版本的特性不是只從BUG中獲得，管理層可能從市場的角度來提出新的特性以求領先競爭對手，開發人員本身也可提出某些要求來納入新版本開發的計劃中，如要求對某部分代碼進行重構以使其結構更清晰更容易維護，執行效率更高。

每個人把同自己相關的功能模塊收集起來，同時預估時間，其中主要包括寫文檔的時間、開發時間和單元測試的時間，一般要求精確到工作日。

這些信息發送給組長，組長再把本小組人員的任務和預估時間發送給管理層，由管理層對此任務及進度進行評估審核，管理層會根據產品發布時間及客戶需求、市場因素等方面作出選擇，可能某些功能由於時間緊急會被推遲到下一個版本中去。

若預估出來的時間同預計的產品發布時間有較大衝突，而且此功能是本版本中必須得做的，則開發小組會被要求重新預估時間，加快開發速度來達到這個要求。

雖然這個開發進度時間是一個大概的估計時間，但我們要盡力按照這個開發進度來執行。每個星期五下午我們有一個Status Meeting（一般那時工作效率較低，適合開會），在此會議上我們會根據這個進度來review我們的工作，每個人手上的工作是否按照這個進度在走，是否有人延後了，是否block住別人的工作了。

在此會議上每個人都要報告自己的進度，同時還要報告上個星期做了什麼，正在做什麼，以及下個星期打算做什麼。

通過這個會議，會讓你覺得有人在監督你，無形之中迫使你不斷地督促自己不要使任務延後，如果有延後的跡象也會儘早發現而趕上。

若某些經過努力不能趕上，那也沒有辦法，只能修改原先的進度表，因為那是我們的估計與現實發生了偏差，我們必須使我們的進度表符合實際情況，這可以避免許多項目發生最後的20%的工作量會占據80%甚至一直拖後的情況。

修改進度表的情況我們曾經發生過，有一次在按照原先的進度執行到將要完成的狀態時突然接到通知由於市場及客戶的原因要求加入另一項重大的功能，這個功能對我們程序的結構有非常大的影響，因此我們就要重新制定一個進度來滿足需求。

在這種情況下，產品原先的開發進度被打亂，發布時間也因此推遲。當然這種情況應當盡力避免，尤其在項目後期產生新的需求，若不得已也應重新規划進度，而不是仍舊依照原先的進度去執行，因為老的進度已不能反映現實的情況。

2 開發文檔

在項目進度安排中我們已經把寫文檔的時間也規划進去了，這裡雖然是寫文文件，其實是設計程序，整理一下思路與架構，磨刀不誤砍柴工，這樣在實際寫代碼時會流暢很多，節省時間，因此可以說真正有思想性的東西都在寫文檔這段時間內完成了。

當然我們這裡的文檔格式不象ISO那樣規定了條條框框，我們的文檔格式相對自由，基本上能隨意發揮，但對於幾個主要點一般來說是需要說明的。

要求寫的文檔能讓他人比較容易地看明白，能把問題講清楚，能反映你的設計思想。

文檔的數量也不多，開發文檔有兩類，一類是function Spec，另一類是Design Document。

function Spec中需要寫明的是本模塊完成的任務，解決什麼問題，有什麼作用，為什麼要這些功能，此外我們還會添加進適用範圍，有什麼不足，注意點是什麼，還有哪些地方在以後可以進行改進。

在這個function Spec中不涉及到任何非常詳細的算法。此文檔不光給開發人員看，還讓QA及其它成員以及後來的新人能根據此文文件來了解此模塊的大致功能，同時也會給文檔編寫者看，他們會根據這些function Spec整理出一份用戶手冊，告訴用戶此版本中新增了哪些功能，各功能模塊有什麼作用，如何使用等信息。

因此在我們的開發過程中function Spec是很重要的文檔，此文檔完成後會抽出一段時間同相關人員及QA一起review這個文檔，讓QA了解設計者的意圖，同時熟悉新的功能模塊，為接下來的測試作準備。如果其中有誤解或不明之處，大家會提出來探討並由開發者修正。

Design Document中主要描述實現此模塊所涉及到的主要算法、數據結構、類的層次結構及調用關係。

這個文檔的閱讀者主要是開發人員，包括任何想了解詳細實現代碼的人，幫助人們理解代碼。在某些功能模塊比較簡單的程序中，此文文件所描述的信息會比較少。

此文檔不象function Spec要在開始寫代碼前就編寫完成，它可以隨著代碼編寫的進行而增加，但基本上遵循文檔先行原則，也就是要增加新的代碼或修改代碼前若有涉及到文檔部分的應先修改文檔，然後再修改代碼。

3. 編寫代碼

由於我們用JAVA語言進行開發，因此我們藉助了Jbuilder IDE工具。關於代碼風格，我們基本上套用Jbuilder中自動的代碼格式編排，但其中需要改變的是縮進是4個字符，類與類之間間隔2行，方法與方法之間間隔2行，import類時用完整的類名。

寫代碼時要對類及函數提供詳細的注釋及說明，基本做到看它們的說明就能知道這個類或函數的功能以及主要算法的實現原理。

在開發過程中對主要的模塊要編寫UnitTest，同時要UnitTest先行，也就是遵循XP規則中的測試驅動原則，當所有的單元測試代碼通過時，此功能也就基本上完成了。

4. 代碼管理

我們採用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，是對組件中基本功能的測試。這個測試每天都會進行，看新加入的代碼或修改是否會影響系統的基本功能，便於及早發現錯誤。

5. 測試

在開發人員完成了function Spec後，測試部門開始了測試規劃，確定需要測試哪些方面，如何測試及進度安排。

測試人員需要寫許多測試代碼，有些測試代碼需要集成進BVT測試，有些可能需要進行單獨的測試，目的都是為了使產品符合要求，使開發人員容易找出問題所在並改正。（更多精彩內容請戳：在軟體測試中，測試員到底扮演著一個什麼樣的角色？）

產品功能是否符合了要求，是否能被發布是由測試人員決定的，因此測試人員也比較辛苦，責任重大。通過了每天的BVT測試，還有一些性能測試、兼容性測試、災難測試等需要在產品發布前進行。

在完成這些測試之後由測試人員決定本產品是否能release出去了，如果沒有什麼問題則會給某些關係較好的用戶進行β測試，之後再最終release出去。

Testin雲測送大家一波超級福利！

① 價值5000元的Testin專屬測試大禮包（包含120分鐘自動化測試、120分鐘遠程真機調試、每日免費使用1次標準兼容測試、每日免費使用1次安全測試）；

② 原51testing產品總監陳霽老師16年測試工作總結精華 -《軟體測試入門必讀》課程。

如何獲取福利？

登陸或者註冊您的Testin帳號進行企業認證，完成認證自動獲得福利大禮包，認證請戳——> http://www.testin.cn

👁 Image
...