「實踐軟件工程」：將來40年軟件工程趨勢預測（一）

關鍵字

實踐軟件工程 軟件工程 互聯網 案例分享 有效性 適用性

前言

筆者認爲「實踐軟件工程」（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點的案例願意分享，歡迎與我聯繫，我會協助推廣：cheny@cheny.com

另：以後的幾篇文章，可能涉及的內容包括：

1. 有效性的基本度量項討論

包括那些相對不太容易度量的內容好比「團隊穩定性」「財務收入」等。

2. 關於UP（統一過程）和UM（統一模型）的擴展討論。

U指某些工程實踐互相支撐，完成一個便可支撐另一個而無需從頭再寫（好比UML中的各類圖之間的關係）。但以往的UP如RUP只涉及軟件技術工程，而對團隊、績效管理、商業運行較少討論；UML更是隻說起純技術範疇。正如前述，這些都限制了技術人員在公司中的地位永遠是「幹活的」。對UP/UM的擴展討論中，將會提到如何集成地管理團隊（結構，層次，績效，擴張，學習……）、研發流程（需求收集、需求管理、需求與技術的映射、需求與代碼的映射……）、財務與客戶（用戶羣建模、用戶建模、產品線、產品、版本……，這些討論更多地是商業層面的，而非技術層面的）。有些內容比較晚纔會出現。

討論的結果，旨在創建一種能打通平衡計分卡中四項的管理思路。當前這四項通常分別是四個部門的四種角色管理的（財務=大老闆，客戶=市場/銷售，內部流程=研發人員+質量部，學習與成長=部門經理+人力資源），而相互之間缺乏類似的或貫通的思路，所以致使矛盾不少。

本人倒沒有徹底想清楚一種模型，並且也認爲這種「想清楚且廣泛適用的」模型應該不存在，但會提供一些過去6個月思考的結果給你們。

一些常見問題好比「爲什麼面向對象由來已久，但咱們公司的軟件複用一塌糊塗？」這類問題，由於它不徹底是一個研發問題，仍是一個部門管理問題，不是一個技術突破所能解決的。這也正是UP的價值。

不過完整的UP實施難度很大，因此咱們會從AUP（Agile UP）入手，理解一個公司最基本的管理過程應該包含哪些內容。

3. 預測依據

預測結果永遠是不許的，預測前提經常比預測結果更重要，不管對預測者仍是旁觀者而言。由於觀察預測前提是否發生，就能對預測結果是否發生及如何發生進行修訂。

原本本文中會包含預測依據，可是限於篇幅沒有寫太多。