“實踐軟體工程”：未來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點的案例願意分享，歡迎與我聯系，我會協助推廣：[email protected]

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

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

包括那些相對不太容易度量的内容比如“團隊穩定性”“财務收入”等。

2. 關于UP（統一過程）和UM（統一模型）的擴充讨論。

U指某些工程實踐互相支撐，完成一個即可支撐另外一個而無需從頭再寫（比如UML中的各種圖之間的關系）。但以往的UP如RUP隻涉及軟體技術工程，而對團隊、績效管理、商業運作較少讨論；UML更是隻提及純技術範疇。正如前述，這些都限制了技術人員在公司中的地位永遠是“幹活的”。對UP/UM的擴充讨論中，将會提到如何內建地管理團隊（結構，層次，績效，擴張，學習……）、研發流程（需求收集、需求管理、需求與技術的映射、需求與代碼的映射……）、财務與客戶（使用者群模組化、使用者模組化、産品線、産品、版本……，這些讨論更多地是商業層面的，而非技術層面的）。有些内容比較晚才會出現。

讨論的結果，旨在建立一種能打通平衡計分卡中四項的管理思路。目前這四項一般分别是四個部門的四種角色管理的（财務=大老闆，客戶=市場/銷售，内部流程=研發人員+品質部，學習與成長=部門經理+人力資源），而互相之間缺少相似的或貫通的思路，是以導緻沖突很多。

本人倒沒有完全想清楚一種模型，而且也認為這種“想清楚且普遍适用的”模型應該不存在，但會提供一些過去6個月思考的結果給大家。

一些常見問題比如“為何面向對象由來已久，但我們公司的軟體複用一塌糊塗？”這類問題，因為它不完全是一個研發問題，還是一個部門管理問題，不是一個技術突破所能解決的。這也正是UP的價值。

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

3. 預測依據

預測結果永遠是不準的，預測前提常常比預測結果更重要，無論對預測者還是旁觀者而言。因為觀察預測前提是否發生，就能對預測結果是否發生及如何發生進行修訂。