在“Agile 宣言”中，有幾個強調 Agile 團隊該如何協同工作的關鍵詞。 其中包括相對于流程和工具而言更重視個體（及其交互）的價值。 各團隊將這些價值作為轉向 Agile 開發的原因之一。 在過去 10 年左右的時間內，自宣言發布以來，開發了各種版本的 Agile。 我將進一步介紹 TFS 2010 中的一些選項，通過這些選項可以采用兩種 Agile 流程模板之一，此外也將介紹我們的 Microsoft 團隊如何使用這些選項。

　　在幾年前的重組中，Microsoft 軟件開發團隊關注的重點是確保讓我們使用的工具也能為我們的客戶 - 也就是您 - 所使用。 這樣，我們就無法使用已存在多年的 Microsoft 內部工具。 我們的開發團隊隸屬管理與安全部門 (MSD)，側重于構建使 Microsoft 能夠為一系列用戶提供服務的軟件，這些用戶包括：IT 用戶、IT 管理員和工程師以及在線服務操作員。 簡言之，我們的團隊可能和您的團隊一樣，都是通過構建軟件來增強或改善客戶所依賴的業務。

　　在采用 Agile 之前，我們不重視客戶反饋，團隊成員之間因職務原因存在人為的隔閡，并且我們也無法將準確的情況反映給管理團隊。 如果不改變這種狀況，我們的整體效力將逐漸縮減，直到最后整個團隊完全走向失敗。

　　在我們轉向 Agile 的過程中，我們希望注重團隊成員之間的彼此交互，然后再側重關注客戶，最后才是關注流程。 在這次變革之前，我們花時間重點關注了與此相反的情況，也就是流程為先，客戶其次，然后才是交互。 過去兩年的成果為：我們如今能夠做到側重為團隊提供強大支持、恢復對客戶的關注，以及在正確的時間執行正確的解決方案。 下面我來介紹如何實現這些成果。

　　適合我們的可能也適合您

　　我們并不是一個獨特的軟件團隊。 我們是一個年輕的團隊，致力于開發能夠直接帶來業務價值的最高質量軟件。 我們所有成員待在這個團隊的時間都不超過三年。 正如我所說過的，我們一直在努力。

　　2010 年 3 月，我們決定必須開始做一些改變。 我們需要一種能夠為我們服務的系統，而不是給我們造成障礙的系統，并且該系統還需要能夠讓我們專心提供客戶價值。 除此之外，該系統應能夠從我們團隊及整個組織的各個層級監控和追蹤進度。

　　當時，我們希望以 Agile 方式開發，但不知道該如何做。

　　引入 MSF Agile 5.0 版

　　我們在測試階段早期就接觸到了 TFS 2010，并決定使用 Microsoft Solutions Framework Agile 5.0 版（以下簡稱 MSF Agile）創建我們的某個項目。 我們當時在尋找一種能夠幫助我們實現核心目標的流程模板，這些核心目標包括：實現有效的產品及沖刺規劃；注重保持開發節奏；最重要的是增強我們與開發人員、測試人員及項目經理 (PM) 之間的交互。 MSF Agile 提供給我們的生命周期（參見圖 1）似乎正是我們所尋找的。

圖 1 MSF Agile 流程

　　MSF Agile 提供了多種工作項類型 (WIT) 來指導我們了解和使用 Agile。 我們首先檢查了各個 WIT（如圖 2 中所定義），以便了解如何有效地加以使用。

　　圖 2 MSF Agile 中的工作項類型定義

　　我想著重強調的一點是，盡管我們研究了所有 WIT，但起初我們只使用其中的一部分。 實際上，我們關注的重點是用戶案例、任務及錯誤。 直到幾個月以后，甚至一年以后，我們才開始引入其他一些 WIT，如測試案例等。 迄今為止，我們的團隊仍未使用問題這一 WIT，但這并不意味著該 WIT 對您不起作用。 像許多學習 Agile 的團隊一樣，我們采用我們喜歡的方式，丟棄我們不喜歡的方式。 我想著重強調的一點是，并非所有人都完全采用 Agile 軟件開發，而 TFS 2010 正好利用 MSF Agile 模板提供了這種靈活性。

　　利用用戶案例 WIT 提高業務價值

　　我們了解到 Agile 團隊應該在用戶案例方面投入大量精力，但我們并非突然就掌握這一點。 首先，我們的用戶案例十分龐大，跨越了多個迭代。 它們在更大程度上是推動任務的主題，而不僅僅是促進增值的用戶案例。

　　一段時間后，我們了解到好的用戶案例需要具備三個關鍵要素。 首先是標題，它簡要地提示了案例所涉及的內容。 使用簡短的標題更易于我們對用戶案例進行堆疊排序，因為簡短的標題更方便瀏覽。 其次是描述，一般以“作為 <用戶類型>，我想 <目標>，這樣一來 <原因>”的格式書寫，提供了整個案例的背景內容。 也就是說，它為什么增值？它為誰增值？ 這就是客戶價值！ 第三是驗收標準，對于其價值，我們也只有在后來切換至 Microsoft Visual Studio Scrum 1.0（以下簡稱 Scrum 1.0）流程模板時才了解到。 驗收標準向團隊澄清了我們計劃提供的內容。

　　隨著我們在采用 Agile 方面日漸熟練起來，我們開始更多地了解了用戶案例，以及該如何與利益相關者及客戶展開關鍵對話。 我們不能只是專注于撰寫優秀的用戶案例。 我們還應該討論自己的團隊是否已對用戶案例正確進行堆疊排序。 這樣就可以在我們就工作順序開始與客戶展開良好且富有成效的對話時作為一個團隊進一步得到成長。

　　軟件團隊（例如我們的團隊）通常自己決定什么是重要的。 這與強調一切都應該以客戶為中心的“Agile 宣言”相反。 為了填補這一差距，我們在用戶案例 WIT 中使用堆疊排序字段來定義我們處理創造價值這一工作的順序。 該字段促使我們與客戶及合作伙伴展開對話，以確保我們的排列與他們一致。 通過使用簡單的 TFS 查詢，我們的利益相關者和客戶可以明白需要提供有序工作列表以滿足客戶需求（這也在我們的儀表板上公布了，我將在稍后介紹這一點）。

　　MSF Agile 中的規劃迭代

　　作為一個團隊，我們希望改變過去那段功能在范圍或規模方面不斷增張卻少有甚至沒有警告的經歷。 并且，我們也希望專注于價值，而非功能。 我們需要準確地規劃工作、分配適量的資源并有效地考慮中斷。

　　Agile 團隊的工作劃分為一些具有固定長度的迭代。 但是，一次迭代應持續多長時間呢？ 經過一番討論，我們選擇了四周的迭代，因為我們在不足四周的時間內無法提供準備就緒的軟件。 幾次迭代之后，我們發現很難在一次迭代內完成所有工作，因此我們試著將切換為六周。 然而，這使得反饋循環過長，因此我們又切換回四周的迭代。 大約 10 個月前，我們切換到兩周沖刺，這使我們能夠更快地得到反饋。

　　在選擇了能夠為客戶提供最大價值的用戶案例后，我們將這些用戶案例分配至迭代。 我們的團隊必須學會專注于構建較小的增量組件，而非龐大且通查為一個個整體的功能。 較小的組件使我們的團隊能夠在更精細的級別（例如 5 到 10 小時的增量內）評估工作。 這樣也提高了測試人員的效力，因為組件規模較小，他們的測試周期通常就會較短。

　　出于資源配置目的，我們的團隊過去常常花大量的時間專注于功能的“設計”及隨后構建這些功能所需的成本。 在 MSF Agile 中，我們對每個案例使用一個對應的案例分數，然后使用“最初估計值”字段為工作賦予一定的價值，從而取代了上述內容。 我們使用沖刺規劃中的規劃撲克進行這種評估（有關規劃撲克的詳細信息，請參見 planningpoker.com）。 每天，我們會要求團隊成員更新其“已完成工作”和“剩余工作”字段，從而根據迭代目標追蹤我們的進度（參見圖 3）。

　　圖 3 管理 MSF Agile 中的規劃估計

　　這是準確追蹤日常工作的基礎，并且我們發現當我們作為一個 Agile 團隊共同努力時，工作會更出色、更高效。

　　隨著我們團隊的成熟，我們漸漸養成每天更新工作評估的習慣，使其成為我們正常流程的一部分。

　　MSF Agile 中的產品規劃和迭代積壓追蹤工具

　　通過使用 MSF Agile 中的“產品規劃”和“迭代積壓”工作簿（參見圖 4），我們得以提高自己估計可承擔工作及可成功完成工作的能力。

圖 4 MSF Agile 中的規劃工作簿模板

　　我們并沒有因早期迭代過程中的失敗而氣餒 - 我們只是專注于不斷改進。 在作為一個團隊進行迭代規劃期間，我們使用“產品規劃”工作簿將用戶案例分配至迭代。 我們試著讓迭代在沖刺規劃開始之前就設置起來，從而節省時間。 （有關創建迭代的詳細信息，請參見 bit.ly/lakyZA。）隨著對自己團隊平均速度（我們在先前迭代中完成的案例分數）了解的增多，我們逐漸能夠更好地瀏覽迭代之間的案例，并且對于自己可以在特定日期完成任務也有一定的信心。

　　在我們面向 Agile 進行的過渡中有一些最有價值的部分，其中之一就與我們使用“迭代積壓”工作簿有直接關系。 在迭代規劃期間，此工作簿提供了多個有幫助的 Microsoft Excel 選項卡。 下面討論各個選項卡的用途。

　　工作簿中的第一個選項卡是“迭代積壓”選項卡，顯示了用戶案例以及與之相關的所有后續任務。 該選項卡與一個 TFS 樹查詢綁定，使您能夠以熟悉的樹視圖形式輕松查看用戶案例以及作為子項的所有任務（有關樹查詢類型的詳細信息，請參見 bit.ly/l0tv1K）。 您需要更新各個沖刺的查詢，以便第一個選項卡能夠顯示當前分配至迭代的所有項。 您可以操作該選項卡中的數據，并可在不退出 Excel 的情況下將其重新發布至 TFS 服務器，這一做法就是我們在沖刺規劃期間創建用戶案例任務的方法（有關詳細信息，請參見 bit.ly/lmPN4k）。

　　第二個選項卡是“區域與迭代”，可用于設置迭代的“開始日期”、“結束日期”及“迭代路徑”，如圖 5 所示。

圖 5 MSF Agile 中“迭代積壓”工作簿的開始和結束日期

　　對于復雜的項目，您可以利用區域路徑確定工作簿范圍。 作為一個較小的團隊，我們很少限定到這一級別。 在具有多個區域且規模較大的團隊中，對于各個區域路徑，您可能會有不同的工作簿副本。

　　第三個選項卡是“中斷”，可用于將團隊成員因休假或節假日而無法繼續實施項目的情況考慮在內。 盡管如此，該選項卡只允許您針對當前分配有迭代工作項的團隊成員設置中斷。 因此，在處理該選項卡之前，請確保您已經準確地安排工作任務并且已將團隊成員分配至該選項卡（在第 1 個選項卡中，即“迭代積壓”），否則團隊成員的下拉列表將為空。

　　我們的團隊發現第四個選項卡非常有用。 該選項卡稱作“產能”，它根據迭代中的剩余工作和天數提供關于每位團隊成員超出產能或產能不足的信息。 該選項卡也考慮了前面提到的“中斷”選項卡中的信息。

　　“產能”選項卡可在團隊成員之間轉移任務，從而方便保持負載平衡。 作為一個團隊，這正是我們在采用 Agile 之前所缺乏的能力，也就是要學會在較早階段及時重新分配，而不是到了最后階段才倉促行動。

　　為了計算產能，工作簿計算了每位團隊成員的每天總產能（每天小時數），并將其乘以迭代中的剩余天數。 圖 6 中所示的最終結果使我們能夠從迭代的第一天（例如迭代規劃）開始處理，從而自己我們所處的狀況。

圖 6 MSF Agile 團隊產能規劃

　　我們從每日站會中了解的內容是不斷變化的。 在圖 6 的情況下，所有團隊成員都超出了產能，這讓整個團隊明白在此迭代內完成所有已規劃的工作是不可能的。

　　我整理了關于工作簿使用方法的演練，并在我的博客上分享了更多詳細信息，博客地址為 bit.ly/fZpzWx。

　　執行特定于團隊的自定義

　　構建軟件并非總是局限于一個團隊。 事實上，它通常需要多個團隊一起合作。 跨團隊軟件開發的難題是存在不同的“團隊”流程。 有些團隊采取瀑布式軟件開發的做法，有些團隊則利用 Scrum。 各個團隊的獨特做法通常會引發一些問題，我們的團隊也不例外，因此也不能幸免。 實際上，雖然我們的兩個團隊都以 Agile 為基礎，但我們使用 MSF Agile 的首批項目之一要求這兩個團隊使用不同的迭代長度和風格來進行交互。 由于 TFS 2010 提供了豐富且強大的能力來自定義任意 WIT（甚至創建一個全新的 WIT），于是它就憑借其靈活性在這一方面幫助了我們團隊。 事實上，我們并不需要一個新的 WIT，只需要對現有的某個 WIT 進行調整。

　　當時，我們正與 Microsoft 部署工具包 (MDT) 團隊合作開發一種稱為用戶驅動安裝的新功能 (bit.ly/kjySZk)。 它使最終用戶能夠更改其 Windows 7 臺式機或筆記本電腦。 利用 Scrum 的 MDT 團隊使用僅在 Microsoft 內部提供的專有工具，但我們的團隊采用 TFS 2010。 除此之外，團隊之間的交互有相當大的一部分主要側重于在我們的團隊提供新功能時出現的錯誤上以及在他們的團隊擁有所有測試時進行的錯誤修復上。

　　兩個團隊在多次迭代時共同合作是為了查看在前幾次迭代中如何奮力滿足規定的產出要求（例如可交付的軟件）。 我們的速度較慢。 作為一個團隊，在與合作伙伴展開合作的幾個月前，我們一直在使用 Agile，并在完成所有工作的情況下有節奏地完成了迭代。 為什么在沖刺階段我們就突然無法實現計劃的產出水平呢？

　　具有諷刺意味的是，變化在于我們在沖刺規劃期間未能考慮到對錯誤的估計。 因此，我們通常一邊開發新功能，一邊處理合作伙伴團隊要求我們修復的錯誤。 由于錯誤這一 WIT 沒有基于時間的字段（例如“剩余工作”和“已完成工作”），我們的剩余工時從未提醒我們還有無法完成的工作。

　　TFS 2010 的自定義功能使得調整這種 WIT 以滿足我們的需求變得非常簡單。 我們更新了錯誤這一 WIT，使其包含時間字段，并將這些字段添加至“錯誤”表格，然后我們就可以通過迭代剩余工時追蹤錯誤和任務。 有關如何向 WIT 中添加自定義字段（例如規劃字段）的詳細信息，請參見我的博客，地址為 bit.ly/gb1BOb。

　　TFS 與 Windows SharePoint Services 的集成

　　正如您所記得的，我們需要提高所在團隊追蹤進度的能力，并將其相應地報告給整個團隊、合作伙伴及管理層。

　　TFS 2010 提供了現成的集成，使我們可以利用新的或現有的 Windows SharePoint Service (WSS)。 創建 MSF Agile 項目包括（如果需要）創建一個 SharePoint 站點，并且該站點需含有一個較好且可定制的儀表板。 由于我們的部分工作是增強團隊內部以及團隊與客戶的交流，我們就利用了 TFS 隨附的內置儀表板。 儀表板和 SharePoint 集成最吸引人的地方便是靈活性。 例如，標準 TFS 項目附帶的儀表板就沒有提供該儀表板視圖中所需的全部內容。 我們想要更多。

　　這些儀表板使我們無需再每天通過電子郵件分享進度報告（例如“剩余工時”、“速度”或“錯誤數”），而是讓我們的管理層及合作伙伴可以訪問我們的 SharePoint 站點，從而以近乎實時的方式查看我們的進度。

　　與其他所有組織一樣，當談到在查看內容方面對什么感興趣時，不同的人有不同的需求。 我們對儀表板進行了自定義，使其包含了其他一些報告，默認情況下這些報告在儀表板上處于未啟用狀態。 例如，管理團隊每月會與我們的團隊會面以審核我們所做的工作，并在我們按照 Agile 項目的生命周期繼續執行任務時向我們提供反饋。 在其中一次會面期間，我們的一位關鍵領導人就問道，他是否可以查看我們正在處理的用戶案例、我們的進度以及當前并不在沖刺階段內的積壓用戶案例。 要了解更多有關我們如何利用儀表板以滿足這位領導人需求的信息，請參見我的博客，地址為 bit.ly/jJ6XUp。

　　充分發揮 SharePoint 和 TFS 2010 項目的優勢

　　如果您或您的公司已經擁有了企業版的 Microsoft Office SharePoint Server (MOSS)，則可利用與 MOSS 鏈接的 MSF Agile 項目來充分發揮全新水平的功能所帶來的優勢。 正如前面所提到的，TFS 2010 附帶有 WSS，但 WSS 缺乏一些良好的企業就緒功能。

　　我們希望使用 MSF Agile 隨附的一些優秀的 Excel 報告。 如 圖 7 所示，這些報告提供了許多功能，例如使用 Excel Web Services (EWS) 在我們的項目儀表板上的 Web 部件中托管報告及其中的數據。

圖 7 MSF Agile 中的 Excel 報告

　　當您的團隊擁有一臺或多臺可用于團隊項目的 SharePoint 2007 或 2010 Enterprise 服務器時，才能使用此功能。

　　當 TFS 2010 在創建 MSF Agile 項目期間檢測到 SharePoint Enterprise 服務器時，它會創建一個包含 EWS 報告和 SQL Server Reporting Services (SSRS) 報告的儀表板。 由于我們獲得了使用“代碼改動”和“錯誤 (按指派)”等報告的能力，加上還可以使用 MSF Agile 中提供的“燃盡”和“燃速”等報告，這種靈活性就賦予了我們很多能力。

　　維護 SharePoint 儀表板時，我們團隊遇到的一個關鍵問題是管理，具體而言就是誰負責及時更新儀表板上的報告。 例如，當我們團隊每兩周迭代一次時，剩余工時的開始日期和結束日期需要每兩周更新一次，否則儀表板數據就無法保持最新狀態。 我們對儀表板的維護持續了幾個月，但隨著時間的推移，我們開始尋求自動創建這些報告的方式，或者希望找到更簡單的方法來追蹤迭代。 我們過渡之后不久（將近一年），便發布了 Scrum 1.0（可從 bit.ly/fdojaD 中下載）。

　　Agile：回顧非常重要

　　隨著我們作為一個 Agile 團隊不斷發展，我們一起花了很多時間來專注于改善團隊、流程及執行過程。 這通常是在我們完成迭代之后，最后結束時就是沖刺審核（根據沖刺目標進行檢查）和回顧。 作為一個 Agile 團隊，往往容易忽視回顧，我們有時也確實會這樣，這使得我們不得不重新在這方面投入努力。

　　在 MSF Agile 中，TFS 使您能夠通過項目 SharePoint 站點中提供的迭代積壓模板來追蹤回顧。 此工作簿使您能夠追蹤自己的速度、您做得較好的方面以及您可以稍加改善的方面（參見 圖 8）。

圖 8 MSF Agile 迭代回顧模板

　　作為一個團隊，我們引以為傲的不僅是專注于在回顧方面獲得改善，同時也包括不斷重新評估我們所做的一切。 盡管我們的學習大多發生在回顧期間，但隨著技術的發展，我們也會對 Agile 流程進行調整。 在我們的情況中，當 Microsoft 發布一個稱為 Scrum 1.0 的新流程模板且我們不能予以忽略時（事實上，我們對此表示熱烈歡迎），TFS 會得到改進。

　　我們向 Scrum 1.0 的過渡

　　盡管我們的團隊不打算嚴格按照基于 Scrum 的模式開展工作，但還是在許多方面與 Scrum 團隊類似。 在采用 MSF Agile 之前，我們使用了產品積壓項 (PBI) 等術語，然后過渡到了用戶案例。

　　和之前一樣，我們決定選擇一個周期較短的項目來評估新的 Scrum 1.0 流程模板。 這和我們采用 MSF Agile 時的做法十分相似：我們花時間讓自己熟悉 Scrum 1.0 模板中可用的 WIT。 如圖 9 所示，盡管術語稍有不同，但許多定義還是相似的。

　　圖 9 Scrum 1.0 中的工作項類型定義

　　我們很快在 Scrum 1.0 中發現了一項重大更改，那就是稱為“沖刺”的 WIT。 該 WIT 允許 Scrum 1.0 團隊在 TFS 2010 中為其沖刺定義具體的開始和結束日期、追蹤此沖刺的目標以及存儲回顧說明。 正如我之前提到的，MSF Agile 在“迭代積壓”工作簿中提供了相似功能，以及有關回顧的 Microsoft Word 模板。 將沖刺、目標及回顧作為一個工作項并能向其中分配工作，這對我們而言是一項極具吸引力的更改。 這是我們從 MSF Agile 轉至 Scrum 1.0 的主要原因。

　　我們團隊中管理功能儀表板、報告及其他迭代產物的 PM 們發現，他們通常會花大量時間更新報告，以便向我們的團隊和合作伙伴反映最新的時間點視圖。 另一方面，Scrum 1.0 擁有一個我們分配沖刺日期的沖刺 WIT。 然后，“剩余工時”報告使用沖刺工作項中的信息來顯示正確的日期范圍（參見圖 10）。

圖 10 Scrum 1.0 中的沖刺剩余工時示例

　　它簡單、無縫且恰好適合我們可在沖刺規劃期間從事的工作。 我們不再需要自定義報告以設置開始日期或結束日期 - 現在當我們在沖刺規劃之前創建沖刺工作項時，它已經為我們設置好了。

　　總的來說，MSF Agile 和 Scrum 1.0 為 Agile 團隊提供了不同的選擇。 決定使用哪一個取決于您，當然，就像取決于我們團隊一樣。 圖 11 是一張表格，其中列出了每個流程模板的 WIT 及其如何相互配合。 對于所有通過 TFS 2010 采用 Agile 軟件開發的新團隊，我所建議的第一件事仍然是深入了解如何使用每個 WIT。

　　圖 11 MSF Agile 與 Scrum 1.0 中的工作項類型比較

　　要了解更多有關流程模板區別的信息，請參見我的博客，地址為 bit.ly/i5tF2G。

　　在 Scrum 1.0 項目中使用迭代工作簿

　　隨著我們團隊的發展以及 TFS 2010 中創建了更多的項目，我們發現自己丟失了迭代工作簿。 迭代工作簿極大地幫助了我們了解中斷，更為重要的是，它還幫助我們從沖刺層面上了解了團隊的產能。 正因為如此，作為一個團隊，我們將工作簿自定義為與 Scrum 1.0 兼容。

　　這種更改的關鍵要點并不是說 Scrum 1.0 對我們不起作用。 實際上，這只是說我們錯過了此工作簿提供的許多功能。 我的隊友 John Socha-Leialoha（博客地址為 blogs.msdn.com/b/jsocha）闡述了如何修改“迭代積壓”工作簿，從而使其與 Scrum 1.0 模板兼容。 工作簿本身無法工作，導致此結果的部分原因是因為它使用的數據存儲于 Scrum 中不可用的字段中。 在他的博客文章中，他側重向他人介紹了該如何學習我們團隊讓工作簿與 Scrum 1.0 項目兼容。 最終結果是我們的團隊得以在規劃和站會期間使用工作簿來追蹤產能。 我們發現的一個缺點是，默認情況下，Scrum 1.0 無法在規劃期間將工作分配給各位成員。 相反，工作以有序的方式直接堆疊排序并放入積壓隊列中。 因此，要想與工作簿兼容，我們必須將所有工作分配給各位成員，以便我們能查看產能。

　　基于領域的追蹤與 Scrum 1.0 中的分配目標

　　正如我所提到的，將工作分配給團隊成員的過程中會出現問題。 對于我們擁有一名開發人員、一名測試人員及一名 PM 的項目，將工作分配給各位成員這一任務很好開展。 但是，讓我們難以掌控的地方是項目中有些領域的產能會根據我們團隊的動態狀況而變化。 例如，某項功能可能對應三名開發人員、兩名測試人員及一名 PM。 當工作的分配取決于誰在當時有空時，您該如何將工作“分解”給各位成員？

　　切換至 Scrum 1.0 模板后，我們的團隊做了一項巨大改變，也就是從將工作分配給各位成員轉向側重基于領域的分配。 我們在 Scrum 1.0 上運行的首批項目失敗了是因為我們將工作分配給各位成員而非各個領域。 我們在團隊中討論了這一問題，并決定使用一個稱為“活動”的領域字段，但在工作項中我們還是將其更名為“領域”（參見圖 12）。

圖 12 Scrum 1.0 中基于領域的分配

　　這樣，只要我們添加了資源或從功能團隊中抽取了資源（可以自行調整），我們就可以一目了然地看出開發人員、測試人員及 PM 的產能。

　　綜合講述

　　我們的 Agile 之旅并不完整，仍然有其他許多機會可以精簡我們的流程。 在 Agile 方面有一種不當的說法，那就是 Agile 團隊沒有專業領域之分。 作為一個團隊，我們認為這是完全不準確的。 相反，我們了解到 Agile 團隊具有高水平的專業領域。 在轉向 Agile 之前，我們的團隊缺乏有效的流程，很遺憾，也就缺乏了專業領域。 轉向 TFS 2010 并采用 MSF Agile 流程模板之后，我們開始走向成熟，并培養了側重學習和適應的精神。

　　我們的適應精神幫助我們從使用 MSF Agile 流程模板發展為擁有今天的成就：現在，我們使用 Scrum 1.0 流程模板，作為一個團隊，我們感覺自己基本上成功實現了目標。我們希望我們的經歷為您帶來了一定的啟示，可以激勵您讓自己的團隊轉向 TFS 2010 并采用這些流程模板之一。

　　當然，如果沒有 TFS 2010，我們的團隊不會取得今天的成就。 最后還是重復一遍，這是一則關于某個團隊憑借 TFS 2010 成功采用 Agile 的故事。

it知識庫：在 TFS 2010 中運用 Agile，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。