書摘:《研究科學的第一步》(Advice for a Young Investigator)

4/17/2008
中文書名:研究科學的第一步
英文書名:Advice for a Young Investigator
作者:Santiago Ramon y Cajal
翻譯:程樹德

「如果當初進入研究所時就看過這本書,或許可以少走一些冤枉路。」是我讀這本書的時候,心頭偶爾浮現的想法。書中提到許多做研究應有的態度跟觀念,但不會讓人有喋喋不休、令人生厭的感覺。作者就像和藹的長者,對後進不厭其煩地提點、說明,深怕新手走岔了路。

不過,中文版有不少句子讀起來有些彆扭,例如:

「偉人有時是天才,偶爾是兒童,可是永遠不完全。」 (p.53)
「如果我的努力只是添加一點小細節,那到底會有什麼幫忙呢?」 (p.58)


很少看到或聽到「會有什麼幫忙」這種說法,「會有什麼幫助」不是很平常的口語嗎?

「很明顯,這種冷酷的儀器狂,不能對任何人有好處,對自己也是個大傷害。」 (p.154)

「不能對任何人有好處」的英文可能是 Couldn't benefit...。一般我們會說:「對任何人都沒好處。」

潘震澤先生也針對此書寫了一篇比較專業的譯評,但這篇譯評僅針對本書的引言部份做討論,未就各章的內容加以評析。

雖然有些缺點,但本書依然值得推薦給有心做研究的人(要是出版社能重新校對潤飾,發行第二版就更好了)。

以下是一些書摘和隨手筆記:

=================<>===================

第一章:引言

我們基本上沒辦法透視自然現象的真理,或者自然現象的本質。因此,我們的立場不只是假設自己無知,甚至無可避免的要假設自然是不可知的,宇宙的「本質」並不是我們科學家所能夠知道的。......諸如生命的起源?物質到底是什麼東西?運動到底是怎麼產生的?人的自覺意識如何出現?我們必須承認,人類的心智,基本上沒辦法解決這些艱難的問題......大腦的產生,並非讓我們發現事物的終極原因,反之,要讓我們能夠決定事物的近因,以及事物之間不變的關係。我這樣講,似乎要限制人的心智能力。其實,人的心智能力所能達成的工作,已經極其龐大了。我們人類的頭腦既能讓我們了解世界的能力,這樣就已經產生了極大優勢,讓我們可以改造環境,改造世界,來改進人類的生活。因此,縱使不知道事物的本質,我們能夠做的,還是很多呢。 (p.42)

我們該知道,其實最傑出的發現,根本不依靠邏輯的演繹關係,學者完全不需要學任何邏輯....因此,與其看空洞的研究方法,還不如讀偉大的科學或開拓者的作品,例如:伽利略、克卜勒、牛頓......。 (p.45)

注:如同讀書要讀原典,會比看那些後來延伸詮釋的書籍更有價值,更能啟發思考(還是原汁原味好)。

叔本華在《意志與表象的世界》 (The World as Will and as Representation) 這本書裡面談到邏輯時,他說:「最好的邏輯,就是在認真探究時,應該把全部邏輯規則拋棄。」他又說:「想要在實際的研究裡面運用邏輯,就像是學走路時,先研究力學的定律一樣。」 (p.49)

第二章:坑殺新手的陷阱

我認為聰明的年輕人,其心中最不幸的觀念,就是對偉大科學家過度地崇拜。另一個影響年輕人的大問題,就是認為很多問題無法被我們解決,甚至連攻擊它都沒有辦法,因為年輕人自認能力不足。以上是年輕人最重要的錯誤觀念。......新手閱讀天才所寫的作品時,可能會迷戀於他優雅的文筆風格,以及談理論時漂亮的戲法,如果新手能夠逃脫這天才的魔力,走進實驗室裡去,設法確定前人的觀察是否真確,檢驗這麼有趣的觀念是否能夠重複實現,那麼,新手就能逐漸怯除他對英雄的崇拜,自信心也就逐漸產生。 (p.53)

我們不要在偉人的面前,自覺卑微自覺渺小,我們要讓新手瞭解一個很殘酷、可是無可避免的定律,那就是:新手們的命運,新手們的事業,如果想要飛黃騰達的時候,那一定要能夠破壞跟減損偉人之聲望方能達成。 (p.55)

法國哲學家盧梭講的尖刻話很能令人傷心,可是卻很真實:「世上不可能找到一個有智慧的人,他不努力去吹捧自己的謊言,倒去鼓吹別人所發現的真理。」(p.56)

注:「很能令人傷心」......試改譯成這樣看看:法國哲學家盧梭說過一句尖刻話:「世上沒有一個智者不努力吹捧自己的謊言,反倒去鼓吹別人發現的真理。」這話雖令人傷心,卻很真實。

剛畢業的學子,腦子裡有另一個錯誤的觀念,他們說:「各門科學最重要的東西都已經被發現了,都已經被鑽研得很清楚了,如果我的努力只是添加一點小細節,那到底會有什麼幫忙呢?聰明努力的觀察家,已經在麥田裡把麥子都收割了,我是否只能做拾穗的工作?......」這說法的真相,其實是「怠惰」偽裝成「謙虛」,「懶散」偽裝成「卑微」。 (p.58)


我可以很公平地這樣說,一般來講,沒有任何科學問題是已經被做得光光的,而不能再重新去探討。相反的,人已經給問題搞得筋疲力竭了所以不願再繼續去探討,不願再去深究。......其實,我們之知識是非常片段而瑣碎,因此,甚至最被精深探討過的課題,裡面仍有很多未知的新發現。 (p.60)

注:「我們之知識」==> 「我們的知識 」

如果,新手願意蒐集更精細的資料,從事這些精明睿智的開創性科學家所不願做的事,那麼我可以保證,在新手尋找瑣碎的細節時,最後可以訓練他的分析能力,可以讓他有強之分析力,以及觀察力,用這兩種力量及他的細密證據,可以成功地解決重要的問題。......還有,我們一定要記得,我們人所認為的所謂重要不重要,偉大或者渺小,其實是基於我們人類觀點所產生的錯誤,在自然裡面沒有高等或低等,沒有優秀或惡劣,也沒有主要或次要的關係。 (p.61)

注意細節以及重視方法跟技術,這兩件事有極其重大深遠的影響。 (p.62)

因之總結來說,世上沒有小問題。表面上看起來很小的問題,其實是我們所不了解的大問題,真的!宇宙內並沒有知識份子所看不起的小細節,有的只是頭腦不靈光的學者,他們渺小的智能,沒辦法參透這無窮無盡的宇宙.......在考慮大自然運作的機制中,淺薄的人把某些部份看作重要,把某些當作次要,可是對有創見的思想家而言,他把大自然的事物區分為已經瞭解的,或者不太瞭解的,而不管這些東西是否大小,是否對人類有立即的用途,沒有人能預測某件事物在未來有多重要。 (p.63--64)

我們攻擊自然界各問題時,只考慮這問題是否值得我們去研究,不要考慮到這問題是否有應用價值,考慮應用價值時,會干擾我們的專注力,甚至減弱我們的分析力。 (6)

有些人要解釋他為什麼失敗又沮喪,就說他沒有做科學的能力。......只要學生相信,好的教育仍然能夠創造人才,只要他能夠灌注很長的時間,來分析一個特定的科學題目,甚至普通心智能力的學生,都可以產生一些新成果,都可以享受科學的樂趣。......如果缺乏天生的心智能力,其實可以用「努力工作」跟「專心致志」來彌補。我們可以說,工作可以替代才能,甚至可以這樣說:工作可以創造才能。 (p.69--72)

第三章:需要何種心智能力?

當新手第一次讀經典名著的時候,並不是每一個人都能發現書中的缺陷跟錯誤,可是,如果對名著太過於尊敬,就像是所有激情狀態一樣,都能防止頭腦對之進行批判性評價,如果讀了一次感覺到頭腦很累,沒辦法領悟,也沒辦法完全吸收,那麼休息幾天吧!幾天後用冷靜的頭腦跟清醒的判斷力,再讀第二次或第三次,然後逐漸地,書中的缺陷就變得愈來愈明顯,而裡面不合邏輯或是錯誤的地方,也被揭發出來;看起來漂亮的假設,失去了它的權威性,揭發出它們非常不穩固的根基,我們終於能不被他的文采所迷惑,換言之,我們終於能逐漸瞭解,對這部經典作品,吾人不再是盲目的崇拜者,而是這本書精明的裁判,這個時候,研究就可以開始了,可以用更好的假設取代作者原有的假設,讓書中每一件事情都經過你嚴厲的批判。

沒有自信心的人,不知道專心致志的神妙力量,這一種大腦的偏極化也就是涉及你對事物的全盤感受,能夠讓判斷變得更精緻,能夠豐富你的分析能力,也能夠刺激建設性的想像,而且因為把全部的理性及推理力量放在問題上面,使人能夠發覺以前看不到的事物間的微妙關係。......長久時間的「專注」能夠讓我們的心靈在最複雜的問題中,也能夠感覺到一絲光線。

第四章:生物研究的新手須知

法國科學家拉普拉斯(Laplace)曾經指出:「所謂發現這種事,其實是把以前不相關的兩個觀念連在一起而已。」 (p.113)

一旦一個人想要得到百科全書似的廣博知識,那他的研究立刻就會觸礁,因為一個缺乏秩序的心靈,會想要不停的獲取知識,而這種心靈是好動的,沒有紀律,而且不能專心。......擁有這種心靈的人,可以變成一個偉大的作家,非常令人快樂的閒談家,甚至是一個有名的演講家,可是這種人不可能在科學上有大發現。 (p.117)
=====================================
購買本書

書摘:戴明的新經濟觀(The New Economics)

4/17/2008
在翻譯《軟體工程與 Microsoft Visual Studio Team System》這本書的過程當中,除了加深我對軟體工程與 Visual Studio Team System 的瞭解,另一個讓我收獲很多的,是每一章最後附的參考文獻。作者 Sam Guckenheimer 在軟體開發方面的經驗非常豐富,而從他引用的相關書籍和文獻來看,可以發現他不僅是軟體工程與 VSTS 的專家,對其他知識領域也涉獵廣博,包括心理學、科技管理、研究製造、經濟學......等等。透過這些參考文獻,也讓我發現一些頗有意思的書。舉例來說,書中對於一些專案管理和變異(variation)的觀念,主要是源自《戴明的新經濟觀》書中的理論。我也挺喜歡這本書,這裡就做個簡短的書摘供大家參考(您也可以參考網路上的另一篇書摘)。

書名:戴明的新經濟觀
作者:W. Edwards Deming
譯者:戴久永
出版:天下文化

---------------< 書摘開始 >-----------------------------------------------

美國人的問題在於教育以及如何發展重視學習的文化。(p.8)

注:台灣也是啊!Orz

顧客不會發明

大家都說要符合顧客的期望。事實上,顧客的期望乃是由你與你的競爭對手所塑造,顧客學得很快。(p.9)

注:例如,是顧客要求軟體廠商發展即時通訊軟體,還是廠商先開發出來,人們覺得好用才開始普及?

高階管理者該為品質負責

公司產品的品質,不可能高於高階管理者所設定的品質水準。(p.20)

注:如果主事者與開發人員在軟體開發方面的理念不一致,或者不了解開發人員為何要這樣做,以及那樣做對品質有何影響的時候,開發人員恐怕很難得到上頭的認同與許可,去做他們認為該做的事。因此,主事者必須對軟體開發的本質、概念、與實務作法有一定程度的了解,才能將開發的方向導正,並確保軟體的品質。所以,結論就是.....不只是開發團隊成員,各位現任(或未來將升任)的軟體公司主管、CIO、專案經理們, 請務必也買一本《軟體工程與 Microsoft Visual Studio Team System》回去看呀! (shame on me ^_^ )

廢除考績制度

將員工排等級,正顯示了管理者的失職。在考績制度下,所有人的目標都是討好上司。結果將會導致士氣低落,品質受損。因此把員工評等分級,分門別類,對於改善工作並沒有任何幫助。

錯誤的企管教育-數字化目標與結果導向管理

數字化目標會導致扭曲和作假,尤其是當系統根本無力達到目標的時候,更有此可能。每個人都會設法達成被分配到的配額(目標),但卻並不對由此所導致的損失負責。(p.37)

注:《軟體工程與 Microsoft Visual Studio Team System》書中也有舉出一些類似的例子,像是:程式設計師故意埋下很多 bugs,並由自己找出這些 bugs,以達到 bug 發現率的數字化目標。報表上的數字看起來是達到目標了,可是實際的產出和績效卻一點也沒有長進。

管理者其實應該專注於流程的改善,而不是設定數字化目標。(p.38)

採用成果導向的管理,帶來的困擾是更多而非更少。......以成果為導向的管理針對結果採取行動,也就是認定結果來自特殊原因。其實重要的是針對造成該結果的原因--也就是系統--下功夫。(p.39)

每一位管理者都認為自己是全力以赴。他們確實如此,而這也正是問題所在。他們的「最佳」,是立基於現行的管理系統之下,而這個管理系統,正如我們前面所指出,會引起難以估算的巨大損失。如果沒有外來知識的協助,管理者的努力只會把我們目前所陷入的坑愈挖愈深。(p.43)

注:Do the right thing. 往錯的方向努力,只會愈陷愈深,導致更大的災難。然而系統本身無法察覺自己的問題,需藉由外來知識(即作者專章介紹的淵博知識體系)的協助才能導正方向。

建立系統的觀念

如果說金字塔型的組織圖真的傳遞了什麼訊息給員工的話,那就是:每個人首要的工作就是取悅上司(以便得到好的考績)。......金字塔的組織圖確實具有破壞系統的作用,因為它促使組織的部門各自為政,形成個別的利潤中心,以致破壞了系統。(p.70)

讓人人了解自己的貢獻

「工作說明」(job description)不是描述動作、做這個、做那個、這樣做、那樣做,還應該增加說明工作的用處,以及工作對整個系統目標的貢獻。(p.73)

內在動機 v.s. 外在動機

將個人、小組、部門、地區排等級,並發獎金給排名在前者,將會打擊所有相關人員的士氣,包括受獎者在內。......無論是小孩或大人,如果必須一直關心自己的表現,以爭取好成績和獎狀,就不能享受學習的樂趣。.....如果必須與他人爭排名,沒有人能夠享受工作樂趣。 (p.122)

注:薪水固然重要,但興趣與工作樂趣更重要。若僅僅為了高薪而跳槽,很可能因此失去了一個很好的工作環境與發揮個人專長的舞台。

人員的管理

不准你爭辯的老闆,不值得你替他賣命。(p.139)

為求縮短開發時間,一般的作法是倉促地完成開發,結果卻發現個別部份無法組合起來,或是突然有更新更優秀的設計點子出現。於是一切再回到原點,重新開始。結果浪費時間,成本提高,最終產品也不如預期。 (p.152)

縮短開發時間的秘訣,在於多下一點功夫在最初的階段上,同時要研究階段間的相互影響。在愈早階段花愈多的努力,所獲得的利益會愈大。 (p.152)


注:軟體開發也是如此。倒不是說我們應該在初期就過度地分析或做過多的前置設計 (up-front design),而是指在初期就應該審慎規劃、分析主要風險、以及做好架構面的考量。把一開始的路鋪好,以後會走得更順。
---------------< 書摘結束 >-----------------------------------------------
購買本書

時程膽小雞

4/17/2008
雞的下場軟體工程與 VSTS》的第九章是在討論專案開發時經常碰到的疑難雜症,以及如何利用 VSTS 的統計報告來發現、診斷這些問題。其中談到一個挺有意思的術語:「時程膽小雞」(schedule chicken),它指的是開發人員因為無法承受時程的壓力,而做出一些敷衍、耍小手段等扭曲的行為,好讓自己的工作看起來已經達到預定進度了。

參與過團隊開發的讀者也許也曾碰過「時程膽小雞」的情形。比如說,在開專案進度會議的時候,可能每個人都說自己的進度沒有落後,其實大家都在等別人承認進度落後。更誇張的,可能還有人會故作姿態:「如果你那邊還要再一兩個星期才能完成,我這邊可以等,我沒問題啦!」如果你回答兩天內就可以完成,他可能就開始緊張了。

再舉一個從別處看到的「時程膽小雞」例子。假設程式經理宣佈某一天必須實施「程式碼凍結」(code freezing),從那天開始不能再增加新的程式,只允許修改有問題的程式碼。於是程式設計師們基於畏懼時程的心理,就算到時候無法如期完成預定進度,還是會在程式碼凍結日的前一天簽入(check-in)所有的程式碼,但這些程式碼可能都沒經過測試、甚至無法執行或建置(管它的,先簽入再說,反正凍結之後是允許修改的)。

個人以為,如果程式設計師沒有勇氣抵抗時程的壓力,而採用敷衍了事或吹噓進度的作法,最後吃虧的還是自己,當然團隊也是。不過話說回來,如果我上班時偷雞摸魚,四處上網看"風景圖"、聊八卦,等到工作時程快要到 deadline 時才開始處理正事,這種情況可就不能說自己是在發揮抵抗時程壓力的勇氣了。

p.s. 以上的例子取自這篇部落格文章:Schedule Game #1: Schedule Chicken

公開透明的專案開發狀態

4/17/2008
上次簡單介紹了《軟體工程與 VSTS》的中心思想,這回我想和大家分享另一個貫穿本書的要旨--公開透明的專案開發狀態。

當我在閱讀和翻譯這本書時,作者在書中舉的一些例子或實務建議經常讓我聯想到過去的專案開發經驗,「公開透明的專案開發狀態」就是其中一個。這聽起來似乎不是什麼了不得的新概念,可是就像作者在書中引述佛洛伊德的話:「天經地義的事情反而沒人會把它說清楚、講明白。」這看似再明白不過的道理,不知有多少人認真思考過並付諸實行?

如果你是一名程式設計師,在開發專案時,是否曾有一種見樹不見林的感覺?這種感覺就好像走在森林裡,你知道自己正往哪個方向走(或者其實是別人告訴你該往哪裡走),可是卻不知道路還有多遠、最終目的長什麼樣子。如果是這樣,你還會積極前進嗎?如果你是 CIO、PM、或 team leader,你希望只有自己能掌握專案的完整資訊嗎?你的管理風格是傾向讓小組成員聽命行事,還是讓他們隨時了解專案的狀態、主動積極解決專案的問題?

考慮另一種情況,當你把客戶反應的問題逐一測試並確認之後,交給程式開發人員處理,你是否希望能隨時知道那些問題的處理進度(以免客戶問你時支支吾吾無言以對),但是又不想一直去叨擾開發人員?如果你是 PM,你是否希望能夠隨時知道目前的專案開發進度?在哪個環節出現瓶頸而拖慢開發速度?誰的工作負擔比較輕可以來支援這個某項任務?......

以上問題的答案,就是公開透明的專案開發狀態。

讓所有成員都能看到專案的所有開發狀態,不僅能夠促進專案成員主動積極的工作態度,同時也能提高團隊合作的效率。如此,團隊的運作將不再是檯面下的動作(這裡並不全然指"小動作"),而是完全的開誠佈公,從而建立一個向心力強、彼此互信的團隊。確實,互相信賴真的是維繫團隊成員的關鍵。試想,少了信賴基礎,團隊成員彼此相互猜忌,工作效率怎麼會好?(為什麼我的工作比較多?為什麼反映給他的 bug 都遲遲未解?到底專案進度落後多少?待會兒的檢討會議要怎樣避免被他人攻擊....)

了解公開透明的重要性之後,接下來的問題便是:How?我們要如何實現這個目標?

VSTS 把專案所有的工作項目都儲存在一個共用的產品工作清單(product backlog)裡面,所有的專案成員都能透過 VSTS 用戶端工具(包括 Team Explorer、Excel、Project...)存取這份工作清單的內容和狀態。註:所謂的工作項目(work items),包括 bug、風險、要完成的軟體功能、以及其他開發相關的工作。

不僅如此,VSTS 能夠維護開發流程中的各個工作項目之間的關連性,同時會把工作項目的狀態與歷史紀錄保存在度量資訊倉儲裡面,以產生各種專案開發狀態的統計圖表。這樣一來,所有團隊成員都能隨時檢視、發現問題、並主動解決問題--換句話說,把軟體開發的整個過程都透明化了!

附帶一提,SCRUM 軟體開發流程是單一 product backlog 概念的先驅,如果您對它有興趣,可以到這個網站逛逛:http://www.mountaingoatsoftware.com/scrum/

如果對敏捷測試有興趣,這裡有教學課程可以參考:Agile Testing Tutorial

增值與減工思維模式(Value-up and Work-down Paradigm)

4/17/2008
軟體工程與 Microsoft Visual Studio Team System》的第一章是「增值思維模式」,這次就先和大家分享個人對此主題的了解與心得。

以往在開發專案時,大都是先與客戶(或主要的利害關係人)討論出專案的目標與粗略的範圍(scope),然後透過與使用者訪談的程序,訂出比較細的專案範圍與功能需求,最後得到一份完整的功能清單(至少當時雙方認為應該夠完整了)。這份功能清單將影響往後的開發計畫決策,包括人力、時間等資源的安排,團隊也是以完成這份清單中所有的功能為目標。當開發團隊把功能清單裏的項目全部完成,就視為這個專案已經完成了。

但問題是,需求往往在一開始並不是那麼明顯。許多時候,使用者都是在看到實際執行的軟體畫面時,心中才開始浮現它所想要的軟體應該長什麼樣子。可是當初卻做了一堆計畫,團隊成員、時間也都安排好了,怎麼辦?比較好的情況是,雙方各讓一步,若需求有大幅的變動(例如增加新的子系統)就延長交貨期限,要不然就增加預算或人力。可是結果到最後往往雙方都不滿意,因為需求範圍的一再改變與擴大,將使開發團隊失去耐心,最後只好以合約書的內容拒絕變更需求;客戶也一樣不滿,因為他花了錢卻沒有得到他真正想要的東西。

寫到這裡,突然想到有一種軟體生命週期是這樣的(摘自《我懂了!專案管理》):

計劃開始 -> 火熱投入 -> 理想破滅 -> 一片混亂 -> 找代罪羔羊 -> 處罰無辜的人 -> 無功之人晉升 -> 限定各項要求

我想許多人應該也有類似的經驗吧(也許沒那麼誇張),我們總是感嘆:為什麼軟體這麼難做?!

前面舉的例子,多少都與需求蒐集的品質有關,但如果我們不試著從問題的本質出發,思考原本的觀念與作法有何不當之處,那麼不管需求文件寫得多詳細、採用什麼開發工具、什麼軟體平台,恐怕最後都會面臨相同的困境。

為了描述以上的問題,並指出解決問題的方向,《軟體工程與 Microsoft Visual Studio Team System》的作者在書中自創了兩個新名詞:value-up 與 work-down,它們分別代表了不同的軟體開發思維模式 (paradigm)。

Work-down 代表過去的軟體開發思維模式,也就是類似前面舉的例子,先列出要完成的功能清單,然後每當完成了一件工作,就把該工作項目從清單中移除或槓掉。等到工作清單裡面的工作都完成了,就代表專案完成了。我在中文版裡面把 work-down paradigm 譯為「減工思維模式」。

相對於「減工思維模式」,是所謂的 value-up paradigm,我在書中譯為「增值思維模式」,它強調的是持續為專案增加新的客戶價值。什麼是顧客價值?講白一點就是客戶想要的、或對他有用的東西。這些客戶價值當然也是根據事前規劃的工作清單所引導,但專案是否完成並不是以清單裏的工作是否做完來決定,而是看專案是否實現了所有的顧客價值 (customer value)。換句話說,這種思維比較站在使用者的立場,認為開發出來的軟體就應該符合使用者的需求。這也正是極致編程(eXtreme Programming,XP)的精神之一--擁抱改變。

可是這麼一來,如果使用者的需求一直變來變去,恐怕沒有一個團隊撐得下去。因此,有了正確的觀念之後,還要配合適當的方法才行。這當中最重要的關鍵,個人以為是反覆與漸進的開發方式--既然軟體的需求一定會改變,那就不要一次定江山;把軟體需求分成幾個小的階段逐次完成,每完成一小步,還可以視情況調整開發方向,對使用者與開發團隊雙方都有好處。這也符合 XP 的精神--邊開車邊調整方向。

可是,有些類型的專案卻不適合這樣做,例如大型的政府標案,這類型的專案通常在一開始就要決定預算和專案範圍,而且以後也不可能更改預算(從其他預算挪用除外)。因此,除非一開始預算就非常充足,否則當使用者提出比較重大的需求變更時,開發團隊通常得根據合約拒絕使用者增加或變更需求。若預算充足,個人比較一廂情願的想法是,開發團隊不用太在意合約裡面的軟體規格,只要 end-user 滿意,實際上還是可以採用增值思維的模式來開發專案,以確保最終的產品符合使用者的需要,我想這才是最重要的吧。

像政府標案這類的軟體專案,通常需要比較正規的、重量級的開發流程,例如 CMMI。相對的,另一種不那麼正式、允許較多彈性的專案,則適用於輕量級的、可機動調整的開發方法,例如 XP。有了正確的觀念與適當的開發方法,如果少了方便的工具,效果也會大打折扣,甚至無法持續下去。因此,Visual Studio Team System 在設計時就考慮到要支援 XP 與 CMMI 這兩種不同「量級」的專案類型,所以預設就提供了 XP 和 CMMI 的開發流程範本,讓團隊能夠以增值方法來開發這兩種類型的專案(當然也支援其他開發流程,你甚至可以自訂流程範本)。至於實務上的要怎麼做,這是本書的其他章節要談的,這次就先聊到這裡吧!

Visual Studio 2008 練功秘笈全系列

4/17/2008
精誠(恆逸)資訊的講師們推出了 Visual Studio 2008 全系列書,預計 3 月 13 日到 3/14 日上市,對研究新技術有興趣或工作上有需要的朋友可以參考看看。

《微軟解決方案框架精要》簡介與試讀章節下載

4/17/2008
書  名:微軟解決方案框架精要-以 MSF 建構成功的解決方案
作  者:Michael S. V. Turner
翻  譯:蔡煥麟
校閱監修:歐宣修、陳盈學、朱子傑、何美玲
出版日期:2007/3/15

簡介

本書是第一本完整介紹 MSF v4 的書籍,內容涵蓋 MSF 的所有基本原則、思維、紀律、與最佳實務,堪稱 MSF 的權威指南。作者本身也是解決方案交付的專家,他在書中提供了實際的範例和個案研究,協助您將這套靈活、彈性的框架套用在任何專案上,以建構成功的技術解決方案。
專案經理固然能從本書獲得啟發,而其他團隊成員若也能了解 MSF 的基本原則與精神,對於凝聚團隊共識,以及彼此的溝通合作也都會有幫助;方法論專家則可以根據團隊和專案的需要,發展出一套以 MSF 為核心理念的開發流程或方法論。


透過本書,您將學習如何:

  • 制定彈性的解決方案交付生命週期
  • 以漸進的方式來定義、設計、建置、穩定化(stabilize)、以及部署符合商業需求的解決方案
  • 建立一個能夠提升團隊效率的動態團隊模型
  • 管理個人、專案團隊、和組織在交付解決方案方面的就緒程度(readiness)
  • 積極降低專案風險
  • 符合發行準則,並確認解決方案已經達成利害關係人的期望和使用者的需求
  • 在專案的每個階段運用治理活動和檢查點(checkpoints)
下載
另外,我將本書所涵蓋的 MSF v4 相關主題整理成 mindmap (見下圖),希望有助於學習和理解。

關於本書的校閱
像這樣一本內容紮實、又包含許多抽象概念的書籍,在翻譯時程緊迫的情況下,如果沒有人幫忙 review,實在很難想像最後的品質會是如何。本書有多位先進參與 review 工作,雖然彼此未曾謀面,但他們卻義務幫了我很多忙。因此,在這裡要再次謝謝他們的協助。特別是歐兄(歐宣修),我是因為翻譯這本書才與他結識,而從他給我的 review 建議中,可以明顯感受到他所付出的心力。不只是感謝,他的專業與細心也讓我打心底佩服。
最後要聲明的是,雖然有這麼多人協助校閱,但由於匆忙付梓,恐仍有疏漏之處。若中文版的內容有任何瑕疵,都是我的責任。讀者如有任何建議、內容勘誤、甚至讀書心得,都歡迎與我聯繫,或在此部落格留言。
閱讀愉快!
到博客來網路書店購買本書

《軟體工程與 VSTS》介紹與試讀章節下載

4/17/2008
書  名:軟體工程與 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)
相關的讀書心得可以到[閱讀筆記]主題區查閱。
對本書的讚美 (Praise for the Book)
「太吸引人了!這本書詳細說明了 VSTS 有哪些功能,以及為甚麼要把這些功能加入 VSTS——這些寶貴資訊只有微軟內部的員工才有辦法提供。也許更重要的,是作者在介紹每一項功能或如何操作的指示時,都會詳細解釋為什麼這些功能對你這麼重要。本書揚棄了以往開發流程的缺點,並取各家所長,指出方法論的未來發展方向,並點出哪些度量資訊能夠用來改良和客製化你在開發專案時採用的方法論。」
  ——Mark Michaelis,《Essential C# 2.0》的作者
「對任何想要使用 Visual Studio Team System 和微軟解決方案架構(Microsoft Solution Framework,MSF)4.0 版的人來說,這本書絕對非讀不可。本書的一個關鍵主題是『敏捷與責任歸屬』,它解釋了軟體開發方法的思維模式轉移至增值(value-up)方法的過程,並說明 Team System 如何支援增值方法。作者以大量的實用範例來說明如何以 VSTS 實踐增值開發方法,而且每個範例都傳達了某些重要的訊息。」
  ——Aaron Kowall,EDS Applications Portfolio Development, Innovation Engineering
「Sam Guckenheimer在公開透明機制方面的先進理念,將徹底改變我們管理軟體專案的方式。不要光只是把 Visual Studio Team System 買回去;你應該要學習如何充分利用它來改變我們的開發習慣並創造價值。Sam 會告訴你該怎麼做。」
  ——David J. Anderson,《Agile Management for Software Engineering》的作者
「Sam 把 Visual Studio Team System 的精華都放到這 250 頁當中了。如果你的工作與軟體開發有關——不論是開發人員、測試人員、專案經理、架構師、還是資訊長(CIO)——你的團隊都應該要人手一本。本書拉近了現代軟體工程理論與開發實務的距離,並以清晰易懂的範例說明如何利用 Team System 實踐它們。這本書和之前的一些書籍最大的不同點,就是它理論與實務並重。不論你是否已經在使用 VSTS、正在考慮是否採用、或者只是想利用它來提高生產力和輔助企業校準(business alignment),你都能在書中發現許多有用的資訊與見解。這是一本非常有趣、實用、而且容易閱讀的書籍。」
  ——Rick LaPlante,Microsoft Visual Studio Team System 部門總經理
「Sam Guckenheimer 是軟體測試社群公認的專家與良師,很高興看到他終於出書了,而且這本書還清楚闡明了他在軟體工程方面的理念。
  ——Cem Kaner,佛羅里達理工學院,軟體工程教授,法學與哲學博士;《Lessons Learned in Software Testing》與《Testing Computer Software》的主要作者
「在這本書裡面,Sam Guckenheimer 捕捉了 Team System 與增值軟體開發思維模式的完整意涵。此思維模式和以往那種計算工作做完多少的方式截然不同,其核心概念在於測量已交付的客戶價值,Team Systsm 就是依循此理念所設計出來的實作品。你會發現 Team System 為專案提供了前所未有的透明度,此透明度將能大幅改善團隊成員的互動與專案的可預測性。更重要的是,它並未因此而增加團隊成員的負擔和工作時間。閱讀本書將能讓你體會 Team System 的完整設計理念與它所帶來的增值軟體開發良性循環的好處。」
  ——Rob Caron,內容架構師,微軟;《Team System Nexus》的作者
「Sam Guckenheimer 堪稱是技術的外交官。在以機動性見長的敏捷學派游擊隊與 CMMI 正規軍對壘的世界中,Sam 提供了一個讓兩者和平共存的方法。此空前創舉使它成為第一本、也是最重要的一本軟體工程書籍。在討論一些像是規劃、撰寫文件、企業治理、稽核、與組織等焦點議題時,Sam 同時展示了敏捷與正規的實務作法,並且說明採用它們的最佳條件。即使書中的範例主要是以 VSTS 來說明,但其理念與指引卻是放諸四海皆準的。本書是寫給專案的所有角色成員,不論他們在實務上選擇的是重量級還是輕量級的方法,Sam 都提供了實用的建議。本書內容新穎且符合時代潮流,其中還論及服務導向架構、測試驅動開發、以及使用者介面社群所發展出來的一些設計技巧。Sam 的這本書可說是軟體界的超優質著作。」
  ——Bill Curtis 博士,chief process officer,Borland Software Corporation;《People Capability Maturity Model》的主要作者
「Sam Guckenheimer 是真正的使用者代言人。他透過 Team System 向世人展示一個提供流程自動化、以度量資訊輔助管理、與幾乎完全公開透明的軟體開發平台。他展現了一種既實用又容易達成的軟體工程方法,同時,他也並未忽略我們有許多亟需解決的棘手問題。」
  ——James Behling,Accenture Delivery Methods 方法論的主架構師,Accenture
「Sam Guckenheimer 和我總是以同樣的方式來支援程式開發小組與作業小組,Sam 的這本書提供一種容易理解、以流程為中心的方法,實現了 MSF 與 Visual Studio Team Sytem 所倡導的軟體開發最佳實務。『瀑布式模型』業已失敗,但這本書仍可以指引你利用 Visual Studio Team System 與恰好足夠達成任務的流程邁向快速開發的康莊大道。」
  ——Brian White,資深產品經理,iConclude, Inc.,《Software Configuration Management Strategies》與《Rational ClearCase: A Practical Introduction》的作者
「透明化是現代敏捷開發環境的關鍵要素。Sam 一直以來都倡導以工具來協助建立完整與透明的整體架構,好讓它們能同時適用於敏捷專案和大型的團隊。一個彼此信任的環境加上敏捷方法的實踐,將能造就更具生產力的開發團隊。要製作像是專案開發速度這類的統計報告已經是輕而易舉的事。現在,所有團隊成員——包括商業分析師、架構師、與測試人員,都能共同參與敏捷開發流程了。」
  ——Granville “Randy” Miller, 《A Practical Guide to eXtreme Programming》與
《Advanced Use Case Modeling》的共同作者
「你能想像一個供軟體工程使用的企業流程再造(Business Process Re-engineering,BPR)工具嗎?一個真的能夠幫助 IT 產業更加精實的工具?這就是這本書所要談的!它是一道通向軟體工程新世紀的大門,進入此門將令你大開眼界。本書要處理的議題很單純,就是:VSTS 能否將我們的 IT 產業從原本工匠藝術成分佔多數的情況變得更科學一些?Sam Guckenheimer 不僅解釋了為什麼這點非常重要,他還提供許多實用的小秘訣,告訴你如何能在不增加人工負擔的形況下提高開發團隊的生產力與效率。
  ——Francis T. Delgado,資深程式經理,Avanade, Inc.

技術提供:Blogger.
回頂端⬆️