一、引言

1 中國式軟件過程的壞味道
?RUP，CMM/CMMI到了中國就變了味。。。。。。

2 Team Foundation Server
?TFS是軟件開發的協作平臺，它要解決的首要問題是團隊成員的協作問題。比如說：
研發團隊內部怎么協作，產品經理，架構師，設計師，開發人員，測試人員怎么進行協作，并行工作？
研發團隊之間怎么協作，開發人員怎么共享重用技術，加強橫向的聯系？
研發團隊與運營團隊怎么協作？

?之前我一直在實踐著Rational系列軟件產品，總覺得Rational系列易用性不好。一直到2006年我才發現有TFS，但安裝部署Team Foundation Server 2005沒有成功，所以到2007年Team Foundation Server 2008(beta1)發布后，我們才開始試用，期間經歷了TFS的多次發布。在4年的實踐過程當中，我們越來越深刻認識到：只要協作的問題解決了，管理的諸多問題將迎刃而解。
?"軟件過程沒有銀彈！"但可以有核彈，TFS就是這樣的核彈，它的威力足以支持超大型的軟件團隊，研發優秀的軟件產品。當然它的威力大小取決于你運用的功力。

3 敏捷過程
?作為軟件全生命周期的工具，TFS支持CMM等重量型軟件過程，也支持敏捷過程。CMM等重量型軟件過程受管理人員的歡迎，敏捷過程更受開發人員的歡迎。重量型軟件過程過于粗放，敏捷過程更細致靈活。從管理思想上來看，重量型軟件過程強調管理，執行力，紀律，制度等，有兵家和法家思想的特點。敏捷過程強調協作，創造性，自由等，無為而治，有道家思想的特點。
?君子性非異也，善假于物也。再先進的思想也離不開工具。扎根在TFS的平臺上，敏捷思想必能開出更加炫麗的花朵。
4 持續改進
?中國文化創造了中國式軟件過程的壞味道，西方文化創造了TFS，也創造了敏捷思想，并且指明了軟件過程持續改進的原則。從蹣跚學步到騰云駕霧絕非一日之功，需要十年磨一劍的執著。而分享成功的經驗，改變中國式軟件過程的壞味道，不要讓TFS也變了味，為千千萬萬的程序員創造良好的生態環境，則是更大的挑戰，需要更多人的努力，更需要持續改進。
?最近我一直在思索，新手怎么學習TFS和敏捷過程。對于剛剛工作的程序員，雖然經驗不足，但惡習未養成，可塑性最好。從一開始就應該持續的學習和實踐，始終走在正確的道路上。千里之行，始于足下。從一下篇開始，我們將把起點定位新手的水平，來學習TFS

二、源代碼管理

重量型過程改進通常會先拿出一個文件夾，里面有各種規范和文檔模板，琳瑯滿目，ISO9000如此，RUP也是如此，CMM更是如此。一般人看到這么多東西非嚇暈過去不可，但咨詢師會鼓勵你，告訴你這是培訓的框架，都是必須品，等你把這些東西掌握了就如何神通廣大了，然后開始漫長的學習過程。新手？這是for高級崗位的。

敏捷開發認為：代碼是最精確的文檔，一個軟件什么都可以省，唯獨代碼是必不可少。一個項目團隊可以沒有項目經理，測試人員，哪怕只有一個人，那一定是個程序員。現在，只要會寫代碼，馬上就可以開始敏捷開發了，門檻不高吧？這才是最貼近我們程序員的軟件過程。

1 TFS 2010入門

TFS 2010的安裝已經很容易了，安裝完后點下面的鏈接先入個門：Visual Studio Application Lifecycle Management?入門

1.1 連接到 Team Foundation Server

1.2 新建團隊項目

1.3 將解決方案添加到源代碼管理

1.4 簽入

簡單練習一下上面列出的4條，你就已經入門了。

?

2 源代碼管理資源管理器

接下來請打開"源代碼管理"，這才是眾妙之門，CMM的文檔模板集只是個笨重的大包裹。練練"簽入"，"簽出"，就可以用TFS來工作了。好像有的人用TFS只是來做源代碼管理，有點兒可惜了。

??

?

3 管理工作區

3.1?編輯工作區

接下來打開工作區，添加或編輯工作區，把TFS服務器映射到本地文件夾D:\Projects，確定后系統會提示你，"工作區已修改，是否要更新本地工作區"，選是。

?

3.2?本地工作區

?

下圖是本地工作區D:\Projects的目錄結構，每個文件夾映射到一個團隊項目，與服務器的團隊項目完全相同。這樣把各個不同的項目區分開，不同項目的成果和過程文件等各自放到各個項目文件夾里，不要再放到桌面，我的文檔，邏輯驅動盤的根目錄等。另外不要把不相關的文件簽入到團隊項目里來。敏捷的秘訣之一就是力求簡單。

?

?

3.3?團隊項目目錄結構

團隊項目的根目錄都包含三個主要目錄：

序號	目錄	說明
1	Data	數據
2	Documents	文檔
3	Source	源代碼

?

軟件=程序+數據+文檔，這不正是我們軟件工程師理解的軟件嗎？讓那些高高在上的理論落地，成為我們實踐中的一部分。

?

4 變更集

4.1?歷史記錄

在"源代碼管理資源管理器"里選中"Source"，然后點擊工具條上的歷史記錄，我們將看到"Source"目錄下所有的變更集。這些變更集是我們日常簽入在TFS上自動化的結果，這不需要CMM過程填這樣那樣的表格，不會增加我們的負擔。即使寫個簡要的注釋慢慢的我們也習慣得了。要知道，我們的目的是給程序員減壓，而不是加壓。

?

4.2?變更集詳細信息

現在我們看看70號變更集的詳細信息，我們看到這次變更是添加了一個文件"LoadLayerCommand.cs"。

右鍵查看一下這個文件里寫了什么：

?

4.3?查找變更集

打開"查找變更集"界面，我們可以按用戶，文件，日期等條件進行組合查詢。下圖是查文件"LoadLayerCommand.cs"的變更歷史，以了解它的開發以及重構等。

?

4.4?簽入原則

變更集是由簽入產生的，所以正確對待每一次簽入。亂糟糟的代碼肯定會導致亂糟糟的變更集，關于如何寫簡潔的代碼，請參考《敏捷軟件開發：原則、模式與實踐》，《重構-改善既有代碼的設計》等書。對于新手，簽入的時候盡量用小的變更，不要把多個單一職責的文件一起簽入，比如說："ImportTxtFileCommand.cs"和"ExportTxtFileCommand.cs"要分開簽入，即使你寫在同一個文件里"MainForm.cs"的兩個方法"ImportTxtFile()" 和"ImportTxtFile()"也分開簽入。為什么呢？是因為我們將歸納變更集來產生工作項，你簽入耦合度非常大的變更集，我們就沒辦法歸納了。正向的工作計劃不容易，逆向的工作總結要容易的多。好了，今天先說到這，至少工作項已經很近了，下一篇探討怎么通過工作總結來提高工作計劃的能力。

三、定制敏捷過程模板

Team Foundation Server 2010內置兩個過程模板，雖然有TFS過程幫助文檔，但微軟并沒有提供我們最需要的實踐指南，示例等。我們一直用"MSF for Agile Software Development v5.0"，長期以來我們盡量適應這個模板，把它當成標準來用。但是漸漸的我們發現這個過程模板跟我們實際的開發工作并不吻合，一方面這個模板畢竟是舶來之品，跟中國式的軟件特點有很大的差異；另一方面軟件過程持續改進是恒定的規律，現階段的工作特點需要跟現狀相符的過程模板，而不是一步到位。

首先啟動Visual Studio 2010，打開"團隊\團隊項目集合設置\過程模板管理器"，下載"MSF for Agile Software Development v5.0"到本地文件夾。

然后下載：Team Foundation Server Power Tools?，安裝完成后，在visual studio里執行"工具\Process Editor\Process Templates\Open Process Template"，打開剛下載的"MSF for Agile Software Development v5.0"進行修改。

?

1 迭代(Iterations)

????團隊項目的第一個階段是"迭代?1"，"迭代?n"等隨項目的進展動態添加。另外，這里增加一個特殊的迭代："積壓"(Backlog)，未計劃的，不明確，不緊急的工作項暫時放到"積壓"里，隨著項目的進展情況以及客戶的要求，"積壓"里的工作項才會安排到"迭代n"里。

2 組成員資格(Group)

????新增三個組：Developers (開發者)，Support (技術支持)，Testers (測試員)

3 團隊查詢(Team Queries)

敏捷過程模板默認生成的團隊查詢如下圖所示，看起來比較復雜，我們一邊用一邊定制新的查詢，來來回回用了兩年，最后總結了最常用的查詢，那些不常用的查詢狠狠心都刪除了。

圖 1 修改前????????????????????????????????????????圖 2 修改后

?

?

3.1修改查詢

3.2 我的所有工作

這個查詢體現的是個人關注，是項目成員工作的入口，把所有項目中指派給他的用戶情景，任務，問題，Bug顯示在一個表格里，使得他可以快速簡便的查看自己的任務情況，比如：新任務，未完成的任務，優先級高的任務等等。實踐發現，這種方式比讓他去各個項目里去查找"我的任務"，"我的Bug"等要有效的多，特別是對于多項目并行開發以及跨部門協作的情況。

?

?

3.3 所有工作

這個查詢體現的是項目關注，關注項目的全部工作項以及工作項之間的父子關系。

4 工作項(Work Item)??

4.1 默認工作項(Default Work Items)

TFS2010支持工作項的層次結構，這樣當工作項特別多的時候就不像TFS2008那么亂了。于是每一個新的團隊項目里都要手工創建完全相同的頂層摘要任務，重復工作又來了，消滅重復勞動，提高自動化水平是我們義不容辭的責任，那就直接在默認工作項里添加吧。一點小遺憾是不能建立父子關系，只能在創建團隊項目后手工完成。

?

4.2 工作項類型(Work Item Type)

本來不想定制工作項類型，無奈敏捷過程模板不支持"開始日期"和"完成日期"，如果想要設置工作項的"完成日期"，還要用Office Project打開tfs才能修改"完成日期"。這也太不敏捷了，打開"Type Definitions"編輯任務，添加上"開始日期"和"完成日期"。

預覽一下看看效果，看起來還挺合適的嘛！自從把這兩個字段放出來，舒適度提高20%。

?

最后，把修改完的過程模板改名為："MSF for Agile Software Development v5.1"，再次打開過程模板管理器，上載到服務器。

代碼下載

四、工作項跟蹤（1）

可跟蹤性是軟件過程的重要能力，TFS主要是以工作項來實現過程的可跟蹤性。曾有人問："你們實際項目里的工作項是怎么樣的？能不能讓我們看看？"我也一直很好奇別的公司TFS里的工作項是怎樣的，網上這方面的資料很少。我就以三年前的三維管線項目為例，說一說我們的工作項跟蹤，歡迎大家批評指正。

?

1 需求

敏捷宣言認為："響應變化 重于 遵循計劃"，需求的變化，尤其是在中國，經常是無休無止。我們要做的就是要在TFS上做好需求管理， 從而達到響應變化的目的。

?

1.1 需求管理

我們先新建一個用戶情景，標題寫上"爆管分析"，然后指定區域，迭代，堆棧級別，需求說明寫到詳細信息里。情景點是跟工作量相關的，我們沒有估算工作量，也沒有安排時間進度。

用戶情景是需求管理的基本單元，跟文檔化需求管理有很大的不同，我們沒有強調需求基線評審，也沒有正式的需求變更審批。需求發生變化時，只管更新到用戶情景的詳細信息。需求往往會經過反反復復的修改，歷史記錄里會保存著更改的時間，人，內容。這比跟蹤需求規格說明書這樣的大文檔的版本歷史要容易的多。

?

1.2?用戶故事

用戶故事是需求建模的一種方式，也是敏捷開發的重要實踐。功能點的建模我推薦采用用戶故事，可以比可視化建模表達詳細的信息。轉到上圖里的"實現"，這時我們看到當前的子項為空，接下來新建一個子任務"編寫爆管分析用戶故事"，經過反反復復的修改最終結果如下：

1 啟動爆管分析命令，系統顯示爆管分析界面；

2 指定一條管段，三維窗口里顯示這條管段的選中狀態；

3 輸入緩沖區半徑后執行分析，系統顯示出閥門井列表；

4 雙擊列表中的一條記錄，三維窗口定位到當前的閥門；

5 點擊[導出]按鈕，列表里的數據導出到excel里了；

（用戶故事完成后合并到用戶情景的詳細信息里，跟需求規格并列）

?

2 設計

軟件的設計涉及到方方面面，同時還有各種各樣的設計方法。我認為實際的工作中我們應該只做必要的設計，敏捷宣言認為："工作的軟件?重于 詳盡的文檔"。工作的軟件就是可以運行的程序，和運行所必須的數據。基于代碼和數據一樣可以作出好的設計，在沒有必要寫文檔時，盡量不要長篇大論。

?

2.1?爆管分析輸出設計

轉到用戶情景的"實現"，創建一個新的子任務，寫上標題"爆管分析輸出設計"，并鏈接"編寫爆管分析用戶故事"作為前置任務。

接下來我們看看這個任務的結果，變更集的注釋是"爆管分析輸出設計.fly"，下載打開發現是用skyline軟件制作的三維數據，如圖所示。

2.2?爆管分析用戶界面視覺設計

再創建一個子任務，寫上標題"爆管分析用戶界面視覺設計"，指派給界面設計師，轉到"所有鏈接"，鏈接類型選擇"已進行版本管理的項"，指定項"$\Pipe2012A1\Documents\設計\輸出設計\爆管分析\爆管分析輸出設計1.png"，寫上注釋"工作輸入"。即"爆管分析輸出設計"任務的工作輸出是這個任務的工作輸入。

工作完成后，我們打開變更集5702，并查看其中的圖片"$\Pipe2012A1\Documents\設計\界面設計\爆管分析\爆管分析界面設計1.png"

?

2.3?爆管分析面向對象設計

再創建一個子任務，寫上標題"爆管分析面向對象設計"，并鏈接"編寫爆管分析用戶故事"作為前置任務。這里的"面向對象設計"已經是詳細設計了，我們的做法是直接到代碼，需要設計類名，輸入數據，輸出數據，方法，命名空間等。"代碼是最精確的文檔"，不要在文檔上繞來繞去，沒有程序員有興趣看那些華而不實的設計文檔。

我們打開"變更集5143"，查看"BoomPipeCommand.cs"。

3 構建

構建最主要的活動是編碼，由于敏捷開發反對過度的詳細設計，所以這里的編碼所涉及到不僅僅是實現，還包括：算法設計，設計模式，代碼重構，代碼調整等等。用代碼承載那些精妙的設計，而不是笨重的文檔。

3.1?爆管分析編碼

再創建一個子任務，寫上標題"爆管分析面向對象設計"，并鏈接"爆管分析用戶界面視覺設計"和"爆管分析面向對象設計"作為前置任務。這樣就不用給該任務鏈接工作輸入了，執行任務的程序員可以直接找到前置任務的工作輸出（即變更集）。

任務完成后，我們看到"變更集5115"的鏈接注釋"BoomPipeCommand.cs"，"變更集5160"的鏈接注釋"BoomPipeControl.cs"。代碼大家都很熟悉了，這里就不再詳述。

4 測試

TFS的測試涉及非常多的內容，本文我只談測試用例和Bug。

4.1 測試用例

轉到用戶情景的"測試用例"，創建一個新的測試用例，標題寫上"手工輸入管段ID進行碰撞分析"，然后使用Microsoft測試管理器進行編輯，在步驟里寫上：

操作	預期結果
點擊[爆管分析]按鈕	左邊欄顯示爆管分析界面窗口
從文本框輸入"J-A229"，回車	三維窗口高亮顯示ID為"J-A229"的管段，并閃爍爆管的圖標。
輸入緩沖區半徑200，點擊[開始分析]按鈕	閥門井列表顯示2條記錄
雙擊列表中的第一條記錄	三維窗口定位到控制閥門"FA-331"并閃爍
點擊[導出]按鈕，選擇路徑"d:\1.xls"	系統提示導出成功。
在excel里打開"d:\1.xls"	顯示2條記錄，ID分別是"FA-331"，"FA-334"，

測試用例完成后結果如下：

4.2 Bug

測試工程師在測試中發現了Bug，這時候應該轉到用戶情景的"所有鏈接"，新建一個Bug，標題寫上"Bug：閥門記錄與操作有誤"，嚴重級別為"中"，然后寫上說明，指派給某個程序員。程序員調試Bug之后，會把狀態改為"已解決"，原因改為"已修復"。指派給測試工程師，測試工程師驗證后，如果沒有問題就將狀態改為"已關閉"。

5 小結

現在讓我們回到用戶情景的"所有鏈接"，我們將看到如下圖所示：

在TFS上，需求管理，項目管理，測試管理，缺陷跟蹤等融為一體。無論是從需求到設計，編碼，測試，Bug的正向跟蹤，還是從Bug向編碼，設計，需求的逆向回溯，都不成問題。取得了可跟蹤的能力，響應變化也就不再是一句空話了。

?

總結

以上是生活随笔為你收集整理的TFS(Team Foundation Server)敏捷使用教程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。