基於Visual Studio 2010進行敏捷/Scrum模式開發

根據Forrester Research今年第二季度的一份研究報告，在超過1000名專業開發人員中，採用敏捷模式進行軟體開發的已經有10.9%採用了Scrum模式，在所有的敏捷開發模式中名列首位，而在所有的軟體專案管理模式中，敏捷模式更是被35%的開發人員所採用。當然，研究報告為我們呈現的僅僅是一個統計學的觀點，到底你的Team Dev應該採用什麼樣的開發模式，這還是要根據各自不同的開發環境，人員構成，公司架構以及文化背景來決定。

圖1：Forrester 關于敏捷模式的調查報告

Visual Studio 2010 是微軟在2010年4月發布的全新一代的整合式開發環境，配合約時發布的Team Foundation Server 2010（TFS——團隊伺服器） ，為Team Dev提供了全面的應用程式生命週期管理（ALM）工具和平台。在2010這個版本中，對于敏捷，或者說Scrum模式的支援是前所未有的。雖然微軟的Visual Studio Team System從2005年開始發布的時候就提供了敏捷流程模板（也就是MSF Agile）模板，但是2008版之前的這個敏捷流程模板都是基於MSF（微軟解決方案架構）的；這個架構是微軟針對自己的研發團隊的最佳實務進行抽取總結出來的，與廣大敏捷開發社區裡面所流行的很多敏捷方法並不是很契合，造成了Team Dev在實施的時候有很多不適用的地方。因此，微軟在開發2010版本的過程中，大量的聽取了敏捷開發社區中的聲音，在自己的MSF Agile 5.0的模板中進行很多針對敏捷，更確切的說是Scrum開發模式的改進，使得2010版本中所整合的MSF Agile 5.0的模板非常適合我們來進行Scrum模式的開發組織。當然，微軟的產品為了追求通用性，在MSF Agile 5.0的模板中並沒有完全採用Scrum模式通行的名稱和流程；同時，微軟在兩周前又發布了一個純粹的Scrum流程模板以供那些希望完全使用Scrum 模式的Team Dev使用，當然這個模板現在仍然是Beta版。

我個人認為，Team Dev採用哪一個模板並不是最重要的，重要的是我們需要在開發過程中不斷地改進過程，並對這個模板進行定製，以便適合我們自己的開發流程。這也是為什麼TFS所提供的是一個模板，因為它的目的就是希望我們在這個模板的基礎上不斷的改進，最終找到適合

自己Team Dev的流程。其實這也很符合Scrum模式的理念；簡單一點來說，Scrum模式是一種針對複雜項目的流程組織方式的架構，其目標是為了讓我們開發出更高品質的軟體產品。圍繞的這個目標，Scrum模式為我們提供一個團隊模型，一系列工具和一個簡單的流程。在這樣一個架構之下，Scrum模式要求我們不斷地改進流程以達到適合團隊的最佳狀態，這種對改進的要求也是Scrum模式區別於其他開發流程的重要特點之一。

為什麼Scrum模式適合軟體開發？

軟體行業至今已經有超過40年的曆史，很多在軟體工程中的管理方法都是在不斷摸索中改進而來的。早期的軟體行業由於規模有限，絕大多數屬於作坊型，幾個人在一起靠著自己的聰明才智創造出軟體產品；但是當團隊規模不斷擴大的時候，開發人員開始需要一種模型來組織越來越龐大的團隊，滿足越來越複雜的需求。因為沒有經驗可循，軟體Team Dev將很多傳統工業工程的方法借鑒到軟體行業，因而出現像“瀑布式”的模型。“瀑布式”模型要求我們在實際的開發工作開始之前進行很多非常細緻的設計和計劃，力圖將不可控的開發過程細化成可以控制的顆粒，以達到對複雜項目的總體控制目的。但是“瀑布式”模型忽視了軟體項目的一個本質特點，那就是需求的不確定性；我們不可能像造汽車一樣在上生產線之前把所有的零件都設計好，所有的流程都規定好，再進行裝配；因為任何軟體在實際進行編碼之前都沒有人知道這些代碼應該如何?，而且每一個開發人員的水平不同，習慣不同，寫出的代碼也是不同的；再加上客戶對於軟體的需求也是在不斷變化的，一年之前的商務程序很可能在一年之後就產生的變化，如果還按照之前的需求進行開發，那麼交付的時候肯定是無法滿足要求的；更重要的事，在客戶沒有看到或者實際操作軟體產品之前，他們永遠也不能明確地告訴你他們要的到底是什麼。因為這種種原因，造成了軟體開發不可能採用傳統的工程方法進行組織，因為其本身是一種需要依賴於開發人員智慧的探索性行為，也造成了我們的軟體項目中有很大一部分是失敗的。

Scrum模式的出現正是基於對於軟體開發行為本質的認識，提供了一種鬆散的架構，讓我們使用一種探索性的流程方法來組織本來就是探索性的開發過程；從根本上滿足了軟體開發本身對於流程的需求。這種方法論實際上是基於愛德華?戴明所提出的戴明環的管理方法；戴明環理論提出：人類在進行任何複雜活動時，獲得成功的最有效流程要經過：Plan 計劃– Do執行 – Check 檢查– Act改進，四個子過程，並不停的迭代以便找到最佳的方法來解決問題。這個理論不是針對軟體開發提出的，但是軟體開發本身其實就是最典型的複雜活動。

圖2：Scrum的流程