VSTS 軟流來襲 您嘗鮮了嗎 ?
叮咚, you got a mail, 來自 Peter Hu 與 Steven 老總的一封信; 除了客套的恭喜發財之外.. 大夥覺得, 站在這波軟流(由Microsoft Visual Studio Team System軟體工程的流行潮流帶動之下), 我們應該要站出來, 寫點東西.. 讓舊雨新知 溫故而知新~ 小弟於是再度執筆… 請問您 嘗鮮了嗎 ?
回顧 & 展望… 沒那麼老套啦…
我們要談什麼 ? 想想Visual Studio Team System 在兩千空五年的12月上市以來, 已經有了一年的成長期~ 不過, 不是只有成果發表啦. 我們想討論的是 在過去一年來, 身為微軟的夥計, 我們與微軟的重要的朋友們在 導入過程的歡笑與淚水~
除了謝謝的客套之外, 在這裡我們要分享導入的寶貴經驗.
過去一年的軌跡
過去一年的中, Team System 在很多企業內開花結果; 透過 鼎升科技 好夥伴的導入協助, 廣達現在不只是專業代工, 在軟體品質上率先導入 Team System拔得頭籌. 南亞科技的資訊團隊¸ 更是將 功能點數的概念, 直接落實在 Team System 上.
除了大企業之外, 我們也和國內專業的 CMMI 顧問中心如: 寶發科技、台灣應用軟件…等如火如荼的密切合作著; 遙想為了和這些顧問達到溝通的無障礙, 我和 Wang-Tun 兩人還頂著假日拋家棄子的在苦讀著CMMI Intro. V1.2的課程訓練.
您開始 VSTS 了嗎 ?
那麼 ? 請問您 開始了您的 Visual Studio Team System 導入了嗎 ?
如果還沒有, 請聽我簡單介紹一下:
Team System 是微軟軟體工程與開發平台的解決方案, 而既然是工程又是平台的概念, 這個產品就不再是一個 獨立的應用軟體而已.
用一張可能您已經不小在在路邊的廣告紙中看到膩了的圖表來解釋, Visual Studio Team System 可以簡單區分為: 工具、流程、延伸套件.
哪些工具 ?
一個專案的成功是要靠不同的角色一起努力而成功的. 這些的角色在軟體工程學中, 我們常叫做 專案關鍵人(Project Stakeholder), 比如 客戶、開發人員、專案經理、資料庫管理師、系統管理人員、系統架構分析師… 等. 不同角色之間彼此是專業分工, 並且使用著的是不同的專業工具.在Visual Studio Team System 平台中, 微軟替不同角色, 設計出不同的專業工具. 目前版本中包含 軟體架構師、軟體開發人員、測試人員、資料庫開發人員以及專案經理人。除此之外, 為了讓專案團隊即時的分享與快速的溝通, 微軟還帶進了一個全新的軟體 ERP 平台: Team Foundation Server
什麼流程 ?
『一個成功的專案, 要靠對的人、好的武器(工具)，最後再搭配一個有效率的流程。』類似的說法在筆者歷年以來,不論在哪一個領域中 (餐飲, 投資理財, 軟體…etc), 都聽過無數次。
Team System的設計團隊在設計 Team System時, 曾經研究過許多種軟體產業中著名的開發方法論：如 MSF、RUP、XP/Agile、CMMI、Scrum…等；並且以微軟內部的開發團隊做為主要的研究對象。這個研究的結果微軟設計團隊發現幾個現象：許多的流程方法論缺少了實作上的細節；許多的方法論更是太複雜,缺少了靈活延伸與客製化的彈性。這個研究的結果是, 微軟在Team System的開發完成時，同時也推出了兩個內建的軟體流程樣板: MSF for Agile / MSF for CMMI.
還沒聽過 MSF 的同學請注意~
MSF 全名是 Microsoft Solution Framework, 顧名思義是微軟的軟體工程流程樣板：目前在 Team System中推出的流程樣板, 是4.x的版本, 如果有人問說為什麼這個樣板很有價值 ?, 我想最好的答案莫過於: 這是個軟體開發流程樣板, 而目前最大的使用者, 同樣也是他的創立者, 剛好就是全世界最大的軟體公司。
在 Team System 團隊設計4.x 的流程時, 做了一個很大的改變, 團隊小組將這個流程與開發工具直接的綁在一起,
上圖中清楚描述了 MSF 的演進與設計核心概念, 您不難理解 在 Team System 中內建的專案入口網站中的流程樣板, 是MSF在Visual Studio開發工具中的一個實作方法, 但如果您需要知道有關 MSF Core 核心紀律等資訊時，您可以在 https://www.microsoft.com/downloads/results.aspx?pocId=&freetext=MSF&DisplayLang=en 微軟的下載專區, 找到雖然是核心的精神文件白皮書。或是在國內天龍書局/Amazon上購買 Microsoft Solution Framework Essentials 書本。
也續您會問, 什麼叫做和開發工具綁在一起 ?
MSF 在 Team System 中的流程樣板, 直接就寫明了 什麼角色, 用什麼樣的工具, 在什麼樣的工作項目中, 應該產出什麼樣的 文件/ 程式碼…etc.
給新朋友的建議.
Steven & Peter 告訴我, 我一定要談談導入的方法與建議, 我想了很久. 決定採用 FAQ 的方法來分享, 在過去一年多來, 特別是前半年多以來小弟是扮演者第一線的技術顧問與產品Pre Sales角色。後半年多來, 我加入微軟後, 便扮演著和過內CMMI顧問公司共推規劃與推廣 Team System加值產品與顧問服務的工作。但不論是哪一種角色, 我最常被 問到幾個問題：
Q1: 我們一點 .NET 經驗也沒有, 怎麼導入 Team System?
也許您很驚訝, 但這絕對是頭號的大問題, 即使在 Peter 剛取得的 2006 年台灣區市調中, .NET 市場普及率已經到達 67%. 但是仍有許多客戶目前團隊的經驗是在 VB6 / Delphi / 其他友商開發平台上. 對這些 .NET 新朋友來說, Team System 絕對不是 “簡單上手” 的平台與解決方案.
如果您是這些朋友, 該怎麼辦呢？通常我們會建議您, 萬丈高樓平地起, 軟體加上工程, 絕對不會是買了一個工具就解決的. 一個正規的學習流程仍是需要被建立的! 這個學習的流程是
“定義” -> “學習” -> “實作驗證” -> “量化導入”
定義:
我們常見的導入膠著或是遇到問題情況都是, 客戶或軟體夥伴和我們提到, 他們已經開始導入了. 他們得做法是 讓兩個工程師開始買書自修或是送去訓練中心上個課程. 但卻沒有定義出導入的雛型專案 ! 這個結果往往是三個月後, 我們又和這些客戶見面了, 但是一旦問他們導入的狀態, 他們通常都是回答, “還在想怎麼導入”; “.NET 中某個技術看起來很有趣”… 我們覺得, 這是有些可惜又浪費資源的; 因為接受訓練的人, 又繼續手邊的舊技術舊專案.. 原本才上了幾天的課程, 或是才K了幾天的書, 現在都還給老師了.
因此我們會建議, 如果您的團隊已經決定開始學習 .NET, 那麼請您就直接定義出您的第一個 .NET 雛形專案為何, 種子人員, 與使用技術規模; 我們甚至有客戶就直接拿些如 “Web訂便當系統..等” 超小型又微不足道的系統做為導入的定義! 於是組織內部員工在上完訓練課程之後, 就馬上著手進行開發. 即使是一個月, 這些成員對 .NET 了解與架構, 就慢慢有了解, .NET種子, 已經在您的組織中開發萌芽了.
學習:
這裡的學習, 我想強調的是 “平台技術的**重點式**深入研究”. 您的團隊可以透過很多種方式或管道取得.NET上的學習資訊, 如 去上個某教育訓練課程專班 ; 買書自修 ; 自聘專家顧問 ; 邀請微軟技術顧問直接到府介紹 ; MSDN 等各式技術活動研討會. 但是請相信我, .NET 的技術領域相當廣泛, 小至手機等小型裝置, XBOX 上遊戲開發; 網頁設計; Smart Client 架構.
請確認您的團隊未來所希望具備的技術領域為何, 授權您的種子人員 別貪心就只先研究該領域技術, 並且在是當的時候尋找專家的協助!
實作驗證 :
在這個過程中, 您的種子人員應該已經開始用著生澀的書本或課堂經驗在做軟體開發, 您的團隊一定也會發現, 原來實作與理論的結合下, 可以取得更多寶貴的經驗, 這些經驗相當重要, 因為他是在驗證您未來的資訊系統投資是否真的可以得到滿足. !
如果您有顧問夥伴的協助, 請您用心吸取顧問留下來的經驗與設計模型, 最好是直接和您的顧問夥伴討論, 您希望的系統效果效能為何, 請顧問團隊直接給您一個好的經驗模型做為開發基礎. 如果沒有, 請別忘記, 網路世界資訊是互助分享的, 您可以在 MSDN 技術論台上尋找高手協助, 甚至是Email給我 polo.lee@microsoft.com, 我也很樂意給您一些建議.
量化導入 :
成功的實作驗證經驗, 就可以當作一個好的經驗樣式, 您然後可以再次尋找一個新的專案下手規劃, 而您的種子員工, 現在正是您的二年級生, 由他們扮演著專家, 帶領其他的新手入門
但請您注意, 在沒有聘請任何專家顧問繼續習助下, 我並不是說只開發了一個定餐系統的經驗, 接下來就可以開始由他們來主導整個 ERP 系統的開發了, 如果允許, 請多讓您的團隊具備更多專案的經驗再一口氣進行主導大型系統規畫;
多少系統經驗才夠 ? 我建議可以由時間與投入資源做為評估基礎, 一個便當系統也許是 兩人半個月開發結束, 但一個小型客服部的 Help Desk 系統, 可能是三人三個月; 比起一個 ERP 系統需要五人六個月來說, 您應該先在 Help Desk 上取得更多經驗; 但如果您的商業迫切, 那麼外聘或是雇用本身已經具備經驗的高手是絕對的要素 !
Q2: 我們不只是微軟平台, 也是用 J 牌的軟體架構, Team System 能用嗎 ?
我想我們不能說, Team System 直接整合了 Jxxx 等所有其他廠商的軟體技術, 但由 Team Foundation Server 託管的專案管理與流程管理等, 本身是無任何技術相依性的存在; 您可以使用透過 Team Foundation Server做為任何軟體開發的管理平台; 託管 jxxx 程式碼; 託管文件、會議記錄…等; 做專案進度追蹤; 資訊回報… 等;
只是唯一的限制是;您無法像 Visual Studio Team Edition 的開發工具一般; 直接做到許多針對程式碼本身品質的驗證與確認功能 (ex: Check In Policy…etc) 當然也就無法在 Team Foundation Server 中看到相關的品質報表.
在國外我們的協力廠商 Teamprise甚至開發了一個軟體套件; 讓支援 Eclipse 開發環境的軟體工具; 可以在非微軟作業系統上將做專案與軟體流程的託管
Q3: 我們還有許多既有的 .NET 2002/2003 ; 甚至是 VB6 軟體, 這系統能用嗎 ?
如果您打算直接在您目前版本的開發工具上 (ex: VB6 / VS.NET 2003..) 上直接按下右鍵進行版本管控的功能, 那麼請您上 Microsoft Download 下載您目前使用的開發工具相對應的 MSSCCI Provider.
https://www.microsoft.com/downloads/details.aspx?FamilyID=87e1ffbd-a484-4c3a-8776-d560ab1e6198&DisplayLang=en; 只是 因為是舊的 IDE 工具, 您只能做好 版本管控, 不能夠直接在舊系統中, 做好全套的 工作管理; 專案管理… 等。
請您特別注意, 您也可以透過 Team Foundation Server 對應的 Team Explorer 獨立 IDE 套件來進行版本管控; 透過正種方式, 您就可以採用 Work Item 為主的 版本管控系統架構. 相同的, 唯一的不方便是 您無法在 開發工具上, 直接按下右鍵做檔案新增/簽入或簽出.
https://download.microsoft.com/download/2/a/d/2ad44873-8ccb-4a1b-9c0d-23224b3ba34c/VSTFClient.img
Q4: 微軟有CMMI 流程, 你告訴我這是什麼 ? 我可以直接拿認證嗎 ?
Team System 的流程樣板, 內建了一個 “MSF for CMMI Process Improvement” 的樣板讓您的團隊參考套用;
就目前來說, CMMI 已經是一個業界標準, 這是個十分嚴謹的 軟體程序規範, 事實上 Team System 的設計團隊在設計流程樣板時, 因為思考到 業界對 CMMI 的認同, 於是針對這個 CMMI 的精神, 由微軟自己的 MSF 流程出發, 設計了一套符合 MSF 精神以及微軟開發工具的最佳運用準則的 CMMI 流程樣板. 您可以簡單來想, MSF for CMMI Process Improvement 是微軟針對 ”微軟平台的軟體團隊” 需要 “符合 CMMI 精神的嚴謹軟體程序” 所整理出來的最適軟體工程樣板.
這個樣板包含了 流程、角色指引、動態報表、文件樣板等. 並且一口氣幾乎囊括所有 CMMI Level 3 所覆蓋到的目標。透過這個樣板 如果您的團隊希望追求的是 CMMI 認證，那麼您可以利用這份流程樣板、當作程序書的基礎已降低大量的文件程序書等製作的時間。
但請您注意, 我們並不是說一但您使用了這個樣板, 明天就可以馬上去申請CMMI憑證, 然後從此過著幸福快樂的日子。在沒有針對您的組織與企業文化調和之前, 任何流程都不可能讓您的團隊直接使用沒有任何負擔.
Q5: Team System看來如此複雜, 我要如何導入才能證明我的團隊是有成長的 ?
這個問題通常都是在我們和 資訊主管等夥伴報告過 Team System 系統價值之後 主管們馬上會問的一個問題；特別是如果您也曾接觸過 Team System，您會發現 Team System 的架構橫跨了四個角色所有的軟體開發生命週期：似乎是相當的龐大!!!
而實際上如果您的團隊本身對 Visual Studio 開發平台與工具並不熟悉，同時在過去專案過程中也沒有太多的軟體工程概念； 那麼我們強烈建議，您的團隊在導入時應該至少要分四個階段導入：
階段一：導入版本管控到您的專案團隊之中
我們建議甚至要求您，將版本管控當作第一個導入基準點，因為在您的團隊習慣了 Team System 的版本管控機制之後，您已經取得了第一個 投資 Team System 的即時報酬! 您的團隊已經習慣將重要資產按照版本概念建立，並且習慣了同一專案多人餐與開發，這都是軟體團隊的重要基礎建設與基本素養。
除此之外選用 Team System 做為管控中心，您還可以得到 專案入口網站做為專案會議、討論、文件分享等好處；您也可以讓團隊分散在台北高雄、大連蘇州，跨標準網路HTTP 80無障礙的即時溝通；
階段二：導入工作項目與Check In Policy 到您的專案團隊之中
在您的團隊建立了版本開發的概念後，這時候您的團隊非常適合開始導入專案與工作項目追蹤的機制；事實上很多組織會等不及的就將階段一與階段二合併導入；因為 專案經理人 最重要的管理機制會在這個階段開始導入進行。
我們建議 您的專案經理人在這個階段開始採用 Microsoft Project / Excel 工具做WBS等專案管理規劃；並且直接就派送工作包給開發人員；而開發人員在這個階段，開始採用 Team System 做為工作進度的回報管理； Team System 的 Check In Policy 提供了重要的稽核點；您的團隊會被要求一定要回報工作狀態之後，才能將異動中的程式碼做簽入與簽出(Check In / Check Out)
在您的團隊習慣將專案資訊透過 Team System 追蹤後，您會發現您的投資報酬是：透明的專案進度、即時的專案報表資訊、異動與需求變更的自動追朔。Team System 引擎將自動追朔專案資訊，並提供專案團隊更好的決策資訊。
階段三：導入測試與臭蟲(Bug)等追蹤 到您的專案團隊之中
也有些團隊，喜歡將階段二與階段三一口氣合併執行；在這個階段中，我們希望您在熟悉了 Team System 中的 Work Item 追蹤之後，進而全面追蹤所有專案活動中所有您需要被追蹤的工作項目：Bug、Test、Issue…etc。在這個階段，我們不強調所有被追蹤的工作項目是透過自動化工具的產生：如 Test、Bug 等工作項目，您的團隊也許還沒有獨立測試人員的編制、甚至沒有習慣的流程建立；但是我們希望您的團隊會開始導入 Team System 中的 Build 機制，並且開始撰寫 單元測試。
再過去的軟體工程中，單元測試是一直被強調但卻往往忽略掉的部分；主要原因是因為撰寫單元測試所花費的時間成本太高，以及軟體開發人員的刻意遺忘；藉由 Team System 自動化的 Code Gen 單元測試程式碼，搭配 Check In Policy 的約束，您的團隊可以漸進養成高品質的軟體撰寫習慣。
Team Build 是Team System一個突破性的專案整合機制，透過 Team Build您的團隊將會漸漸習慣如 Daily Build & Weekly Build 等高品質團隊共通的專業素養。同時在您花時間學習導入之後，您所得到的報酬會是 您的團隊 每天 / 每周 都有一份最新的 組件報告：包含了 該組件的版本、所有對應的工作項目、發生臭蟲數量、所有異動程式清單。以讓您的產品經理有一份品質的報告標準。
在這個階段完成時，您的團隊每天都可以在專案入口網站中取得目前軟體品質報告、臭蟲等分類報告、組件報告等資訊。
階段四：導入自動化測試與工程管理到您的專案團隊之中
階段四對於您的團隊來說，最大的考量在 “自動化” 與 “進階的測試方法導入”。而我們之所以將這個階段放在最後，主要也是因為 自動化 表示 “以建立流程、並且習慣的使用中”； 進階測試 則表示 “更複雜的測試方法與架構、採用更進階的工具功能”。
在這個階段我們建議您的團隊考量納入 “持續不段的整合Continuous Integration” 概念，在階段三中，您採用了 Team Build，但我們不要求您有固定的時間節點，但在這個階段中，我們建議您的團隊要定義出固定產出 組件 並且 檢視組件品質報告的 流程與習慣。
此外，對於複雜的進階測試議題，我們也建議您 全面採用自動化的測試工具做為測試標準工具；在階段三中您開始了追蹤 臭蟲 工具項目，但您的追蹤可以是透過手動在 Team System 中鍵入。透過 Team System 中的 Tester 測試人員專業工具：Web Test、Load Test、Manual Test…等， 您會發現這些工具所自動產生 臭蟲 工作項目，包含了許多更細膩的品質指標。我們建議您，在這個階段也全面導入 Team System 中的Code Analysis Check In Policy；您的投資在這個階段中，您將會看到 完整的 品質報告 (包含 程式碼覆蓋率、程式碼攪動比率、壓力測試品質報告) 同時您的團隊已經是 “一個習慣製造高品質軟體” 的專業團隊。