Visual Studio 2010 Ultimate ─ 軟體品質與團隊效率(4)
建立開發團隊專屬的最佳Scrum流程
文／崔啟文

Microsoft Visual Studio 2010 Ultimate企業旗艦版及Visual Studio Team Foundation Server 2010，已包括過去Visual Studio Team System的所有功能，整合了軟體開發生命週期管理(Application Lifecycle Management, ALM)所需的解決方案。而Team Foundation Server 2010中MSF(Microsoft Solutions Framework) for Agile Development Process v5.0的專案範本已經加入支援Scrum開發流程，藉此框架，可以節省並減少在導入過程中需要學習及調整的時間，讓專案更加順利的進行及成功。

---

Scrum不是一方法論，它是一個框架(Framework)。也就是說Scrum不會馬上告訴你應該怎麼做。而Scrum的強處和痛苦之處，就是你必須被迫根據自己特殊的狀況，來進行調整。對於大部份的開發人員而言，Scrum只是一個時髦術語，但是對於他們的日常工作，並沒有任何的關聯或是影響。

然而，真正試著去導入Scrum開發流程，無論是決定團隊的大小(3-12人)、不同的Sprint長短(2-6星期)，定義不同的「作完」，不同的Product backlog及Sprint backlog紀錄方式(Excel、索引卡)、不同的測試策略、不同的展示方式、不同的方法來同步多個Scrum團隊的訊息…等等。這一個持續學習及調整的過程，才能形成團隊專屬的最佳Scrum流程。

Scrum或Agile Process參考資料如下：
●http://www.xprogramming.com/xpmag/whatisxp.htm。
●http://www.scrumalliance.org/learn_about_scrum。
●http://www.scrumforteamsystem.com/en/default.aspx。

專案團隊初期可利用在Team Foundation Server 2010中新加入的MSF for Agile Development Process v5.0範本，依照該版本支援的Scrum開發流程，藉此減少導入需要學習及調整的時間。(圖1)


圖1：Scrum開發流程示意圖。


產品規劃項目
Product backlog是整個Scrum中的核心，也是所有東西的起源。基本上來說，它是由需求、故事或是功能所組成，裡面用的是客戶的術語來描述客戶想要的東西，我們一般稱為「User Story」或是「Backlog Item」。

以Team Foundation Server 2010的User Story為例，如圖2，說明幾個重要的欄位：
●Iteration：用來代表Sprint，一個2-6週的反覆循環。
●Work Item ID：唯一識別碼。避免之後變更故事名稱，它可以避免我們找不到。
●Title：指故事名稱。用簡潔、敘述性的句子來代表故事，例如「查詢目前線上人數」，一般而言大約2-10個字左右。
●Stack Rank：產品負責人要評估故事的重要性，數字愈高代表愈重要，與Team Foundation Server 2005/2008中的順位欄位(優先順序)不同，因為順位通常1代表最高優先順序，若之後有更重要的事情，則會有所謂插件的困擾。(難道要給0或是-1嗎？)
●Story Point：指Scrum的初始估算，指這個故事與其它的故事相比，完成這個故事需要的代價是多少。最小單位是用Story Point來表示，通常代表人-天(man-day)，重點是非絕對值(2 point不代表2個人-天)，而是取一個比例值。
●Description with Acceptance Criteria：大略描述這個故事，類似一個簡單的測試規格書。如果專案有實作測試驅動開發(Test-driven development, TDD)，那你也可以在Test Cases頁籤中將對應的Test Case Work Item連結進來。
●All Links / Attachments：連結一些其它的相關資訊、解釋或是參考資料…等。


圖2：用客戶的術語來描述細節。


Sprint規劃及工作指派
有了Product backlog之後，接下來，我們要開始規劃Sprint。Sprint規劃會議是一個非常重要的會議，甚至算是Scrum裏面最重要的活動。事前我們必須先定義出每個Sprint的長度，究竟需要幾個星期？接下來，召開Sprint規劃會議，會議最主要的目的是產出一些有用的成果：
●Sprint的目的。
●團隊成員的名單(如果他們不是100%的投入這個Sprint，一定要列出他們的投入程度)。
●Sprint backlog。
●事先訂好的展示時間。
●對於Scrum的每日會議，事先好舉行的時間及地點。

大部份的Sprint規劃會議會花很多時間在討論產品backlog的細節，需要評估它們，決定重要性，以及進一步分解它們…等等。而拆解出來的工作，就可以利用Team Foundation Server 2010上的Task實作，如圖3所示。


圖3：利用Team Foundation Server 2010上的Task實作。

Team Foundation Server 2010也提供Burndown報表，如圖4，Scrum master可以馬上知道目前Sprint的狀況，並確認團隊是否會對這些警訊採取行動。圖5即為Burndown報表的呈現，你會發現，Burndown報表上有一條直線由左上一直到右下角，代表是Sprint進行的理想值。而該數值還可以用人時(man-hour)，或是工作項目數量來進行分析，以不同面向了解現行Sprint進行的狀況是否異常。


圖4：預設提供的報表。


圖5：Burndown報表的呈現。


每日例行性會議
每日例行性會議(Daily Meeting)很重要，因為它的用意是每天早上需規劃當天要完成的事項，並且讓專案成員彼此進行溝通及要求協助。所以會議結束後，一定要把會議結論(變更的User story)更新到Sprint backlog。

當然，理論上應該是Scrum master更新整個Sprint backlog，或是Product backlog，但是我們會希望Scrum master能更專注在產品管理及解決整個專案的問題上，所以Team Foundation Server 2010可允許所有擁有變更權限的專案成員，都可以很方便的更新User story或是Task。


成果展示
當Sprint結束時，無論好或壞，都要將成果展示給其它人，這是一種宣告也是一種壓力，會讓整個專案成員都動起來。


回顧會議
回顧會議是Scrum中另一個很重要的會議。回顧為什麼很重要，因為如果沒有回顧，你會發現團隊會一再的犯同樣的問題。檢討這次的Sprint問題在哪裏，你會發現下一次的Sprint會更好。


產品的品質管理
試著把Scrum和XP(eXtreme Programming)結合後，可以帶來很多好處，原因是Scrum著重在管理以及組織的實踐，而XP大多著重於實際的程式碼開發，它們互相解決不同領域的問題，並且互補對方的不足。


測試驅動開發
測試驅動開發(TDD)意味著，你要先完成自動測試腳本，再去測試與檢驗程式碼，之後可能會需要重構你的程式碼，加強或改進可讀性，及移除重複的地方，一直反覆進行此類的動作。TDD對於系統設計而言，大家都是抱持正面的看法，但是導入真的很難，多數程式設計師要花費一段時間才能夠掌握。

在Visual Studio 2010 Ultimate企業旗艦版及Team Foundation Server 2010中，已擁有完整的測試工具及環境可支援TDD，例如：Visual Studio 2010提供單元測試、資料庫單元測試、自動程式碼UI測試、Web效能測試及負載測試…等等，讓整個開發團隊對於產出的程式碼更加有品質，如圖6；Team Foundation Server 2010則提供Test Case的工作項目，在專案管理及系統設計上幫助整個團隊，如圖7。


圖6：Visual Studio 2010內建多種測試樣本。


圖7：Team Foundation Server 2010提供Test Case的工作項目。

Test Case的工作項目同時可以連接Microsoft Test Manager 2010，利用「測試中心」可以控管整個測試計劃、測試及事後的追蹤，如圖8。


圖8：測試中心控管測試計劃、測試及事後的追蹤。

同時透過測試中心再連結「實驗室中心」，可依據設定將程式部署至不同Hyper-V伺服器上，進行不同環境(例如：作業系統、瀏覽器種類及版本)的模擬及測試。Visual Studio 2010所提供的測試工具，能讓你的每個Sprint所產出程式碼更加穩定，及更高的品質。(圖9)


圖9：實驗室中心可將程式部署至不同Hyper-V，進行不同作業環境的模擬與測試。


Scrum master的檢查清單
Scrum master的檢查清單，通常會列出Scrum master最常見的管理事務。通常繁鎖又固定的事務，很容易就被人遺忘，所以準備一份檢查清單是能幫助你，適時的記起一些事情。
結語
還是要再提醒一下，Scrum開發流程是一個框架，它必須依據不同的環境，加以特別的客製化，所以在一般的狀況下很難會有一個最佳的實作範本。捉住一個重點，就是開發過程中的溝通非常重要，因此要把握每次的會議。另外，決定Sprint時間長短、Product backlog、Sprint backlog的重要性，這些都是關鍵。