工作項跟蹤（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向編碼，設計，需求的逆向回溯，都不成問題。取得了可跟蹤的能力，響應變化也就不再是一句空話了。