閱讀: 1579 評論: 4 作者: ξ簫音ξ 發(fā)表于 2009-12-08 11:11 原文鏈接

      隨著微軟Visual Studio 2010 Ultimate Beta2版本的發(fā)布，除了它提供協(xié)同一致的ALM(應用程序生命周期)管理工具外，MSF for Agile Software Development過程框架從4.2升級到5.0，并且是以Scrum模型為基礎導向擴展，并且結(jié)合了VSTS2010工具的眾多特性，從而成為微軟.NET相關技術人員手中不可多得的利器。

　　在本文中，筆者將介紹Visual Studio 2010 Ultimate Beta2版本中的MSF for Agile Software Development V5.0的Scrum思想以及實施方法，通過對這些內(nèi)容的闡述，讓讀者了解VSTS2010的敏捷之道，以便于.NET管理和開發(fā)人員能隨心所欲的應用在自己的項目中，從而構建出高效的軟件開發(fā)團隊。

　　1.引言

　　道是天地萬物演變的本體或本原，是存在之根本。一個行業(yè)或者一個事物既然現(xiàn)實地存在著，那么它的發(fā)展必然遵循著本身的自然規(guī)律。

　　談起敏捷之道，令筆者不禁想起在《笑傲江湖》中描寫令狐沖獨孤九劍的精髓‘行云流水，任意所至。’這就是活學活用，實戰(zhàn)中隨手配合招式的變招。風清揚教令狐沖‘將這華山派的三四十招融會貫通，設想如何一氣呵成，然后全部將它忘了，忘得干干凈凈，一招也不可留在心中。’其實是將華山劍法一招一式固有的套路動作拆開使它不存任何招數(shù)，再自由組合套路形成渾然一體的招式使出來。這都是活學活用，而這只是第一步。做到出手無招，才是真正踏入了高手的境界。真正的無招是沒有主觀的招式，根本并無招式，敵人如何來破你的招式?

　　軟件開發(fā)的敏捷之道也是如此，當開發(fā)團隊為了求得高質(zhì)量、高效的完成軟件產(chǎn)品的交互過程，無論項目管理者還是團隊成員都需要全方面地學習，包括工具的熟練使用、學習UML、OOAD等技術和收集前人開發(fā)過程中的經(jīng)驗等等，從而使個人以及團隊綜合素質(zhì)的大大增強，這就是為學的過程，最后把這些零碎無序的知識系統(tǒng)化后再全部統(tǒng)統(tǒng)‘忘掉’，達到出手無招、隨心所欲，全是下意識自然而然的行動，無變之變，這就是敏捷之道，這可能就是做項目管理及開發(fā)的最高境界吧!

　　敏捷的含義就是速度的最大化。當你咖啡杯從你的手中悄然滑落的時候，你卻下意識地接到了它，這種直線運動是最快的，其實里面蘊藏著一種意境和思想。這種下意識就是一種境界思維，它沒有經(jīng)過大腦，條件反射的方式以最短最快的速度取得了結(jié)果。

　　這種現(xiàn)象又讓筆者又聯(lián)想起了李小龍的“截拳道”，它的一個特點就是充分運用‘節(jié)約的經(jīng)濟線’(兩點間的直線)的技擊原理，所以它打擊對方的機會和實用性最佳，而且最快，這種“下意識”的境界就是一種太極哲理，搏擊之最高境界。萬物皆有道，這都是從道的本體中演化出來的!

　　2.敏捷之簡易

　　簡單通常是一個好的設計具備特征，這些設計是經(jīng)典的并且很難再改進的。 例如，Lego積木(參考圖1所示)，經(jīng)過許多年還保留著原來的樣子，因為沒有人能想出更簡單的設計讓人們將木塊組合再拆開。人們無法再改進這些設計，因為它們不能夠再簡化，而將它們設計得更復雜也無法讓它們更好用。

　　敏捷團隊注重簡易，這樣做可以消除那些沒必要的復雜。只需專注于開發(fā)當前所需要的功能和最簡單的設計。如果能使用簡單來幫助一個敏捷團隊開發(fā)出馬上就需要的軟件，而不浪費人力和資源，這就是他們給那些投資的用戶以最好和最直接利益的方法。

　　我們再從《易經(jīng)》中的‘簡易、變易、不易’的角度思考，可以把它看做是對易理的高度抽象→易理對宇宙的高度抽象→‘簡易’指變與不變都是‘道’的體現(xiàn)，自然而然而非刻意求變，萬事萬物都只是按其本性生生不息而已。所以，簡易之理是對大自然萬事萬物高度的抽象;‘變易’是指‘變化’，任何‘生生不息’都是處在不斷的變化之中，沒有停止過，宇宙中的萬物沒有一樣東西是不變的;‘不易’是指萬事萬物的變化都有其不變的本性，同時又有當變則變、不當變則不變的含義。宇宙中萬事萬物雖然不斷變化著，但是卻有一項永遠不變的‘東西’存在，就是能變出萬事萬物的那個‘東西’，是永恒存在的，中國傳統(tǒng)哲學里稱之為‘道’。”

　　2001年2月由17位世界輕量級方法學家提出了一份敏捷聯(lián)盟宣言，這個宣言只是簡單的四句話，但卻是敏捷方法的精髓，也是對敏捷的高度抽象，這便是敏捷之道的最高境界：

　　個體與交互 勝過 過程與工具

　　可以工作的軟件 勝過 面面俱到的文檔

　　客戶協(xié)作 勝過 合同談判

　　響應變化 勝過 遵循計劃

　　3.Scrum敏捷過程模型

　　在Visual Studio 2010中，項目過程模板變化很大，微軟把Scrum作為基本Agile開發(fā)模型(Scrum模型為基礎參考導向)，如圖2所示。TFS2010中集成了MSF for Agile Software Development v5.0，可操作性上又融合了敏捷等軟件開發(fā)流程思想模型。

　　Scrum最初的含義是英式橄欖球爭球隊,是敏捷軟件開發(fā)模型中的一種。Scrum 將軟件開發(fā)團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發(fā)流程中所需具備的最佳技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，確保每天、每個階段都明確的朝向目標推進。Scrum令人痛苦之處就在于你不得不根據(jù)自己的具體情況來對它進行調(diào)整，如果能夠“隨心所欲”應變，那么你就會體會到它的強大。

　　敏捷Scrum開發(fā)過程框架中，產(chǎn)品backlog是Scrum的核心，也是一切的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。它里面包含的是客戶想要的東西，并用客戶的術語加以描述，通常叫它故事(story)，有時候也叫做backlog條目。

　　例如，我們建立一個產(chǎn)品 BACKLOG(示例)，如表1所示。

　　我們的故事包括這樣一些字段：

　　ID：統(tǒng)一標識符，就是個自增長的數(shù)字而已，以防重命名故事以后找不到它們。

　　名稱(Name)：簡短的、描述性的故事名。它必須要含義明確，這樣可以跟其他故事區(qū)分開。

　　重要性：(Importance)：產(chǎn)品負責人評出一個數(shù)值，指示這個故事有多重要。例如：

　　20或100。分數(shù)越高越重要。避免“優(yōu)先級”這個說法，因為一般說來優(yōu)先級1都表示“最高”優(yōu)先級，如果后來有其他更重要的東西就麻煩了。它的優(yōu)先級評級應該是什么呢?優(yōu)先級0?優(yōu)先級-1?

　　初始估算(Initial estimate)：團隊的初步估算，表示與其他故事相比，

　　完成該故事所需的工作量。最小的單位是故事點(story point)，一般大致相當于一個“理想的人天(man-day)”。

　　如何做演示(How to demo)：它大略描述了這個故事應該如何在sprint 演示上進行規(guī)范，本質(zhì)就是一個簡單的測試規(guī)范。

　　筆者借鑒過很多敏捷書籍和在實戰(zhàn)的應用中嘗試過很多字段，但最后發(fā)現(xiàn)，只有上面提到的六個字段我們會一直使用下去，這也就是一種最簡化。

　　我們可以把backlog存放在TFS2010服務器上，或者共享在TFS2010的Excel或者Project(參考圖3所示)文檔里面，這是為了多個用戶可以同時編輯它。

　　雖然正規(guī)意義上這個文檔應該歸產(chǎn)品負責人所有，但是我們并不想把其他用戶排斥在外，開發(fā)人員常常要打開這個文檔，弄清一些事情，或者修改估算值。

　　VSTS2010已經(jīng)支持Scrum的Product Backlog的模板，并且可以進行Backlog的迭代，如下圖4所示。

　　打開Product Backlog，建立User Story，如圖5所示。

　　編寫相關Story條目內(nèi)容，如圖6所示。

　　當編寫完Story條目內(nèi)容后，我們可以在Web端的Project Portal查看user story的內(nèi)容與條目，如圖7和圖8所示。

 

　　在share point的Project Portal中，我們可以對該story進行編輯等操作。如圖9所示。

　　我們可以對表1進行擴展，如表2所示。

　　Backlog組件 ID Important Estimate How To Demo Notes

　　組件用處 事件的編號 事件的重要性，用一個分數(shù)來表示。分數(shù)越高越重要(但重要的事件，內(nèi)容不一定多) 初始的估算，也就是完成某個事件所需要的工作量。 事件的簡單測試 用簡潔的語句進行注解、說明等。

　　Backlog組件 Track Components Requestor BugTrack

　　組件用處 對產(chǎn)品的分類 產(chǎn)品由哪些部份組成 記錄最先提出的需求，并在后續(xù)的開發(fā)過程中進行反饋。 Bug跟蹤

　　注：有顏色的組件可以說是必需的!

　　在TFS2010中支持Reports的生成Excel報表，內(nèi)容包括backlog、工作項等，如圖10、11、12所示。

　　生成報表，如圖11所示。

　　在Scrum敏捷框架中，最強的就是快速應對客戶需求的靈活變化。Scrum中有四個很標致性也很核心的詞：backlog , sprint、迭代、反饋。結(jié)合VSTS2010的工具，可以快速進行story的變化，并且快速完成。例如，在產(chǎn)品 BACKLOG(參考表1)，在每個Spint中，實現(xiàn)特性How To Demo，通過VSTS2010的Architecture繪制SSO統(tǒng)一登錄的UML順序(如圖13所示)，完成Spint Demo(可以是Spint中一部分)。

　　敏捷軟件開發(fā)的核心是：使用項目行為的“輕量但足夠”的規(guī)則以及使用以人為本的規(guī)則及面向溝通的規(guī)則。Scrum的Sprint計劃會議非常關鍵，應該算是Scrum中最重要的活動(這當然是我的主觀意見)。要是它執(zhí)行的不好，整個sprint甚至都會被毀掉。

　　舉辦Sprint計劃會議，是為了讓團隊獲得足夠的信息，能夠在幾個星期內(nèi)不受干擾地工作，也是為了讓產(chǎn)品負責人能對此有充分的信心。Sprint計劃會議會產(chǎn)生一些實實在在的成果：

　　·sprint目標。

　　·團隊成員名單(以及他們的投入程度，如果不是100%的話)。

　　·sprint backlog(即sprint中包括的故事列表)。

　　·確定好sprint演示日期。

　　·確定好時間地點，供舉行每日scrum會議。

　　Scrom敏捷過程管理實施流程，如圖15所示。將整個產(chǎn)品的backlog分解成Sprint Backlog,這個Sprint Backlog是按照目前的人力物力條件可以完成的。召開sprint planning meeting，劃分，確定這個Sprint內(nèi)需要完成的任務，標注任務的優(yōu)先級并分配給每個成員。注意這里的任務是以小時計算的，并不是按人天計算。進入sprint開發(fā)周期，在這個周期內(nèi)，每天需要召開Daily Scrum meeting。整個sprint周期結(jié)束，召開Sprint review meeting，將成果演示給Product Owner.團隊成員最后召開Sprint retrospective meeting，總結(jié)問題和經(jīng)驗。這樣周而復始，按照同樣的步驟進行下一次Sprint.

　　最終結(jié)果是，每個Sprint都產(chǎn)生出一個可見的、可用的交付產(chǎn)品，并向用戶進行展示。一個增量可能是中期的，也可能是可交付的，但是它應該是獨立的。 Sprint的目標是完成盡可能多的優(yōu)質(zhì)軟件來確實質(zhì)性進展，而不是用紙上里程碑(paper milestones)作為依據(jù)。

　　4.Scrum索引卡(白板文化)

　　在大多數(shù)sprint 計劃會議上，大家都會討論產(chǎn)品 backlog中的故事細節(jié)。對故事進行估算、重定優(yōu)先級、進一步確認細節(jié)、拆分，等等都會在會議上完成。敏捷開發(fā)中提倡建立物理索引卡。要想收到好的效果，不妨創(chuàng)建一些索引卡，把它們放到墻上(或一張大桌子上)。

　　筆者在這里也有個擴展方法，可以制作電子版的索引卡，如圖16所示。可以清晰、直觀的顯示燃盡圖和索引卡等信息。

　　ScrumDashboard是微軟站點中的一個開源項目，最新版本ScrumDashboard2.4.0.8，大家可以到http://scrumdashboard.codeplex.com/ 下載數(shù)據(jù)腳本以及源碼。

　　5.總結(jié)

　　VSTS2010的增強的功能特點結(jié)合MSF for Agile Software Development V5.0中的Scrum敏捷過程框架，使從事在微軟.NET技術相關工作方向的人們擁有了一把利劍。

　　寫到此筆者不禁又想起了在《神雕俠侶》中楊過得到的獨孤求敗的三柄劍：

　　利劍、重劍、木劍;

　　如果我們把微軟VSTS2010工具，看成是敏捷開發(fā)團隊中，在不同階段中所使用的‘劍’，隨著你的功夫和意境提高，你手中的利器就顯著不重要了，無劍的境界便是最高的追求。敏捷有時也為靈感所致，如果敏捷團隊的人們能鍛煉出這種境界，便是軟件開發(fā)之最高境界，那就是敏捷之道了。所以，敏捷的開發(fā)團隊也是講究天人合一(團隊敏捷意識合而為一)，敏捷也是哲學的。

　　除了工具和Scrum外，令人忽視的就是團隊成員的素質(zhì)能力和意識。我在《我也能做CTO程序員職業(yè)規(guī)劃》書中也講過，如果公司團隊人員始終保持不被開除的水平，他就不能自動自發(fā)。天底下水是最自動自發(fā)地朝下流，但是你要讓你的團隊成員整體地自動往上走。例如，有目的、有計劃，有要求的業(yè)績，有期限，有質(zhì)量的標準。做到這些才僅僅是外因。

　　內(nèi)因就是驅(qū)動員工愿意干事情，要有內(nèi)在驅(qū)動力。每個人敏感程度不同，給每個類型程序員的驅(qū)動力也不同。所有的員工自動自發(fā)的工作都是有內(nèi)因的，(參見圖16所示)，掃描你的團隊成員屬于哪種類型。例如，他是家庭感情型，你就可以在某個節(jié)日或者事件里到他家做客，體現(xiàn)領導對他的重視和認可。讓家人覺得領導得好，家庭的力量對他施加自動自發(fā)的內(nèi)因驅(qū)動力。如果程序員是‘危機風險型’，你就提供他創(chuàng)新的機會和平臺，發(fā)揮他的最大內(nèi)因驅(qū)動力等。當然，這都必須結(jié)合外因才會可度量、可操作、可監(jiān)控和有目標方向。

 

我為it168籍稿，原文:http://tech.it168.com/a2009/1125/814/000000814906.shtml

　　發(fā)表評論

---

新聞頻道：微軟必應主頁圖片征集活動“美麗家鄉(xiāng)”

推薦鏈接：Windows 7專題發(fā)布

網(wǎng)站導航：博客園首頁  個人主頁  新聞  社區(qū)  博問  閃存  知識庫

文章來源:http://www.cnblogs.com/xiaoyin_net/archive/2009/12/08/1619213.html