在這個行業(yè)里混跡了很多年，最近這幾年我一直在想個問題：軟件到底是什么？應該歸類為——科學？工程？還是藝術？
　　最近看了西班牙軟件專家Albero先生在MetricView雜志上的一篇文章——《敏捷與功能規(guī)模》，開篇就說道：盡管軟件行業(yè)總是能夠發(fā)明和創(chuàng)造一些新的技術，但是歸根結(jié)底可以將其歸屬為藝術。比爾蓋茨也曾經(jīng)說過：軟件是藝術與工程的偉大結(jié)合。
　　這篇文章給了我很多啟示，我大致地給國內(nèi)的朋友們介紹一下，并不會完全依賴于原文，同時也會夾雜一些我的感想。                                                                                   
　　怎么體現(xiàn)軟件的藝術性呢？假設，有兩個軟件產(chǎn)品擁有相同的功能，表面上看來沒有差別，但是內(nèi)涵卻截然不同，肯定其中有一個的性能更好；維護費用更低；用了更少的代碼行；有更少的缺陷和風險?？傊幸粋€軟件相比較會做得更加“藝術”。
　　軟件是否藝術，取決于以下幾個因素：
　　開發(fā)團隊的技術知識；需求的質(zhì)量；開發(fā)團隊和管理團隊的“常識（common sense）”。
　　在英文世界里，common sense，是個魔力詞組。從公元前300多年，亞里士多德就開始思考，直到2000多年后的今天，很多人還是不能夠理解其哲學思辨。

　　這幾項要求有時候很簡單，有時候也很難實現(xiàn)。
　　如果在開發(fā)的過程中，團隊從技術視角來做決策和行動、存在狹隘的利益沖突、缺乏知識、存在大量的灰色概念。軟件產(chǎn)品很有可能就淪落“平庸”。
　　這一點，其實國外的專家講得還比較“樂觀”，在國內(nèi)，我們經(jīng)?？梢钥吹?ldquo;這根本不是我想要的”場景。盡管這些軟件已經(jīng)“發(fā)版、上市、交付、驗收”了，但是從某種意義上來講，它們甚至都不能被稱之為產(chǎn)品。
　　很有挑戰(zhàn)性，也很有必要，我們要升級自己的觀念，那就是要給“常識”增加一個定語——“卓越的常識（common sense excellence）”。
　　其中一個卓越的常識，其實在國內(nèi)也不陌生，那就是要將目標SMART化。
　　軟件開發(fā)和管理團隊的目標——給用戶、客戶提供質(zhì)量最好的產(chǎn)品；客戶（外部客戶，或者是內(nèi)部客戶）的目標——以最好的價格收獲最大的價值。
　　這些目標就需要SMART(Specific明確，Measurable可度量，Achievable可實現(xiàn)，Relevant相關性，Time bound時限性)。
　　其中的這個M，就是度量，是一切科學管理的基礎。這也是本文所要講述的重點。
　　那么我們應該度量什么呢？
　　 IT項目只是個“一次性”的過程——我國有很多的PMP，對這個常識應該是不陌生。而IT的產(chǎn)品才能夠給客戶提供戰(zhàn)略價值，或改善流程（更快、更便宜）。
　　所以，我們應該度量、監(jiān)控的目標應該是產(chǎn)品，而不是項目。這個常識，國內(nèi)了解的可能還不多。

敏捷——項目管理領域里春天的故事

　　2001年的2月中旬，在美國猶他州的“雪鳥”滑雪場，17位軟件開發(fā)的思想者（thinkers）發(fā)表了著名的《敏捷宣言》。其全稱應該是“敏捷軟件開發(fā)的宣言”。
　　這個敏捷宣言，也是一個“卓越共識”?？偹苤岳锇耸l“原則”。
　　仔細分析這些原則，其本質(zhì)也是要強調(diào)：給客戶提供價值。（我們的最高優(yōu)先級就是確?？蛻魸M意——通過盡早并持續(xù)地交付有價值的軟件）產(chǎn)品一定要滿足用戶真實的需要（needs），要做正確的事情，同時也要正確地做事，在所有的層面都要步調(diào)一致……
　　從“卓越共識”的角度來看，這個宣言其實并沒有什么新意。但是有時候，尤其是我們困惑于的項目具體問題中，這些語句還是能夠給我們指南的。
　　無疑這些年來，敏捷給項目管理領域帶來春天。國內(nèi)也是有越來越多的企業(yè)在嘗試。但是其給我們帶來的價值，很少有組織能夠度量、統(tǒng)計。
　　這里還是要插一句，我以前看到的一個數(shù)據(jù)是：美國著名的IT咨詢公司——Standish，從1996年開始，在每年的報告中都發(fā)布關于項目成功率的統(tǒng)計信息，在隨后持續(xù)超過20年的時間內(nèi)，雖然IT技術以及軟件工程方法日新月異，但IT項目的成功率一直徘徊在40%左右。也就是說，敏捷并沒很好地拯救IT項目管理領域。

要清楚4個概念

　　我們一定要清楚地分清兩個概念：項目、產(chǎn)品，并且分別對其進行正確的管理和度量。盡管這個管理思想本身很簡單，但是無論是大公司還是小公司，也無論中外，在實踐中做得都不是很好。幾乎所有的度量工作都集中于項目，甚至是合同。
　　客戶要實現(xiàn)一個IT解決方案、產(chǎn)品、或者是增強包，可以與開發(fā)團隊簽署不同類型的合同（固定總價，單價，成本加成）。而開發(fā)團隊既可以選擇瀑布模式，也可以進行敏捷。所有這些工作都不會影響到最終產(chǎn)出物——產(chǎn)品。
　　只有IT產(chǎn)品，才能過為客戶提供價值，并且核算最終的“有形成本”（可能包括了多個項目、多個合同、多個供應商、多個開發(fā)團隊的費用）。
    另外兩個重要的概念就是：工作量與規(guī)模了，對于這兩個概念就很少有人混淆了。也許是因為兩者之間的相似性很小，當然了，很多人都會有個誤區(qū)——認為規(guī)模越大工作量越大，反之亦然。
　　無論是國外，還是國內(nèi)，幾乎所有的項目都會管理工作量，但是很多項目都不會去管理、度量規(guī)模。

　　在敏捷中，經(jīng)常使用“故事點”來度量規(guī)模，并計算軟件開發(fā)的工作量。故事點方法最大的問題就是太“隨心所欲”（arbitrary）——從某種意義上來講，這也是此方法的優(yōu)點，相比較于“功能點”方法，學習成本、制度的管理成本要低很多。
　　但是，也正是由于這個特點，同一個公司的兩個不同團隊，對于同一個故事，會估算出不同的故事點數(shù)量。盡管如此，這種方法對于獨立的故事而言，還是能夠起到估算、計劃、跟蹤的作用。
　　國際著名的軟件工程專家Caper Jones曾經(jīng)總結(jié)出“軟件度量的十三條準則”，故事點方法最多只能滿足其中的四條。這個方法不能標準化，非常含糊其辭（容易引發(fā)歧義），不足以發(fā)布組織級的數(shù)據(jù)（例如：生產(chǎn)率），不適用于其他的新項目或歷史項目，不能轉(zhuǎn)換為其他相關的度量數(shù)據(jù)，不能適用所有的產(chǎn)出物，不能夠支撐所有類型的軟件，也不支持重復使用。
　　無論是敏捷的度量，還是傳統(tǒng)的度量，都可以為我們打開“產(chǎn)品度量”的大門。如此度量得出的數(shù)據(jù)，可以作為其他戰(zhàn)略性度量的基礎。
　　相同的IT產(chǎn)品其“規(guī)模”肯定也是相同的，而不管是其創(chuàng)造的過程是敏捷，還是瀑布。也不管是用什么的合同類型。如果有可能，我們倒是可以做個對照試驗，用不同的項目管理方式打造相同的IT產(chǎn)品，比較不同項目的進度、成本、質(zhì)量等特性指標。