隨著資訊系統的規模擴大，觸角深入每個環節。要完成乙個資訊系統真是千頭萬緒，若專案的各開發過程有輔助工具，以建立完整的開發架構，讓資訊團隊所有的成員容易擷取各個開發流程所需要的進度評估資料。並有幾本書描述各階段性流程的精神，對應工具的操作方式就好了。
工欲善其事，必先利其器
微軟在2005
年推出了
microsoft visual studio team system(vsts)
，並搭配新版的
msf(microsoft solution framework) 4.0
方**。有別於先前的
msf 3.0
版，4.0
版是以當下最流行的兩套開發方**：「敏捷
(agile)
」和「軟體能力成熟度整合模式
(capability maturity model integration cmmi) level 3
」為本。期待提供大家整合開發流程的利器。
vsts
以集中而共享的資訊，讓團隊所有的工作者通透地了解任何乙個開發環節的現狀。並將抽象的方**化為實際的模板檔案和需要填入的窗體，並以專屬的工具程式來完成各流程的需求，隨後以報表呈現結果。而借由此類工具，我們也比較能夠發揮敏捷開發的精神，快速地走過各個階段，讓多個團隊成員同時並進，一次次遞迴分析、設計、開發、測試、除錯、部署等流程。
雖然整個
vsts
架構的立意良善，但如此大部頭的全套開發流程輔助工具在國內還算開風氣之先，這不是乙個專案經理熟悉專案建置、程式設計師學會程式技巧，或是
dba
熟悉資料庫架構就可以單兵作戰。而是整個團隊的學習與工作上的默契培養。向乙個團隊推廣各成員角色獨特的理論與技術，然後要成員們再憑著各自學到的新技術協同合作，這讓學習與應用本身就是一件工程。
而筆者此次介紹的這本書「軟體工程與
microsoft visual studio team system(
原文書名為
software engineering with microsoft visual studio team system)
」，就是描述各開發流程重要的精神。作者
sam guckenheimer
是vsts
的產品規劃師，代表我們各種軟體開發人員對
vsts
的需求。由他來解釋
vsts
的理念再適合不過了。
這是一本討論
what
和why
而沒有how
的書，由於內容較形而上，且知識密度很高，所以並不好讀。每每筆者讀了一段後，總要停下來印證一下就自身實務上，是否可以此為準則，還是因為辦公室政治與文化的差異，導致作者的立意雖好，但會在我們自身企業內水土不服。
增值的軟體開發生命週期
相對於現實世界的工程特徵
(如建築工程)：
l重複前乙個橋梁、道路或房舍的設計，以降低風險與成本。
l設計成本較低，建置成本較高，建置過程中不太改需求。l採
work-down
工作流程，也就是仔細地將設計分解成多個實做的工作專案，分配資源，並在開工後逐一槓掉已完成的專案，以工作專案的完成度決定進度。
l適合低風險、低變動以及需求明確的設計，若要以軟體種類來模擬，可能企業資源規劃
(erp)
較為適合。
而軟體世界的工作流程並非如此，它的特徵如下：
l若與其它已有的前乙個設計近似，購買即可。要自行開發的，通常沒有近似的經驗，且有很深的企業營運邏輯。
l需求時常更改，因為商業環境一直在變動。
l需求明確時，適合
work-down
，不確定時，適合
value-up
。也就是在週期性的時間點量測客戶價值的完成度，但認定需求輸入是變動的，並非固定值。
本書強調反覆與漸進
(iterative and incremental i & i)
的增值(value-up)
式開發流程，希望能夠同時整合迅速靈活與責任歸屬兩個面向。
本書涵蓋了軟體開發大部分的生命週期，除了最後段的發行/上線
/維護外，一般的專案管理、需求分析、架構設計、程式開發、測試除錯都有專章涵蓋。並伴隨
msf 4.0
的主要角色。若你在團隊中，剛好身處該角色，可以先熟悉
msf
所賦予的責任歸屬。再搭配一步步教你
vsts
操做的書，將概念實現出來。
本書在各章都有**來輔助理論解說，並盡量以故事或實務經驗來讓論點鮮活。而部分章節以統計圖為例證，說明相對的開發流程階段之趨勢分析，以討論需求的滿足、專案的進度、測試的周延、
bug
的分布…
等等，並描述圖表的解讀方式與潛藏的迷思。透過一目了然的圖示，將讓我們更能掌握專案的運作。
軟體質量是我們普遍欠缺的，作者以增值思維貫穿全書，並約有一半章節對
bug
深入討論，這是國內一般軟體開發團隊所忽視的。書中有趣的論點與作法俯拾皆是，例如他們在收集需求時，有易用性實驗，也就是要受測著進入被監控的房間內操作軟體，同時大聲說出做每一動作的感想，而測試環境會錄製使用者操作軟體的方式，在檢討時，結合使用者的影像聲音一起呈現。
又如管理專案時，使用描述性的，而非規範性的度量。規範性的度量是明白指出達成目標的條件，例如程式設計師撰寫的程式**行數，測試工程師發現的
bug
數，或是程式開發者解決
bug
的數量，這種單一的簡單度量長時間施行後，只是鼓勵員工鑽漏洞，打擊做事者的士氣。例如寧願重複複製程式**，而不撰寫成可重用的函式或物件。或是故意埋入
bug
後，再發現並解決。
為了預防上述的弊端，作者強調在週期性開發，逐次達交的模式下，量測的重點應是已完成、有質量、可交付的工作，參照多個量測資料才推測合理的結果，且評比的物件是團隊而非個人，不以單一資料而以客戶滿意度為獎懲依據。
譯者的心路歷程
本書的譯者蔡煥麟先生曾經與筆者在恆逸資訊教育中心共事，是位功力紮實的講師與工程師，本書由他譯來，文筆流暢外，更因處處的「譯註」，讓讀者更能了解作者所言的來龍去脈。如他所言：「
儘管這是一本寫給開發團隊所有成員閱讀的書籍，但其內容深度對一般開發人員來說，恐怕還是有些過於艱澀、不易閱讀，這是我在翻譯時經常擔心的。作者沒有用太多文字向讀者解釋什麼是
extreme programming
、agile
、cmmi
、scrum...
等術語，而是假設讀者對它們已經有基礎的認識，或者應該自行去閱讀相關的書籍、文章。但從軟體工程相關書籍的種類與數量，以及各大討論區、論壇**的主題大都圍繞在程式設計方面的問題來看，台灣的軟體開發人員在這方面似乎仍偏重於程式設計的技術面議題，如
asp.net
、ado.net...
等。在這種情況下，有些讀者或許仍欠缺一些必要的背景知識，再加上
vsts
又是一項新產品，因此他們在閱讀這本書時，可能無法平順地前進。雖然作者適時地在每章後面加上注釋，讓讀者能夠找到相關的資訊或參考出處。但是對大多數忙碌的讀者來說，恐怕也考驗著他們的耐心。
因此，我在書中加了一些譯註，期望能降低閱讀門坎，讓讀者閱讀時會比較平順些。」由於
vsts
是新產品，而以往在微軟領域理也少有軟體工程論述譯作，相信在翻譯此書時，名詞的選擇、陌生領域的術語意義都需揣摩推敲。譯者嚴謹的做事風格讓譯本如實表達了作者的意念，如他所說：「
flow
（心流），
這個名詞出自《快樂，從心開始》。當初為了翻譯這個名詞，我跑了好幾家書店，卻都買不到這本書，原來早已絕版，最後總算在圖書館借到。另外，為了顧及翻譯的正確性，也盡量查詢書中引用到的一些術語的參考文獻，如：《戴明的新經濟觀》、《跨越鴻溝》、《人月神話》、《
extreme programming explained
》...
等等。這樣一路翻譯下來，讓我覺得本書作者真是博學多聞。而當初為了翻譯一句話而去買一本書，本來頗覺費事，但也發現自己的視野更加開闊。」
另外，本書的也都經由譯者中文化了，足見他架起
team foundation server
，建立範例專案的資料，以抓取
vsts
中文版的操作畫面。順著作者的思緒走訪一遍
vsts
的各項功能，定讓他更貼切地譯出文字，同時也讓習於中文環境的使用者在閱讀本書時，沒有障礙。
閱讀建議
本書的第
一、二、九、十章是綜合的概論，而中間的章節比較偏向軟體團隊中，不同職稱的人所負責的工作。你可以先閱讀概論後，接著跳到屬於自己工作角色的章節，而後再擴散到鄰近工作專案，相信對於整個軟體開發生命週期會有更深一層的認識。
在書籍一開始有來自各界一長串對本書的溢美言詞
(其中還包含了物件導向的巨擘
ivar jacobson)
，從不同面向褒揚此書，倒也呈現不少軟體工程理論、業界認知、
vsts
定位三者間的關係。
最後，本書中，每章都有注釋，主要是詳列引言的出處，但都可以當作你的延伸閱讀。你可以將本書當成建構現代化資訊系統的入門指引，而後藉由注釋提供的聯結，進一步深入各領域。
由於本書僅著重在精神的描述，並未介紹實際的操作，或許你可以搭配一本與
vsts
逐步使用指引有關的書，例如
microsoft press
所出的「
working with microsoft visual studio 2005 team system
」，並輔之以試用
vsts
，將更有收穫。
而本書譯者的網誌有提供該書的試閱與討論，也不妨去瞧瞧：
譯者在以下**也提供了一些心得和書籍的勘誤：
如何構建優秀的團隊？
自己曾經帶過乙個6人左右的團隊，經歷了一些事情之後，才發現自己的管理能力非常差。雖然個人能力在持續提公升，但團隊能力卻增長不大。究其原因我覺得是自己對管理的理解不到位。很欣賞馬總說的一句話 你從開始當管理者這一天起，別人的成功是你的成功。你通過一件事情的完成，去成就他人的成功，這就是當管理者 我覺得...
什麼樣的團隊才是優秀的團隊
記得以前看過乙個資料，一般團隊組成為 1 2 3 1 1代表乙個領導者 2代表2個優秀者 3代表3個普通者 1代表1個淘汰者 領帶者代表的團隊的發展方向 優秀者是團隊成功的助推器 普通者是優秀團隊的基石 而淘汰者，成為了團隊不斷進步和超越自我的鞭策力量。帕克基諾比利的突破和帕克的速度，成為了馬刺成功...
團隊工具 打造優秀團隊的工具，團隊價值圈
林正剛 在做企業教練的這幾年中，我發現很多企業連自己的企業價值觀都說不清楚，對應聘者就更無從說起了。所以我建議創業者先要設計適合自己企業的 價值圈 然後用這個價值圈作為打造團隊的 藍圖 這個藍圖可以用來作為聘請人的基礎，它也是打造團隊的總價值圈。價值觀的匹配度是首要考慮因素，每家企業無論刻意還是無意...