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

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

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

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

　　適合我們的可能也適合您

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

　　2010 年 3 月，我們決定必須開始做一些改變。 我們需要一種能夠?yàn)槲覀兎?wù)的系統(tǒng)，而不是給我們?cè)斐烧系K的系統(tǒng)，并且該系統(tǒng)還需要能夠讓我們專心提供客戶價(jià)值。 除此之外，該系統(tǒng)應(yīng)能夠從我們團(tuán)隊(duì)及整個(gè)組織的各個(gè)層級(jí)監(jiān)控和追蹤進(jìn)度。

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

　　引入 MSF Agile 5.0 版

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

圖 1 MSF Agile 流程

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

　　圖 2 MSF Agile 中的工作項(xiàng)類型定義

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

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

　　我們了解到 Agile 團(tuán)隊(duì)?wèi)?yīng)該在用戶案例方面投入大量精力，但我們并非突然就掌握這一點(diǎn)。 首先，我們的用戶案例十分龐大，跨越了多個(gè)迭代。 它們?cè)诟蟪潭壬鲜峭苿?dòng)任務(wù)的主題，而不僅僅是促進(jìn)增值的用戶案例。

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

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

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

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

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

　　Agile 團(tuán)隊(duì)的工作劃分為一些具有固定長(zhǎng)度的迭代。 但是，一次迭代應(yīng)持續(xù)多長(zhǎng)時(shí)間呢？ 經(jīng)過一番討論，我們選擇了四周的迭代，因?yàn)槲覀冊(cè)诓蛔闼闹艿臅r(shí)間內(nèi)無法提供準(zhǔn)備就緒的軟件。 幾次迭代之后，我們發(fā)現(xiàn)很難在一次迭代內(nèi)完成所有工作，因此我們?cè)囍鴮⑶袚Q為六周。 然而，這使得反饋循環(huán)過長(zhǎng)，因此我們又切換回四周的迭代。 大約 10 個(gè)月前，我們切換到兩周沖刺，這使我們能夠更快地得到反饋。

　　在選擇了能夠?yàn)榭蛻籼峁┳畲髢r(jià)值的用戶案例后，我們將這些用戶案例分配至迭代。 我們的團(tuán)隊(duì)必須學(xué)會(huì)專注于構(gòu)建較小的增量組件，而非龐大且通查為一個(gè)個(gè)整體的功能。 較小的組件使我們的團(tuán)隊(duì)能夠在更精細(xì)的級(jí)別（例如 5 到 10 小時(shí)的增量?jī)?nèi)）評(píng)估工作。 這樣也提高了測(cè)試人員的效力，因?yàn)榻M件規(guī)模較小，他們的測(cè)試周期通常就會(huì)較短。

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

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

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

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

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

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

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

　　我們并沒有因早期迭代過程中的失敗而氣餒 - 我們只是專注于不斷改進(jìn)。 在作為一個(gè)團(tuán)隊(duì)進(jìn)行迭代規(guī)劃期間，我們使用“產(chǎn)品規(guī)劃”工作簿將用戶案例分配至迭代。 我們?cè)囍尩跊_刺規(guī)劃開始之前就設(shè)置起來，從而節(jié)省時(shí)間。 （有關(guān)創(chuàng)建迭代的詳細(xì)信息，請(qǐng)參見 bit.ly/lakyZA。）隨著對(duì)自己團(tuán)隊(duì)平均速度（我們?cè)谙惹暗型瓿傻陌咐謹(jǐn)?shù)）了解的增多，我們逐漸能夠更好地瀏覽迭代之間的案例，并且對(duì)于自己可以在特定日期完成任務(wù)也有一定的信心。

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

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

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

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

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

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

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

　　“產(chǎn)能”選項(xiàng)卡可在團(tuán)隊(duì)成員之間轉(zhuǎn)移任務(wù)，從而方便保持負(fù)載平衡。 作為一個(gè)團(tuán)隊(duì)，這正是我們?cè)诓捎?Agile 之前所缺乏的能力，也就是要學(xué)會(huì)在較早階段及時(shí)重新分配，而不是到了最后階段才倉(cāng)促行動(dòng)。

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

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

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

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

　　執(zhí)行特定于團(tuán)隊(duì)的自定義

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

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

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

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

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

　　TFS 與 Windows SharePoint Services 的集成

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

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

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

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

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

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

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

圖 7 MSF Agile 中的 Excel 報(bào)告

　　當(dāng)您的團(tuán)隊(duì)擁有一臺(tái)或多臺(tái)可用于團(tuán)隊(duì)項(xiàng)目的 SharePoint 2007 或 2010 Enterprise 服務(wù)器時(shí)，才能使用此功能。

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

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

　　Agile：回顧非常重要

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

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

圖 8 MSF Agile 迭代回顧模板

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

　　我們向 Scrum 1.0 的過渡

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

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

　　圖 9 Scrum 1.0 中的工作項(xiàng)類型定義

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

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

圖 10 Scrum 1.0 中的沖刺剩余工時(shí)示例

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

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

　　圖 11 MSF Agile 與 Scrum 1.0 中的工作項(xiàng)類型比較

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

　　在 Scrum 1.0 項(xiàng)目中使用迭代工作簿

　　隨著我們團(tuán)隊(duì)的發(fā)展以及 TFS 2010 中創(chuàng)建了更多的項(xiàng)目，我們發(fā)現(xiàn)自己丟失了迭代工作簿。 迭代工作簿極大地幫助了我們了解中斷，更為重要的是，它還幫助我們從沖刺層面上了解了團(tuán)隊(duì)的產(chǎn)能。 正因?yàn)槿绱耍鳛橐粋€(gè)團(tuán)隊(duì)，我們將工作簿自定義為與 Scrum 1.0 兼容。

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

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

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

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

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

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

　　綜合講述

　　我們的 Agile 之旅并不完整，仍然有其他許多機(jī)會(huì)可以精簡(jiǎn)我們的流程。 在 Agile 方面有一種不當(dāng)?shù)恼f法，那就是 Agile 團(tuán)隊(duì)沒有專業(yè)領(lǐng)域之分。 作為一個(gè)團(tuán)隊(duì)，我們認(rèn)為這是完全不準(zhǔn)確的。 相反，我們了解到 Agile 團(tuán)隊(duì)具有高水平的專業(yè)領(lǐng)域。 在轉(zhuǎn)向 Agile 之前，我們的團(tuán)隊(duì)缺乏有效的流程，很遺憾，也就缺乏了專業(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 流程模板，作為一個(gè)團(tuán)隊(duì)，我們感覺自己基本上成功實(shí)現(xiàn)了目標(biāo)。我們希望我們的經(jīng)歷為您帶來了一定的啟示，可以激勵(lì)您讓自己的團(tuán)隊(duì)轉(zhuǎn)向 TFS 2010 并采用這些流程模板之一。

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

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

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