關鍵字
前言
筆者認爲“實踐軟件工程”（Practical Software Engineering）將成爲未來40年軟件工程發展的大趨勢。
實踐（Practical）一詞的含義具有雙重含義。
一方面實踐指日後的軟件工程焦點將從知識的完備性、體系性、權威性轉向有效性、適用性。
另一方面它還指日後軟件工程的實踐者而非發明者將擁有更多的話語權乃至主導權，案例分享將取代培訓課程成爲主流的知識獲取途徑。
由於“未來40年”的週期長度甚至超過了國內的軟件業的歷史，更超過互聯網興盛期的歷史，因此要做這麼長期的預測，很多分析依據不能受限於當前的所謂“實際情況”。
軟件工程的新焦點
有效性
有效性指將出現由具體的度量數據或具有統計意義的定性數據支撐軟件工程發展的傾向。
歷來的瀑布模型、CMMI乃至敏捷開發等方法，其傳播往往是由權威機構（或潛在的權威機構）來發動的，並非由一些明確的改進案例來自發產生的。
在CMMI的推廣過程中，實際上有很多SEI的度量數據支持其實際效果，但作爲傳播動力而言，其起到的作用很小。企業採納CMMI多數是基於其權威性直接做出的選擇；SEI亦疏於對其實際效果的度量和監控。當然SEI有理由這樣做：因爲它實際上是美國國防部DOD的下屬機構，其關鍵詞可以理解爲“美國+軍工”，因此並不對“改進全球軟件研發”負有責任。
敏捷開發儘管來自於實踐，但其實際效果卻缺少“實踐性”的度量，多數時候人們都“聽說”敏捷開發很好，“鼓舞了士氣，提升了生產率，提高了質量”，但對具體的數值，基本上一無所知。上次在中國敏捷大會上，一個基本共識是“敏捷開發傳入中國接近10年，但現在還沒有一個企業聲稱自己能被拿出來作爲案例。”
有效性的定義
“我們用得很好”這種含糊的說詞不能被作爲有效性的定義，更爲合理的有效性定義應當包括：
1. 在使用某方法後，團隊或組織的績效得到改善。
2. 在組織內部統計後發現，使用某方法的團隊具備更好的績效。
3. 在行業內部統計後發現，使用某方法的組織具備更好的績效。
有效性應該被從多個方面度量，平衡計分卡可以認爲是一個很好的提示，它指出應該被度量的方面包括：
1. 內部過程層面的提升（內部）
即我們常說的生產率的提升，進度、質量、成本等方面的提升。
內部過程是傳統軟件工程所關注的焦點之一，軟件工程的度量長期以此爲主。這在早期一些技術關鍵行業中是至關重要的，比如航空航天，軍工，銀行等。
但若只關注內部提升是狹隘的，典型的就是若一家普通企業不像上述企業一樣可以聚焦於技術度量，而不得不應對壓力日漸增長的財務、市場、客戶、競爭對手環境，那麼只關注研發過程，會大大削弱研發過程在公司中的地位，進而削弱研發人員在公司中的地位。
2. 學習與提高（內部）
指團隊的擴張性、人員穩定性、能力提升速度等團隊因素。
無論一個過程本身是好是壞，但若無法提供隊員的學習與成長空間，進而形成團隊的擴張，那麼遲早也會出現問題。從這一點上說，無論是各司其職老死不相往來的分工+流程式的重型流程，還是四五個人自己挑選任務+自己說了算+互不干擾的極端敏捷主義流程，都會傷害團隊的學習與成長。
這也是本人力主推廣鬆結對編程和139團隊的原因之一。2001年我所在的團隊至今還是我親自經歷的擴張速度最快、隊員水平提高最多的團隊，鬆結對編程的概念就是源於在這個團隊的經歷。
3. 財務方面的提升（外部）
儘管看起來軟件工程無法直接產生財務收入，但若一種軟件工程缺少與公司收入增加的因果關係，在高層能獲得支持的概率很小。
實際上很多軟件工程都宣稱可以通過更好地把握客戶需求、減少質量成本、縮短工期……等方法來縮減成本和增加收入，但很少看到相關的數據。
多數軟件從業者都逃避對公司至關重要的財務收入責任，又抱怨技術人員在公司的地位不高，陷入惡性循環。在業界平均收入最高的Google，有一個被內部技術人員引以爲豪的重要指標，就是其服務器的運營成本只有業界的50%，而這些運營成本是Google這類公司最大的開銷之一。這裏的程序員和支持人員沒有抱怨銷售和市場人員，而是用自己卓越的技術來證明自己對公司的收入貢獻，進而贏得了自己想要的收入。
4. 客戶（外部）
客戶的滿意度代表了直接從外部觀察到的某種軟件方法的結果。
無論一種方法被團隊或組織認爲好與不好，若客戶認爲不好，則可以整體認爲不好。
比如，無論一種測試方法內部認爲多麼有效，若客戶認爲產品的質量並未提高，那麼這種測試方法就值得懷疑。懷疑的結果未必是推翻它，而是要思考爲何事與願違以及如何改進。
有效性的度量
而且度量結果應該滿足：
1. 這些結果應該具備大致可度量、可比較的量化指標，因此可以用於時間前後或團隊、組織之間的比較。
團隊與組織間的可比較性要求使用某些業界普遍適用的方法，而不是企業自創的。
比如基於功能點的產生的生產率和質量度量就具備可比較性，而基於代碼行、故事點、用例點、頁面數等進行的就難以度量。
2. 儘管受到多種其他因素的影響，但統計學上而言這種方法與更好的績效整體呈現正相關性。
財務方面的提升可以說受到非軟件工程方面的影響很大，但若所有采用某種方法的企業其財務都走了下坡路，那麼無論兩者誰爲因果，都應當進行必要的分析。
比如有一種傳言是“組織越傾向於使用全職的Scrum Master，則企業的效益越可能走下坡路”。雖然這種微觀實踐和宏觀結果之間的關係很弱，但它實際上是“摩天大樓定律”的軟件業版本，即若企業有多餘的錢做多餘的事情時，企業就要開始走下坡路了。
適用性
適用性的定義
早在早期學習CMM（CMMI的前身）的時候，書上就宣稱“在日本，有一家只有3個人的企業也通過了CMM的2級認證”，以論證CMMI適合小團隊。而在學習敏捷開發的時候，也常常看到“用敏捷開發管理500人大型團隊”的案例。這些案例，其實就像沙特動物園飼養了一頭北極熊一樣缺少說服力。這裏要否定的不是沙特動物園有北極熊這件事情，而是在沙漠生態中引入北極熊的問題。
有說服力的適用性定義應當包括：
1. 對某個行業或某類公司而言，這種方法的價值主張與其非常符合。
比如在美國軍工企業實施CMMI，其適用性就很好。在中國互聯網行業實施CMMI，則適用性就堪憂，因爲很難用美國國防部的標準來要求一個互聯網企業，兩者的價值觀有根本的不同。
2. 有數據或共識表明，在具備某個特徵（比如大型團隊）的多數嘗試者中，這種方法被證明利大於弊。
這一條是針對“跟隨者”而說的，日後他們會在看到積極的數據後才做決定，而非像現在一樣盲從很久才發現走錯了路。
3. 在只有少數嘗試者成功的情況中，其跨越門檻的方法具備一定的共性，或至少是可學習的。
這一條是針對“勇於嘗試者”而說的。
很多研發方法在“國內不適用”，原因是文化和管理的差異。不過反過來，國內企業常常把文化和管理差異當作與生俱來的先決條件，從來沒有想過它其實是可以被改變的。
就像有人常常說“我們的甲方一直就是很強勢的，預算從來都不能改動，而需求則總是增加。”其實，我們現在就有辦法嘗試改變這一假設，在40年後更可以。但若總是把它當作一個雷打不動的事實，總是不假思索地問“那你說有什麼辦法”而不是主動思考哪怕1分鐘，這個現狀就很難改變。
適用性的度量
適用性度量大致有兩個途徑。
1. 行業數據的分析
功能點分析是現在唯一擁有確切、大量行業數據的軟件工程方法，ISBSG、IFPUG、SPR、NESMA等都具有大量的有實際使用價值且被廣泛使用的歷史數據，項目數量可能接近五萬個，度量項則大約達到500～1000萬個。
其他的曾經出現過的熱門的軟件工程或相關方法，比如面向對象、UML、CMMI、敏捷開發……儘管實際採用或嘗試的企業數量遠遠超過功能點分析，但可提供分析的數據則正好相反。
未來軟件工程方法的發明者和推動者，應該有義務採集或發起對行業數據的採集，以驗證自己的價值主張是否實現，以及在哪些環境中能更好地實現。若不能或不敢提供相應的數據報告，則很大程度上表明瞭可能信心不足。
Version One一年一度的敏捷調查是用於評估“敏捷開發有效性及適用性”一個很好的嘗試，但這種嘗試其實本來應該是敏捷聯盟的義務，而非由一家軟件公司發起。
2. 行業案例的廣泛分享
案例分享與行業數據相比，這更像是一種定性的分析。
基於當前互聯網現狀及未來數十年潛在的發展，案例分享的聲音將逐漸超過權威機構發佈信息的聲音。這很類似新聞發佈機制的變化：最初是官方報紙，之後變成民間門戶網站，而最後變成微博等多元的信息傳播機制。換言之，未來北極熊的生存情況，將可能不再由動物園發佈，而是北極熊本人發佈。
實際上，現在在網絡上已經有很多支持或反對某種軟件工程方法的聲音，只是還不成熟。多數停留在道聽途說或淺嘗則止之後的感受，較少有堅持嘗試和思考後的聲音。
日後隨着實踐活動的深入，傾聽案例分享將成爲人們獲取知識的主要途徑。而且在嘗試中發現的新的實踐，將成爲未來軟件工程方法的新源頭。與以往大師或大型企業的方法相比，這些新實踐的方法可能不完善且存在問題，但其適用性有保證，學習的門檻也會相對較低。
當很多實踐者在分享相似過程和結果的案例的時候，極有可能表明他們採用了相同的思考方法，一種新的軟件工程方法就誕生了。
實踐案例分享的新趨勢
案例分享由來已久，“實踐軟件工程”中的案例分享與以往常常發生的案例分享有何區別？
實踐軟件工程注重案例的收益而非過程
用《我們推行敏捷開發的過程分享》來命名一個當前的案例足以賺取眼球，但在未來則不行。由於各種軟件工程方法逐一走下神壇，人們逐漸冷靜下來，回到自己追逐軟件工程的起點：我們爲什麼要推廣敏捷開發？
轉變的結果是，下面這幾個案例的名字，將出現在未來40年的搜索引擎緩存中：《我們是怎樣使用1/4業界代碼量編寫相同功能的》《我們是怎樣讓24個月的項目按期完成的》《我們是怎樣把成本控制在計劃的5%的》《我們是怎樣將延期項目個數控制在10%的》
新的案例都宣揚了一個可度量的或至少很容易達成共識的有效性收益，並以一個實際的案例而非“可能有效”的方法來支撐。
案例中實現收益的方法或許是一個有名字的過程比如“敏捷開發”，也可能什麼都不是，但人們追求收益的動力將大於過程。
曾經有一羣實踐者要寫一本“敏捷開發案例集”，一個重要問題就是“什麼是敏捷開發，哪些案例可以收集進來？哪些則不行？”筆者的主張最後被採納，包括：
1. 必須是一個真實的案例
2. 必須是一個有收益的案例
3. 大致與敏捷開發沾邊即可，不沾邊其實也可
因爲若我們執着於是否敏捷而放棄某些有益的案例，那麼我們應該修改書的名字。
實踐軟件工程注重單點收益而非完整過程
由於軟件開發的多元化和快速變化，將導致很難完整實施某種方法。
比如現在很多微型公司正在爲蘋果和Google開發手機應用，甚至很多大受歡迎的軟件產品都是業餘時間開發的；未來每10年可能都會出現與之前截然不同的開發方法。這將導致軟件工程的發展遠遠跟不上軟件開發本身的發展。
開發者與其等待一種爲自己量身定製的完整過程，不如基於自己的需要單點突破。這時候就更會接受具備與自己相同價值觀的案例，而不是一種號稱神奇而實際上鮮有人試驗成功的複雜方法。與後者相比，前者有實際收益的先例，而且實現的困難也被證明不是不可逾越的。
當然有案例和一定能模仿還有距離，最後一節將做總結性介紹。
未來案例的呈現方式
前段時間與麥思博（MSUP）的劉總討論Top100 Summit 軟件開發案例徵集活動，下面是我當時的建議（略有擴充）。這些建議在一定程度上是本文的總結，也補充了幾個沒有談到的地方。
1. 案例名稱或主題必須具備1條鮮明的收益，而不是泛泛而談
比如《我們是怎樣使用1/4業界代碼量編寫相同功能的》就是一個好名稱，而《我們是怎樣提升軟件開發過程的》則相反。
另外如果有多條收益，與其泛泛羅列，不如把一條講透。
2. 案例必須基於可度量的指標
比如不能說“實現了敏捷開發後，我們的研發進度大大加快了”，因爲這可能只是短迭代造成中間產品速度；但可以說“實現了敏捷開發後，我們的交付週期從10個月每個版本縮短到3個月”。同樣前面代碼量的案例也不能說“我們編寫了大量可複用的函數和類庫”，而必須提供有共識的度量結果，比如“我們使用1/4的業界代碼量編寫了相同的功能”。
3. 案例必須說明獲得收益的具體方法
比如不能說“敏捷開發激勵了員工積極性，產生了更高的質量”，而要說“實施了……制度後，用戶反映的缺陷率降低了50%”。
4. 案例必須說明曾經試驗過的其他方法及未來的考慮
我力薦《硝煙中的Scrum與XP》一書的原因就在於此。作者顯然沒有淺嘗則止就草率寫出了這本書，而是在真正實踐和思考後，把中途走過的彎路、沒走過的岔路都加以描述，還對未來前面的路做了預測。
如果世界上和中國有大量的這種深度的實踐者，實踐者掌握話語權的時代就不遠了。
另：若您有符合以上4點的案例願意分享，歡迎與我聯繫，我會協助推廣：[email protected]
另：之後的幾篇文章，可能涉及的內容包括：
1. 有效性的基本度量項討論
包括那些相對不太容易度量的內容比如“團隊穩定性”“財務收入”等。
2. 關於UP（統一過程）和UM（統一模型）的擴展討論。
U指某些工程實踐互相支撐，完成一個即可支撐另外一個而無需從頭再寫（比如UML中的各種圖之間的關係）。但以往的UP如RUP只涉及軟件技術工程，而對團隊、績效管理、商業運行較少討論；UML更是隻提及純技術範疇。正如前述，這些都限制了技術人員在公司中的地位永遠是“幹活的”。對UP/UM的擴展討論中，將會提到如何集成地管理團隊（結構，層次，績效，擴張，學習……）、研發流程（需求收集、需求管理、需求與技術的映射、需求與代碼的映射……）、財務與客戶（用戶羣建模、用戶建模、產品線、產品、版本……，這些討論更多地是商業層面的，而非技術層面的）。有些內容比較晚纔會出現。
討論的結果，旨在建立一種能打通平衡計分卡中四項的管理思路。當前這四項一般分別是四個部門的四種角色管理的（財務=大老闆，客戶=市場/銷售，內部流程=研發人員+質量部，學習與成長=部門經理+人力資源），而相互之間缺少相似的或貫通的思路，因此導致矛盾很多。
本人倒沒有完全想清楚一種模型，而且也認爲這種“想清楚且普遍適用的”模型應該不存在，但會提供一些過去6個月思考的結果給大家。
一些常見問題比如“爲何面向對象由來已久，但我們公司的軟件複用一塌糊塗？”這類問題，因爲它不完全是一個研發問題，還是一個部門管理問題，不是一個技術突破所能解決的。這也正是UP的價值。
不過完整的UP實施難度很大，所以我們會從AUP（Agile UP）入手，理解一個公司最基本的管理過程應該包含哪些內容。
3. 預測依據
預測結果永遠是不準的，預測前提常常比預測結果更重要，無論對預測者還是旁觀者而言。因爲觀察預測前提是否發生，就能對預測結果是否發生及如何發生進行修訂。
本來本文中會包含預測依據，但是限於篇幅沒有寫太多。