書　　名：軟體工程與 Microsoft Visual Studio Team System
作　　者：Sam Guckenheimer
翻　　譯：蔡煥麟
出版日期：2006/9/20

簡介 (Introduction)

樸實的書名清楚點出了本書的重點所在，就是軟體工程與 Micrsoft Visual Studio Team System（VSTS） 二者。一個是理論構想，一個是輔助工具，作者恰如其分地將兩者結合在這本書裡面。正如 Ivar Jacobson（物件導向三巨頭之一）在本書的序言中所說的，這是一本兼具理論與實務的技術書籍。

本書由碁峰出版，採頁頁對譯的編排方式，並提供中文版的索引。

閱讀環境

您不需要在電腦前面一邊閱讀本書一邊操作（雖然我有時候也會這麼做），因為這不是一本逐步教學的 how-to 書籍；但我想一個舒適安靜的環境是絕對必要的（例如圖書館、臥室 ）。書中舉的一些實例可能正好是你目前開發專案時碰到的問題，或者與你過去的開發經驗吻合，因而激發你的靈感，讓你更進一步去思考過去的作法有什麼缺點，以及往後該如何改善。不論是 Hmm...(掩卷沉思)、唉～(仰天長歎)、還是 A-ha! (豁然開朗)，在閱讀時，我都很喜歡這種感覺。希望您也能在書中找到對自己有用的東西。

下載試讀章節 (Free Chapters)

• 章節目錄、關於作者、序、前言 (994 KB)
• 譯者導讀 (210 KB)
• 第三章：需求 (1.15 MB)
• 索引 (153 KB)
• 勘誤表(Errata)

相關的讀書心得可以到[閱讀筆記]主題區查閱。
對本書的讚美 (Praise for the Book)
「太吸引人了！這本書詳細說明了 VSTS 有哪些功能，以及為甚麼要把這些功能加入 VSTS——這些寶貴資訊只有微軟內部的員工才有辦法提供。也許更重要的，是作者在介紹每一項功能或如何操作的指示時，都會詳細解釋為什麼這些功能對你這麼重要。本書揚棄了以往開發流程的缺點，並取各家所長，指出方法論的未來發展方向，並點出哪些度量資訊能夠用來改良和客製化你在開發專案時採用的方法論。」
「對任何想要使用 Visual Studio Team System 和微軟解決方案架構（Microsoft Solution Framework，MSF）4.0 版的人來說，這本書絕對非讀不可。本書的一個關鍵主題是『敏捷與責任歸屬』，它解釋了軟體開發方法的思維模式轉移至增值（value-up）方法的過程，並說明 Team System 如何支援增值方法。作者以大量的實用範例來說明如何以 VSTS 實踐增值開發方法，而且每個範例都傳達了某些重要的訊息。」
「Sam Guckenheimer在公開透明機制方面的先進理念，將徹底改變我們管理軟體專案的方式。不要光只是把 Visual Studio Team System 買回去；你應該要學習如何充分利用它來改變我們的開發習慣並創造價值。Sam 會告訴你該怎麼做。」
「Sam 把 Visual Studio Team System 的精華都放到這 250 頁當中了。如果你的工作與軟體開發有關——不論是開發人員、測試人員、專案經理、架構師、還是資訊長（CIO）——你的團隊都應該要人手一本。本書拉近了現代軟體工程理論與開發實務的距離，並以清晰易懂的範例說明如何利用 Team System 實踐它們。這本書和之前的一些書籍最大的不同點，就是它理論與實務並重。不論你是否已經在使用 VSTS、正在考慮是否採用、或者只是想利用它來提高生產力和輔助企業校準（business alignment），你都能在書中發現許多有用的資訊與見解。這是一本非常有趣、實用、而且容易閱讀的書籍。」
「Sam Guckenheimer 是軟體測試社群公認的專家與良師，很高興看到他終於出書了，而且這本書還清楚闡明了他在軟體工程方面的理念。
「在這本書裡面，Sam Guckenheimer 捕捉了 Team System 與增值軟體開發思維模式的完整意涵。此思維模式和以往那種計算工作做完多少的方式截然不同，其核心概念在於測量已交付的客戶價值，Team Systsm 就是依循此理念所設計出來的實作品。你會發現 Team System 為專案提供了前所未有的透明度，此透明度將能大幅改善團隊成員的互動與專案的可預測性。更重要的是，它並未因此而增加團隊成員的負擔和工作時間。閱讀本書將能讓你體會 Team System 的完整設計理念與它所帶來的增值軟體開發良性循環的好處。」
「Sam Guckenheimer 堪稱是技術的外交官。在以機動性見長的敏捷學派游擊隊與 CMMI 正規軍對壘的世界中，Sam 提供了一個讓兩者和平共存的方法。此空前創舉使它成為第一本、也是最重要的一本軟體工程書籍。在討論一些像是規劃、撰寫文件、企業治理、稽核、與組織等焦點議題時，Sam 同時展示了敏捷與正規的實務作法，並且說明採用它們的最佳條件。即使書中的範例主要是以 VSTS 來說明，但其理念與指引卻是放諸四海皆準的。本書是寫給專案的所有角色成員，不論他們在實務上選擇的是重量級還是輕量級的方法，Sam 都提供了實用的建議。本書內容新穎且符合時代潮流，其中還論及服務導向架構、測試驅動開發、以及使用者介面社群所發展出來的一些設計技巧。Sam 的這本書可說是軟體界的超優質著作。」

BugNET 這套問題追蹤工具除了具有免費、容易安裝設定等優點，個人用到現在也都沒碰到什麼大問題（目前用在約 20 人的團隊），挺穩定的，而且一直都還持續更新，功能也愈來愈強。最近對目前參與的專案有一些軟體品質方面的疑慮，想要從平日登錄到 BugNET 的資料抓出一些統計數據，這才發現 BugNET 提供的統計圖表並不是很夠用。所幸它提供了一個 view，從這個 view 取出的資料，幾乎已經能夠滿足我的需要了，剩下的只是如何產生圖表而已。這篇就大概介紹一下我從這個 view 取出哪些資料，以及利用 Excel 產生的圖表，同時扼要說明一下這些圖表的用途。BugNET 提供的 view 名稱叫做 BugsView。以下分別介紹用來產生統計圖表的 SQL 命令、圖表範例、以及用途說明。由於 BugNET 本身已經有提供的問題狀態統計圖（一張圓餅圖，顯示已結案、處理中、重新提出...等各種問題處理狀態各佔多少百分比），所以這裡就不列出了。
要先說明的是，有些 SQL 命令看起來很冗長，我也沒特別花時間去查是否還有更精簡的指令，基本上只求能達到我的目的。此外，這裡的圖表範例，都是先利用 SQL 命令得到資料，然後直接貼到 Excel，稍作加工（修改欄位標題、加總等等），再使用 Excel 的插入圖表功能即可完成。當然你也可以撰寫程式將這些產生圖表的動作自動化，方便隨時查閱。1. 每個月的問題數量
SQL 命令：
SELECT STR(YEAR(ReportedDate), 4, 0) + '/' + STR(MONTH(ReportedDate), 2, 0) AS RptYYMM,
COUNT(YEAR(ReportedDate) + MONTH(ReportedDate)) AS Cnt
FROM BugsView
GROUP BY YEAR(ReportedDate), MONTH(ReportedDate)
ORDER BY RptYYMM
圖表範例：

說明：
從這張統計圖可以看出哪些月份的問題數量比較多，以發現數字背後所隱藏的事件或原因。例如 2007 年 10 月可能有某個新系統上線，而使用者對該系統反映的問題較多，因此數量明顯增加；2008 年 2 月份由於經過一次年假，問題的數量就少得多。當系統完成驗收之後，系統應該會逐漸穩定，因此這張統計圖的問題數量應該呈現逐漸減少的趨勢，若非如此，專案經理就得進一步了解實際的原因。
2. 問題的優先等級分布
SQL 命令：
SELECT PriorityName, COUNT(PriorityName) AS Cnt
FROM BugsView
GROUP BY PriorityName
圖表範例：

說明：
在登錄問題時，必須根據問題的嚴重或緊急程度做分級（triage）。在所有提出來的問題當中，我們比較有興趣的是「緊急」跟「很重要」的問題佔多少比例，因為我們將這類問題定義為較具急迫性的問題，開發團隊必須在指定的期限內處理完畢。如果這類嚴重問題的數量很多，要不是軟體的品質水準太低，就是登錄問題的人員對於問題的分級不確實，比如說，可能每次登錄時都希望問題盡快獲得解決，就一律歸類為緊急問題。
3. 問題數量與軟體品質的關係
SQL 命令：
SELECT TypeName, COUNT(TypeName) AS Cnt
FROM BugsView
GROUP BY TypeName
圖表範例：

說明：
BugNET 的問題類型也可以自行指定。我把問題的類型分成 Bug、改進意見、新增需求、需求變更、待討論、以及無效問題等六類。Bug 代表軟體的設計錯誤，包括設計不符合使用者的需要、無法執行特定的功能、以及執行結果不正確等等；改進意見代表功能雖然可正常執行，但是在易用性、穩定性、效能等方面有待加強之處；以上兩項均代表軟體的品質，若其總和數量偏高（例如：超過事先定義的警戒線），專案經理就要特別注意。新增需求與需求變更皆屬於需求異動的部份，開發團隊可以從這兩項數據得知使用者是否經常提出需求變更，以了解需求蒐集和系統分析階段是否有需要改進的地方是，例如：需求誘導技巧是否需要改進、每一項需求是否皆經過使用者的同意即確認、或使用者是否傾向於事後（上線後）才提出新需求等等。屬於「待討論」的項目代表該問題的範圍或定義尚未釐清，主要是讓開發人員可以紀錄一些尚未確定的需求或議題（後來發現這項並不實用）。「無效問題」則是開發人員實際測試後，發現是使用者對系統操作方式不熟悉，或者其他環境因素所造成。
4. 各子系統的品質
SQL 命令：
SELECT ComponentName, TypeName, COUNT(*) AS Cnt
FROM BugsView
GROUP BY ComponentName, TypeName
ORDER BY ComponentName, TypeName
圖表範例：

說明：
BugNET 可讓我們設定系統有哪些 Components，也就是說，你可以自行定義子系統及各項元件，這樣在登錄問題時才能夠特別指明該問題是發生在哪個子系統，將來也才能夠得到比較詳細的統計數據。當整個系統的 Bug 數量偏多，你可以從這張圖進一步看出各個子系統／元件的品質。例如圖中的人事系統光是 Bug 和改進意見的數量加起來就有 171 個，佔整個系統問題數量（689）的 25%，專案經理可能要針對這個子系統特別研究一下是哪裡出了問題。
P.S. 以上圖表都沒有標示時間範圍，它們都是同一個專案的 current stat，也就是從一開始登錄問題到目前為止的狀態統計。
P.S. 以上圖表除了子系統名稱被我換掉，其餘皆是真實資料的統計數據。
結語
有時候，我們從最近 user 的反應「感覺」最近系統好像很多毛病，並將此意見反映給開發團隊時，經常得到的答案是：「程式的品質並沒有太大的問題，很多都不是 bugs，而是 user 的需求一直變更和新增。」此時解決爭議的最好辦法，就是拿出數據，這也是我製作這些圖表的用意：讓數字說話。
不過，在運用這些圖表時，務須牢記一件事：無論是問題統計圖表還是其他專案度量結果，其提供的資訊可能只偏單一面向，專案經理在獲得此初步資訊之後，應進一步蒐集其他相關資訊，以提供問題的佐證，或者向團隊詢問，如此方能確定問題的根源，並提出正確的解決方案；如果單憑某個單一數據就驟下結論，而向團隊質疑或提出指控，不僅容易做出錯誤的決策，將專案開發工作引導至錯誤的方向，也很容易造成團隊成員的反感。
還有一種統計圖我很想看到卻沒有做的，就是問題的成長速度 vs. 問題的解決速度。因為有些問題實在花很多時間才解決掉，對於 bugs，我們特別關心它的平均處理時間。
以上有不少想法和觀念均來自《軟體工程與 Microsoft Visual Studio Team System》。我不時會回頭參考這本書，每每覺得這本書寫得真好，因機緣巧合而能夠翻譯此書，實在是沾了作者的光。希望 Guckenheimer 在 Rosario 問世之後也能更新這本書的內容。呃......大概只是奢望。

從書名可知《Large-Scale Software Architecture: A Practical Guide using UML》裡頭談的是如何使用 UML 來設計大型軟體的架構，不過，如作者說的，中小型軟體專案也可以採用書中建議的方法，因為很多看似大型的、重量級的方法，都必須從比較小的 case 去實踐、練習（儘管會付出過多 effort，有殺雞用牛刀之嫌），否則一次就從大案子下手，結果恐怕不會太樂觀。

簡介

《等效翻譯探索（增訂版）》是由翻譯家金堤先生所著，這本書原為簡體版，後來才在台灣發行繁體中文版。閱讀時很順暢，沒有明顯感覺簡體書的影子，想必繁體中文版已經針對兩岸用語差異的部份做過一番調整了。

等效翻譯理論強調譯文不僅要能準確傳達原文語意，同時要盡量維持文句的通順。其基本原則是「同一信息，用兩套不同的語言，接受者不同，卻要產生基本相同的效果。」作者指出，古人早就提過等效翻譯的概念，如玄奘說的「既需求真，又需喻俗」，而作者所提出的等效論，看起來似乎是基於奈達的「功能對等」理論（最初發表時的名稱是「動態對等」），加以調整並融合自己的經驗與理念所發展而成。無論起源為何，重點在於這套理論「對兩千年來西方翻譯家們相持不下的直譯與自由譯之爭，提供了一個令人信服的答案。」其中的自由譯，即所謂的「意譯」。

義大利有句諺語說：「翻譯就像女人，漂亮的，可能不忠實；忠實的，又可能不漂亮！」換句話說，就是直譯與意譯兩相衝突，好比魚與熊掌，不可兼得，因此譯者只好在「寧信而不順」與「寧順而不信」之間擇一為之。但是等效理論認為這是不正確的觀念：「順」與「信」二者並非互斥，實為一體之兩面，應該同時並存。而且，一旦走上意譯的路子，等於為譯者開了方便門，在碰到難處時，譯者可能更容易採取閃躲、任意刪改原意的「變通」辦法，而不是盡力突破眼前的困境。

以下分別整理等效翻譯理論的重點概念、書摘、以及一些感想。

三個核心概念

• 接受者概念：譯文必須被讀者接受，翻譯過程才算有效。要讓讀者接受，首先必須了解原文的對象是什麼樣的人，從原文的語言、文化當中掌握正確的語感，並充分理解原文；接下來，要產生譯文時，則須排除原語的干擾，以譯入語的語感創造出原文同樣效果的譯文。
• 效果概念：效果指的是譯者傳遞的訊息必須對接受者（讀者）產生作用（impact），此作用就是接受者獲得的一切理解和感受，包括：主要精神、具體事實、意境氣氛。這裡的效果，跟奈達所提出的「動態對等」理論所說的效果有些差異，奈達認為，讀者除了有感覺，還要做出實際的反應，例如：讀了聖經就真的去受洗。
• 對等概念：翻譯所需之對等「是一個相對概念，並不是要求達到完全相同的效果，而是達到可能範圍內最接近原著對原文讀者所產生的效果。」簡單地說，就是譯文必須通達。這裡「通達」跟奈達主張的「自然」（nature）概念不同，奈達認為，如果讀者因為文化、環境、或時空背景等因素而無法體會原文要表達的意境，譯者應該調整譯文，讓讀者讀起來感覺比較自然；這看起來更像是犧牲原文的意境而屈就讀者，等效論並不贊成這種作法。

三個翻譯階段

作者建議的翻譯步驟分為三個階段，共九個步驟：

第一階段：以理解原文為主的準備階段。基本上單純使用原語思維。此階段盡量不用雙語字典，而用原語字典或其他原語參考資料。

• Step 1: 仔細閱讀原文，勿試圖翻譯。
• Step 2: 研究作者及作者的其他著作。
• Step 3: 徹底了解即將動手翻譯的原文，包括內容、形象、細節、暗藏含義。

第二階段：雙語雙軌工作的具體翻譯階段。

• Step 4: 使用譯入語創造自己的譯文。此時要注意避免受到原語的干擾。
• Step 5: 譯稿完成後，逐句核對原文。
• Step 6: 將譯稿放置一段時間不去理他，以便「冷卻」。

第三階段：單純使用譯入語來複合譯稿。

• Step 7: 用冷卻後的眼光審閱譯稿，讓自己盡量成為客觀的讀者。
• Step 8: 請不懂原語的讀者閱讀定稿，以找出讀起來彆扭的地方。
• Step 9: 仔細考慮讀者意見，對譯稿做最後潤色。

書摘

初學翻譯的人往往以為藝術就是華麗的詞藻，千方百計拼湊四字詞語和所謂的文學語言，結果不僅損害了內容也破壞了藝術。 (p.8)

有些人在發現原文「講不通」的時候，不是回頭去懷疑一下自己的理解有什麼差錯......，而是盯著他們認為「講不通」的詞句，「根據上下文」對這些詞句作「靈活」的處理，沒有想到這個「上下文」實際上是他們自己頭腦中的錯誤認識，而這樣的「靈活」實質上就是「寧順而不信」的一種表現形式。 (p.37)

因著意傳神而忽略事實，這是許多翻譯作品及評論中可以看到的一個傾向，其特點一是在傳神的過程中忽視事實，二是在追求文字美的時候忽視真正的傳神。 (p.39)

我們常說好的翻譯應該讀起來不像翻譯。但是「讀起來不像翻譯」的作品，如果沒有起到翻譯應做的傳遞正確信息的作用，還能算是好翻譯麼？這正是問題的核心所在。 (p.39)

只要承認翻譯的目的是給別人看或聽的，就不能不同意「信」和「順」二者之間不但沒有不可克服的矛盾，而且是必須共同存在的條件，是一個統一體的兩面。 (p.42)

感想

我是個半路出家的業餘譯者，翻譯對象也只限定在「硬梆梆」的軟體開發類書籍，不過，我相信多了解一些翻譯理論，對於從事翻譯工作還是很有幫助的。本書除了闡述等效翻譯理論，也有提到譯者經常面臨的困境以及常犯的毛病，與自己的翻譯經驗（雖然很貧乏）對照之下，確實也得到一些印證和警惕。讀完本書，翻譯時在兩種語言文字進出之間的拿捏，自覺也有了更加明確的準則。

值得一提的是，譯家馮亦代先生曾對作者翻譯的《尤里西斯》提出多處批評，而本書最後也收錄了金教授對這些抨擊的回應文。金教授不僅逐條比對不同譯法，也詳細說明了當時為什麼會這麼譯，馮先生的批評又是錯在哪裡。我們不僅能夠從這篇回應文看到等效翻譯理論的明證，也看到一位翻譯名家的風範，例如文中有一段話：

「我感謝馮先生費心寫這兩篇文章，尤其是他用對比方法，使我有機會比較深入地談一談我的具體原則和思路，便於廣大的讀者和專家看清問題所在，給我更具體的幫助。」

這無疑是誠心的感謝，因為透過金教授的回應，確實充分展現了等效理論的實用性，以及他在翻譯《尤里西斯》時所秉持的認真態度。然而，馮亦代的譯評卻幾乎都不正確且不負責任，例如馮的譯評開頭便說他沒有對照原文書，原來他是光憑另一個譯本的比較，就認定金教授的譯本在十頁內有 36 處誤譯。

面對這種批評，金教授的回應是不慍不火，不卑不亢，實在令人欽佩。然而，轉念一想，自己從前也曾批評過別人的翻譯，又有多少是未經深思熟慮和查證就貼在部落格上的呢？想來真是汗顏。網路上也不乏因為翻譯而引發的爭論（例如這裡和這裡），在評論別人的譯作時，又怎麼能不多加謹慎呢？！

最後，引用電影《料理鼠王》片尾的一句話，藉以警惕自己：

In many ways, the work of a critic is easy. We risk very little yet enjoy a position over those who offer up their work and their selves to our judgment. We thrive on negative criticism, which is fun to write and to read. But the bitter truth we critics must face, is that in the grand scheme of things, the average piece of junk is more meaningful than our criticism designating it so.

「評論家的工作很輕鬆，我們不必冒什麼風險，卻擁有評論他人及其作品的權力。我們吹毛求疵批評別人，樂此不疲。但坦白說，大部分被罵得一文不值的作品都比我們的評論有價值。」

在原文書中碰到 orthogonal 時，總是會讓我停下來，想想作者要表達的意思到底是什麼。我在 Collins COBUILD Advanced Leaner's Dictionary 2006 和 Longman Dictionary of Contemporary English 4th Edition 都查不到這個單字，但是分別在以下網路資源中找到這個單字的中文翻譯：

• 顏元叔網路辭典：(幾何)長方形。
• Yahoo! 奇摩字典：【數】直角的;矩形的。
• 中文維基百科：正交。

另外，從 Google 也可以查到一堆採用 "正交" 作為對應中文的例子。

試將這些查到的中文詞彙套用到以下例句：

Alternately, we can cut across the system in an entirely orthogonal way.
譯：我們還可以用另一種完全正交（矩形、直角）的方式切割系統。

However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views.
譯：然而，事實上我們無法同時用兩種方式建構系統，因為它們是完全正交（矩形、直角）的觀點。

上述例句摘自 Grady Booch 的 Object-Oriented Analysis and Design with Applications 3rd Edition，前後文主要是在討論演算法分解（功能分解）與物件導向分解這兩種分割系統的方式。即使有完整的上下文，看了這種直接對號入座的譯法恐怕也是讓人摸不著頭腦。

中文的資源不夠用，最好的辦法就是找原文的解釋了。以下解釋摘自英文維基百科（在該字的 Derived Meanings 小節）：

Orthogonality is a system design property facilitating feasibility and compactness of complex designs. Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system. The emergent behavior of a system consisting of components should be controlled strictly by formal definitions of its logic and not by side effects resulting from poor integration, i.e. non-orthogonal design of modules and interfaces.

以下則是 SearchStorage.com 的解釋：

In geometry, orthogonal means "involving right angles" (from Greek ortho, meaning right, and gon meaning angled). The term has been extended to general use, meaning the characteristic of being independent (relative to something else). It also can mean: non-redundant, non-overlapping, or irrelevant. In computer terminology, something - such as a programming language or a data object - is orthogonal if it can be used without consideration as to how its use will affect something else.

從以上的解釋可以發現，orthogonal 有許多衍生意義，而用在前面舉的兩個例句時，比較適合的翻譯應為「無關」、「互不影響」（「正交」一詞反而讓人覺得涉及的事物彼此有關、有交集）。根據這些線索，試將前二例句重譯如下：

Alternately, we can cut across the system in an entirely orthogonal way.
譯：我們還可以用另一種截然不同的方式切割系統。

However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views.
譯：然而，事實上我們無法同時用兩種方式建構系統，因為它們是完全不同的觀點。

這裡我將 orthogonal 均譯為「不同的」，主要是希望在不離原意太遠的前提下，讓句子讀起來更順。