那篇文章提到期待專案問題藉由收尾巴的過程而得到解決的想法，往往是要付出很慘痛的代價的，但很多人卻無法從這些寶貴的經驗中得到教訓。同人在那篇文章提到一個觀念，就是不根據需求的變動或軟體的現存問題規劃出合適的架構與概念設計，現存設計很難會有足夠的空間來容納新功能。因此，最好還是採取務實的做法，針對變化而適時修正計劃，不要樂觀而天真的以為收尾巴就可以解決問題。

在那篇文章的迴響中，志威兄與可樂魔也分享了他們的經驗。志威兄提到了，專案的控管真的是一門藝術，需要累積許多豐富的經驗。每次專案的歷史重演，真的會讓人抓狂。可樂魔則提到，他看到他們公司的眾家 PM 們，他們的心態還是希望在這最後的階段可以「修復所有問題」，但真的有價值的「記取錯誤經驗」和「再利用經驗」都像是狗屁一樣。

對於他們的分享，本篇文章正巧提出同人因應相同問題的實務做法。我認為如果那篇文章指出了對待樂觀主義的心態問題，那麼本篇文章所討論的則是如何處理軟體專案樂觀主義的問題。本篇文章在 CNet / ZDNet Taiwan 分為上下兩篇文章刊出，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。

在軟體專案的開發過程中，時程提供了專案進度追踪與資源運用的控制基準，讓專案管理者能夠可以用更有效率的方式達成專案目標。通常，軟體開發者會藉由軟體開發的經驗或專業預估合理的專案時程。理論上，專案時程代表軟體開發者對軟體需求者的承諾，同時也是專案團隊合作、與進度追踪的重要依據^[1]。

不過，軟體開發專案與其它的產品開發在開發流程上卻存在顯著的不同。就本質而言，軟體本身具有抽象化的特質，因此，軟體開發的專案時程預估大多是靠個人的直覺或主觀認定。每個人對時程預估都有所不同的認知，對同一個軟體開發作業，經由不同的人所預估所需花費的時間與成本往往會有不同的結果，但卻沒有人會確切知道該作業實際的完成時間與所耗資源與成本。

實際上，合理的軟體專案的開發時程往往要在接近完成時，才會真正地出現。在接近專案的尾聲時，我們才會真正知道我們預估的開發作業時間是否合理。但直到專案後期才發現時間不足或需要投入更多的資源時，卻會為開發團隊帶來巨大的壓力，結果常使整個開發團隊措手不及而造成專案的迫切的危機。

為什麼計劃總是與現實差別那麼大，莫非真的是「計劃趕不上變化，變化比不上老闆一句話」嗎？難道軟體專案的時程真的是無法預估的嗎？事實上，沒有時程的預估，專案就無從管理；而依照筆者在實務上的觀察中發現，問題的核心並不在時程無法正確預估，而是在於對時程的預估抱持太過樂觀的想法，因而對專案進行了無效的管理。

過程與目標的混淆

以管理的觀點來看，專案時程只是為了要達成專案目標，所採用的最可行的方案。但在規劃過程中，專案的不確定性將使得時程的預估變得很複雜，而為了增加規劃的效率，通常需要做一些假設來簡化這些的複雜性，以使時程規劃可以順利進行。

換句話說，專案時程本身存在許多的前提假設，這代表專案時程並非達成專案目標的唯一途徑，而是依計劃進行的一種可能性。但換個角度來看，專案時程有時候可能會無法實現，或是就算它真的被實現了，卻不一定能達成專案的真正目標。例如，軟體開發者常常在緊要關頭才會發現到，原先所規劃的時程其實是太低估了開發作業所需要的時間，或是發現專案時程遺漏了重要的工作項目，使得整體的工作產出無法整合。

因此，在開發過程中，造成軟體專案無法按時程進行的最主要原因，其實是在於把計劃錯認為專案目標，而忽略了該檢視存在專案時程中的假設是否依然成立，因而造成了專案目標與過程之間產生了混淆。依照筆者的觀察，這種混淆往往會造成管理過程的溝通問題、以及進度追踪的數字迷惘的兩大後遺症。

管理過程的溝通問題

在軟體工程領域中，理論上，依據軟體的功能與複雜度，可運用軟體度量的概念來具體客觀度量軟體規模，以協助軟體開發者預估合理的開發時程與成本。不過，在實務上，要準確地度量合理的開發時程，其實還是取決於軟體開發團隊的歷史經驗與度量的成本。

如此看來，只要時程規劃者擁有足夠的歷史經驗並且願意投入相當的度量成本，發展出精確的專案時程是可行的。但事實上，為專案做這樣的投資卻是不見得會划得來的。因為，軟體開發的過程常常會牽涉許多複雜的人際溝通與事物的變化，要巨細彌遺地將它們表達成數字，並不是一件容易做到的事情，同時也很容易讓管理變得很複雜，結果往往會未蒙其利，先得其害。

例如，筆者常常會發現有些專案管理者，只會一味地要求開發者提供開發作業的的進度，卻沒有深入理解開發過程的實際狀況，也不去專注於溝通與協調。因此，對於團隊成員在開發的過程中所出現的困難，往往無法提供立即而有效的協助，而在無力改善問題的情形下，讓問題不斷地擴大而造成時程延宕也是必然的結果。

其實，預估開發作業的工期並不在於數字的精確性，而是為了形成團隊成員彼此分工合作的基礎。換句話說，要讓管理更有效率，時程規劃與進度控管必須兼顧專案的複雜性與團隊的文化。更明確地說，時程規劃與進度追踪應該支援團隊達成專案目標，而不是用來產生對團隊的限制。因此，專注於專案時程數字的表象而忘了忽視了團隊的溝通，很容易形成在管理上的本末倒置。時程規劃的重點，應該是放在如何增進團隊的溝通與互動上。

進度追踪的數字迷惘

軟體專案的開發產出，是非常難以具體客觀衡量的。一般而言，在軟體功能完成之前，沒有人能夠穩定而客觀的量測出軟體開發工作的實際完成比例，而大多僅能憑開發者的直覺與主觀認定。筆者常看見開發者所回報進度完成比率，感覺好像在菜市場在喊價（叭啦拳）一樣，流於沒有意義的數字遊戲。我們很難從這些數字中了解到真實的專案狀況，一切都只是估計，而這些估計只是開發者的樂觀想法而已。

沒有穩定而客觀的具體衡量，我們就看不到專案的實際狀況；不了解專案的實際狀況，我們就難以知道專案是否偏離目標，及時採取行動以調整專案計劃。結果，大多數的情形都是，發現專案已偏離目標時，其落差已經相當大而必須採取激烈的手段才能挽回，但卻無形中卻增加了更多的副作用，因而使專案陷入了惡性循環之中。

事實上，要讓管理發揮效果，必須掌握「行動要快，動作要小」^[2]的原則，要在專案偏離目標但還尚未迷航的情況下，就必須立即採取有效的行動，修正專案的方向。因此，專案績效的衡量不在於表象上的進度數字，而是在於掌握專案的目前實際狀態。專案績效不只要看是否有按照時程來投入資源，更要看所完成的實際產出是否符合預期。這也就是說，單憑開發者投入的總工時是不足以衡量專案開發的實際績效，因為這是假設資源的投入百分之百會變成專案的有用產出，事實上這個假設在實際上多半是不成立的。

所以，管理者應該按照已驗證的軟體功能或模組來衡量專案進度，而不是開發者憑感覺的估計，這樣才不會掉入問題的陷阱而忽略了問題本質。在管理的過程中，必須要能比較出目前專案所投入的成本與專案的目標、以及時程計劃之間的差距為何，如此才能明白專案未達預期到底是要改善資源的運用，還是需要調整計劃，才能朝向達成專案目標而努力，否則就好像瞎子摸象一樣，一切都只能聽天由命罷了。

如何客觀衡量開發績效？

然而，軟體開發不比其它的專案，想要做到客觀而穩定地衡量出開發績效，其實並不容易。然而，依據 Gilb’s law 的法則：「任何東西只要需要度量就會找到方法可以度量，有量總比沒量好」，以最經濟的方式，針對需要來發展出適當的客觀績效衡量方法。績效衡量的重點並不在於精確度，而在於促進團隊的溝通以及有助於專案目標的達成。但要如何才能做得到呢？在此，筆者分享一些個人的實務經驗。

許多軟體開發者習慣用開發流程來做任務分工，也就是用分析、設計、實作、測試等作業來分工，但如此開發作業不容易有客觀的衡量標準；而且也容易遺漏了一些重要的作業，例如常常在測試過程才會發現分析或設計的瑕疵與遺漏。

因此，筆者認為，開發作業應該依軟體功能來分類，這樣不但可讓開發作業彼此獨立，同時也容易讓軟體需求者清楚功能是否有所遺漏，使軟體開發作業可以達到「彼此獨立，全無遺漏」（MECE，mutually exclusive, collectively exhaustive）的良好結構。

有了良好的開發作業結構後，我們就可以依開發過程的階段來衡量專案進度了。例如，開始進行開發時，就代表此功能進度達到 25%、功能開發完成時，就代表此功能完成進度達到 50%、功能驗證或審查完成時，就代表此功能完成進度達到 75%、而完成功能的交付後，則此功能完成的進度才算是 100% 完成了。

當然，筆者所提的方法，不見得可以適用所有的軟體專案，不過，此方法是基於軟體開發的實事求是的原則與精神。依照此原則，我們可針對專案實際需要發展出確實可用的績效衡量方法。讓軟體專案可以具體客觀衡量，這樣才不會被無可救藥的樂觀主義所矇騙了呀！

1. 陳建勳，陳漢山譯（2006），專案管理之美學，歐萊禮。
2. 曾昭屏譯（2006），溫伯格的軟體管理學－系統化思考（第一卷），經濟新潮社。

《易經．繫辭傳》有言：「天下事一致而百慮，殊途而同歸」。在不同產業中，設計所呈現出的面貎也許不盡相同，但是其策略本質卻是不會輕易改變的，亦即為未來可能發生的變動提供適應變化的能力。然而，開發者想要讓軟體具備足夠的彈性，以符合未來可能會面臨的需求改變，抽象化思考與設計能力會是關鍵因素，加上專案成本估算之軟體價格的迷思所形成的動態模型，當我們愈想要加入有彈性在我們的軟體設計上時，就更難以面對市場的競爭壓力，於是只好放棄設計彈性的理想。記得我和吳宗成教授曾經討論過國內軟體設計的議題，依照吳教授的觀察，他告訴我：＂台灣的軟體開發者大部分都在做 concrete design 而非 concept design，有用的設計是 concept design 而非 concrete design＂。由此可知，在台灣軟體開發環境不重視設計的情勢下，大部分的人多抱持著：今天先把功能寫出來，明天再求最佳化往往是軟體專案以時間換取空間的常見做法；我並不反對這種看法，但設計者必須培養持續改善的專注力，好的設計其實源自於紀律。

設計真的沒辦法堅持彈性的理想嗎？如果我們願意換一種思維方式，是不是就可以堅持理想，試圖打破軟體價格的迷思。於是，我們換一種做法，不以降低軟體開發成本為目標，而是藉由邊際效益的提昇來展現設計的附加價值，強調高品質的軟體設計及好的軟體來自於軟體工程的想法，不再自廢武功落入削價競爭瘀„惡性循環中。換句話說，當我們體認到軟體維護的重要性時，就必須為未來可能的改變而設計，以保有系統修改及維護的彈性。那要如何做呢？我們可以學習別人良好的設計範例，先從臨摩就座開始，慢慢提昇我們的設計能力。於是，我們向 design patterns 取經，學習如何為不確定來設計、體會務虛的設計藝術。

然而，design pattern 的學習看似簡單，但學了之後，要真正用在軟體開發上，卻又不是那麼一回事。看得懂是一回事，要實際去用卻是另外一回事：為什麼那些大師可以「化腐朽為神奇」，運用 design pattern 使設計變得更有彈性，而我們常把能用的 pattern 都用上了，不但沒讓設計變簡單，反而讓設計變得相當繁複，要了解它都很困難了，更不用說實作與維護了。〈由招熟漸悟懂勁〉告訴我們設計招式與心法搭配的其中奧妙所在：

設計技巧如何，因人而異，面對相同問題，每個人可能會有不一樣的設計手法，程式寫得愈多，對設計愈有不同的體會，如果你對程式如何解決問題沒有深切的體認，很難設計出彈性及功能兼具的系統。所以以個人的心得來說，業務流程、演算邏輯及程式語言的技巧是招式的運用，而內化的領域知識、OOAD 的分析設計原則、封裝、抽象化乃至於 Pattern 的運用則是心法的展現。這兩者互相反覆搭配、增長。

運用 design pattern 雖然是增加設計彈性的利器，但為了維護這些設計彈性，卻必須付出開發成本，當我們的設計充斥了「沒有用的彈性」時，就會浪費許多無謂的時間與資源，而不會再有足夠時間回應軟體需求的變化，及足夠的空間來容納真正需要的功能。以經濟學的角度而言，設計者須重視設計的機會成本，要為現實需求而設計，避免想太多而造成軟體設計的過度工程化的後遺症，而在設計上充斥著沒有必要的複雜度。以物件導向設計原則而言，抽象性愈高的套件，穩定度就要愈低，否則它就會沒有什麼用處，穩定度愈高的元件，抽象性就要愈低，否則它就會很難被重複使用^[1]。總之，要設計彈性與功能兼具的系統，其實最關鍵的是務實與務虛兩種設計策略能夠相互達到均衡，以達成設計與實作觀點的兩分之形，如下棋般，讓不同觀點皆能發展出最佳的著手。

太強調抽象的設計思維，系統很容易失焦而徧離主題，做出功能不符合客戶需求的軟體；太強調具體的實作而缺少設計，系統會缺乏彈性而難以適應需求的變更，不斷地增加軟體開發的成本與風險。所以設計其實是一種權衡與適應變化的能力，而不應企求設計一次到位，想要以不變應萬變是不切實際的。想當年，克明兄曾針對可迅速維修保養的坦克車提到模組化的思維，有網友回應認為軟體和坦克不同，所以不能相提並論；而我卻認為這是取決於設計的出發點為何，我當時曾提出：

整合並非不可行，重點您是以什麼觀點來看設計。如果您把方便整合的觀念溶入設計中，您會設計減震點（Decouple point），把模組化與差異化的部分巧妙地隔開，這種設計策略就是所謂的延緩策略（Postponement），好處是可能待需求確認後才開始實始生產差異化的部分，而共用的模組則可以重覆使用增加開發績效，縮短開發時間及成本。其實就是所謂的（DFx，Design for xxx），例如克明兄所說坦克的例子就包含了 Design for maintenance 的設計概念。

所以軟體開發能如果做到元件模組化，服務差異化，那整合一點都不困難。可惜大部分的公司都是反其道而行－元件差異化，服務模組化。結果反而造成系統變得更複雜，整合更加困難。

其實不做整合的主要的原因還是市場利基及公司策略方向，如果人家很容易把我整合進去，那我還有什麼搞頭，當然要把系統弄得別人很難整合進去。但標準化，同步工程及整合是不可擋的趨勢，如果忽略它們，那未來將被新的浪潮所淹没。

其實，design pattern 就是一種軟體設計之延緩設計策略的促成技術（Enabling Technique），但設計者也要小心 design pattern 的誤用所造成過度設計會讓設計變得更複雜，這中間該如何拿捏呢？單純地為當下而設計且讓設計儘量簡單吧！Qing 認為：＂建立一個具演化能力的設計，讓這個設計能夠隨時依照可見到的迫切需求，在很短的時間內滿足這個迫切的需求，同時繼續為下一次的演化而做準備。就是這樣，每一次的改變，除了滿足目前的需要之外，同時也為下一次的改變而做準備＂。喲哪桑也說：＂簡單未必容易。為了同時修掉既有的問題、又讓軟體隨著需求而演化，開發者的設計技藝得更純熟，而開發者往往還要更密切地與使用者互動、快速回應、人際溝通要更強。從我經驗來看，這通常是成熟開發者才辦得到。＂。我則認為：＂軟體專案的規劃比較適用於反覆與漸近式開發（IID, iterative and incremental development），它強調用適應性計劃（adaptive planning）來取代預測性計劃（predictive planning），把規劃設計與承諾完成的水準與資訊品質等量齊觀，是一種面對現實的規劃。雖然不做事先的設計，但開發者所做事就是在做設計，一種面對現實的設計，因此軟體設計並不昧於專案現實。＂

喲哪桑認為，設計的簡單策略需要「成熟」開發者才能辦得到，但我覺得成熟這個字容易帶有對某種特定開發能力高下的偏見，所以認為這個詞如果修正為「有紀律」會更為貼切。一個有紀律的開發者必須不斷地專注在面對「現實」，認清問題，用「目前最合適」的解決方法來解決。「現實」代表解答問題的目標是顯而易見的，所以我們可以輕易地寫程式來驗證目標是否真的可以達到；而「目前最合適」則代表我們馬上可以把設計實作出來，並且用先前的驗證程式驗證出來，這就是設計的紀律的具體呈現。而在設計實務上，我則用三種工具來促成設計開發團隊的紀律，那就是：

1. 測試先行，以測試驅動來開發功能。
2. 必要時，在增加功能前先重構。但增加功能時不重構；重構時，亦不增加功能。
3. Daily build，持續不斷整合，確保所開發的軟體是可運作的。

這些工具，都是十分簡易的，設計者並不需要很高的設計能力，但當建立起設計者之紀律時，設計能力會與日俱增，除了能快速回應需求改變化，軟體也會更具有彈性，其實好的設計源自於紀律呀！

Powered by ScribeFire.

1. 抽象性的度量是套件中套件所有類別或界面數量除以抽象類別或界面的數量；而穩定度的度量則是向外關聯性－套件內類別關聯至套件外類別的數量，加上向外關聯性－套件內類別與套件內其它類別關聯的數量，然後再將相加的總合除以向外關聯性。相關內容請參考林昆穎與吳京子譯（2005），《敏捷軟體開發》。

話說當年，同人與夫人度蜜月遊蘇州，蘇州的園林是有名的，另外絲綢也很重要，難得來到蘇州，我們很想買些絲製品送給親友做紀念。

我們逛了拙政園，因為前一天遊杭州就直接坐車到蘇州，並沒有好好的睡一覺，所以我們夫妻倆都覺得很累，精神並不是很好。逛完拙政園之後，有車伕問我們要不要坐他的車遊蘇州。車資不貴，又可帶我們到各重要的景點去看看，而且是難得的經驗，所以我們就讓他帶我們遊蘇州了。

車伕帶我們去看絲綢，看到老婆喜歡，我不忍心掃她的興，但我們所帶的錢實在不多，雖然經過殺價後我認為省一點花應該還夠用，而勉強接受；但事後卻證明我太樂觀了，遊蘇州所需的費用比我想像的還要多，結果許多園林及風景名勝沒辦法進去玩，還有差點擠不上回到上海的火車。還好，最後順利地回到渡假村，但過程卻充滿了驚險。

以管理的觀點來思考問題，任務目標的不同會造成了度量的差異。學長與我都需要及時的資源來完成某件任務，學長的目標是騎車到達目的地，而我的目標則是完成旅行。我們都需要資源來達成目標，然而，所不同的是對資源或時間的限制不一樣，這其實就是日常作業與專案活動的不同，學長提道：

我的目標是避免沒油，不是管理我的油錢，因此我的第三招 – 記錄加油的日期，也就綽綽有餘了。

車子是每天都要騎的，我們不用擔心沒錢加油，而是要擔心油到用時方恨少，一旦沒油卻找不到地方可加油。至於加了油要去那裡，並不是我們管理度量的目標，加油站到處都有，只要有錢就會有油，所以只要在油快用完時找到加油站就不用擔心到不了我們要去的地方。也就是說，日常作業的度量方式大多都不用擔心資源有限性的問題。

旅行就不一樣了，在信用卡未普及的地方旅遊，必須注意你帶的錢是否足夠，所以管理度量的重點在於用最經濟的方式玩遍我們想要玩的地方，但如果我們的錢不夠玩那麼多地方，只好捨棄某些比較不重要的景點，就像那時候我們的蜜月旅行一樣，必須重新規劃我們的旅行路線。這個旅程，我們以前沒走過，就好像專案一樣，具備唯一性及臨時性的特性，而且受到範圍（遊玩的區域、目標與主題）、時程及資源等限制。所以，專案活動的度量方式的重點在於有效控制資源的有限性。

學長提醒我們，要注意我們量的東西回答了什麼問題，達到什麼目標。哈米尼斯也建議拿事實當成數據的驗證來輔助量測。然而，我卻想更具體地提出一個軟體度量的常見迷思－只以工作量當成度量基礎。《人月神話》告訴我們，太樂觀地把工作量與專案成果相提並論很容易陷專案團隊於「焦油坑」之中。進度與預算得確是專案的重要目標，但工作量是估計出來的，估計的百分比還是估計的，所以單以工作量來度量專案進度與預算其實是不夠敏捷亦不夠精實，就算有事實的輔助，也因為發現得太晚而於事無補。

那麼該怎麼辦呢？《溫伯格的專案管理學》告訴我們，把穩軟體的方向在於用穩定而肉眼可見的觀察團隊產出與規劃的落差並採取行動改善現況。所以度量不是喊拍啦拳來預估工作量而是比較可運作的軟體與我們實際花費或預算成本的差別在那裡，進度報告不該只有兩條 S 曲線，除了代表成本與時程的 S 曲線之外，應該還要有第三條代表專案實際產出的 S 曲線。沒有錯，我說的正是如實獲值管理這樣的專案度量工具。但我的訴求重點並不在工具的使用，因為工具是死的，它必須由人來予以活用，這正是重視敏捷與精實的管理態度。如同在旅程中，當我們警覺我們的錢可能帶得不夠時，我和老婆就會商量那些景點對我們具價值與意義，那些景點可以予以捨棄，同樣的狀況也發生在我們的埃及之旅，當我們人在 Hurghada，發現因為天候問題而使到西奈半島的船不開時，要到西奈半島已是不切實際的夢想了，所以只好捨棄 Taba 的渡假村，而改變計劃，到亞斯文並瞻望雄偉的 Abu Simbel 神廟，讓我們花費的金錢與時間與我們的目標（有個難忘的旅程）相聯接，其實做專案又何嘗不是這樣呢？

Powered by ScribeFire.

有些處在這種情況下的 PM，會訴諸於量化一些不需要量化的事物。由於不確定該做什麼，或者害怕去做最需要做的事，他們會以次要事情占據時間。當 PM 與專案之間隔閡變大時，把注意力放在不必要的圖表、資料表、查核清單、以及報告的情形就會增加。PM 在某一時刻開始相信資料流程就是專案，這是有可能的。他們把焦點擺在不重要而容易做的事情上（試算表或報告），而不是重要而難做的事情上（程式設計成果或進度）。他們也許會自欺說，如果照著特定程序執行，然後把查核清單上的事做好，專案就可以保證成功（或者比較嘲諷地說，任何會發生的失敗，技術上都不是他們的錯）。

上述這段話其實並沒有反對軟體專案預測與規劃，Berkun 認為「不要把焦點擺在流程及方法上，專案經理應該把焦點放在團隊上，簡單的規劃和追踪系統當然還是要用，但必須符合專案的複雜度，以及團隊的文化。更精確地講，規劃和追踪應該支援團隊達成專案的目標，而不是設限」。Tom Democro 曾說「沒有度量就沒有控制」，站在管理的角度來看，人們無法管理不能度量的事物。所以在專案管理過程中，軟體度量扮演著重要的角色。這也正如同喲哪桑學長所說的：

聲稱無法評估、不能衡量，只是沒有努力嘗試的藉口。如果你真的想要成長、要進步，要當PRO的工程師、PRO的團隊，你一定要量。

不過，站在務實的角度來看，我們也要小心軟體度量會帶來的數字陷阱。許多專案管理者迷失在軟體度量的數字遊戲中，他們所度量的結果忽略了目標，結果讓專案徧離軌道。其實軟體度量的重要性並不在於準確的預測數字，而是在於軟體開發實事求是的態度。把軟體開發過程都巨細彌遺地表達成數字，用來衡量專案績效，其實並不容易做到，而且很容易讓管理變得很複雜。雖然，理論上，我們可以運用經驗法則找出軟體開發所需的努力拿來做軟體度量，然後再用軟體系統開發控制理論的機械觀點來看軟體專案的進行，只要投入資源就可以把軟體產生出來；但這種論點其實是假設軟體專案開發是線性模式，而忽略其它非線式因素的影響，但這些非線性因素，卻往往是專案複雜度大增以致無法掌控的主因。

我認同學長提到了「要成長、要進步，度量不可少」的看法，但卻想提醒「數字只是表象」，專案團隊必須探索隱藏在數字所透露的訊息。沒有錯，或許對於專案想要開發的軟體，我們只要想量，就一定能量。但量子力學的測不準原理卻告訴我們：在微觀粒子層面，當我們愈清楚知道粒子的位置時，我們就愈不可能知道粒子確切的運動情形。專案軟體開發牽涉複雜的人事變化，所以適用於微觀子層面。於是，當我們花愈多時間想要掌握開發產出時，我們就愈沒有時間掌握開發團隊。軟體度量採用的量測模型只是可以用來解釋我們可以如何來掌控軟體開發的進行（不是唯一）的方式。因此，度量的重點不在於它完全正確，而是在於對你現在的專案團隊完成專案目標是有用的，因此是讓數字來幫助團隊進步，而不是讓團隊照著數字來照章行事。世界上最珍貴的東西其實是金錢與數字所無法衡量的，問題不要只看表面^[1]，所以千萬不要掉入數字陷阱而讓我們忽略問題本質，這也是身為 PRO 的軟體開發人員所必須注意的呀。

Powered by ScribeFire.

1. 這是《小王子》一書中的名句。

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

最新的 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 甚鉅，不可輕忽。

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