同事好奇重構的決定是否有客觀的標準，同人表示這部分多半還是個人主觀的經驗居多。在同事後來開車載我回台北的路上，我們再次談到決定重構的時機。同事覺得重構的時機似乎不是一件容易掌握的事，同人進一步地解釋，當時我們在應用程式的開發沒有太多重構的機會最主要的原因，是因為在架構上力求簡潔而單純的設計概念，使得應用程式的開發已經變得很簡單，實在不太需要運用重構用來增加設計的彈性。

趁這個機會，同人向同事強調架構的彈性不應該以需求不得改變為前提，而是要能夠因應「有限度」的變化而發展而不斷地調整及演進。也就是好的架構並非從恒久不變的核心來出發，而是要先去識別出問題的輪廓才找得到適用的核心。同人經常在軟體開發的實務中看到，人們花費了太多的心力來堅持不變的核心，到最後才會發現原來問題是出在自己對問題假設錯誤。

那麼，在軟體開發的過程中，有沒有方法可以避免我們浪費心力在無謂的堅持上，然後用比較簡單而又有效率的方式來完成我們的工作呢？經過與同事上面的對話，同人想到運用到我在分享會中所提到的觀念與實務，可以很輕易地掌握設計演進的節奏。藉由此篇文章分享出來，也算當做同人在 1/9 敏捷開發分享會後的一個註腳吧。

設計演進的基準

軟體開發與其它的產品開發有一個很大的不同，在於軟體通常很難在一開始就定義出明確的需求規格，取而代之的是軟體的發展方向，是用來解決利害關係人在真實世界所面臨的問題。這也是使用 IPO 傳統目標導向來開發軟體經常遇到的困難，當需求的改變不可能不經常發生的時候，軟體開發在品質文化上就不應該採用「照章行事」的模式，而是應該建立具有回饋機制的開發系統來把穩軟體的開發方向。

可以「把穩方向」的軟體開發系統應該具有什麼樣的回饋機制呢？根據溫伯格在他的軟體管理學的觀點，管理者賴以把穩方向的回饋機制，必須是可以直接及穩定的觀察專案目前的狀況、並且比較專案目標與現況的差異、然後以後續如何減少差異為目標改變或調整計劃、最後再根據計劃採取行動來改善專案狀況。其中有關於直接而穩定的觀察，直接代表肉眼可直接觀察的專案結果，穩定代表不同觀察者每次觀察的結果都相同。

相信從以上的觀點，我們可以清楚看到「把穩方向」的品質文化與敏捷開發調整式規劃的關連。規劃的目的不是為了得到一個巨細彌遺的計劃讓我們照表操課，而是指引一個達到目標的概略方向，然後因應專案實際現狀來調整計劃，來使我們不致迷航。基於這樣的觀念，運用 TDD（測試驅動開發）剛好可以提供對專案進行直接及穩定的觀察。

TDD 改變我們對解決問題的假設，不假設用什麼方法來解決問題，而是假設問題情境來思考各種可能的方法，並發展出最經濟的解決方案。假設方法如何解決問題並不是不好，只是這樣很容易讓開發者把他所熟悉的方法當成黃金錘，但最後所開發出來的軟體卻不見得符合使用者實際的需要，而且通常要花費很長的時間才會發現以上的落差，因此不會有足夠時間和資源來符合使用者的需求。

如果能儘早驗證開發的成果是否符合實際的需要，開發者就可以在早期得到使用者的回饋，進而調整努力方向來改善開發成果。傳統的開發方法沒有辦法做到早期回饋，是因為使用者要等到軟體開發出來才能接觸到系統，而且通常他們缺乏軟體開發的專業知識，所以在這之前他們是很難給予開發者有效的回饋。TDD 的開發思維則是促使開發者從思考軟體的使用情境出發，不要太早接觸繁複而細節的設計或實作，而是因應實際的需要而定義出界面規格，然後依據這些規格來決定該如何驗證問題能夠被解決。

因此，TDD 可以直接而穩定的在早期觀察開發狀態，提供設計演進的基準。這樣的基準可以讓開發者在開發過程中，直接面對目標而開發系統而不致迷航。也就是因應現實問題情境的需要，開發者未必有足夠的時間與心力來把設計做到盡善盡美，而是嘗試定義出最主要的功能需求，先採用最簡單的方式來滿足它們，然後再視使用者回饋的實際需要增添或修正功能，必要的時候甚至可以進行重構來維持設計簡潔與完整。換言之，TDD 是用來使開發者面對目標，讓開發範圍不要無謂擴張的一項有力工具。

延緩設計的決策

然而，當開發者採用了 TDD 的開發模式之後，是否正意味著我們儘快將使用者需要的功能實作出來，並不需要進行太多的設計工作，是否代表設計對使用 XP 實務的開發者來說是不重要的呢。但依照同人自身的經驗來看，對於使用 XP 實務的開發者而言，設計並非不重要，而是留下為實際的問題改進設計的彈性。

TDD 並非不做設計，而是把做更周詳的設計的時間延後到可以得到更佳設計決策的時候。或者更根本地來說，TDD 本身就是一種設計手法；而不是因為它以寫測試案例開始，而就把它當做開發的測試過程，這樣的誤解反而違反 TDD 的基本精神。

就設計的觀念來看，設計概念的完整性會直接影響設計的良窳。因此開發者應該盡全力來找出解決問題最重要的概念，同時隱藏或略除不必要的實作細節，來使設計更容易了解與實作。這也就是設計關鍵在於抽象化的道理，但問題是在對問題認識未盡全面以及成本或時程的限制，開發者通常沒辦法在第一時間找出解決問題最適當的核心概念。

因此，TDD 在還沒寫實際的程式之前，先撰寫測試案例。其所關注的問題並不是有效率的測試，而是務實的設計。先以測試案例的方法來識別出系統的大致輪廓，目的是以解決問題為前提，把問題的範圍限制在開發者可以全局掌控的情況下發展解決方案。而不是為了解決方案的堅持而使問題發散，最後反而使問題失焦而終致失控局面的發生。

如此，縱使軟體開發的變化是難以預測的，但只要每一次的變化都可以將廣大的可能性，限制在某一部份，那麼開發者就可以在系統的穩定與彈性之間維持良好的動態平衡；既不會讓需求的變化造成設計的崩壞，也不會因為技術的限制而造成設計的僵化。

穩定的設計可以在環境改變的情況下，不致使系統失去控制，彈性則是可以適應需求的變化而改進系統的設計。期待設計在一開始一次到位，這通常是不切實際的期待，還不如面對現實，先用簡單的方式滿足需求，然後隨著對問題的更深入理解，自然而然地演進出可以適應變化的設計。

這樣的觀念是把軟體開發的焦點放在系統邊界，然後隨著環境變化而逐步演進核心的設計，與傳統機械觀點的隱喻所不同的是，軟體開發不是努力去製造一些東西，而是運用生物演化觀點的隱喻：軟體開發是為了改變一些事情而努力。TDD 與 Refactoring 的搭配，正是促成軟體開發演化出複雜適應性以適應變化的實務方法。它們可用來避免軟體設計求道之過，所謂「道可致而不可求」不去強求而自然得到，才是真正的致呀。

提早整合的行動

其實軟體開發專案要把穩方向是很困難的，溫伯格認為主要的原因多半是管理者介入無效的管理作為；沒辦法掌握好「動作要小，行動要快」的原則，結果更增加專案的複雜度與風險，使得問題更加難以處理。

因此，如果使用 TDD 與 Refactoring 這兩項實務，可以讓我們具體地用測試案例來直接而穩定地觀察開發成果，運用簡單的設計來解決問題，又可以在必要的時候施重構來改善設計，以增加適應變化的彈性。那這樣還有沒有可能沒辦法掌握好設計演進的節奏呢？同人認為唯一的可能就是開發者沒有提早整合的行動，例如沒有在早期接受回饋以調整測試案例與重構，使得行動太慢，動作太大。

為什麼開發者會沒有提早整合呢？理論上，當開發者開發的程式完成 TDD 的測試程式之後，照理要進行清理程式碼的動作。比如說進行重構來去消除程式碼的重覆性或使程式碼看起來更簡潔而易懂。這樣可以讓程式碼在每一次的修正之後，都還是最乾淨的情況下，所以是不大可能會增加程式碼複雜度而造成未來難以維護的問題。

然而，在考量專案實際的問題下，開發者不見得每一次都會有足夠的時間來整理他的程式碼，使之形成良好的程式寫作風格與結構。而且管理者也很難知道開發者到有沒有力行這樣的原則，除非能夠對每一支程式來進行 Peer Review，否則只有「完成功能之後必須清理程式碼」的說法，而沒有為提昇程式碼品質而在每支程式交付時，提供改善回饋的具體措施，對專案其實並沒有太大的助益。

可能有人會認為搭檔編程的實務，就是讓每一次的程式開發都提供回饋。基本上同人並不反對這樣的說法，但要這樣做必須注意開發團隊的文化是否能夠支持這樣的做法。

同人以前曾有專案成員調動到使用搭檔編程的專案團隊，雖然看起來搭檔編程似乎讓她能力有所成長，但我也發現到她也出現適應不良的現象而心生抗拒，而當同人與他當時的主管當時的關心，也很難讓他願意分享自己的心情。由此看來，似乎還是有人習慣自己一個人寫程式，而不喜歡由兩個人共同開發一支程式，而且開發資源的分配者也不見得能夠支持這樣的觀念。

當然，要針對每一支程式做到 Peer Review，在實務上還是有很大的困難的。同人認為問題並不是 review code 要花費多少時間，而是專案需不需要針對程式碼進行儘早的回饋，以在最適當的時機採取最適當的行動？這其實是取決於專案願意花費多大的代價來提昇軟體的品質，不然當品質不合乎需求時，專案所節省下來的預防與檢驗成本將會為造成更大的失敗成本。

要落實提早整合的行動，專案團隊每天早上的 Daily stand-up 會議與採用 Daily build 持續整合的機制，是讓開發團隊的反應能力可以「與時俱進」的回饋活動。就像同人在分享會所分享的實務，在 Daily stand-up 會議得到開發實際碰到的問題，其實是幫我們識別關鍵設計概念的機會。由於過去問題尚未出現或對它們還不太明瞭，所以我們不需要或沒辦法進行設計的深入考量。而在 Daily stand-up 會議中，我們可以及時得到用來演進設計的資訊，並討論如何在後續的計劃中調整設計。

至於 Daily build，每天都會整合出可以實際運作的軟體。在 build 軟體的過程中，會自動執行 TDD 的自動化測試，以確保系統功能都是正常的。如果在 build 的過程中發生問題，馬上會立即通知相關的開發者立即解決問題。這樣可以在每天都讓每個開發小組都能密切地保持緊密的溝通與整合，發現問題立即處理而不需要等問題擴大之後才動大刀。

Daily stand-up 會議與 Daily build 的活動，讓每天都持續溝通與持續整合，每次都讓專案都朝向目標前進一小步，更重要的是，讓成員與時俱進地掌握設計演進的節奏！

前一陣子有兩個與資訊系統失常有關，而且眾所矚目的新聞事件，也就是戴爾電腦網路購物系統與台北捷運內湖線的系統異常。相信很多人都認為這兩個系統會發生系統異常相當離譜，在系統上線之後才發現系統無法正常運作，造成系統使用者的困擾，同時也會讓人對系統可靠度與穩定度失去信心，而增加系統的失敗成本。

雖然平心而論，想要事前預料系統可能發生的問題，並加以預防或因應其實並不容易，因為開發系統，尤其是軟體開發常會碰到事先難以預料的問題。但如果能在錯誤造成危害之前，就能夠發現問題並採取適當的行動來解決它，應該就能減少系統的失敗成本。因此，看到戴爾與台北捷運內湖線的重大系統異常，讓筆者想探討如何在系統失敗前發現錯誤，以避免系統失敗的巨大損失。

設計不夠好？

戴爾是世界知名的電腦直銷公司，擁有 13 年的網路直銷經驗。對於這種有豐富網路直銷經驗的公司來說，系統連續發生產品標價錯誤的問題，實在是一件令人感到不可思議的事情。在戴爾發生第二次標價錯誤事件之後，筆者聽到有一位工程師出身的朋友指出，戴爾筆記型電腦的標價錯誤，是因為他們的系統設計不良。他依據新聞的報導，對比自己的網站開發經驗，認為可以確定這絕對是設計的問題。研判是促銷資料沒有正確關連產品資料，才會發生這種錯誤。

從戴爾回應外界連續標價錯誤事件的說法，第一次錯誤定位為人為作業疏失，第二次錯誤是因為系統異常。這麼看來朋友的說法似乎有些道理，但從系統開發流程的角度來看，卻讓筆者產生一個疑問。如果是因為設計有問題，應該是可以在系統正式運行前被測試出來，但為什麼要直到錯誤釀成災禍才被使用者發現？朋友表示要做到完整測試系統是很困難的，還不如把系統設計做好，這樣系統自然不會出錯。

在觀念上，我同意朋友的說法，因為好的設計的確可以減少系統發生錯誤的機會。但問題是朋友的想法在實務上卻有操作上的困難。因為設計夠好是很難被清楚定義，尤其是在專案時程及資源有限的情況下，想要設計出可以在各種情況下適用的系統是非常困難的。面對系統運作環境與需求變化無常的情況下，設計通常只是一種權衡與取捨之道；沒有可以解決所有問題的最佳設計，只有針對解決重要問題的最適當設計。

如果我們不能定義出具體明確的系統問題，所謂的較好的設計也只不過對未來可能變化的假設所做的設計，但實際上未來的變化可能會出乎我們的意料之外。當我們對系統的假設不再成立時，就會產生系統可能發生異常的風險。因此，戴爾出現系統異常的原因，問題的關鍵可能並不在設計的好壞，而是沒有掌握好問題的複雜度；今天系統碰上比過去更複雜的問題，是當初設計系統之時所沒有想到的情境。

造成錯誤的原因

從筆者過去系統開發的經驗顯示，過去長期運作正常的系統，經常會因為運作環境發生變化，而使系統在現今發生功能失常。我想戴爾的情況應該也是類似的狀況，否則如果是設計有問題，就很難解釋為什麼過去運作正常的系統，會在今天出問題。如同商業周刊的評論「戴爾烏龍 在於沒換腦袋」所提到的：

戴爾系統無法偵錯的關鍵——戴爾仍以經營企業顧客的思維在做消費者生意，否則怎會沒把消費者異常下單行為納入管理流程？

戴爾成立以來都是以企業市場為重，占營收比重超過八成。直到二○○七年才進入消費市場，這是很大的突破，因為經營企業市場，客戶數量少，強調服務與產品穩定度，但經營消費市場，客戶數倍增，就必須靈活彈性。

但此次事件讓我們看到，即使經歷兩年，戴爾網路系統的「腦袋」還沒轉過來，管理階層也是一般。

從戴爾大中華區中小企業處許肇元的說法，我們也可以了解戴爾系統異常的問題。網路上有一篇 jeremy 寫的專訪中提到許肇元對短短 10 多天連續出了兩次錯誤的解釋：

「因為我們成長的速度太快，而系統並沒有配合我們的成長。像是我們的訂購流程，每個零組件都可以客製化，訂一台筆電的流程換算下來就幾十個關卡，每個關卡都跟價錢有關，牽一髮而動全身。這次事件中，我們真的學到很多，也重新檢視了我們的系統。」

這更讓人相信，問題的關鍵並非單純的系統單一功能失常，而是戴爾忽略了商業模式改變會對系統產生影響，而沒有做好事先預防與事後可以及時因應的準備。

由此可知，造成戴爾系統發生錯誤看起來並非出在各部分功能的問題，而是系統整體整合出現問題而造成系統異常。那麼台北捷運內湖線的系統異常是不是也是相同的問題？從相關新聞報導我們發現，系統發生錯誤的原因也是因為系統沒有整合好，內湖線無法順利整合木柵線舊有系統。這大概從決策當局決定採用規格無法統一的中運量的系統，以及冒險採用無線通訊新技術時就已經註定了這樣的結果。再加上測試時間不足，自然會使品質問題更加雪上加霜而惡化。

造成系統失敗的條件

如果戴爾電腦和台北捷運內湖線的系統異常，種種跡象都顯示是整合出現問題，那麼我們不禁要問：為什麼它們的整合都會出現問題呢？從筆者系統開發的經驗來看，我相信是因為系統整合牽涉的問題太多或是太複雜，使得開發者難以掌握。再加上人們在尚未意識到系統的複雜度之前，常會認為自己有能力解決所有的問題，但實際上他們想要這樣做卻做不到。一言以敝之，系統失敗的根源其實是來自於人性的弱點，雖然這個真相往往被硬體、作業系統或平台的功能失常所掩蔽。

如同著名的軟體工程顧問溫伯格在《第一級評量》提到，造成軟體系統失敗的條件有八個 F，它是分別是弱點（Frailty）、愚蠢（Folly）、執迷不悟（Fatuousness）、好玩（Fun）、欺騙（Fraud）、狂熱（Fanaticism）、硬體功能失常（Failure）與運氣（Fate）。筆者發現這些造成失敗的條件，其實正是表現人性弱點的不同面向。

弱點

弱點是做想做的事卻做不到，它是軟體失敗的終極源頭。因為人不是完美的，他們做不到設計所要求的，不論那是一個程式設計，或是一個過程設計。溫伯格認為管理階層的責任是設計出一個程序以規範程式如何修改，承認自然界的事實，與確保程序本身被執行。而且他認為人們傾向在發生錯誤後懲罰嫌疑犯其實很不好，因為他會讓人隱藏錯誤、浪費時間在找嫌疑犯、以及分散注意力忽略管理階層的責任；建立並執行能及早找出失敗，並預防悲慘後果的程序。

愚蠢

愚蠢是做到想要做的事，但它卻是錯的事。愚蠢的基礎是無知，雖然它在當下沒有發生錯誤，卻會在以後造成錯誤。不過透過學習可以改善無知，進而將愚蠢矯正過來。溫伯格認為建立完整訓練師徒制、技術審查計劃、提供落實計劃的支援，是管理階層可以用來矯正愚蠢的職責。

執迷不悟

執迷不悟是指不肯學習，一直做出蠢事，一次又一次的做。此外，想要管理好一個愚蠢的人，卻不提供他根除愚蠢所需的訓練和經驗，這也算是一種執迷不悟的行為。溫伯格認為在軟體工程機構中，除了把執迷不悟的人送到其它行業去，否則沒有什麼防護措施可以抵擋執迷不悟的人。

好玩

好玩是程式設計師會寫一些奇怪的程式來為自己找樂子，溫伯格認為沒有人能夠預測別人認為好玩的事是什麼，因此好玩的心理是所有失敗的源頭中最危險的一個，因為它防不勝防。但管理者應該提供預防之道：一是開放透明的系統，另一個則是讓單單工作本身具有足夠的趣味。

欺騙

欺騙是用非法的方式從一個系統中獲取個人利益。溫伯格認為好玩是在失敗的源頭中，帶來的最小的損失。因為一個系統找樂子的方法有千百種，但值得一偷的東西卻沒多少。他認為軟體工程經理要好好閱讀以資訊系統詐騙為主題的文章，並採取一切可能的預防措施來防堵它。

狂熱

狂熱是試圖摧毀或瓦解一個系統，而原因不是為了個人利益，而是為了報復。溫伯格認為防範弱點而採取的行動中，多數也可以減少恐怖份子所造成的威脅與影響。

硬體功能失常

溫伯格提到硬體若不能造著當初設計的目的而執行工作，就會造成功能失常的現象，這類問題多半可以用軟體來克服。他認為當人們抱怨硬體造成他所寫的軟體出問題時，我們應該找出它表達的意思，以免遺漏這句話所帶來的重要資訊：

1. 硬體沒什麼大不了的功能失常，但程式設計師需要找藉口來隱瞞一些事實。
2. 硬體功能失常問題都在一般的預期範圍內，可能程式設計師沒有採取正確的防護措施。例如將程式碼或測試腳本做備份。
3. 硬體功能失常，但沒做妳硬體供應商關係的管理工作。
4. 硬體功能失常是由人為錯誤所造成的，如使用者做出出乎意料的動作。

運氣

溫伯格指出運氣不好是多數表現不佳的經理愛用藉口，這不是事實。他建議當我們聽到一個經理老愛說運氣不好時，我們應該把運氣兩字換成經理，因為沒有不好的士兵，只有不好的軍官。

系統異常與人性弱點

從以上造成系統失敗的條件我們可以知道，系統發生異常的原因可能是系統的設計不夠好、硬體設備或作業系統出錯或是系統運作的環境太複雜了，但發生問題的真相卻都大部份是因為人性的弱點。因此，要在失敗前發現錯誤，進而採取行動防止系統失敗，重點管理好人性弱點，而非不承認它的存在，卻只在事後責備人們沒有盡到責任，但事實上最大的責任是管理階層沒有盡到管理的責任。

例如在台北捷運內湖線在 7/10 發生系統大當機的事件後，當外界質疑為什麼發生這麼嚴重的當機事件時，筆者注意到有一篇新聞報導提到市府官員有人表示「這個問題，80 % 是因為電腦中毒」言下之意系統異常多半是因為硬體的功能失常所致，而比較不可能是軟體的瑕疵或人為的錯誤。

溫伯格說過「對錯誤的直接觀察，本身並無意義，但是對『人們作何準備來面對錯誤的發生』的統合觀察就很有意義」那位市府官員的說辭，筆者相信只是為了隱瞞了一些事實，以免公布實情而讓損失更加擴大，然而這卻表現反應他們對面對系統錯誤發生的準備並不夠充分。

筆者再舉一位朋友的經驗為例，以前他們公司採用 .Net 開發平台開發新產品。由於他偏好 Java 的程式寫作慣例，加上當時微軟聲稱與 C# 整合不成問題，讓他很想用 J# 程式語言來開發系統。雖然他的同事擔心系統的整合會出現變數而反對，但由於他的堅持，管理階層還是照他的意思，讓他用 J# 開發他的程式，與其他同事以 C# 的程式來進行整合。

後來在整合時，他們發現碰到很多平台上及程式語言本身的問題。為了解決這些問題，他只好修改他的程式以處理這些問題，但也讓系統愈變愈複雜，結果使軟體問題層出不窮。但朋友仍然還是堅持要用他喜歡的方式開發系統，最後在管理階層無法忍受他的執迷不悟，並且在彼此無法達成共識的情況下，要求他離開了那家公司。

從這位朋友的故事中，我們看到他的弱點、愚蠢以及他和管理階層的執迷不悟。他的弱點是想實現他的設計理念並完成不同語言的整合，但後來卻發現這是個艱鉅的任務。在發現了專案時程及市場上的壓力並不允許他實現他的設計理想時，卻一再地堅持做自己想做的事而非應該做的事，這是愚蠢。而與管理階層之間一次又一次想要對方同意自己的觀點，卻又不去理性客觀地評估現實，而只是一廂情願地以為讓對方發現此路不通就會懸崖勒馬，這是他與管理階層的執迷不悟。

朋友的經歷並不是特例，在實際的系統開發專案中，筆者總是看到相同的故事正在持續上演。就像戴爾電腦、台北捷運內湖線發生系統異常的事件一樣，應該發揮效果的程序、流程與方法，在關鍵時刻竟然沒有發揮作用。筆者認為問題的關鍵是在於人性的弱點，我想只有在適當地管理好人性弱點之後，程序、流程與方法才能真正地落實，並且發揮出應有的效果吧。

管理的重要性

如果導致系統異常的關鍵是在於人性的弱點。那麼管理階層就應該負起管理人性弱點的責任，以避免專案因為人性弱點而造成系統異常的意外事件而慘遭失敗。從去年跨年夜發生的台灣大哥大行動電話用戶大當機的事件，又再一次地讓我們看到管理對避免系統異常而造成失敗的重要性。

去年跨年夜，台灣大哥大發生行動電話用戶大當機，經檢調查出是台灣諾基亞西門子公司離職工程師，涉嫌以女友名義登入台灣大資料庫並刪除資料造成大當機，檢方昨天將陳依妨害電腦使用罪嫌起訴。

筆者看到新聞提到那位工程師，否認是遭開除而挾怨報復，只說會這麼做是因為「好玩」。讓我想到溫伯格說的，好玩的心理是所有失敗源頭最危險的一個，因為沒有人可以預測到別人認為好玩的事是什麼。

當然，我想事件的真相應該不是因為那位工程師基於好玩的心理，而是被公司開除而心生報復。造成台灣大哥大系統當機的原因，固然是難以預料到的惡意破壞，但這並不代表這種系統失敗是無法防止的。筆者認為問題在管理上，因為管理階層忽視人性弱點，而沒有盡到管理者應盡的責任。

或許有人會認為筆者這樣說對管理者要求太多了，但如果系統開發團隊沒有紀律來把事情做好，這的確是管理者的問題。管理者設計或制定流程，目的是為了幫工程師把事做好，但如果流程不能落實，那是必然代表管理出現了問題，所以管理者必然難辭其咎。

好比說，為什麼離職員工可以用他離職前的帳號密碼來登入系統，然後做出一些危害系統的行為？又或者，為什麼會讓人興起想要破壞系統的動機，而身為負責系統成敗的高階管理者，為什麼會不去防範可能破壞系統的行為？

因此，即使可能是因為好玩，管理者也要思考如何降低人們為了找樂子而影響系統的動機。如前面所提到過的，讓員工的工作更有趣，同時讓流程更透明。此外，避免員工試圖摧毀或瓦解一個系統，不是為個人利益而是為了報復。管理者應加強防範弱點而採取的行動，因為它們多數也可以減少這種攻擊。

以上這些都是管理者的職責，以避免系統因為人為的疏忽而失敗。總而言之，預防系統失敗，管理最重要的工作就是認清「人的不完美」，才能知道如何管理人性，進而避免發生人為錯誤而造成意外，產生系統的重大損失。

軟體專案團隊在專案開發的過程中，常會面臨許多問題，例如需求的不斷變化、資源的短缺、時間的急迫性、以及技術的難以掌握等。這些事件雖然都將直接影響專案的產出與品質，並且會令開發者會感到相當困擾，但只要存在希望，問題都還是可以有解決之道的。然而，在什麼情況下，專案發生了什麼事會讓開發者完全失去希望，並且感到他的世界相當悲慘呢？

相信許多人都會同意，總要等到專案驗收前，才發現程式品質有問題是一件很令人沮喪的事情。而筆者根據軟體專案實務經驗也發現，對軟體開發者而言，最悲慘的事件莫過於在專案臨驗收之際，才發現程式沒有合乎品質上要求。

軟體開發者的悲慘世界

筆者用一個笑話來比喻這種開發者的悲慘世界。話說有三兄弟開車回家，就在車停妥在停車場時，突然發現大樓停電了。很不巧的是，他們住在五十樓，停電沒辦法坐電梯，於是他們只能用爬樓梯的方式回到他們居住的地方。

爬到十樓的時候，大哥建議每人講一個最悲慘的故事，並且從他開始。大哥說：「從前有一個人從小就沒有父親，是由母親含辛茹苦地養大，好不容易稍稍有了一點小成就想要報答母親時，母親卻病死了。」，說完時他們己經到了二十樓。

二哥接著說：「從前有一對情侶非常相愛，男孩要出國留學，女孩也發誓不管多久一定會等他回來，四年之後男孩終於學成歸國，女孩也堅貞如是，但是女孩卻在去接他的途中出車禍，當場死亡。」講到這裡時，不知不覺的已經到了四十樓。

這個時候，沒想到三弟只不過說了一句話，三兄弟馬上坐在樓梯上大哭。他說：「大哥，二哥，對不起，我忘了把鑰匙放在車上了！」

軟體開發者的悲慘世界就像這個笑話一樣，眼看目標就在眼前，這時卻發現最關鍵的地方，亦即軟體品質沒有達到要求而將導致前功盡棄。而更令人絕望的是，在最後一刻才發現這樣的窘境，此時要及時彌補缺失卻是相當困難的。

就像笑話中的三兄弟一樣，他們必須有人回車上拿鑰匙，而原來走過的路要再重新再走一次。軟體專案開發也是一樣，先前沒做好的開發作業必須回過頭重新把它們做好，而後續的開發作業也必須重做一次。但問題是客戶馬上就要驗收，開發者通常已經沒有足夠的時間來解決問題了。

對於開發者而言，這樣的悲慘世界可真是可怕的夢魘呀。然而，這樣的現象為什麼老是一而再，再而三地發生，到底是什麼地方出了問題呢？顯然問題多半出在開發者無法儘早發現程式瑕疵並及時因應，卻讓自己在茫然無知的狀況下，讓問題不斷地惡化下去。而依據筆者的實務經驗顯示，這種現象可以從開發者的紀律、確認與驗證的過程兩方面來理解。

開發者的紀律

可能有些人會把無法早期發現程式瑕疵歸咎於「無常」兩字，就像笑話中大哥、二哥所提供的故事一樣。得確，軟體專案的本質是充滿不確定性的，實際上會發生的問題是很難事先預料得到的。然而，但當我們經過深入地去檢討後卻常常可以發現，藉由良好的開發者紀律可以減少因為一時疏忽而產生不良後果。就如同笑話中三弟所言的疏忽一樣，許多程式的瑕疵是因此在剛開始分析或設計時就己經存在了需求或設計規格中，但卻直到最後一刻才會被發現。

依據筆者的觀察，一些軟體開發者在分析或設計時，經常不會事先思考需求或設計規格的驗證問題，而是等到程式實作出來過後才會開始思考測試該如何進行。由於在需求或設計規格上，並沒有思考到如何驗證的問題，其內容就常常就會因為不夠完備而顯得草率而馬虎，自然使得程式碼的產出常常會缺東漏西，甚至產生一些錯誤。

而等到開發者在開始進行編程時，規格上所缺漏的部分自然就不會被實作出來，而需求與設計的錯誤更會具體地被實作在程式碼當中。當然部分需求或設計的疏漏與錯誤，可藉由在實作的過程中被發現。但對於一些經驗、能力不足、或態度不夠積極的程式實作人員而言，他們通常只會按照規格來開發程式，而不會去進行溝通並發展良好的程式結構來解決工作上的問題。

另外，有些開發者會習慣於暫緩程式的驗證，他們總以為進行程式的開發遠比進行測試驗證還來得要有生產力，甚至在面對時程的壓力時，會選擇省略功能測試，期望以整合測試或系統測試來將測試問題延後處理。

因此，以上種種原因，使得測試作業太慢開始、程式碼之中散佈著因為需求或設計規格、或實作結構問題所產生的一些疏漏或錯誤，這些現象使得程式瑕疵擴散或蔓延的速度比修正的速度還來得快。當程式的瑕疵愈變愈多、除錯就會顯得更困難，對程式的除錯與測試都是個沉重的負擔，更不用說可以及早發現程式中的瑕疵了。

確認與驗證的過程

在軟體工程的領域中，確認過程代表確定開發產出滿足及符合原始的設計，也就是把事情做對。而驗證過程則代表檢查開發設計滿足或適合預期的使用，也就是做正確的事情。在台灣，一般大型軟體專案多半採用 V-Model 的軟體開發流程模式來進行軟體的確認與驗證。此開發模式展現了不同抽象層次觀點的開發作業與相關的測試作業之間的關係。

一般而言，我們會將軟體專案開發分為三個開發層次，高階的抽象層次為處理使用者的需求分析；中階的抽象層次則將重點置於將所了解的需求轉化為軟體架構；低階的抽象層次主要為系統功能的細部設計與系統實作。

在每個開發作業完成之後，開發者應當進行確認過程來確保開發作業符合需求及設計規格後才能進行下一個開發作業。而直到程式被實作出來之後，開發者必須依序按照不同開發層次的要求來進行驗證過程，以各種不同類型的測試作業來檢查軟體是否真能符合實際使用上的需求。如下圖所示。

此開發模式配置了良好的結構方法，讓每個開發作業都可以根據前一個開發作業的詳盡產出來進行作業。而測試計劃可以很好地提早在編程前就開始進行規劃，如此將為專案省下大量的時間。但事實上，採用 V-Model 在專案後期仍然還是會從程式碼當中出現不少瑕疵，似乎按照規格來開發系統仍然無法解決需求與設計在專案後期因為經常變動而影響程式碼品質的困境。

為什麼會如此呢？從 V-Model 的開發流程結構我們其實不難發現到，愈高階層次的開發作業是愈晚被驗證的，而在它尚未被驗證前，較低階層次的開發作業都會因為它的變動而受到影響。例如，在系統測試時，如果發現軟體無法通過驗證的原因是因為需求規格的瑕疵，如此就必須回過頭來修正需求規格的瑕疵，並重新進行設計與程式開發。

換句話說，愈高階層次的開發產出，其瑕疵是愈晚才會被驗證出來。而相較於低階層次的開發產出，其衝擊影響力又是相當嚴重的，因為這代表瑕疵將會在較低層次的開發產出中擴散與蔓延。因此在實務上要做到「早期發現、早期治療」，讓需求或設計的瑕疵盡早被發現與解決其實並不容易。除非需求與設計規格能夠儘早驗證完全無誤，然而，在程式在尚未實作出來之前，開發者又該如何做到這一點呢？

如何早期發現、早期治療？

如果對於需求或設計，開發者無法先驗證其可行性與正確性，而必須等待程式實作出來才能靠測試作業來加以驗證的話，那麼我們將會期望測試作業必須具備相當高的效率及足夠的涵蓋面。但實際上，測試的效率與涵蓋面會受限於專案的時程與成本，因此希冀測試作業能夠有效率地找出程式所有的瑕疵的想法往往是不切實際的。

一旦我們愈晚進行測試，因未驗證的分析設計而產生的遺漏或缺陷將會使程式中的缺陷不斷地擴散，如此將會使開發人員更窮於應付。換句話說，不良的需求或設計往往會加重測試的負擔與壓力。

因此，要用較低的成本與時間來達到最佳的程式品質，其關鍵並不在於測試的效率與涵蓋面，而是在於提昇需求與設計規格的品質。然而，我們該如何發展出較佳的需求與設計規格，並且能夠及早發現存在需求與設計規格的瑕疵以適時加以修正呢？

筆者認為，開發者在進行分析及設計的過程中，就應該同時思考需求規格與設計該如何驗證的問題，而不是等需求或設計規格完成後才去設計驗證的程序。同時，在需求或設計規格交付之前，應該讓團隊針對欲交付產出進行實質上的技術審查，以集思廣義的方式促進集體反思，以找出分析或設計者所忽略的潛在問題與瑕疵。

如此將使因個人盲點而產生之需求或設計的瑕疵會因此大幅減少。因為，為了要找出如何驗證需求或設計規格的方法，就會強迫我們客觀思考自己的想法是否完備、有沒有被我們所忽略的問題沒被考慮到，進而完善我們的思慮。另一方面，請別人來一齊檢查自己所分析或設計的開發產出，更可以站在更客觀的立場來看問題，透過不同的觀點來了解自己是否忽略了什麼。透過集體思考的過程，我們可以得到更為一致的需求與設計觀點，就不會流於個人的執著與徧頗。

在驗證需求或設計方面，在分析或設計過程就必須思考驗證需求或設計的具體方法。這代表了不一定要等實作設計的程式完成後，才能開始寫測試程式。如果我們無法依據設計來寫出測試程式時，其實正代表著我們設計的思慮多半是有問題的，我們對設計的想法可能還不夠具體，如此的設計是很可能存在許多我們所想不到的缺陷與瑕疵的。當然，先寫測試程式並不是唯一可以「在分析或設計過程中思考需求或設計如何驗證」的方式，不管採用任何形式的開發方法論，筆者認為都應該先想到如何以具體可行的方式來驗證需求與設計。

舉個例子來說，架構設計必須包含架構的概念驗證（POC，Proof of Concept）。架構設計者不應該省略驗證架構的程式，卻期待程式實作者來幫他實現未經驗證的設計構想。他必須自己親自驗證架構，如此才能透過驗證，使自己設計的架構趨於成熟，而不致讓開發團隊在使用架構的過程中出現問題叢生的困擾。

而在技術審查方面，在設計過程中進行 software inspection，除了可以提早發現需求或設計的瑕疵，更能促進團隊成員相互學習以提昇開發能力。品質不只要靠檢驗，而是不去設計有缺陷及瑕疵的系統。然而，不管開發者的分析或設計能力有多強，都不能保證其開發產出絕對沒有問題。在這種思維下，全員參與是一個好主意，於是讓同僚參與需求或設計規格的審查可讓系統設計更趨於完善，一來可以用比較客觀的方式來確保設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。

因此，在思考如何驗證需求與設計的過程中，會讓我們不知不覺地把焦點放在最主要目標的達成上，可以讓我們更有效地整合開發作業與測試作業。而讓同僚參與分析與設計的討論過程中，將有效撤除開發作業之間的藩離，透過同步的協同作業可得到截長補短的好處，如此將發揮一加一大於二的團隊綜效。其實同步與整合，正是讓程式瑕疵得以早期發現、早期治療的有效的做法呀。

首先，Coplien 提到了做不做測試驅動開發（TDD，test-drivern development）或是驗收測試是一個錯誤的問題，因為軟體開發應關注在品質上，測試所能涵蓋到的品質問題只是片斷而零散的，它是在軟體產業中所知當中，最沒有效率的方法。

然後，Coplien 用「宗教信仰」來批評 TDD 的追隨者，認為他們是盲目的而未加以審慎地思考它可能並不是最佳的實踐方法，同時對於任何的批評也會招致他們的情緒反應，他指出這已經變成一個宗教信仰的問題了。

Coplien 認為要用系統工程的角度來思考問題，也就是如何用最有成本效率的方式把工作做好，而新時代的敏捷運動卻一貫地脫離這些實務。他認為表面上加緊進行簡單的設計看起來很好，但一旦將這些設計放在一起卻會看到它們彼此是片斷而零散的。

不過，Coplien 的觀點在軟體開發社群中卻引來了不少的批評，有人提到對自己親身體驗到的成功所懷有的熱情是不應該與教條主義或宗教信仰混為一談的，更有人認為 Coplien 的觀點缺少事實根據，並且他的主張是懷有個人偏見的。〈软件开发社区“宗教信仰”之争风波未息〉總結這些批評提到：

Coplien 的核心觀點並沒有問題，只是選用了錯誤的論據進行了錯誤的證明。這也提醒我們要以冷靜理性的態度對待問題，否則便有可能在遠離一個極端的同時，走向另一個極端。

同人認為這個宗教信仰之爭是沒有意義的，甚至會覺得 Coplien 對軟體測試的批評讓我覺得很困惑，他想要表達的是什麼？他說要關注於思考而不要對新技術或熱門詞彙亦步亦趨，這個我同意，但從他的文章看起來，他似乎也不由自主地建立了另一個宗教信仰。

特別是「做 TDD，還是驗收測試？」這個問題更令我疑惑，這兩者明明是不同層面的問題，拿來比較有何意義呢？我不認為它是如 Coplien 所說的偽命題，相信應該還有更深的一層意義。

於是，同人換個角度來思考問題，驗收測試與 TDD 有何不同？一個是由客戶端來驗證軟體是否符合他們的品質要求，另一個則是開發者以測試驅動的方式來開發軟體系統。顯而易見地，這個問題的重點並不在測試，而是「開發者應該自己驗證程式，還是該仰賴客戶來幫你找程式缺陷？」。換言之，就是我們常聽到的一句話：品質是檢驗出來的，還是設計出來的？

進行軟體測試的目的，最主要是要防止軟體在客戶端產生功能失常（failure）的情形，但它並無法完全確保程式本身絕無瑕疵（defect）存在。一旦軟體測試涵蓋面不足時，交付給客戶的軟體就很容易會產生品質的問題。 然而測試的涵蓋面要夠廣，軟體開發所需的開發成本與時間就要增加，所以與其靠檢驗來控制品質，還不如把設計做好。所以，品質是設計出來的，而非檢驗出來的。

不過，雖然品質並不是檢驗出來的，但軟體要具備足以信賴的品質，卻不能省略測試。舉個例子來說，不管開發者如何確保他的開發所產出的品質，驗收測試是絕對不可能省略的，否則客戶是很難信任軟體是合乎他們需求的。良好的軟體設計可以減輕測試的負擔與壓力，但它絕對無法否定軟體測試的價值。

所以，品質的問題並不是測試效率太低；而是開始測試的時間拖得太久，使得分析設計階段的缺陷不斷地擴散而使開發人員窮於應付。例如開發者在設計的過程中有沒有去思考設計驗證的問題，還是把這個責任推給後續的品管作業，例如 code inspection，或是各種形式的審查作業？

這個答案無關乎方法論本身的優劣，而是關乎開發者面對問題的態度，這對品質有著直接而深遠的影響。沒錯，我們需要專注於思考，但思考的重點並不在用那一種檢驗方式比較有效率，因為那樣我們將會落入品質是檢驗出來的迷惘當中。而是應該思考，對這個問題為什麼我會這樣設計？我如何驗證它是可行的？有沒有可能它會無法解決問題或造成其它我沒有想到的問題？

軟體工程本來就是實務中的理論，測試先行從來就沒有遠離過軟體工程的實務範疇。所以用不用 TDD 其實並不重要，每一種方法都有它的假設與限制，要認清問題，然後按照實際狀況來予以實踐並調整，陷於主觀的意氣之爭其實是沒有意義的。不同的方法沒有宗教信仰的問題，而是只有如何有效地加以運用來達成目的而已。因此，要讓軟體滿足客戶品質的要求，思考的重點是在於確認設計的實踐，而不在於方法論的偏見呀。

Powered by ScribeFire.

木金兄果然厲害,拜讀所談,獲益斐淺. 小弟補充一點如下:

最新的 CMMI v1.2 版裡已將籌獲流程獨立出來，成為 CMMI-ACQ，即Acqusition 採購流程管理。與原來的開發流程 CMMI-DEV、以及新的CMMI-SVC 服務流程，合成所謂的互補薈集 (Three Complementary Constellations)。

CMMI-DEV 對於資訊系統/軟體開發流程提供了管理、度量及監控的指引，CMMI-ACQ 促使委外籌獲單位居於清楚認知及決策領導的地位。CMMI-SVC的重點則在於提供組織內部及外部客戶服務的參考模式。

看起來 CMMI 的標準，也在朝向提昇 StakeHolder 的參與在努力。

外包單位不可以自外於整個專案，CMMI-ACQ 與 CMMI-DEV 的流程互相對應，共同面對整個專案的成敗。

誠如學長所言，外包單位不可自外於整個專案，外包管理做不好，輕者績效不彰，重者損兵折將，其影響 stakeholder management 甚鉅，不可輕忽。

附記：上週六才發現，林序學長和喲哪桑學長早就認識，人際網絡真是四處連結的網路呀！

不過，在企求開發工具為我們加分之前，我們必須要思考如何才能先拿到基本分數。克明兄最近在〈從軟體架構師(Architect)的觀點來看軟體開發流程〉一文中提到他對工具與自動化的觀點：

“工具” 與 “自動化”，這是流程制訂者與管理者最迷信也最喜歡導入的機制。這兩種當然是很重要，但卻不是最優先考量的，也不是導入後就能解決軟體開發根本的問題的。……而自動化，這個可是有趣的議題。筆者是把有些資深軟體工程師想要開發出把設計圖直接轉換為程式碼這樣的自動化機制，比喻為如同機器貓小叮噹的百寶箱，只要把建築藍圖輸入道具機內，就可以幫你自動產生一棟高樓大廈來！ 不是不可行，不過，你可能先得要有小叮噹才行。

而喲哪桑學長則告訴我們 Defect Detection Tool 之道聽途說：

幾年前，曾經有朋友跟我抱怨他正在評估的工具，他說用工具掃過他的 source code，找到的 defect 裡，每兩個 defect 就有一個不是真的 defect。……我並不清楚，這類工具一般的 detection rate 與 false positive rate 為何，也不清楚這幾年是否有大幅的進步，更沒有去稽核我朋友的評估過程。這二分之一的 false positive，真的只是道聽途說。

雖然只是道聽途說，但因為這關係軟體的品質，所以我們不能冒太大的風險，但也不能只是一味地土法煉鋼。亦即，不可以太過仰賴工具也不能完全不用工具，而是要適當地運用工具來提昇我們的開發的效能與品質。那麼工具的使用該如何取捨呢？方法論的實證研究^[1]顯示，大部分方法論使用者認為方法論所帶來的負面因子為：

1. 方法論太笨重並且會造成開發過程的惰性。
2. 遵循方法論會干擾實際的開發工作。

而他們也認為方法論也會帶來一項正面因子－在軟體開發過程中促進專案控制與提昇產出的可見度。

所以在開發方法論要導入工具，要注意工具的使用不能太複雜、也不能養成團隊成員太過依賴工具的習慣、避免因為工具的使用而影響實際開發工作、讓工具能幫助我們管理與控制專案的產出並且有助於成員溝通。開發工具的地位應該站在輔助的角色，而不是因為工具而工具。

喲哪桑學長在 defect detection tool 的使用建議我們：

既然工具只是輔助，又假設 false positive 真是問題，我以為在進行 software inspection 前，應該先使用工具掃過 source code，指派人手逐一檢查過工具找出的 defect，修好該修的 defect 之後，再進行 Software Inspection。甚至，工具找出的 defect，若有疑義，也可以做為 inspector 的討論，以決定它是否為 defect。如此一來，才會藉由工具的輔助，好讓人力產生更大的價值。

這正是「既有典藏，茍非其人，道不虛行」^[2]的道理，軟體開發的關鍵還是在於人的身上，新方法論強調人本、溝通而非制式的流程、文件或工具。使用工具的目的，其實主要是為了促進個人創意的發揮與其增進相互溝通。現在的整合開發環境（IDE）都做得很好，尤其是使用開放源碼的自由軟體（open source）並不會很笨重，例如 java 社群的 eclipse，可以事先根據過去經驗及業界的最佳實務訂出良好設計慣例的 coding template 的標準，只要讓開發人員在 check in 之前要先 apply 此 template。而 eclipse 會自動檢查程式碼有沒有可能有問題的 code，例如：用到廢棄的 API、區域變數未定初值或變數從未被使用、不需要的 import 等等。還有其 refactor 也很好用，它讓程式碼的重構變得更簡單，如果能加上自動化測試工具（例如 junit），會讓程式碼的品質更可見而更易於管理與控制 。

總之，好用的工具要靠專案團隊正確的使用才有加分的效果，如果只有工具而沒有善用的知識，有比沒有還更可怕，不可不慎呀！

Powered by ScribeFire.

1. Fitzgerald, B. 1998. An empirical investigation into the adoption of systems development methodologies. Info. Manage. 34:317-328.
2. 《周易繫辭下》

我個人不是很同意依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的.

而我的原文是這麼說的：

對於一個開發流程未慣例化的組織而言（即未達 CMMI ML2），推行 review 可能會遭受極大的反彈；而對於一個開發流程未針對現況做回饋控制的組織而言（即未達 CMMI ML3），review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。

其實我要討論的重點並不在於 software review 形式的多寡，事實上，我文中提到的形式和學長所說的形式並不是同一件事。徧向形式審查的意思是審查的要點在於看工作產出有沒有遵照開發組織規章或專案計劃所規定的文件規範及慣例，對於工作的內容卻無法做到實質上的審查；而所謂的技術審查或 peer review 則是除了工作產出的形式是否符合規定外，審查的重點更會擺在工作產出的實質內容，我常稱這種審查叫做實質審查，用來和形式審查區隔開來。

所以我文中的形式與否並不是指 formal 或 informal，而是指開發團隊如何訂立工作產出審查的準則與流程。如果開發組織的軟體品質文化^[1]只在於掌握軟體開發慣例，亦即所重視的是表單或標準流程的話，能做到形式審查就很了不起了，但慣例化的問題在於對變化反應的能力較差，要解決這個問題，必須用工程管理的角度，亦即讓軟體品質文化朝向較有效的回饋控制以掌握更複雜的專案，要做到回饋控制，工作產出的實質審查則是不可或缺的。

我認為工作產出的審查的形式化多寡並不是重點，因為不管我們採用那一種審查，關鍵會在於專案要解決的問題有多複雜，客戶的了求有多高^[2]，這些因素決定了我們所適用的軟體品質文化模式。要先了解開發團隊的軟體品質文化，才知道該不該 review 及如何來 review，至於工作產出的審查種類該怎麼分，其實並不是我想訴求的重點，通常我只會用實質審查或形式審查兩種審查來區分不同的軟體品質文化模式。

Powered by ScribeFire.

1. 即《溫伯格的軟體管理學》一書中所指的「軟體次文化」
2. 這是溫伯格所建立的軟體次文化模型，請參考文獻 1

沒有壞就不要修，本是西洋古老的諺語。只不過，我還是會擔心，等到壞了，修也來不及囉！

我可以理解學長的 concern，但以 problem-solving 的角度來看問題，第一步一定要先弄清楚問題是什麼。再來問這是誰的問題，在問題擁有者並不想解決問題時，貿然要對方改變只會招致埋怨而對問題沒有任何的助益。

以易經的乾卦的處事哲學來看，所謂「君子以成德為行，日可見之行也。潛之為言也，隱而未見，行而未成，是以君子弗用也」，這是乾卦潛龍勿用的道理，在問題未浮現前，我們是不須採取任何的行動，因為這種狀況下所採取的行動是不會有好的成果的。而「君子學以聚之，問以辨之，寬以居之，仁以行之」，這是乾卦見龍在田的道理，事情開始成形了，我們要有反思與謙虛的態度，才能做出正確的舉止。再來是「乾乾因其時而惕，雖危，無咎矣」，這是乾卦夕愓若厲的道理，須多反省時機對不對，與時俱進，才會無咎。這些是老祖先留下來的基本培養 problem-solving 能力的心法，關鍵在不要在一開始就一頭栽進我們所認定的解決方案呀。

承上所言，找出我們的問題，如果我們的問題是「擔心」，處理的方法有兩種。第一種就是改變我們所擔心的事情狀態，我們可以提出觀察提醒對方可能會有不好的事情發生，但不提供解決方案，這時我們的擔心就變成他的問題，如果他認為這問題很嚴重，他自然會找你提出建議解決方案，否則就由他去吧；另一種方法則是改變我們對所擔心的事情的感受，這時我們可用更客觀的角度去看事情，也就是站在對方的角度來事情，雖然這種做法看起來有點駝鳥心態，但在無法改變環境的情況下，我們也只能這樣做了，除非我們選擇離開這個環境，不受其影響。換個角度來看，即使事後真的造成一發不可收拾，但至少能讓大家能夠學到寶貴的經驗與教訓，未嘗不是好事一件呀。

Powered by ScribeFire.

曾經在書上看過這樣的例子 software inspection 演變成 另外一種型式的專案批鬥大會

由於專案的壓力使然，會使得PM也許會對某些工程師的工作產出提出意見，進而產生批鬥

當然，我並不是反對 software inspection ，而是在做這件事的同時，需要明確的規劃和目標設定

如同文中提到的「反思」，是正向看待問題並思考，進而產生好的循環

回過頭來，還是在於公司或組織是不是有建立適當的文化和訓練，並且這項投資要能夠被管理階層所認同，講來講去~ 還是管理上的問題啊

批鬥大會其實是專案衝突的一種形式，當專案團隊成員有感受到彼此意見分歧、對方干擾的行為及產生負面情緒時，就會展開團隊的衝突過程^[1]。雖然衝突太多會對團隊的決策共識及接受度有負面的影響，但如果團隊完全沒有衝突，大家想法相同，團隊內呈現一言堂的現象，會導致決策品質的低落。適度的衝突，可混合不同的意見或建設性的批評，藉由不同觀點的了解，和有創造力的選擇自由，而增加決策品質^[2]。所以說，批鬥大會不見得是壞事，當問題發生，早期發現早期治療才是最根本的問題解決之道，避免批鬥並沒有解決問題，卻代表了我們只是讓問題延後發生的駝鳥心態。在解決問題的過程中，就算是相互對立，但只要清楚對立的目的是為了解決問題而非相互攻訐，在態度上可以相互尊重，在言詞上避免用言語攻擊或迴避問題^[3]，這樣的溝通與對立的目的是要剌激團體正向思考，以促進問題有效解決的良性循環。

看看我在前篇文章所引用的文獻^[4]對集體反思技術的觀點：

單環學習著重在實務目標的學習，而雙環學習則更看重認知層次的學習，因此會透過反思更進一步看清行動背後的假設，而借由改變看事情的角度而達到更深一層的學習，很多企業的戰略目標之所以達不成，並不是執行力的問題而是對目標本身沒有反思。

缺少集體反思的技術，使得大多數企業缺乏創新能力，反應遲緩，比如：』射殺信使』、部門間角力、回避真正的問題、大量流於形式的會議等等。

強調團隊集體反思能力，乍看之下是曠日費時，卻是組織學習的必需．所謂欲速則不達，組織如果沒有養成集體反思的習慣，任由誤會隨時間積累而不清除最後就會形成許多心結，而阻礙組織的發展，到最後就會惡化成各立山頭的政治遊戲，斷送了組織寶貴的生命！

團體反思的文化是需要培養的，而過程中則需要靠由上而下的概念性知識與由下而上的操作性知識反覆互動而達到動態平衡^[5]。只靠上面要求或制定任何規章或規範沒有工程師的現場知識與經驗的回饋，團隊就根本不知如何突破框架而有所創新；同樣地，只靠工程師辛苦努力奮鬥而缺乏願景與目標，大家會不知為何而忙，更不用說落實常規而讓努力產生價值了。兩種不同類型的知識的良性互動，其實是要靠團隊紀律^[6]的支持，software inspection 機制的目的就是要形成團隊紀律，有了良好的紀律，團隊才能從優秀到卓越呀！

1. H. Barki and J. Hartwick(2004), Conceptualizing the construct of interpersonal conflict. The International Journal of Conflict Management,Vol. 15, No.3, pp. 216-244
2. 蘇麗玉（2005），系統開發人員與使用者在資訊系統發展過程中之衝突與系統績效之探討－以銀行業為例，銘傳大學資訊管理學系碩士論文。
3. 面對重要且困難的溝通與解決令人失望的問題可參考《關鍵對話》與《關鍵對立》兩本書
4. 白國際管理顧問公司總經理，沈沂採訪整理，《21世紀商業評論》2005年11期
5. 即心智互動與知識轉化的相互搭配
6. 紀律要靠修煉，團隊最重要的修煉就是團隊要有系統思考的能力

基本上我蠻認同程式碼檢驗這個步驟，不過這個步驟不應該是由人來作，更不應該全部交由一個人來作，而是交由一套工具來處理，如此可以省去不必要的人力支出，而且也可以將 Knowledge 分享給 Team 的每一個人。

站在節省人力支出的立場，用工具幫我們檢驗程式碼的想法看起來好像不錯，如果這樣做可以維持程式碼品質而降低人力的花費，當然是最好的選擇，但程式開發的價值首重創意性思考，但工具卻只能預先設好檢驗的規則，在已設定的規則範圍之外，還是有很多 defect 是會被工具忽略掉，但這些 defect 是不應該被忽略的，因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作，交由一套工具來處理，對於改善軟體品質而言，其實是不夠的。

亦即在檢驗程式碼的工作，工具並不能取代人力的，工具最多只能站在輔助的地位，因為審查程式碼並不是 routine job，這個工作需要的是程式實作的專業知識與技巧，要用人的肉眼直接來逐行檢驗，不能由工具代勞。

專案團隊的設計，其實是為了發揮團隊的綜效，讓專案的績效大幅增加。軟體專案團隊要成功，是專注於專業分工與整合團隊綜效相互配合。雖然電腦輔助軟體工程可以簡化設計及開發的過程，讓我們用更有效率的方式來設計程式，但如果太強調效率而缺少整合，效率只是讓無法創造價值的軟體在製品（in-process inventory）不斷地增加而已，徒然增加品質成本。

整合需要團隊有效的互動，也正如敏捷軟體開發宣言所強調的「人本與互動勝過流程與工具」。Software inspection 不是只有檢驗而已，它更重視學習及互動的過程，團隊的學習除了個人知識與技術的單方面獲取外，更重視團隊成員的互動並重視學習的回饋環路。在 software inspection 會議中，團隊成員可以提出個人看法，以積極及開發性的討論來促進集體反思，讓團隊以更有創造力的方式來工作。就像〈反思技術打破』集團性弱智』〉一文所提到的：

一個有學習力的企業要有集體反思的能力。在行動之後，能集體停下來反思的能力，「反思」不同於「檢討」，強調的是調整看事情的「角度」，團隊探究的重點是行動背後的假設，而不是行動本身，當交談的層次進入到假設及認知的層面時，團隊才有可能進入所謂的「雙迴圈學習」，也就是一群人「共同思考」的境界，而唯有在這樣的氛圍下大家才不會相互指責抱怨、不會計較誰的貢獻比較多、不會被認為提出了愚蠢的看法，真正創新才有可能出現！（白國際管理顧問公司總經理，沈沂採訪整理，《21世紀商業評論》2005年11期）

所以，團隊合作重視每一個團隊成員與其互動的過程。在參與 software inspection 的過程中，除了可以達到知識分享的目的外，還會讓成員感到受他有受到重視，無形之間增加團隊向心力及凝聚力。當我們用工具檢驗程式碼時，並沒有辦法享受到這些好處，如同我在〈軟體開發能力的自我組織〉中曾經提到的：

公司缺少了像 Inspection 這樣的機制，任何的抽象思考、建模及各種提昇設計能力的技巧最多只能「孤芳自賞」，對組織開發能力的助益其實是有限的。「獨樂樂不如與眾樂樂」，當專案實施 Inspection 時，成員的設計能力及 software asset 變得與日俱增，而且在團隊溝通上助益也很大，可說是好處多多。

Software inspection 可以用來 QA ，更可以做到 team building，這些都不是用了 CASE 工具就可以勝任的呀！

Powered by ScribeFire.