1. 程式人生 > >軟體研發是高科技嗎?

軟體研發是高科技嗎?

軟體研發是高科技嗎?


摘要
本文闡述了兩個觀點,一是對軟體的需求已經遠遠超過軟體的供給能力,二是目前的軟體研發模式遠遠夠不上高科技的名聲,換言之,目前的軟體研發流程不是高科技,企業IT主管需要採取策略改進軟體研發流程,從而提升開發效率。

目標讀者
企業和機構的CIO/CTO,主管科技的政府領導

任何一位政府高官或者企業高管都會告訴你,我們正在經歷一個激動人心的資訊文明時代。資訊科技和通訊技術的飛速發展,使得整個人類社會處於一個資訊化、網路化、智慧化的變革之中。各種新興的技術日新月異,令人目不暇接。一方面,它們促進了生產效率的提高和社會關係的改善,另一方面,它們也帶來了新的問題和新的矛盾。

對於企業和機構的CIO/CTO來說,資訊科技的發展使得CIO/CTO在企業和機構裡的角色越來越重要,企業和機構越來越依賴科技部門的力量來提升組織的工作效率,為客戶提供體驗更好、功能更豐富的產品和服務,並由此保持市場競爭的優勢。

今年6月,微軟以75億美元收購程式碼託管平臺GitHub。 GitHub上面有8500萬個程式碼庫(也可稱為軟體專案),2800萬名開發人員在GitHub上進行協作開發。當微軟執行長 Satya Nadella 談到為什麼要收購GitHub時,他說,“現在每一家公司都是軟體公司,開發人員是這個‘新時代’的建立者,他們在為整個世界編寫程式碼,而 GitHub 是他們的‘家’”。

有趣的是,2017年有將近70萬來自中國的新使用者在GitHub上註冊。

2017年GitHub新註冊使用者的地理分佈

微軟看到了世界對軟體開發人員的巨大需求,因為世界對軟體的需求已經遠遠超過軟體的供給能力

全球權威的IT研究與顧問諮詢公司Gartner預測,到2021年,全球市場對應用開發需求的增長比相應的研發能力的增長快5倍以上

有人說,人工智慧的發展將導致對開發人員的需求大大減少,因為一些原來需要開發人員手工程式設計的任務可以由人工智慧代替。這種說法不無道理,但是它沒有看到有大量新的應用場景需要更多的開發人員。

軟體的需求增長有幾方面的原因。第一,新興技術層出不窮,移動網際網路,大資料,雲端計算,人工智慧,增強現實/虛擬現實, 3D列印,區塊鏈,物聯網等技術在較短的時期內集中湧現,另外,晶片、儲存等硬體的效能不斷提升,使得企業急於採用這些最新的資訊科技成果以期在市場上獲得競爭優勢。第二,新興的商業模式不斷湧現,比如O2O,眾籌,眾包,P2P,共享經濟,等等,使得市場上出現了大量採用新型商業模式的初創企業,它們不斷蠶食傳統企業的市場並創造新的市場,而這些新型的商業模式都需要全新研發的業務系統來支撐。第三,也是最根本的原因,是整個社會正在經歷一場深刻的數字化變革,傳統企業、機構和政府都在向數字化轉型,大量線下的業務元件和業務流程都在往線上轉移,這些自然都離不開軟體

精確計算和預測全社會對軟體的需求是非常困難的,這類統計資料很少,下面舉的例子是美國軍方的。雖然軍用軟體和民用軟體有很大的不同,而且美國的情況與中國的情況也有所不同,但是畢竟這是一份難得的、公開的研究報告,可供參考。

2017年美國國防部資助的一項研究分析了美國國防部對軟體的需求與供給的關係。研究報告顯示,美國國防部軟體需求的增長在15%~25%之間,也就是說每3-5年新增軟體體量增加一倍

美國國防部軟體需求預測

這張表上顯示的是每年新增的程式碼量(美國軍方的程式語言主要是Ada),並不包括需要維護的老程式碼。新增的程式碼分為兩類,一類是針對老系統編寫的維護性程式碼,一類是為全新系統編寫的程式碼。

這是軟體的需求,那麼軟體供給的情況又如何呢?供給側主要包含兩個因素,開發人員人數的增長和開發人員平均生產力的增長。根據歷史統計資料,假設加入美國國防部專案的軟體開發人員每年增長5%,平均生產力每年增長4%(兩者都是最樂觀的假設), 逐年的軟體生產能力預測如下圖所示(圖中的綠色曲線):

美國國防部軟體需求與供給預測

可見在2017年美國國防部已經無力同時維護老程式碼又開發所有想開發的新程式碼了。到2020年,根據軟體需求預測,美國國防部需要29萬名軟體開發人員,但實際上開發人員總數只能達到13.5萬人,還不到總需求人數的一半。

那麼,軟體需求的旺盛與供給的不足之間的矛盾如何解決呢

明顯的解決方法有三種,第一是控制需求,這顯然是行不通的,在充分競爭的市場上先進技術就是競爭優勢,在條件允許的情況下,沒有哪個企業不願意以最快速度採用先進技術來超越對手。

第二是擴大軟體就業人才基數,這跟整個社會的大學教育和職業教育有關,不是哪個單獨的企業或者機構能夠在短時間內改變的。另外,增加開發人員意味著人力成本的增加,而企業IT專案的預算又是越來越緊張的,花更少的錢在更短的時間裡開發出更多的軟體已經是軟體專案的常態了。

剩下的第三個選擇就是提升軟體研發的效率。模組化開發,敏捷開發,整合開發工具,團隊協同工具,自動測試工具,等等,這些在提升軟體研發效率上都起到了很好的作用。但是我們做的還遠遠不夠,就像上面Gartner所預測的和美國國防部研究報告所指出的那樣,軟體開發效率的提升遠遠趕不上對軟體的巨大需求。

那麼,問題出在哪裡呢

讓我們來重新審視軟體開發的整個過程。事實上,軟體開發流程並不像我們大多數想象的那樣是很高科技的,相反地,軟體程式設計大部分還是非常傳統的手工作坊式的工作,耗時,瑣碎,大部分時間裡個人獨立工作,需要高度集中精力,經常會有缺陷。

如果你把軟體程式設計跟真正高科技的行業,比如汽車製造業,相比的話,兩者之間的差別就非常明顯了。在汽車製造業,首先設計出一個概念車的數字化藍圖,這個藍圖可以以各種方式來呈現這輛概念車,甚至可以讓這輛車去碰撞一棵虛擬的樹來測試車的安全效能,這些都是在真正的樣車生產出來之前就可以完成的。當各種測試都完成,並且所有相關方都滿意的時候,這個設計藍圖會連線到一條長長的機器人生產線,進入車的量產階段,在這個生產線上,自動化程度高的驚人,需要人工參與的地方很少。

汽車生產線

如果拿軟體開發過程與汽車生產過程相比,軟體開發過程落後汽車生產過程70年。軟體開發過程首先是需求分析和產品設計,其結果是一疊厚厚的文件(一般稱作產品需求文件),上面描述了產品應該長什麼樣以及它應該有的所有功能。然後,這疊厚厚的文件交給了使用者,由使用者進行確認。使用者確認以後,一批程式設計師根據這些文件編寫程式碼,完成文件上面所要求的功能。最後,再由使用者執行軟體,驗證文件上面的所有功能都完全按照要求實現。

首先,產品的需求文件離真正意義上的藍圖還差得很遠,第二,沒有一種機制讓這個需求文件在接下來的開發流程中被嚴格的遵守,這就導致在產品完成以後,仍然需要使用者再一次通過執行軟體來驗證所有的需求。由於產品需求文件並不是真正意義上的藍圖,其間有很多模糊的、容易造成歧義的地方,再由於整個開發流程無法保證嚴格遵守產品需求文件,生產出的產品與使用者的真正需求之間不免產生各種差異,結果造成軟體的多次修改。第三,由於有人工的大量參與,由於整個流程的自動化程度較低,軟體產品的質量無法達到理想的狀況。

那麼,有什麼更好的軟體開發流程呢?敬請關注本系列的後續文章。