《VSTS軟件工程實踐》前言

為什么要寫這本書

在2003年加入微軟后，我負責Visual Studio Team System (VSTS)項目，這一新產品線剛剛于2005年底發布。作為這一組產品的規劃師，我擔任了首席客戶代言人這一我很喜愛的角色。我已經在IT行業工作了20多年，在職業生涯的大部分時間里，我做過測試員、項目經理、分析師和開發員。

作為一名測試人員，對于那些高級開發者的實踐（比如單元測試、代碼覆蓋度、靜態分析以及內存和性能的特征分析），我始終都能夠理解其理論價值。同時，我不能理解一個人怎樣才能有耐性去學習那些晦澀難懂工具，而這些工具又是你在遵循正確的實踐時所需要的。

作為一名項目經理，我經常煩惱的是：我們所能得到的體面的數據僅僅是那些與缺陷有關的數據。單靠缺陷數據來駕馭一個項目，就仿佛是閉著眼睛開車，只有在你碰到什么東西時才轉動方向盤。你真正想要看的是能指引正確方向的正確指示器，而不是僅僅在偏離路線時能感到的顛簸。在這一崗位上，也是類似的情況，對于諸如代碼覆蓋度和項目速度之類的度量，我始終都能夠理解它們的價值，但是我不能理解一個人怎樣才能實際地收集到所有這些數據。

作為一名分析員，我愛上了建模。我邊看邊思考，發現圖形化的模型控制了文檔和溝通的方式。但是一旦進入到實現階段，模型就總會過期。而且模型還正好沒有處理開發者、測試者和運行中的關鍵顧慮。

在所有這些情形中，由于把整個團隊的各開發環節連起來太困難了，我受到了挫折。我喜愛SCRUM（一個敏捷過程）中“單一產品待處理隊列”的創意：你能在一個地方看到所有工作，但是人們實際使用的工具卻都以它們各自的方法來分割工作。這些需求與那些工作有什么關系，與這邊的模型元素，與那邊的測試又有什么關系？還有，在這樣的混合中，源代碼又處于一個什么樣的位置呢？

從歷史的觀點來看，當IT停止了對手工過程的自動化嘗試時，我認為，已經“柳暗花明又一村”了?，F在IT所詢問的問題是“使用了自動化之后，我們怎么樣才能再造核心業務過程？”這是IT開始交付真正的業務價值的時刻了。

人們常說“鞋匠的孩子沒鞋穿”。這對于IT也很貼切。我們在忙于其他業務過程的自動化的同時，卻在很大程度上忽略了我們自己。實際上，所有的以IT專業人士和團隊為目標的工具仿佛仍然是對老的手動過程的自動化。那些過程在自動化之前需要很高的開銷，在有了自動化以后，它們仍然有很高的開銷。有多少次你參加的是一個1小時的項目會議，而會議的前90分鐘卻都在討論誰的數字才正確呢？

現在，有了Visual Studio Team System，我們會很嚴肅地問“有了自動化，我們怎樣才能再造我們的核心IT過程呢？我們怎樣能消除這些優秀過程中的額外開銷呢？我們怎樣才能既讓這些不同角色的每個人都能有更高的生產力，同時還能把他們整合成一個高效的團隊呢？”

誰應該讀這本書

本書為那些考慮在軟件項目中使用VSTS的軟件團隊而寫。這是一本關于為什么的書，而不是一本關于怎樣做的書［1］。 VSTS身后的指導思想是什么？為什么這些觀點以這些方式來表現？例如，為什么把這么多東西都叫作工作項？度量元倉庫度量了些什么？你為什么要使用這些特定的報表？

我一次又一次地體驗過：人們在知識、技能和經驗上的不同使得軟件項目啟動時的條件也不一致。有的事情對于有的人來說是一個自證明的真理，而對于另一個人則是一個神話；有些事情對于有的人來說是常識，而對于另一個人則是個發現。各種功能角色往往已被固定在職業階梯中，而這種對功能角色的自然強調使這一問題更加惡化了。我當然相信是有專家級的開發人員、專家級的測試人員、專家級的架構師、專家級的業務分析師和專家級的項目經理的，但是交付的客戶價值要求的是各學科之間的協作。在與其他角色隔離的情況下，去努力優化某一個角色，并不一定會提升客戶所能看到的結果的交付。

解決這一矛盾的一種方法是找一個現場教練（onsite coach）來領導團隊通過一組一致的過程。教練很棒，但不是每個人都能享受這種奢侈能和教練一起工作。因為我不能發給你一個隨需應變的教練，所以我就寫了這本書。

本書不是用戶手冊那樣的教程，不會一步一步地告訴你應該以怎樣的順序點擊哪里。VSTS中已經帶有大量關于這些主題的優秀文檔，我會在適當的地方列出這些文檔的引用。確切地說，本書提供了一個框架，讓我們按照一種可以直接利用VSTS工具的方式來思考軟件項目。實際上，我們開發VSTS正是為了能夠以這種方式來管理軟件項目。

本書也不是一個軟件工程文獻的縱覽。在最近的40年中，已經有了幾十種甚至上百種關于軟件工程的著作。這里我就不對它們重述了，并且也不再全部包括那些其他著作已經包括了的材料。我預料到很多專家會批評說我的某些觀點在今天是不言而喻的。不幸的是，正如Freud所指出的，不言而喻的東西往往根本沒有人說。其結果就是：只有當發生了錯誤的爭論時，團隊成員之間在假設上的不同才能暴露出來。因此，如果你責怪我陳述了過多顯而易見的東西，我承認的確如此。

我展示了足夠的Team System理論和實踐例子，目的是向大多數主流的IT項目和團隊描述一個實際的過程。對于必須符合FAA（美國聯邦航空管理局）的要求的航空軟件來說，這一過程可能不夠正式；對于駐扎在車庫中的3個人的團隊來說，這一過程可能又不夠松散。

如何讀這本書

VSTS所包含的過程指南被稱作微軟解決方案框架(Microsoft Solutions Framework，MSF)，其中所包含的核心概念就是一個基于團隊同行的團隊模型。團隊模型還考慮到了不同尺度的專門化。MSF定義了在成功的項目中必須扮演的7類選民（選區），或者說視點，如圖P?1所示。MSF還包括了對于上調和下調伸縮性的建議。在本書中，我始終會強調這些視點，并使用下面這樣的一個圖標：

圖P-1微軟方案框架引入了一個團隊同行的模型，錨定在一個成功項目所需要表現出的7個視點之上。用于CMMI過程改進的MSF把這7個視點細化為18個，而用于敏捷軟件開發的MSF把產品管理和用戶體驗合并在了一起，從而使用6個角色實現了這7視點，它同時還提供了將它們減至為3個的指南

這本書是寫給整個團隊的。它展示信息的風格是為了能讓所有團隊成員感知彼此的視點。不過，本書還是針對角色來劃分章節，這樣就使讀者能夠根據自己對特定角色的需要而關注某些章節或略過某些章節。我已經努力將這些主題保持在這樣一個級別上：既對團隊的所有成員都有吸引力，又對任何人都不晦澀難懂（我的這一選擇可能更會使某些人要批評我講的過于簡化）。在當今這個專業化的年代中，你與同事的專長各有不同，而你們之間的約定和對他們的預期也應該至少保持在這樣一個級別上，我認為這很重要。如果你很忙，可以根據這些圖標閱讀那些與你最感興趣的角色相關的主題。

文檔提示

正如我所說的，這不是一本講如何做的書。在那些需要VSTS的細節或它的文檔的地方，你會看到一個文檔提示，就像下面這個例子：

Microsoft Developer Network（MSDN）訂閱

每套VSTS中都包括了一個微軟開發者網絡（MSDN）的訂閱。請從鏈http://msdn?microsoft?com/teamsystem開始，按照Reference→Product Documentation的鏈接向下走。對于有些術語，你可能想檢查一下它們的用法。想要查詢它們，請查閱MSDN的主題：

Development Tools and Technologies

Visual Studio Team System

Visual Studio Team System Glossary?

?譯者注：若要訪問中文MSDN中Visual Studio Team System，請用：

http://www.microsoft.com/china/msdn/vstudio/teamsystem/default.aspx 。

VSTS詞匯表在中文MSDN中相應的主題為：

Visual Studio 2005

Visual Studio Team System文檔

Visual Studio Team System 詞匯表

http://msdn2.microsoft.com/zh?cn/library/ms242882    (VS.80).aspx）我做出這樣的選擇是因為我假設在你讀本書的大多數時間里，你沒有坐在一臺電腦前，你只是偶爾才會想要回到電腦桌前去做一些動手操作。當你只是閱讀時，你可以跳過這些提示。

其他人的思想

我在本書中的目標是介紹VSTS背后的思想，但不是原樣宣讀這些思想。重新設計VSTS就是為了使不同的過程能夠合適地應用到不同的組織和項目上。VSTS和本書都大量使用了軟件社區已制定出的優秀實踐。我已經在尾注中盡可能地包括了相應的資源。如果你對于這些參考書目沒有興趣，就不必去讀這些尾注了。

在你開始之前需要對VSTS了解的內容

本書初稿的評審者曾經抱怨我沒有把VSTS中有什么解釋得足夠清楚，因此我就把這個直接來自微軟網站的產品介紹放到了下面的板塊中?，F在已經有了4個VSTS的客戶端產品，并且以后可能還會更多，但是我并沒有區分它們，因為價值是在Team Suite中的。當然，微軟讓你按菜單點菜的方式來購買功能，但我想保持簡單。

因此，在我寫到“VSTS”或“Team System”的時候，我所寫的就是指Team Suite。

微軟解決方案框架（Microsoft Solutions Framework，MSF）是VSTS的一部分，如圖P?2中的“過程指導”框所示。MSF在框外分為兩種形式，并能定制成無數的變種。這兩個標準形式是：

?  ● 用于敏捷軟件開發的MSF（MSF for Agile Software Development）

?  ● 用于CMMI過程改進的MSF（MSF for CMMI Process Improvement）

稍后我會對這兩種MSF描述得略微深入一些，但是基本上，如果你的組織對軟件過程比較陌生，請從用于敏捷軟件開發的MSF開始。如果出于地理上的分布、過程改進計劃、一致性審計或期望通過CMMI評估等原因，你需要更為正式的過程的話，那么你應該考慮用于CMMI過程改進的MSF。

只有在有必要的時候，我才會區別這些產品，除此之外，我將保持關注于它們的公共概念。

圖P?2Visual Studio 2005 Team System由4個客戶端產品和一個服務器產品組成

聲明

最后，我需要澄清一下，本書中的觀點僅是我個人的觀點，并不一定是微軟公司的觀點。雖然我是微軟的一名雇員，但是我的寫作是我的個人行為，不是為了公司而寫作。不要為了我在這里所表達的觀點和所犯的錯誤而責備微軟（除非你想告訴他們雇傭我是一個錯誤），請來向我抱怨。你可以直接來我的博http://blogs?mircosoft?com/sam/與我討論。

參考資料

［1］ 關于如何操作VSTS的書, 請參見Will Stott 和James Newkirk編寫的《Visual Studio Team System ? Better Software Development for Agile Teams 》(Boston, MA: Addison?Wesley, 2006)?

致謝

很多人激勵我編寫這本書，他們給予了不尋常的幫助。我首先要感謝我的編輯Karen Gettman，感謝她愿意考慮一個第一次寫作的人的愿望和提議。Ivar Jacobson和Cem Kaner是我的重要的導師，他們多年以來都在鼓勵我寫作。

接下來是Rick LaPlante，他還是我現在的老板。在Rick雇我作Visual Studio Team System的組產品規劃師的時候，他在我身上下了注，現在他已經完全成了一個支持性的管理者。除了Rick之外，還要感謝幾百個同事，正是他們把VSTS創造成現在這個產品。每一次和他們的接觸都是并且將繼續是一次思想的充電。

正如你將看到的，我很依賴于Granville (“Randy”) Miller和David J? Anderson的工作，是他們創造了用于敏捷軟件開發的MSF和用于CMMI過程改進的MSF。我們在創建MSF v4的實例時有過無休止的爭論和發現，我從其中所學到的東西形成了你在這里讀到的主要內容。

感謝我的合著者Juan J? Perez，以及Personify Design的Kim Tapia St Amant為本書創造了盡可能多的豐富例子和演示。和他們一起工作非常愉快。

最后，我要感謝眾多的審閱者，包括Jeff Beehler, James Behling, Charlie Bess, Rossen Blagoev, Rob Caron, Wendy Chun, Kevin P? Davis, Cristof Falk, Linda Fernandez, Ken Garove, Bill Gibson, Martin Heller, Bijan Javidi, Yulin Jin, Cem Kaner, Chris Kinsman, Aaron Kowall, Clementino Mendonca, Thomas Murphy, Gary Pollice, Tomas Restrepo, Johanna Rothman, Joel Semeniuk, Will Stott, Dan Sullivan, David Trowbridge, Mike Turner, Kumar Vadaparty 和Peter Williams。Addison?Wesley的Kim Boedigheimer, Ben Lawson和Michael Thurston在最后階段給了我極大的幫助。如果沒有所有這些審閱者的建議和意見，本書可能只有現在篇幅的一小部分。

Sam Guckenheimer

華盛頓州雷德蒙德

2006年1月