TFS(Team Foundation Server)敏捷使用教程(四)：工做項跟蹤（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)敏捷使用教程(一)：引言
• TFS(Team Foundation Server)敏捷使用教程(二)：源代碼管理
• TFS(Team Foundation Server)敏捷使用教程(三)：定製敏捷過程模板
• TFS(Team Foundation Server)敏捷使用教程(四)：工做項跟蹤（1）