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

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

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

　　在我們轉(zhuǎn)向 Agile 的過程中，我們希望注重團隊成員之間的彼此交互，然后再側(cè)重關(guān)注客戶，最后才是關(guān)注流程。 在這次變革之前，我們花時間重點關(guān)注了與此相反的情況，也就是流程為先，客戶其次，然后才是交互。 過去兩年的成果為：我們?nèi)缃衲軌蜃龅絺?cè)重為團隊提供強大支持、恢復(fù)對客戶的關(guān)注，以及在正確的時間執(zhí)行正確的解決方案。 下面我來介紹如何實現(xiàn)這些成果。

　　適合我們的可能也適合您

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

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

　　當(dāng)時，我們希望以 Agile 方式開發(fā)，但不知道該如何做。

　　引入 MSF Agile 5.0 版

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

圖 1 MSF Agile 流程

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

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

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

　　利用用戶案例 WIT 提高業(yè)務(wù)價值

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

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

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

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

　　MSF Agile 中的規(guī)劃迭代

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

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

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

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

　　圖 3 管理 MSF Agile 中的規(guī)劃估計

　　這是準確追蹤日常工作的基礎(chǔ)，并且我們發(fā)現(xiàn)當(dāng)我們作為一個 Agile 團隊共同努力時，工作會更出色、更高效。

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

　　MSF Agile 中的產(chǎn)品規(guī)劃和迭代積壓追蹤工具

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

圖 4 MSF Agile 中的規(guī)劃工作簿模板

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

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

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

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

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

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

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

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

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

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

圖 6 MSF Agile 團隊產(chǎn)能規(guī)劃

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

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

　　執(zhí)行特定于團隊的自定義

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

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

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

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

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

　　TFS 與 Windows SharePoint Services 的集成

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

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

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

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

　　充分發(fā)揮 SharePoint 和 TFS 2010 項目的優(yōu)勢

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

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

圖 7 MSF Agile 中的 Excel 報告

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

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

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

　　Agile：回顧非常重要

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

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

圖 8 MSF Agile 迭代回顧模板

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

　　我們向 Scrum 1.0 的過渡

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

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

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

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

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

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

　　它簡單、無縫且恰好適合我們可在沖刺規(guī)劃期間從事的工作。 我們不再需要自定義報告以設(shè)置開始日期或結(jié)束日期 - 現(xiàn)在當(dāng)我們在沖刺規(guī)劃之前創(chuàng)建沖刺工作項時，它已經(jīng)為我們設(shè)置好了。

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

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

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

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

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

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

　　基于領(lǐng)域的追蹤與 Scrum 1.0 中的分配目標(biāo)

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

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

圖 12 Scrum 1.0 中基于領(lǐng)域的分配

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

　　綜合講述

　　我們的 Agile 之旅并不完整，仍然有其他許多機會可以精簡我們的流程。 在 Agile 方面有一種不當(dāng)?shù)恼f法，那就是 Agile 團隊沒有專業(yè)領(lǐng)域之分。 作為一個團隊，我們認為這是完全不準確的。 相反，我們了解到 Agile 團隊具有高水平的專業(yè)領(lǐng)域。 在轉(zhuǎn)向 Agile 之前，我們的團隊缺乏有效的流程，很遺憾，也就缺乏了專業(yè)領(lǐng)域。 轉(zhuǎn)向 TFS 2010 并采用 MSF Agile 流程模板之后，我們開始走向成熟，并培養(yǎng)了側(cè)重學(xué)習(xí)和適應(yīng)的精神。

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

　　當(dāng)然，如果沒有 TFS 2010，我們的團隊不會取得今天的成就。 最后還是重復(fù)一遍，這是一則關(guān)于某個團隊?wèi){借 TFS 2010 成功采用 Agile 的故事。

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

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