內 容 簡 介
本書以Visual Studio Team Foundation Server 2012為軟件開發生命周期(ALM)的平臺，著重從Scrum等敏捷方法和Visual Studio工程實踐的角度詮釋.NET開發人員如何充分利用敏捷方法和VS管理工具更快交付產品。書中提供最真實的開發技巧與最先進的敏捷實踐，旨在幫助解決軟件工程所面臨的困境與挑戰，有系統地終結浪費、改善透明度，讓軟件開發成為一種輕松愉快的工程過程。
本書適合.NET程序員閱讀和參考，可以幫助他們更快構建更多價值的軟件產品，提高用戶滿意度。
前 言
七年前，我們將Microsoft Visual Studio進行了擴展，以包含應用程序生命周期管理(ALM)，使我們的幾十萬用戶以及數萬名微軟同事的生活更輕松，生產力更高。2010年，當我們發布了Visual Studio 2010高級版、旗艦版、專業測試版以及Team Foundation Server之后，我們已經實現了成為廣泛公認的行業領導的目標。2012年，我們給服務器補充了托管團隊基礎服務的公共預覽，并開始更頻繁地給軟件團隊提供更多價值。
過去七年中，我們從客戶身上學到了很多東西。Visual Studio使得高性能的敏捷軟件開發團隊能夠更頻繁地發布更高質量的軟件。它被廣泛公認為提供給軟件團隊的市場領先的創新解決方案。我們系統地深入研究了浪費應用程序生命周期的主要根源，提升了團隊廣泛參與的透明度，并專注于最終用戶的價值流。我們已經消除了角色之間不必要的筒倉，專注于建設一個多學科的自我管理的團隊。下面是一些例子。
* 沒有更多的無法再現。軟件開發中浪費的最大一個來源是開發人員無法重現報告的缺陷。傳統上，這就是所謂的“無法再現”bug。測試人員或用戶提出一個bug，稍后收到“無法重現”或“它在我的機器上工作”或“請提供更多信息”或類似的響應。通常，這是Bug Ping-Pong持久戰的第一次迸發，雖然軟件沒有得到改進，但產生了巨大的挫折感。
Bug Ping-Pong對地理分布的團隊尤其困難。正如第1章和第8章詳細介紹的那樣, VS 2012縮短或消除了這場沒有贏家的游戲。
* 不再等待構建建立。很多開發團隊已經掌握了持續集成的實踐方法，從而一天中能多次產生軟件的定期構建，甚至是高度分布式的基于Web的系統。雖然如此，測試人員經常等待數天得到一個新的構建來測試，因為將此構建部署到現實生產實驗室中很復雜。通過虛擬化測試實驗室并將自動化部署作為構建的一部分，VS 2012使得測試人員能夠每日或當日沒有中斷地獲取新鮮構建。第7章將描述如何構建和實驗室自動化。
* 沒有更多的UI回歸。最有效的用戶界面(UI)測試往往是探索性的，無腳本的手動測試。然而，當bug修正后，往往很難說它們是實際已修復，還是僅僅沒被再次發現而已。VS 2012通過捕獲測試人員探索的操作日志并允許它轉換成自動測試，從而消除了這種不確定性。現在，修復可以重新測試，并且自動化能夠專注于實際觀察到的bug，而不是猜想的bug。第8章涵蓋探索和自動化測試。
* 沒有更多的性能回歸。大多數團隊都知道失去客戶最快捷的方式是緩慢的應用程序或網站。然而，團隊不知道如何量化性能需求，因此，直到發布前才測試負載能力，這時修正發現的bug為時已晚。VS 2012使得團隊能夠盡早開始負載測試。性能量化并不需要提前進行，因為測試能夠回答這個簡單問題“什么變慢了？”從端到端結果，VS能夠分析代碼中的熱路徑，并直接為開發人員指出故障點。第6章和第8章涵蓋性能分析和負載測試。
* 沒有更多遺漏的變更。軟件項目有許多活動部件，迭代越多，部件變動得越多。開發人員和測試人員很容易誤解需求或者忽略變更的影響。為解決這個問題，Visual Studio專業測試版引入了測試影響分析。此功能比較任意兩個構建之間的變更，通過查看構建之間完成的工作，并基于先前覆蓋情況分析哪些測試覆蓋了變更代碼，從而建議運行哪些測試。第3章和第4章分別介紹了產品待辦工作和變更管理，第6章到第8章從單元測試顯示測試影響分析以及相應的安全網，構建自動化，和驗收測試。
* 不再計劃黑盒。過去，團隊往往不得不猜測他們的歷史速度和未來容量。VS 2012直接從Team Foundation Server數據庫繪制這些并建立一個Excel工作表，允許團隊查看沖刺中個人的負載有多重。然后，團隊可以根據需要透明地轉移工作。敏捷計劃的例子在第2章和第4章討論。
* 沒有更多遲來的意外。敏捷團隊，迭代遞增地工作，經常使用燃盡圖來評估他們的進展。不僅VS 2012自動化燃盡圖，項目儀表板也從很多維度超越了燃盡圖：需求、任務、測試、bug、代碼改動、代碼覆蓋率、構建健康和障礙提供質量和進度的實時視圖。第4章將介紹運行項目的“快樂路徑”并討論如何解決項目“臭味”。
* 不再擔心舊版本。很少有軟件項目是真正的“新建”，在新項目上開發全新的軟件。更經常的情形是，團隊擴展或改進現有系統。不幸的是，較早版本的工作人員往往已經無法解釋他們留下的資產。VS 2012通過引入架構發現工具使得現有代碼的使用更加容易。VS 2012在軟件中顯示這種模式，使我們能夠自動執行減少或消除不必要依賴性的規則。這些規則可以成為簽入政策的一部分，確保團隊的“完成”定義能夠防止意外的架構漂移。架構變化也能夠被捆綁到bug或工作以保持透明度。第5章介紹現有架構的發現，第7章告訴我們如何自動化“完成”的定義。
* 沒有分布式開發的痛苦。分布式開發是必需的，原因有很多：地理分布、項目復雜性和版本演變。VS 2012前瞻性回顧性地去除了分布式開發過程的痛苦。門控式簽入在接受簽入之前強制執行帶有驗證測試的干凈構建。分支可視化允許回顧性地觀察已應用的變更。代碼變更和描述變更的工作項更新(例如，bug修復)都可見。可以直觀地發現哪里已經變更以及哪里仍然需要提升。第6章和第7章告訴我們如何在分布式團隊中使用源、分支和積壓。
* 沒有更多的技術筒倉。越來越多的軟件項目使用多種技術。過去，團隊往往不得不根據他們的運行時目標選擇不同的工具。因此，.NET和Java團隊無法跨筒倉共享數據。Visual Studio Team Foundation Server 2012通過分別為.NET和Java在Visual Studio和Eclipse集成開發環境(IDE)中提供客戶端集成了二者。這樣就將二選一的選擇變成了兼容并蓄，雙贏了。同樣，第6章和第7章包含使用Java資產以及.NET的例子。
這些場景并不是詳盡的清單，而是VS 2012開發動機的代表。所有這些都說明了簡單優先級：減少浪費，提高透明度，加快終端客戶的價值流。本書是為考慮使用VS 2012運行軟件項目的軟件開發團隊而寫的。本書更多的是關于根源而非方式。
本書總體上是為團隊寫的。它以一種幫助所有團隊成員了解對方觀點的方式展示信息。我一直試圖保持主題能夠吸引所有團隊成員。我喜歡愛因斯坦的名言“盡量簡單，而不是更簡單。”我試著這樣寫。我希望你會同意并且在看完本書后向你的同事(也許是老板)推薦。
關于Visual Studio 2012
我所指的Visual Studio(或VS)，指的是完整的產品線。如下圖所示，VS 2012 系列由一臺服務器和一小部分的客戶端工具組成，VS旗艦版上都有。
Team Foundation Server(TFS)是ALM的主干，提供源代碼控制管理、構建自動化、工作項跟蹤、測試用例管理，報告和儀表板。TFS的一部分是實驗室管理，擴展TFS的構建自動化，將物理和虛擬測試實驗室集成到開發過程。
如果你只有TFS，那么可以得到一個叫Team Explorer的客戶端，獨立或者作為插件啟動Visual Studio Professional IDE。Team Explorer Everywhere，一個用Java寫的類似客戶端，作為Eclipse插件啟動。你還可以得到Team Web Access以及允許連接到Microsoft Excel或Project的插件SharePoint托管儀表板。
Visual Studio高級版添加了第6章中描述的圍繞使用代碼的場景。Visual Studio專業測試版盡管具有VS的名字，但實際上是一個IDE之外的獨立應用程序，是為測試人員設計的。可以在第8章看到大量專業測試例子。VS旗艦版包括專業測試，增加了架構建模和發現，在第5章討論。
還有豐富的合作產品，使用可擴展性在TFS上提供額外的客戶端體驗。下圖顯示一些第三方擴展的例子，啟動MindManager、Microsoft Word以及Microsoft Outlook作為TFS的客戶端。可以在www.visualstudiowidgets.com/找到一個目錄。
當然，所有的客戶端讀取并輸入數據到TFS，儀表板上的趨勢面通常托管到SharePoint。使用 Excel Services或SQL Server Reporting Services可以自定義這些儀表板。儀表板示例是第4章的重點。
當然，在開發者中心還可以進一步了解VS。
目 錄
第1章 敏捷共識 1
敏捷的起源 1
敏捷的出現是為了處理復雜性 2
經驗過程模型 3
新的共識 4
關于Scrum 5
潛在可上市 6
減少軟件開發中的浪費 8
透明性 9
技術債務 9
一個例子 10
自管理團隊 11
回到基礎 11
小結 12
尾注 13
第2章 Scrum、敏捷實踐和
Visual Studio 15
Visual Studio和過程制定 16
過程模板 16
團隊 18
過程周期和TFS 19
發布 20
沖刺 21
由下而上的周期 25
個人開發準備 25
測試周期 26
每個周期對“完成”的定義 29
檢查和調整 29
任務板 30
看板 30
為項目適配過程 31
地理分布 32
小結 34
尾注 34
第3章 產品所有權 37
什么是產品所有權 38
商業價值問題：花生醬 38
客戶價值問題：死鸚鵡 39
范圍蔓延問題：下沉的船 40
Scrum的產品所有權 41
發布計劃 42
興奮、滿意和不滿意：卡諾分析 44
客戶驗證 52
服務質量 57
安全和隱私 57
性能 58
用戶體驗 58
可管理性 58
需求有多少層次 60
工作分解 60
小結 61
尾注 62
第4章 運行沖刺 65
來自定義過程控制的經驗 66
精通Scrum 67
團隊規模 68
快速估算(計劃撲克) 68
對比的類比 72
使用描述性而非規定性指標 72
使用儀表板回答日常問題 76
燃盡圖 76
質量儀表板 78
Bug儀表板 82
測試儀表板 82
構建儀表板 83
選擇和自定義儀表板 83
使用微軟Outlook來管理沖刺 84
小結 85
尾注 86
第5章 架構 89
敏捷共識中的架構 90
檢查和調整：涌現式架構 90
架構和透明度 91
可維護性設計 92
探索現有架構 92
了解代碼 92
維護控制 98
了解域 101
小結 109
尾注 110
第6章 開發 111
敏捷共識中的開發 112
沖刺周期 113
每日周期中要警惕避免 113
保持代碼庫干凈 114
在簽入時捕獲錯誤 114
擱置而非簽入 119
代碼協作 120
早期檢測編程錯誤 123
測試驅動的開發提供清晰度 123
代碼未經測試 125
通過改變數據來優化測試 127
將單元測試重用為構建驗證測試 128
有冗余代碼時 130
使用自動化代碼分析捕獲編程錯誤 131
捕獲副作用 133
隔離意外行為 133
隔離生產中的根本原因 135
優化性能 137
防止版本偏差 140
版本控制什么 140
分支 141
并行工作在不同版本 142
合并及跟蹤分支間的變更 144
使用Eclipse或直接使用Windows
Shell 145
使工作透明 146
小結 147
尾注 148
第7章 構建和實驗室 149
周期時間 150
定義“完成” 151
持續集成 152
自動構建 154
每日構建 155
BVT 155
構建報告 155
維護構建定義 156
維護構建代理 157
自動部署到測試實驗室 158
建立測試實驗室 159
在生產中是否能像在實驗室中一樣
正常工作 160
自動部署與測試 164
消除浪費 170
完成PBI 170
盡可能頻繁地集成 170
檢測流程中的低效率 171
小結 173
尾注 174
第8章 測試 175
敏捷共識中的測試 176
測試和價值流 177
檢查和調整：探索性測試 177
測試和減少浪費 178
測試和透明度 178
測試產品積壓工作項 179
最重要的首先測試 180
可操作的測試結果和錯誤報告 182
不再“無法再現” 184
使用探索性測試以避免錯誤的
信心 185
處理bug 188
哪些測試應該自動化 189
自動場景測試 189
使用HTTP測試 191
負載測試，沖刺的一部分 193
了解輸出 197
診斷性能問題 197
生產-現實測試環境 198
報告 199
基于風險的測試 200
像工作項那樣捕獲風險 201
安全測試 202
小結 202
尾注 203
第9章 微軟開發部門的經驗教訓 205
規模 206
商業背景 207
文化 207
浪費 208
債務危機 209
2005年之后的改進 210
做到并保持干凈 210
集成與隔離 211
產品積壓工作 212
迭代積壓工作 215
工程原則 217
結果 217
敏捷共識行動 218
經驗教訓 218
社會契約需要重建 219
經驗教訓 219
慶祝成功，但不宣告勝利 221
Visual Studio 2012之路 221
尾注 223
第10章 持續反饋 225
敏捷共識在行動 226
小結 230
生活在混沌的邊緣 231
尾注 232
